From nobody Wed Mar 1 07:52:20 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB931294E3 for ; Wed, 1 Mar 2017 07:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3VOKwy8dDwu for ; Wed, 1 Mar 2017 07:52:17 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EC91295A7 for ; Wed, 1 Mar 2017 07:52:17 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id u48so33232912wrc.0 for ; Wed, 01 Mar 2017 07:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=sArgCTQYRhvBJJi2MivuLEPrwI1josALOcKfVx/7hCs=; b=I8IOhYdcRpcbJeUdzume64StMR2FnMTh34BgmojAOphhAlaDoVlMVVgY4Cbue+nTb9 1DR03/IjfMVrhh1yJB/C7Dn8Si8HPLamaJ83tPEm8ZrcMmA8AcXut7XvdNxlqbsz0Lf8 0vetRJi065Yyhp8P6VAw00uS+Qhw/C0FsJ6wqaSMBChYZlS6lPAHiZ4Upzv17ka3+Oi2 0BNuP9jc/1PRVJCDGheWS5dJ+o8w2vnWk+Kmo5RHf8vOIrPibbPkttstKm9lmoDsZhko bsSkOdM5Jc6HScSTl1pfmaWtX6XZwnRzgjFT53sa6awWBt/bNpR25lmCioVqQGew5Rkf 5zpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=sArgCTQYRhvBJJi2MivuLEPrwI1josALOcKfVx/7hCs=; b=F1W8NH00fBG24GNG/OG9za7Ref/f+dXcEof6kKzZReDI/i+r7WytA1aztdRNPY3Upm w7krzx+cygrMB3Wldv3QrRpR1GgCZJuxfG8xRDNLUW/RwQpEUX0aMmfcke6EXFojbqbs bBr/2bA8guqaFZMp7Spx5zz58EhPCEvEaMmWdRVb8zZtTW87UTRen8dADC1g5kWxArqE +qTFSOb4DHMDkJM6r+6TZdO+itngl87mz+NlIxpnRPlVFFj2bwuVhFprD5idVDrOrUs8 qwDJjF+0zzcj0WeMMmbS2mUI2TBH7+4CYUgSTKpkyQUt/CM9XBgy3SU2fZ5mHb/xixe+ M9hQ== X-Gm-Message-State: AMke39kIFQxvijyGhaTl56h231Y0NYx0YUfAz/abxXzPN2KNKuHTJfkG9Fph8L1lP7nIag== X-Received: by 10.223.146.195 with SMTP id 61mr670589wrn.91.1488383535820; Wed, 01 Mar 2017 07:52:15 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id 40sm7129621wry.22.2017.03.01.07.52.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 07:52:14 -0800 (PST) From: "jouni.nospam" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Wed, 1 Mar 2017 07:52:12 -0800 To: dime@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Dime] IETF important dates X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:52:19 -0000 Folks, Just a reminder.. 2017-03-01 (Wednesday): Cut-off date for requests to reschedule Working = Group and BOF meetings UTC 23:59. 2017-03-03 (Friday): Final agenda to be published. 2017-03-13 (Monday): Internet Draft submission cut-off (for all drafts, = including -00) by UTC 23:59, upload using IETF ID Submission Tool. 2017-03-15 (Wednesday): Draft Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. 2017-03-17 (Friday): Early Bird registration and payment cut-off at UTC = 23:59. 2017-03-20 (Monday): Revised Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. 2017-03-20 (Monday): Registration cancellation cut-off at UTC 23:59. 2017-03-24 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local meeting time. 2017-03-26 - 2017-03-31: IETF 98 in Chicago, IL, USA= From nobody Wed Mar 1 22:54:05 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 583511293E3; Wed, 1 Mar 2017 22:54:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Shucheng LIU To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148843764035.7093.4978052381971422851.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 22:54:00 -0800 Archived-At: Cc: draft-ietf-dime-load.all@ietf.org, dime@ietf.org, ietf@ietf.org Subject: [Dime] Review of draft-ietf-dime-load-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 06:54:00 -0000 Reviewer: Shucheng LIU Review result: Has Nits Hi all, I have reviewed draft-ietf-dime-load-07 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. “This document defines a mechanism for conveying of Diameter load information. RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information.” My overall view of the document is 'Ready with nits' for publication. ** Technical ** No. ** Editorial ** *Section 4, page 4 >That is, the OLR requests that the reacting node reduce the offered load……. s/reduce/reduces * Section 4.1, page 5: >The fundamental difference is that an overload report requires that reduction. What does the second “that” refer to? It may change to “The fundamental difference is that an overload report requires the reduction of offered load”or so. * Section 5, page 10: >For the PEER load report, C follows the same procedure as A1 for determining if the Load report was received from the peer from which the report was sent and, when finding it does, stores the load information for use when making future routing decisions. This sentence may need to split for more readable purpose. * Section 5: Full name of *AVP* should be put into Abbreviations before using first time. From nobody Fri Mar 3 12:44:17 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4633129602 for ; Fri, 3 Mar 2017 12:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 z474dYmYRc7u for ; Fri, 3 Mar 2017 12:44:14 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C321295C3 for ; Fri, 3 Mar 2017 12:44:14 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Fri, 3 Mar 2017 15:44:13 -0500 From: Dave Dolson To: "dime@ietf.org" Thread-Topic: RFC4006bis: new Redirect-Address- AVPs should be using Address type Thread-Index: AdKUXunPJzY/F+KYRAKbZLrfl7IkQA== Date: Fri, 3 Mar 2017 20:44:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E987053443Dwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Address type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:44:16 -0000 --_000_E8355113905631478EFF04F5AA706E987053443Dwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft of RFC4006bis (https://tools.ietf.org/id/draft-ietf-dime-rfc4006b= is-01.txt) introduces new AVPs Redirect-Address-IPv4Address and Redirect-Address-IPv6A= ddress. These are currently defined as textual. I.e., "dotted decimal" and "RFC5952= ". I would like to propose these instead be defined to use the more compact an= d less ambiguous binary address format. Specifically, I would like to ask this group if these two fields can be con= solidated into one field, Name: Redirect-Address-IpAddress Type: Address, per https://tools.ietf.org/html/rfc6733#section-4.3.1 -Dave --_000_E8355113905631478EFF04F5AA706E987053443Dwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft of RFC4006bis (https://tools.ietf.org/id/draf= t-ietf-dime-rfc4006bis-01.txt)

introduces new AVPs Redirect-Address-IPv4Address and= Redirect-Address-IPv6Address.

These are currently defined as textual. I.e., “= ;dotted decimal” and “RFC5952”.

 

I would like to propose these instead be defined to = use the more compact and less ambiguous binary address format.

 

Specifically, I would like to ask this group if thes= e two fields can be consolidated into one field,

Name: Redirect-Address-IpAddress

Type: Address, per https://tools.ietf.org/html/rfc6733#section-4.3.1

 

 

 

-Dave

 

 

--_000_E8355113905631478EFF04F5AA706E987053443Dwtlexchp1sandvi_-- From nobody Fri Mar 3 12:44:26 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43C12961E for ; Fri, 3 Mar 2017 12:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 qwzHH2cL6efC for ; Fri, 3 Mar 2017 12:44:19 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1307412961C for ; Fri, 3 Mar 2017 12:44:19 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 3 Mar 2017 15:44:17 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Fri, 3 Mar 2017 15:44:16 -0500 From: Dave Dolson To: "dime@ietf.org" Thread-Topic: RFC4006bis: Using IPv4-mapped-IPv6 addresses in Redirect-Address-IPv6Address Thread-Index: AdKUXAYmPpa31PbRRT2PgzfhwBRZTw== Date: Fri, 3 Mar 2017 20:44:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870534445wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: [Dime] RFC4006bis: Using IPv4-mapped-IPv6 addresses in Redirect-Address-IPv6Address X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:44:21 -0000 --_000_E8355113905631478EFF04F5AA706E9870534445wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been reviewing https://tools.ietf.org/id/draft-ietf-dime-rfc4006bis-01= .txt One thing I noticed is that nothing is said about whether it is acceptable = to use IPv4-mapped-IPv6 addresses in IPv6 AVPs. https://tools.ietf.org/html/rfc4291#section-2.5.5.2 Briefly, an IPv6 address like ::ffff:c000:201 (also written ::ffff.192.0.2.= 1) is used to represent an IPv4 address. This simplifies the number of AVPs required, simplifies software, and makes= IPv6 a first-class citizen. I'd like to ask this group if we can add language to explicitly permit ipv4= -mapped-ipv6 addresses in RFC4006bis. -Dave --_000_E8355113905631478EFF04F5AA706E9870534445wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been reviewing https://tools.ietf.org/id/draft-ietf-dime-rfc4006bis-01.txt<= /p>

 

One thing I noticed is that nothing is said about wh= ether it is acceptable to use IPv4-mapped-IPv6 addresses in IPv6 AVPs.=

https://tools.ietf.org/html/rfc4291#section-2.5.5.2

 

Briefly, an IPv6 address like ::ffff:c000:201 (also = written ::ffff.192.0.2.1) is used to represent an IPv4 address.<= /p>

This simplifies the number of AVPs required, simplif= ies software, and makes IPv6 a first-class citizen.

 

I’d like to ask this group if we can add langu= age to explicitly permit ipv4-mapped-ipv6 addresses in RFC4006bis.

 

 

 

-Dave

 

--_000_E8355113905631478EFF04F5AA706E9870534445wtlexchp1sandvi_-- From nobody Fri Mar 3 16:01:06 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE97129671; Fri, 3 Mar 2017 15:55:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533411.15846.11488691380701974535.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:34 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] dime - Requested session has been scheduled for IETF 98 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:34 -0000 Dear Jouni Korhonen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dime Session 1 (1:00:00) Friday, Afternoon Session I 1150-1320 Room Name: Zurich D size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Diameter Maintenance and Extensions Area Name: Operations and Management Area Session Requester: Jouni Korhonen Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 150 Conflicts to Avoid: First Priority: detnet tsvwg tsvarea quic iccrg Second Priority: 6man v6ops intarea People who must be present: Stephen Farrell Lionel Morand Jouni Korhonen Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sat Mar 4 01:18:30 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF3129469 for ; Sat, 4 Mar 2017 01:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6elyet0wWEy for ; Sat, 4 Mar 2017 01:18:27 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D220129411 for ; Sat, 4 Mar 2017 01:18:27 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Sat, 4 Mar 2017 04:18:25 -0500 From: Yuval Lifshitz To: Dave Dolson , "dime@ietf.org" Thread-Topic: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Address type Thread-Index: AdKUXunPJzY/F+KYRAKbZLrfl7IkQAAaAwMg Date: Sat, 4 Mar 2017 09:18:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.132.4] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Address type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 09:18:28 -0000 Hi Dave, I think this makes sense. Reason I added these a UTF8 is to enable easier t= ransition from the existing Redirect-Server-Address which is UTF8) to the n= ewly proposed Redirect-Address-IPv4Address and Redirect-Address-IPv6Address= AVP. However, since there are new AVPs, not part of a standard yet, it is probab= ly good time to change them. Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Friday, March 03, 2017 10:44 PM To: dime@ietf.org Subject: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Addr= ess type The draft of RFC4006bis (https://tools.ietf.org/id/draft-ietf-dime-rfc4006b= is-01.txt)=20 introduces new AVPs Redirect-Address-IPv4Address and Redirect-Address-IPv6A= ddress. These are currently defined as textual. I.e., "dotted decimal" and "RFC5952= ". I would like to propose these instead be defined to use the more compact an= d less ambiguous binary address format. Specifically, I would like to ask this group if these two fields can be con= solidated into one field, Name: Redirect-Address-IpAddress Type: Address, per https://tools.ietf.org/html/rfc6733#section-4.3.1=20 -Dave From nobody Mon Mar 6 11:23:14 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC0112997D for ; Mon, 6 Mar 2017 11:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goO8kfNzfUOc for ; Mon, 6 Mar 2017 11:23:12 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2BF1298BF for ; Mon, 6 Mar 2017 11:23:12 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id p64so52068684qke.1 for ; Mon, 06 Mar 2017 11:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=SaUpeyzRfjGOaEiaqje3Xfo8vVpxIdHnODKA8jS4QWk=; b=G3fIIi5BcB+yWuhwa86AbLTBSYKdDmvp6AqKbbg1Ndo76CXjitKnbWRzo69E9WwOEs bNwJerIce/PxcadgBQ47t55l+e5+Et4p6r/rrOetkRl89SkWR6FBrugm3ocyFFB8MKAG kQcNAYRLM7kLdTJlqrCmctZ4uAs4SNhYGk+P88ZaComAtFz4JSUQ6mxsLlROM2EhppyA u+TfjQ5WA1B21s80lX2sYGZZuIZr9Yz74aIZkat62Mtp70VG0/Ltk9qErPl1mBXRafbi Xx8j1d4QJ3nHPV6wyg5o7xgYP5Jsx3f5za+LuFT7E0CVzi1YlOOQ0J0y8kL7VE2+CXbi 5+eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=SaUpeyzRfjGOaEiaqje3Xfo8vVpxIdHnODKA8jS4QWk=; b=GC0MO6rXHLoSBmZqVQzRGcqe6yjuX0iaKaovhkZktBHZ0iCWjzcJ3qlArE74Jz03jK 3e/y4Qb39mJTcld+gCkkq+dYkvrfJd2nJ7HFi5DPKFI936wsvDp13zwNR/M+fHMzBocN M2LVOaw6IuEeu3BbU+FxCVL3LwW1p0n+GMP6HQWUkW/5gn0kXQrwvxzFNd3C4h0TLS35 qz+NbQR6R6vj7KPTUBLpz496jT4VsRSJNcx+5KY80Y+BRB9LsSRhl0fSJd/eUlJG0pSC kc0sp2kzzsOjQ7fkNcnINpQ78PZ6ZPej63Q/8c21iZOLXuyI3DjGveaGf11AYvJb6oy7 feew== X-Gm-Message-State: AMke39l9dqCV7qibl/3xutje6oAnfmNiE6EiDZuEfsaSM8MVSUTavS4up8PT18zVSbkyeg== X-Received: by 10.55.108.131 with SMTP id h125mr6127216qkc.190.1488828191006; Mon, 06 Mar 2017 11:23:11 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id d30sm14004006qtb.18.2017.03.06.11.23.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 11:23:09 -0800 (PST) From: "jouni.nospam" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <60D19DEE-C934-4664-97E1-0893E679B94C@gmail.com> Date: Mon, 6 Mar 2017 11:23:08 -0800 To: dime@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Dime] agenda requests to IETF98 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 19:23:13 -0000 Folks, The final IETF agenda is out since last Friday.. Chairs have already = done most DIME agenda slot requests on your behalf ;) 1200 Group signaling (10 min) 1210 RFC4006bis (20 min) 1230 draft-bertz-dime-policygroups (10 min)=20 1240 draft-bertz-dime-predictunits (10 min) There=E2=80=99s still some half an hour space left in the agenda but I = would not encourage expanding it too much ;) - JOuni & Lionel= From nobody Tue Mar 7 04:58:44 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8330C129416 for ; Tue, 7 Mar 2017 04:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mLMcRJFYxf3 for ; Tue, 7 Mar 2017 04:58:41 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0891293E3 for ; Tue, 7 Mar 2017 04:58:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26036BEF4 for ; Tue, 7 Mar 2017 12:58:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqgQqUFZPyNq for ; Tue, 7 Mar 2017 12:58:38 +0000 (GMT) Received: from [172.28.172.2] (unknown [109.125.19.162]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1571BED6 for ; Tue, 7 Mar 2017 12:58:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488891518; bh=y86dsBtW2ZGC/B0T14UaQeEMSglkA7vC3YQR4JSppqY=; h=To:From:Subject:Date:From; b=VyyOn0eGvKHxVVsT2cKeGKw6tmAXJp5zFT6Z4DRD4fdlsgjOrn4OfBvMSY5QJb/HC G+dIFCF3c8lQ3nAdwIwtYBTb7daZDIw4jaJEhHyDEAqED47q+Wwjl8JwSQ99f/1Lbs lAOrgXRqnB7wCo/1wMrUWWVW51TZ23IKH4Pt1L+M= To: "dime@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <7400eb7e-9699-52d4-e194-adf944b95cb2@cs.tcd.ie> Date: Tue, 7 Mar 2017 12:58:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cqE0HruB3lNoCXdORFOPvSwPrsn768JqX" Archived-At: Subject: [Dime] Drafts on March 16th IESG telechat... X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 12:58:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cqE0HruB3lNoCXdORFOPvSwPrsn768JqX Content-Type: multipart/mixed; boundary="7mJmfvGBPadh3tc7Cl68pgmOLt8kvEXpE"; protected-headers="v1" From: Stephen Farrell To: "dime@ietf.org" Message-ID: <7400eb7e-9699-52d4-e194-adf944b95cb2@cs.tcd.ie> Subject: Drafts on March 16th IESG telechat... --7mJmfvGBPadh3tc7Cl68pgmOLt8kvEXpE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I've put two dime drafts [1,2] on the March 16th IESG telechat. If there are any changes to be made to those as a result of recent discussion or the various reviews, then it'd be best if those are done before the end of this Thursday to give the IESG a week to review what we hope are final versions. (If some minor changes are needed later we can handle those, but better to get stuff done now.) Cheers, S. --7mJmfvGBPadh3tc7Cl68pgmOLt8kvEXpE-- --cqE0HruB3lNoCXdORFOPvSwPrsn768JqX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYvq58AAoJEC88hzaAX42i4lQH/Rr7W94BBEdaWqmpQ3Gb4nFp ndZ5I6jar2P0mnHqFaEamqRRZ3uHZZUyx7qWCe+YeLoRlauCSm+8LCeHT2Jib2Fs GZIGEU1Lz0TSXCf1VgwlVgNsQ/9cyfO+XDoPByCcazvj6O2L/BTmKIhzw0Oeceji W696+zzZl94l3zDK0XHP4vBOwIVcZj4MCeT67AXcFIwrjqoK7INRxCt7GVx+j2xE ebRGC5YPYByaPDkfw6KoFmvap7+5eqDol9Ly8sgkr3YtMxz6XiZadk9V7TXjOoW6 bsM24HQAnGLC2VDdOhMXuHfrNKuW7ZwVMFWWPu6OQQjFhOxTEQkzNUJ5umRRFu4= =Ll33 -----END PGP SIGNATURE----- --cqE0HruB3lNoCXdORFOPvSwPrsn768JqX-- From ajoshi@definitionnetworks.com Tue Mar 7 03:01:20 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ECE129413 for ; Tue, 7 Mar 2017 03:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=definitionnetworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_gD4Q9uaqiR for ; Tue, 7 Mar 2017 03:01:19 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343F0126DFB for ; Tue, 7 Mar 2017 03:01:19 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id x37so88349023ota.2 for ; Tue, 07 Mar 2017 03:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=definitionnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1niadnspo9I2F7y2ifCdlukIXdM/RAahPtpKUqHipRY=; b=YQKp9gLjHrJrpOwBVoKlRI6P4kpBke7rdMul34QHiSw/aUM0u4DO+C2DIiMQhajjOT SHknMYPmH4VBVWw88r1hhk4B9TpQI4zcEeZLP+F94Lns5vKYV+4GtR0kaDKVahTAR479 LL1aed/huGqfF9eFJvbuE8N6aXhJ7G8i+S4Dx/f+eumSXerh5s0OLoE77V9DvFRZPyYC nPYtQLbqUHkIulBCZ0PSvGuSGlmJclQciKTv5f6//m9GjHvjf0KniLwZGqPLQKcpQ7hD crOz+802fqDD9zrmPqrzzFmbjpo5B1NneoOZajudkb8B4zzOCfZp7n6Uqrw2vsWLSRsu oBMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1niadnspo9I2F7y2ifCdlukIXdM/RAahPtpKUqHipRY=; b=XOJAs79rUr8vTJ581hhdm5JyY2tJfkan/jnlV0Rp8fBeY+NxPQ1Z4AH2YySvKzybLC DhevS9scRzZ/VnFsgrfhL/KJ/JojWJwd0/ik24p1+vjsF1kc0nTHScbPVSXrg7qkOIPa IF8XWzDpKiyDuA58wsczNBL0qQ3UhStx3SnncQQxLl4jYd15fkBZXtRmDoIXAdoXIxZg oV/7gnGZLQnZDV4y7K/JWG0iVb5N6IMkA3P9T+bL7OtktEw6tCfy592zGsdMsUAhSE5R occDqC6URn0d31+C6C9GHbB/Rp7re/8voX6DIiRH341opfgOQJdDr9/20dRK3ei0SASx Sg0w== X-Gm-Message-State: AMke39n0VbyYW//9284xjoeJYnEzInYcfKCbeNR/rYvOfIW8wH0cDZ3G2WaLNTJwI2COyT/xoMWLiLFNIpAZGg== X-Received: by 10.157.27.12 with SMTP id l12mr9789029otl.199.1488884478301; Tue, 07 Mar 2017 03:01:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.173 with HTTP; Tue, 7 Mar 2017 03:01:17 -0800 (PST) From: Ajinkya Joshi Date: Tue, 7 Mar 2017 16:31:17 +0530 Message-ID: To: dime@ietf.org Content-Type: multipart/alternative; boundary=94eb2c09b51070eadb054a21eef8 Archived-At: X-Mailman-Approved-At: Tue, 07 Mar 2017 06:51:27 -0800 Subject: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 11:04:25 -0000 --94eb2c09b51070eadb054a21eef8 Content-Type: text/plain; charset=UTF-8 Hello, I have following questions regarding diameter RFC 6733, I would really appreciate if someone can help me with these. 1. Regarding diameter peer state machine - Section 5.6.1 (Peer State Machine --> Incoming connections) mentions that Origin-host is used for identifying peer state machine and as per state machine, once it moves into I-Open, new CER is rejected. This concludes, that there can't be more than one transport connections with same diameter host (as specified by Origin-host). Section 2.1 (Transport) mentions that "A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed." Questions -- - Does section 2.1 implicitly assumes that multiple diameter instances (within a peer) would correspond to different diameter host ? Otherwise, it could contradict with section 5.6.1 - If multiple transport connections (towards the same peer) are allowed per diameter host, is it expected that peer would do load balancing between them? (There is a connection load balancing section in RFC 3539 - Section 3.4.3) 2. Regarding diameter peer failback procedure - Section 5.5.4 mentions "a connection request should be periodically attempted with the failed peer in order to re-establish the transport connection" Question -- - If the failed peer is dynamically discovered via DNS lookup, is it expected that peer would perform DNS query before trying to establish the connection again? Or DNS lookup is driven only by TTL field received in the prior DNS answer ? -- Regards, Ajinkya Joshi --94eb2c09b51070eadb054a21eef8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I have following questions regar= ding diameter RFC 6733, I would really appreciate if someone can help me wi= th these.

1. Regarding diameter peer state machine= -
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 Section 5.6.1 (Pee= r State Machine --> Incoming connections) mentions that Origin-host is u= sed for =C2=A0 =C2=A0 identifying peer state machine and as per state machi= ne, once it moves into I-Open, new CER is =C2=A0 =C2=A0 =C2=A0 rejected. Th= is concludes, that there can't be more than one transport connections w= ith same =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 diameter host (as= specified by Origin-host).=C2=A0

=C2=A0 =C2=A0 Se= ction 2.1 (Transport) mentions that "A given Diameter instance of the = peer state machine MUST =C2=A0 =C2=A0 =C2=A0NOT use more than one transport= connection to communicate with a given peer, unless multiple =C2=A0 =C2=A0= =C2=A0 =C2=A0instances exist on the peer, in which, case a separate connec= tion per process is allowed."

=C2=A0 =C2=A0 = =C2=A0Questions --=C2=A0
  • Does section 2.1 implicitly assu= mes that multiple diameter instances (within a peer) would correspond to di= fferent diameter host ? Otherwise, it could contradict with section 5.6.1
  • If multiple transport connections (towards the same peer) are al= lowed per diameter host, is it expected that peer would do load balancing b= etween them? (There is a connection load balancing section in RFC 3539 - Se= ction 3.4.3)
2. Regarding diameter peer failback procedure -<= /div>

=C2=A0 =C2=A0 =C2=A0 Section 5.5.4 mentions "= a connection request should be periodically attempted with the failed =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0peer in order to re-establish = the transport connection" =C2=A0

=C2=A0= =C2=A0 =C2=A0 Question --=C2=A0

  • If the fa= iled peer is dynamically discovered via DNS lookup, is it expected that pee= r would perform DNS query before trying to establish the connection again? = Or DNS lookup is driven only by TTL field received in the prior DNS answer = ?
--
Regards,
Ajinkya Joshi
--94eb2c09b51070eadb054a21eef8-- From nobody Tue Mar 7 07:39:43 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9948B129416 for ; Tue, 7 Mar 2017 06:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3j4tyjcHq8S for ; Tue, 7 Mar 2017 06:03:48 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEC81294C8 for ; Tue, 7 Mar 2017 06:03:38 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:65003 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clFi5-003PJU-HL for dime@ietf.org; Tue, 07 Mar 2017 06:03:38 -0800 To: dime@ietf.org References: <7400eb7e-9699-52d4-e194-adf944b95cb2@cs.tcd.ie> From: Steve Donovan Message-ID: <0f5ba01f-cb36-f572-c189-fb49bfe80c9e@usdonovans.com> Date: Tue, 7 Mar 2017 08:03:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <7400eb7e-9699-52d4-e194-adf944b95cb2@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------4EF9D496E4E22E2F38ED5984" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Drafts on March 16th IESG telechat... X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:03:49 -0000 This is a multi-part message in MIME format. --------------4EF9D496E4E22E2F38ED5984 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Stephen, I'm working on that as we speak. I should have new versions, with minor changes, ready today. Regards, Steve On 3/7/17 6:58 AM, Stephen Farrell wrote: > Hiya, > > I've put two dime drafts [1,2] on the March 16th IESG telechat. > > If there are any changes to be made to those as a result of > recent discussion or the various reviews, then it'd be best if > those are done before the end of this Thursday to give the > IESG a week to review what we hope are final versions. (If some > minor changes are needed later we can handle those, but better > to get stuff done now.) > > Cheers, > S. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------4EF9D496E4E22E2F38ED5984 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Stephen,

I'm working on that as we speak. I should have new versions, with minor changes, ready today.

Regards,

Steve

On 3/7/17 6:58 AM, Stephen Farrell wrote:
Hiya,

I've put two dime drafts [1,2] on the March 16th IESG telechat.

If there are any changes to be made to those as a result of
recent discussion or the various reviews, then it'd be best if
those are done before the end of this Thursday to give the
IESG a week to review what we hope are final versions. (If some
minor changes are needed later we can handle those, but better
to get stuff done now.)

Cheers,
S.




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

--------------4EF9D496E4E22E2F38ED5984-- From srdonovan@usdonovans.com Tue Mar 7 06:51:46 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF67F129582 for ; Tue, 7 Mar 2017 06:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMBykORXe_Tx for ; Tue, 7 Mar 2017 06:51:27 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C5E12962F for ; Tue, 7 Mar 2017 06:45:27 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:65159 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clGMa-003tfZ-60; Tue, 07 Mar 2017 06:45:26 -0800 To: Misha Zaytsev References: <148648420573.16333.15352530276464414850.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <3cc40001-cf24-be8c-ef1a-e6138f1b8351@usdonovans.com> Date: Tue, 7 Mar 2017 08:45:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AB63291F43623BB7BDA19B7D" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Cc: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-agent-overload-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 14:51:46 -0000 This is a multi-part message in MIME format. --------------AB63291F43623BB7BDA19B7D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Misha, See my comments inline. Steve On 2/22/17 12:56 PM, Misha Zaytsev wrote: > Hi Steve, > > Let me also reply to your edits when you were applying my comments. I > still have some concerns. > I will use the old numbering of the comments from my previous mails. > > 8. section 4 > LOSS" Is it a new type defined in the scope of this draft? > > SRD> Loss is defined in the DOIC specification (RFC 7683) > > [Misha]: All mentions about "LOSS" in the RFC7683 are related to loss > algorithm. > Nothing is mentioned in relation to report type like in this section. > So, I think my comment is still valid. > SRD> I agree the wording is bad. I've changed it to teh following -- "This is especially a concern if both reports indicate the LOSS abatement algorithm." > 15. section 5.2.3 > Still thinking that it is more correct to change "request" to "report" > in 2nd and 3rd paragraphs. > > If a reacting node receives an OC-OLR AVP of type peer and the > SourceID matches the DiameterIdentity of the Diameter peer from which > the *report *was received then the report was generated by a Diameter > peer. > > If a reacting node receives an OC-OLR AVP of type peer and the > SourceID does not match the DiameterIdentity of the Diameter peer > from which the *report *was received then the reacting node MUST > ignore the overload report. > > This will be aligned with 1st paragraph in this case. If you still do > no agree, then please explain what request is meant here since the 1st > paragraph is saying about "report". SRD> A report is carried in a request. The DiameterIdentity contained in the SourceID is compared to the DiameterIdentity of the entity that sent the message that carried the report. I have changed "request" to "response message" to be correct here. > > Could you check this particular section? > I think you can easily find the places where these 3 different terms > are used in the section text: "Peer Report OLR", "OC-OLR AVP", "OLR" > > Here is just one example: > > If the *Peer Report OLR *was received from a Diameter peer then the > reacting node MUST determine if it is for an existing or new overload > condition. > > My proposal was to use the only term "peer report" for all such > occurrences. > The reason behind is to avoid multiplying the usage of the different > terms that are about the same entity and just use the only one. SRD> Done. > > 16. section 5.2.3 + 22. section 6.2 > How may it happen that peer report reacting node receives a peer > report not from the peer that generated it? > Peer reports can be sent only to peer report reacting node, right? And > peer reports are not relayed, right? > SRD> This is to handle cases where there are agents in the network > that do not support the peer report feature. These agents would relay > peer reports, as they would any other AVP they don't understand. > > SRD> It is correct that a DOIC node should *not (?)* send a peer > report to a non supporting node. We, however, are paranoid, and left > the wording in the specification to handle miss behaving DOIC nodes, > given that bad things can happen when erroneous or malicious overload > reports are inserted into the network. > > [Misha]: If peer report cannot/should not be sent thru an agent that > does not support peer report feature and the only reason to leave such > wording in the spec is protect against potential malicious reports > inserted somehow in the network, then I'm proposing to explicitly > state such things in the spec. Otherwise, this wording may be > misleading/contradicting (with other parts of the spec) when reading > the spec SRD> I've added the following note to clarify -- "Note: Under normal circumstances, a Diameter node will not add a peer report when sending to a peer that does not support this extension. This requirement is to handle the case where peer reports are erroneously or maliciously inserted into response messages. > Best regards, > > /Misha > > 2017-02-07 21:10 GMT+03:00 Misha Zaytsev >: > > Hi Steve, > > It looks that some of my comments (which I did not send in the > first 2 mail) were lost. > So, I'm putting them here: > > 24. section 6.1.1. "OC-Feature-Vector" -> "OC-Feature-Vector AVP" > in the header. > > 25. section 6.1.2 "OC-Peer-Algo" -> "OC-Peer-Algo AVP" in the header > > 26. section 6.2 corrected AVP names > > This extension makes no changes to the *OC-Sequence-Number* or > *OC-Validity-Duration* AVPs in the OC-OLR AVP. > > 27. section 6.3 > > Probably, it is the matter of preference, but I would still > propose to rename SourceID to Source-Identity. > > 28. section 6.4. > > 6.4. Attribute Value Pair *F*lag *R*ules > > 29. section 7.1 > > 7.1. AVP *C*odes > > > 30. section 7.2 > > 7.2. New *R*egistries > > > Also I will check your answers on my applied comments in detail > and come back to you if I still have any concerns. > > /Misha > > > 2017-02-07 19:19 GMT+03:00 Steve Donovan >: > > I've attached the diff file for this version of the draft. > > Regards, > > Steve > > > On 2/7/17 10:16 AM, internet-drafts@ietf.org > wrote: > > 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 of the IETF. > > Title : Diameter Agent Overload and the > Peer Overload Report > Author : Steve Donovan > Filename : > draft-ietf-dime-agent-overload-09.txt > Pages : 17 > Date : 2017-02-07 > > Abstract: > This specification documents an extension to RFC 7683 > (Diameter > Overload Indication Conveyance (DOIC)) base solution. > The extension > defines the Peer overload report type. The initial use > case for the > Peer report is the handling of occurrences of overload > of a Diameter > agent. > > Requirements > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ > > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dime-agent-overload-09 > > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-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/ > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > --------------AB63291F43623BB7BDA19B7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Misha,

See my comments inline.

Steve

On 2/22/17 12:56 PM, Misha Zaytsev wrote:
Hi Steve,

Let me also reply to your edits when you were applying my comments. I still have some concerns.
I will use the old numbering of the comments from my previous mails.

8. section 4
LOSS" Is it a new type defined in the scope of this draft?

SRD> Loss is defined in the DOIC specification (RFC 7683)

[Misha]: All mentions about "LOSS" in the RFC7683 are related to loss algorithm.
Nothing is mentioned in relation to report type like in this section. So, I think my comment is still valid.

SRD> I agree the wording is bad.  I've changed it to teh following -- "This is especially a concern if both
        reports indicate the LOSS abatement algorithm."
15. section 5.2.3
Still thinking that it is more correct to change "request" to "report" in 2nd and 3rd paragraphs.

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

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

This will be aligned with 1st paragraph in this case. If you still do no agree, then please explain what request is meant here since the 1st paragraph is saying about "report".
SRD> A report is carried in a request.  The DiameterIdentity contained in the SourceID is compared to the DiameterIdentity of the entity that sent the message that carried the report.  I have changed "request" to "response message" to be correct here.

Could you check this particular section?
I think you can easily find the places where these 3 different terms are used in the section text: "Peer Report OLR", "OC-OLR AVP", "OLR"

Here is just one example:

If the Peer Report OLR was received from a Diameter peer then the
reacting node MUST determine if it is for an existing or new overload
condition.

My proposal was to use the only term "peer report" for all such occurrences.
The reason behind is to avoid multiplying the usage of the different terms that are about the same entity and just use the only one.
SRD> Done.

16. section 5.2.3 + 22. section 6.2
How may it happen that peer report reacting node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And peer reports are not relayed, right?
SRD> This is to handle cases where there are agents in the network that do not support the peer report feature.  These agents would relay peer reports, as they would any other AVP they don't understand.

SRD> It is correct that a DOIC node should not (?) send a peer report to a non supporting node.  We, however, are paranoid, and left the wording in the specification to handle miss behaving DOIC nodes, given that bad things can happen when erroneous or malicious overload reports are inserted into the network.

[Misha]: If peer report cannot/should not be sent thru an agent that does not support peer report feature and the only reason to leave such wording in the spec is protect against potential malicious reports inserted somehow in the network, then I'm proposing to explicitly state such things in the spec. Otherwise, this wording may be misleading/contradicting (with other parts of the spec) when reading the spec
SRD> I've added the following note to clarify -- "Note: Under normal circumstances, a Diameter node will not add a peer report when sending to a peer that does not support this extension.  This requirement is to handle the case where peer reports are erroneously or maliciously inserted into response messages.
Best regards,

/Misha

2017-02-07 21:10 GMT+03:00 Misha Zaytsev <misha.zaytsev.rus@gmail.com>:
Hi Steve,

It looks that some of my comments (which I did not send in the first 2 mail) were lost.
So, I'm putting them here:

24. section 6.1.1. "OC-Feature-Vector" -> "OC-Feature-Vector AVP" in the header.

25. section 6.1.2 "OC-Peer-Algo" -> "OC-Peer-Algo AVP" in the header

26. section 6.2 corrected AVP names

This extension makes no changes to the OC-Sequence-Number or OC-Validity-Duration AVPs in the OC-OLR AVP.

27. section 6.3

Probably, it is the matter of preference, but I would still propose to rename SourceID to Source-Identity.

28. section 6.4.

6.4.  Attribute Value Pair Flag Rules
29. section 7.1

7.1.  AVP Codes

30. section 7.2

7.2.  New Registries

Also I will check your answers on my applied comments in detail and come back to you if I still have any concerns.

/Misha


2017-02-07 19:19 GMT+03:00 Steve Donovan <srdonovan@usdonovans.com>:
I've attached the diff file for this version of the draft.

Regards,

Steve


On 2/7/17 10:16 AM, internet-drafts@ietf.org wrote:
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 of the IETF.

         Title           : Diameter Agent Overload and the Peer Overload Report
         Author          : Steve Donovan
        Filename        : draft-ietf-dime-agent-overload-09.txt
        Pages           : 17
        Date            : 2017-02-07

Abstract:
    This specification documents an extension to RFC 7683 (Diameter
    Overload Indication Conveyance (DOIC)) base solution.  The extension
    defines the Peer overload report type.  The initial use case for the
    Peer report is the handling of occurrences of overload of a Diameter
    agent.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dime-agent-overload-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-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/

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


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




--------------AB63291F43623BB7BDA19B7D-- From internet-drafts@ietf.org Tue Mar 7 07:06:41 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B62129451; Tue, 7 Mar 2017 07:06:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148889920174.23121.11042507566532752991@ietfa.amsl.com> Date: Tue, 07 Mar 2017 07:06:41 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:06:42 -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 of the IETF. Title : Diameter Agent Overload and the Peer Overload Report Author : Steve Donovan Filename : draft-ietf-dime-agent-overload-10.txt Pages : 17 Date : 2017-03-07 Abstract: This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-agent-overload-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-10 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 Mar 7 08:20:28 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256A41294BD for ; Tue, 7 Mar 2017 07:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rw5hBKS_q_g for ; Tue, 7 Mar 2017 07:52:28 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7030412949B for ; Tue, 7 Mar 2017 07:52:13 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:49270 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clHPC-000JWn-Pt for dime@ietf.org; Tue, 07 Mar 2017 07:52:13 -0800 To: dime@ietf.org References: <148843764035.7093.4978052381971422851.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <0372f33f-08c5-a446-a004-4f6a46578c4a@usdonovans.com> Date: Tue, 7 Mar 2017 09:52:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148843764035.7093.4978052381971422851.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Review of draft-ietf-dime-load-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:52:29 -0000 Shucheng, Thank you for your review. Please see my comments inline. Steve On 3/2/17 12:54 AM, Shucheng LIU wrote: > Reviewer: Shucheng LIU > Review result: Has Nits > > Hi all, > > I have reviewed draft-ietf-dime-load-07 as part of the Operational > directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the intent of > improving the operational aspects of the IETF drafts. Comments that > are not addressed in last call may be included in AD reviews during > the IESG review. Document editors and WG chairs should treat these > comments just like any other last call comments. > > “This document defines a mechanism for conveying of Diameter load > information. RFC7068 describes requirements for Overload Control > in > Diameter. This includes a requirement to allow Diameter nodes to > send "load" information, even when the node is not overloaded. > RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution > describes a mechanism meeting most of the requirements, but does > not > currently include the ability to send load information.” > > My overall view of the document is 'Ready with nits' for publication. > > > ** Technical ** > No. > > > ** Editorial ** > > *Section 4, page 4 >> That is, the OLR requests that the reacting node reduce the offered > load……. > > s/reduce/reduces SRD> Change made. > > > * Section 4.1, page 5: > >> The fundamental difference is that an overload report requires that > reduction. > > What does the second “that” refer to? It may change to “The > fundamental difference is that an overload report requires the > reduction of offered load”or so. SRD> Change made. > > * Section 5, page 10: > >> For the PEER load report, C follows the same procedure as A1 for > determining if the Load report was received from the peer from which > the report was sent and, when finding it does, stores the load > information for use when making future routing decisions. > > This sentence may need to split for more readable purpose. SRD> Change made > > * Section 5: > > Full name of *AVP* should be put into Abbreviations before using first > time. SRD> I've added AVP to the terminology section. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Mar 7 08:20:34 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833B51295C2 for ; Tue, 7 Mar 2017 07:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJRD6ullSFGU for ; Tue, 7 Mar 2017 07:53:39 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9DB12949B for ; Tue, 7 Mar 2017 07:53:17 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:49276 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clHQE-000KRZ-H7 for dime@ietf.org; Tue, 07 Mar 2017 07:53:17 -0800 To: dime@ietf.org References: <148889920174.23121.11042507566532752991@ietfa.amsl.com> From: Steve Donovan Message-ID: <6756512a-cd74-1d8f-7657-a8ed7449ff2a@usdonovans.com> Date: Tue, 7 Mar 2017 09:53:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148889920174.23121.11042507566532752991@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------8A1731A842669A2BBFBCEACD" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-agent-overload-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:53:55 -0000 This is a multi-part message in MIME format. --------------8A1731A842669A2BBFBCEACD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I believe I have addressed all comments received in this version. I've attached a diff file to show where changes were made. Steve On 3/7/17 9:06 AM, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Diameter Agent Overload and the Peer Overload Report > Author : Steve Donovan > Filename : draft-ietf-dime-agent-overload-10.txt > Pages : 17 > Date : 2017-03-07 > > Abstract: > This specification documents an extension to RFC 7683 (Diameter > Overload Indication Conveyance (DOIC)) base solution. The extension > defines the Peer overload report type. The initial use case for the > Peer report is the handling of occurrences of overload of a Diameter > agent. > > Requirements > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dime-agent-overload-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-10 > > > 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/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------8A1731A842669A2BBFBCEACD Content-Type: text/html; charset=UTF-8; name="Diff_ draft-ietf-dime-agent-overload-09.txt - draft-ietf-dime-agent-overload-10.html" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-agent-overload-09.txt - draft-ietf-dim"; filename*1="e-agent-overload-10.html" Diff: draft-ietf-dime-agent-overload-09.txt - draft-ietf-dime-agent-overload-10.txt
< draft-ietf-dime-agent-overload-09.txt   draft-ietf-dime-agent-overload-10.txt >
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Updates: RFC7683 (if approved) February 7, 2017 Updates: RFC7683 (if approved) March 7, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: August 11, 2017 Expires: September 8, 2017
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-09.txt draft-ietf-dime-agent-overload-10.txt
Abstract Abstract
This specification documents an extension to RFC 7683 (Diameter This specification documents an extension to RFC 7683 (Diameter
Overload Indication Conveyance (DOIC)) base solution. The extension Overload Indication Conveyance (DOIC)) base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
Requirements Requirements
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2017. This Internet-Draft will expire on September 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8 5.1.1. Reacting Node Behavior . . . . . . . . . . . . . . . 8
5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9 5.1.2. Reporting Node Behavior . . . . . . . . . . . . . . . 9
5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10 5.2. Peer Overload Report Handling . . . . . . . . . . . . . . 10
5.2.1. Overload Control State . . . . . . . . . . . . . . . 10 5.2.1. Overload Control State . . . . . . . . . . . . . . . 10
5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11 5.2.2. Reporting Node Maintenance of Peer Report OCS . . . . 11
5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11 5.2.3. Reacting Node Maintenance of Peer Report OCS . . . . 11
5.2.4. Peer-Report Reporting Node Behavior . . . . . . . . . 12 5.2.4. Peer-Report Reporting Node Behavior . . . . . . . . . 12
5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 12 5.2.5. Peer-Report Reacting Node Behavior . . . . . . . . . 12
6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13 6. Peer Report AVPs . . . . . . . . . . . . . . . . . . . . . . 13
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 13
6.1.1. OC-Feature-Vector . . . . . . . . . . . . . . . . . . 14 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 14
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14 6.1.2. OC-Peer-Algo AVP . . . . . . . . . . . . . . . . . . 14
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15 6.3. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15 6.4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16 7.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Informative References . . . . . . . . . . . . . . . . . 17 10.1. Informative References . . . . . . . . . . . . . . . . . 17
10.2. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Normative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. The extension Indication Conveyance (DOIC) [RFC7683] base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
skipping to change at page 8, line 34 skipping to change at page 8, line 34
overloaded host or realm. Any messages that survive throttling due overloaded host or realm. Any messages that survive throttling due
to host or realm reports should then go through abatement for the to host or realm reports should then go through abatement for the
peer overload report. In this scenario, when doing abatement on the peer overload report. In this scenario, when doing abatement on the
PEER report, the reacting node SHOULD take into consideration the PEER report, the reacting node SHOULD take into consideration the
number of messages already throttled by the handling of the HOST/ number of messages already throttled by the handling of the HOST/
REALM report abatement. REALM report abatement.
Note: The goal is to avoid traffic oscillations that might result Note: The goal is to avoid traffic oscillations that might result
from throttling of messages for both the HOST/REALM overload from throttling of messages for both the HOST/REALM overload
reports and the PEER overload reports. This is especially a reports and the PEER overload reports. This is especially a
concern if both reports are of type LOSS. concern if both reports indicate the LOSS abatement algorithm.
5. Peer Report Behavior 5. Peer Report Behavior
This section defines the normative behavior associated with the Peer This section defines the normative behavior associated with the Peer
Report extension to the DOIC solution. Report extension to the DOIC solution.
5.1. Capability Announcement 5.1. Capability Announcement
5.1.1. Reacting Node Behavior 5.1.1. Reacting Node Behavior
skipping to change at page 11, line 22 skipping to change at page 11, line 22
[RFC7683] apply to the peer report. [RFC7683] apply to the peer report.
5.2.3. Reacting Node Maintenance of Peer Report OCS 5.2.3. Reacting Node Maintenance of Peer Report OCS
When a reacting node receives an OC-OLR AVP with a report type of When a reacting node receives an OC-OLR AVP with a report type of
peer it MUST determine if the report was generated by the Diameter peer it MUST determine if the report was generated by the Diameter
peer from which the report was received. peer from which the report was received.
If a reacting node receives an OC-OLR AVP of type peer and the If a reacting node receives an OC-OLR AVP of type peer and the
SourceID matches the DiameterIdentity of the Diameter peer from which SourceID matches the DiameterIdentity of the Diameter peer from which
the request was received then the report was generated by a Diameter the response message was received then the report was generated by a
peer. Diameter peer.
If a reacting node receives an OC-OLR AVP of type peer and the If a reacting node receives an OC-OLR AVP of type peer and the
SourceID does not match the DiameterIdentity of the Diameter peer SourceID does not match the DiameterIdentity of the Diameter peer
from which the request was received then the reacting node MUST from which the response message was received then the reacting node
ignore the overload report. MUST ignore the overload report.
If the Peer Report OLR was received from a Diameter peer then the Note: Under normal circumstances, a Diameter node will not add a
peer report when sending to a peer that does not support this
extension. This requirement is to handle the case where peer
reports are erroneously or maliciously inserted into response
messages.
If the peer report was received from a Diameter peer then the
reacting node MUST determine if it is for an existing or new overload reacting node MUST determine if it is for an existing or new overload
condition. condition.
The OLR is for an existing overload condition if the reacting node The peer report is for an existing overload condition if the reacting
has an OCS that matches the received OLR. For a peer report, this node has an OCS that matches the received peer report. For a peer
means it matches the Application-ID and the peer's DiameterIdentity report, this means it matches the Application-ID and the peer's
in an existing OCS entry. DiameterIdentity in an existing OCS entry.
If the OLR is for an existing overload condition then it MUST If the peer report is for an existing overload condition then it MUST
determine if the OLR is a retransmission or an update to the existing determine if the peer report is a retransmission or an update to the
OLR. existing OLR.
If the sequence number for the received OLR is greater than the If the sequence number for the received peer report is greater than
sequence number stored in the matching OCS entry then the reacting the sequence number stored in the matching OCS entry then the
node MUST update the matching OCS entry. reacting node MUST update the matching OCS entry.
If the sequence number for the received OLR is less than or equal to If the sequence number for the received peer report is less than or
the sequence number in the matching OCS entry then the reacting node equal to the sequence number in the matching OCS entry then the
MUST silently ignore the received OLR. The matching OCS MUST NOT be reacting node MUST silently ignore the received peer report. The
updated in this case. matching OCS MUST NOT be updated in this case.
If the received OLR is for a new overload condition then the reacting If the received peer report is for a new overload condition then the
node MUST generate a new OCS entry for the overload condition. reacting node MUST generate a new OCS entry for the overload
condition.
For a peer report this means it creates an OCS entry with a For a peer report this means it creates an OCS entry with a
DiameterIdentity from the SourceID AVP in the received OC-OLR AVP. DiameterIdentity from the SourceID AVP in the received OC-OLR AVP.
If the received OLR contains a validity duration of zero ("0") then If the received peer report contains a validity duration of zero
the reacting node MUST update the OCS entry as being expired. ("0") then the reacting node MUST update the OCS entry as being
expired.
The reacting node does not delete an OCS when receiving an answer The reacting node does not delete an OCS when receiving an answer
message that does not contain an OC-OLR AVP (i.e. absence of OLR message that does not contain an OC-OLR AVP (i.e. absence of OLR
means "no change"). means "no change").
The reacting node sets the abatement algorithm based on the OC-Peer- The reacting node sets the abatement algorithm based on the OC-Peer-
Algo AVP in the received OC-Supported-Features AVP. Algo AVP in the received OC-Supported-Features AVP.
5.2.4. Peer-Report Reporting Node Behavior 5.2.4. Peer-Report Reporting Node Behavior
skipping to change at page 14, line 11 skipping to change at page 14, line 15
This extension also adds the OC-Peer-Algo AVP to the OC-Supported- This extension also adds the OC-Peer-Algo AVP to the OC-Supported-
Features AVP. This AVP is used by a reporting node to indicate the Features AVP. This AVP is used by a reporting node to indicate the
abatement algorithm it will use for peer overload reports. abatement algorithm it will use for peer overload reports.
OC-Supported-Features ::= < AVP Header: 621 > OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ] [ OC-Feature-Vector ]
[ SourceID ] [ SourceID ]
[ OC-Peer-Algo] [ OC-Peer-Algo]
* [ AVP ] * [ AVP ]
6.1.1. OC-Feature-Vector 6.1.1. OC-Feature-Vector AVP
The peer report feature defines a new feature bit for the OC-Feature- The peer report feature defines a new feature bit for the OC-Feature-
Vector AVP. Vector AVP.
OC_PEER_REPORT (0x0000000000000010) OC_PEER_REPORT (0x0000000000000010)
When this flag is set by a DOIC Node it indicates that the DOIC When this flag is set by a DOIC Node it indicates that the DOIC
Node supports the peer overload report type. Node supports the peer overload report type.
6.1.2. OC-Peer-Algo 6.1.2. OC-Peer-Algo AVP
The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and The OC-Peer-Algo AVP (AVP code TBD1) is of type Unsigned64 and
contains a 64 bit flags field of announced capabilities of a DOIC contains a 64 bit flags field of announced capabilities of a DOIC
Node. The value of zero (0) is reserved. Node. The value of zero (0) is reserved.
Feature bits defined for the OC-Feature-Vector AVP and associated Feature bits defined for the OC-Feature-Vector AVP and associated
with overload abatement algorithms are reused for this AVP. with overload abatement algorithms are reused for this AVP.
6.2. OC-OLR AVP 6.2. OC-OLR AVP
This extension makes no changes to the SequenceNumber or This extension makes no changes to the OC_Sequence_Number or
ValidityDuration AVPs in the OC-OLR AVP. These AVPs are also be used OC_Validity_Duration AVPs in the OC-OLR AVP. These AVPs are also be
in peer overload reports. used in peer overload reports.
The OC_PEER_REPORT feature extends the base Diameter overload The OC_PEER_REPORT feature extends the base Diameter overload
specification by defining a new overload report type of "peer". See specification by defining a new overload report type of "peer". See
section [7.6] in [RFC7683] for a description of the OC-Report-Type section [7.6] in [RFC7683] for a description of the OC-Report-Type
AVP. AVP.
The overload report MUST also include the Diameter identity of the The overload report MUST also include the Diameter identity of the
agent that generated the report. This is necessary to handle the agent that generated the report. This is necessary to handle the
case where there is a non supporting agent between the reporting node case where there is a non supporting agent between the reporting node
and the reacting node. Without the indication of the agent that and the reacting node. Without the indication of the agent that
skipping to change at page 15, line 38 skipping to change at page 15, line 43
In the case of peer reports, the SourceID AVP indicates the node that In the case of peer reports, the SourceID AVP indicates the node that
supports this feature (in the OC-Supported-Features AVP) or the node supports this feature (in the OC-Supported-Features AVP) or the node
that generates an overload with a report type of peer (in the OC-OLR that generates an overload with a report type of peer (in the OC-OLR
AVP). AVP).
It contains the DiameterIdentity of the inserting node. This is used It contains the DiameterIdentity of the inserting node. This is used
by other Diameter nodes to determine the node that inserted the by other Diameter nodes to determine the node that inserted the
enclosing AVP that contains the SourceID AVP. enclosing AVP that contains the SourceID AVP.
6.4. Attribute Value Pair flag rules 6.4. Attribute Value Pair Flag Rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|OC-Peer-Algo TBD1 x.x Unsigned64 | | V | |OC-Peer-Algo TBD1 6.1.2 Unsigned64 | | V |
|SourceID TBD2 x.x DiameterIdentity | | V | |SourceID TBD2 6.3 DiameterIdentity | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. IANA Considerations 7. IANA Considerations
7.1. AVP codes 7.1. AVP Codes
New AVPs defined by this specification are listed in Section 6.4. New AVPs defined by this specification are listed in Section 6.4.
All AVP codes are allocated from the 'Authentication, Authorization, All AVP codes are allocated from the 'Authentication, Authorization,
and Accounting (AAA) Parameters' AVP Codes registry. and Accounting (AAA) Parameters' AVP Codes registry.
One new OC-Report-Type AVP value is defined in Section 6.2.1 One new OC-Report-Type AVP value is defined in Section 6.2.1
7.2. New registries 7.2. New Registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
The values used for the OC-Peer-Algo AVP are the subset of the "OC- The values used for the OC-Peer-Algo AVP are the subset of the "OC-
Feature-Vector AVP Values (code 622)" registry. Only the values in Feature-Vector AVP Values (code 622)" registry. Only the values in
that registry that apply to overload abatement algorithms apply to that registry that apply to overload abatement algorithms apply to
the OC-Peer-Algo AVP. the OC-Peer-Algo AVP.
8. Security Considerations 8. Security Considerations
 End of changes. 25 change blocks. 
45 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--------------8A1731A842669A2BBFBCEACD-- From nobody Tue Mar 7 08:22:12 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B12E6129582; Tue, 7 Mar 2017 08:18:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148890353268.30275.13518195824298533892@ietfa.amsl.com> Date: Tue, 07 Mar 2017 08:18:52 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:18: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 of the IETF. Title : Diameter Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-08.txt Pages : 22 Date : 2017-03-07 Abstract: RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. This document defines a mechanism for conveying of Diameter load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-08 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 Mar 7 08:23:22 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20C1294B8 for ; Tue, 7 Mar 2017 08:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.699, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFDYM2mete_N for ; Tue, 7 Mar 2017 08:23:14 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318081294E4 for ; Tue, 7 Mar 2017 08:23:14 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:49580 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1clHt9-000gSh-2q for dime@ietf.org; Tue, 07 Mar 2017 08:23:13 -0800 To: dime@ietf.org References: <148890353268.30275.13518195824298533892@ietfa.amsl.com> From: Steve Donovan Message-ID: <3f8d76af-2169-4dca-b161-488d5684f25b@usdonovans.com> Date: Tue, 7 Mar 2017 10:23:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148890353268.30275.13518195824298533892@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------0CF8CA1F49E37C6B8B4E8B16" X-OutGoing-Spam-Status: No, score=0.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-load-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:23:17 -0000 This is a multi-part message in MIME format. --------------0CF8CA1F49E37C6B8B4E8B16 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit All, I believe that I have addressed all of the comments received on the Load draft. I have attached a diff showing the changes made. Regards, Steve On 3/7/17 10:18 AM, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Diameter Load Information Conveyance > Authors : Ben Campbell > Steve Donovan > Jean-Jacques Trottin > Filename : draft-ietf-dime-load-08.txt > Pages : 22 > Date : 2017-03-07 > > Abstract: > RFC7068 describes requirements for Overload Control in Diameter. > This includes a requirement to allow Diameter nodes to send "load" > information, even when the node is not overloaded. RFC7683 (Diameter > Overload Information Conveyance (DOIC)) solution describes a > mechanism meeting most of the requirements, but does not currently > include the ability to send load information. This document defines > a mechanism for conveying of Diameter load information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-load/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dime-load-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-08 > > > 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/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------0CF8CA1F49E37C6B8B4E8B16 Content-Type: text/html; charset=UTF-8; name="Diff_ draft-ietf-dime-load-07.txt - draft-ietf-dime-load-08.html" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="Diff_ draft-ietf-dime-load-07.txt - draft-ietf-dime-load-08."; filename*1="html" Diff: draft-ietf-dime-load-07.txt - draft-ietf-dime-load-08.txt
< draft-ietf-dime-load-07.txt   draft-ietf-dime-load-08.txt >
Internet Engineering Task Force B. Campbell Internet Engineering Task Force B. Campbell
Internet-Draft S. Donovan, Ed. Internet-Draft S. Donovan, Ed.
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: August 11, 2017 JJ. Trottin Expires: September 8, 2017 JJ. Trottin
Nokia Nokia
February 7, 2017 March 7, 2017
Diameter Load Information Conveyance Diameter Load Information Conveyance
draft-ietf-dime-load-07 draft-ietf-dime-load-08
Abstract Abstract
This document defines a mechanism for conveying of Diameter load RFC7068 describes requirements for Overload Control in Diameter.
information. RFC7068 describes requirements for Overload Control in This includes a requirement to allow Diameter nodes to send "load"
Diameter. This includes a requirement to allow Diameter nodes to information, even when the node is not overloaded. RFC7683 (Diameter
send "load" information, even when the node is not overloaded. Overload Information Conveyance (DOIC)) solution describes a
RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution mechanism meeting most of the requirements, but does not currently
describes a mechanism meeting most of the requirements, but does not include the ability to send load information. This document defines
currently include the ability to send load information. a mechanism for conveying of Diameter load information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2017. This Internet-Draft will expire on September 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
4.1. Differences between Load and Overload information . . . . 4 4.1. Differences between Load and Overload information . . . . 4
4.2. How is Load Information Used? . . . . . . . . . . . . . . 5 4.2. How is Load Information Used? . . . . . . . . . . . . . . 5
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 8
6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10 6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10
6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10 6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10
6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11 6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11
6.2. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 6.2. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12
6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Addition and removal of Nodes . . . . . . . . . . . . . . 13 6.4. Addition and Removal of Nodes . . . . . . . . . . . . . . 13
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 14 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 14
7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14 7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 14
7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15 7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 15
7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 15 7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 17 Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 17
A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 17 A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 17
A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 18 A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 18
A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 18 A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 20 A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 20
A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 20 A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 20
A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 20 A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 21
A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 21 A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 21
A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 21 A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
[RFC7068] describes requirements for Overload Control in Diameter [RFC7068] describes requirements for Overload Control in Diameter
[RFC6733]. The DIME working group has finished the Diameter Overload [RFC6733]. The DIME working group has finished the Diameter Overload
Information Conveyance (DOIC) mechanism [RFC7683]. As currently Information Conveyance (DOIC) mechanism [RFC7683]. As currently
specified, DOIC fulfills some, but not all, of the requirements. specified, DOIC fulfills some, but not all, of the requirements.
In particular, DOIC does not fulfill Req 23 and Req 24: In particular, DOIC does not fulfill Req 23 and Req 24:
skipping to change at page 3, line 40 skipping to change at page 3, line 40
that the working group did not agree on a general approach for that the working group did not agree on a general approach for
conveying load information. It chose to progress the rest of DOIC, conveying load information. It chose to progress the rest of DOIC,
and deferred load information conveyance to a DOIC extension or a and deferred load information conveyance to a DOIC extension or a
separate mechanism. separate mechanism.
This document defines a mechanism that addresses the load-related This document defines a mechanism that addresses the load-related
requirements from RFC 7068. requirements from RFC 7068.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
AVP
Attribute Value Pair
DOIC DOIC
Diameter Overload Information Conveyance ([RFC7683]) Diameter Overload Information Conveyance ([RFC7683])
Load Load
The relative usage of the Diameter message processing capacity of The relative usage of the Diameter message processing capacity of
a Diameter node. A low load level indicates that the Diameter a Diameter node. A low load level indicates that the Diameter
node is under utilized. A high load level indicates that the node node is under utilized. A high load level indicates that the node
is closer to being fully utilized. is closer to being fully utilized.
skipping to change at page 4, line 4 skipping to change at page 4, line 8
Diameter Overload Information Conveyance ([RFC7683]) Diameter Overload Information Conveyance ([RFC7683])
Load Load
The relative usage of the Diameter message processing capacity of The relative usage of the Diameter message processing capacity of
a Diameter node. A low load level indicates that the Diameter a Diameter node. A low load level indicates that the Diameter
node is under utilized. A high load level indicates that the node node is under utilized. A high load level indicates that the node
is closer to being fully utilized. is closer to being fully utilized.
Offered Load Offered Load
The actual traffic sent to the reporting node after overload The actual traffic sent to the reporting node after overload
abatement and routing decisions are made. abatement and routing decisions are made.
Reporting, Reacting Node Reporting Node
Reporting node and reacting node terminology is defined in Reporting Node: A Diameter node that generates a load report.
[RFC7683].
Reacting Node
Reacting Node: A Diameter node that acts upon a load report.
Routing Information Routing Information
Routing Information referred to in this document can include the Routing Information referred to in this document can include the
Routing and Peer tables defined in RFC 6733. It can also include Routing and Peer tables defined in RFC 6733. It can also include
other implementation specific tables used to store load other implementation specific tables used to store load
information. This document does not define the structure of such information. This document does not define the structure of such
tables. tables.
3. Conventions Used in This Document 3. Conventions Used in This Document
skipping to change at page 4, line 34 skipping to change at page 4, line 42
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 2119 [RFC2119] interpretation does not apply for the above listed RFC 2119 [RFC2119] interpretation does not apply for the above listed
words when they are not used in all-caps format. words when they are not used in all-caps format.
4. Background 4. Background
4.1. Differences between Load and Overload information 4.1. Differences between Load and Overload information
Previous discussions of how to solve the load-related requirements in Previous discussions of how to solve the load-related requirements in
[RFC7068] have shown that people did not had an agreed-upon concept [RFC7068] have shown that people did not have an agreed-upon concept
of how "load" information differs from "overload" information. While of how "load" information differs from "overload" information. While
the two concepts are highly interrelated, in the opinion of the the two concepts are highly interrelated, there are two primary
authors, there are two primary differences. First, a Diameter node differences. First, a Diameter node always has a load. At any given
always has a load. At any given time that load may be effectively time that load may be effectively zero, effectively fully loaded, or
zero, effectively fully loaded, or somewhere in between. In somewhere in between. In contrast, overload is an exceptional
contrast, overload is an exceptional condition. A node only has condition. A node only has overload information when it is in an
overload information when it is in an overloaded state. Furthermore, overloaded state. Furthermore, the relationship between a node's
the relationship between a node's load level and overload state at load level and overload state at any given time may be vague. For
any given time may be vague. For example, a node may normally example, a node may normally operate at a "fully loaded" level, but
operate at a "fully loaded" level, but still not be considered still not be considered overloaded. Another node may declare itself
overloaded. Another node may declare itself to be "overloaded" even to be "overloaded" even though it might not be fully "loaded".
though it might not be fully "loaded".
Second, Overload information, in the form of a DOIC Overload Report Second, Overload information, in the form of a DOIC Overload Report
(OLR) [RFC7683] indicates an explicit request for action on the part (OLR) [RFC7683] indicates an explicit request for action on the part
of the reacting node. That is, the OLR requests that the reacting of the reacting node. That is, the OLR requests that the reacting
node reduce the offered load -- the actual traffic sent to the node reduces the offered load -- the actual traffic sent to the
reporting node after overload abatement and routing decisions are reporting node after overload abatement and routing decisions are
made -- by an indicated amount (by default), or as prescribed by the made -- by an indicated amount (by default), or as prescribed by the
selected abatement algorithm. Effectively, DOIC provides a contract selected abatement algorithm. Effectively, DOIC provides a contract
between the reporting node and the reacting node. between the reporting node and the reacting node.
In contrast, load is informational. That is, load information can be In contrast, load is informational. That is, load information can be
considered a hint to the recipient node. That node may use the load considered a hint to the recipient node. That node may use the load
information for load balancing purposes, as an input to certain information for load balancing purposes, as an input to certain
overload abatement techniques, to make inferences about the overload abatement techniques, to make inferences about the
likelihood that the sending node becomes overloaded in the immediate likelihood that the sending node becomes overloaded in the immediate
future, or for other purposes. future, or for other purposes.
None of this prevents a Diameter node from deciding to reduce the None of this prevents a Diameter node from deciding to reduce the
offered load based on load information. The fundamental difference offered load based on load information. The fundamental difference
is that an overload report requires that reduction. It is also is that an overload report requires the reduction of offered load.
reasonable for a Diameter node to decide to increase the offered load It is also reasonable for a Diameter node to decide to increase the
based on load information. offered load based on load information.
4.2. How is Load Information Used? 4.2. How is Load Information Used?
[RFC7068] contemplates two primary uses for load information. Req 23 [RFC7068] contemplates two primary uses for load information. Req 23
discusses how load information might be used when performing discusses how load information might be used when performing
diversion as an overload abatement technique, as described in diversion as an overload abatement technique, as described in
[RFC7683]. When a reacting node diverts traffic away from an [RFC7683]. When a reacting node diverts traffic away from an
overloaded node, it needs load information for the other candidates overloaded node, it needs load information for the other candidates
for that traffic in order to effectively load balance the diverted for that traffic in order to effectively load balance the diverted
load between potential candidates. Otherwise, diversion has a load between potential candidates. Otherwise, diversion has a
skipping to change at page 5, line 42 skipping to change at page 5, line 49
Req 24 discusses how Diameter load information might be used when no Req 24 discusses how Diameter load information might be used when no
overload condition currently exists. Diameter nodes can use the load overload condition currently exists. Diameter nodes can use the load
information to make decisions to try to avoid overload conditions in information to make decisions to try to avoid overload conditions in
the first place. Normal load-balancing falls into this category, but the first place. Normal load-balancing falls into this category, but
the diameter node can take other proactive steps as well. the diameter node can take other proactive steps as well.
If the loaded nodes are Diameter servers (or clients in the case of If the loaded nodes are Diameter servers (or clients in the case of
server-to-client transactions), both of these uses of load server-to-client transactions), both of these uses of load
information should be accomplished by a Diameter node that performs information should be accomplished by a Diameter node that performs
server selection. Typically, server selection is performed by a node server selection (selection of the Diameter endpont to which the
(a client or an agent) that is an immediate peer of the server. request is to be routed for processing). Typically, server selection
However, there are scenarios (see Appendix A) where a client or proxy is performed by a node (a client or an agent) that is an immediate
that is not the immediate peer to the selected servers performs peer of the server. However, there are scenarios (see Appendix A)
server selection. In this case, the client or proxy enforces the where a client or proxy that is not the immediate peer to the
server selection by inserting a Destination-Host AVP. selected servers performs server selection. In this case, the client
or proxy enforces the server selection by inserting a Destination-
Host AVP.
For example, a Diameter node (e.g. client) can use a redirect For example, a Diameter node (e.g. client) can use a redirect
agent to get candidate destination host addresses. The redirect agent to get candidate destination host addresses. The redirect
agent might return several destination host addresses, from which agent might return several destination host addresses, from which
the Diameter node selects one. The Diameter node can use load the Diameter node selects one. The Diameter node can use load
information received from these hosts to make the selection. information received from these hosts to make the selection.
Just as load information can be used as part of server selection, it Just as load information can be used as part of server selection, it
can also be used as input to the selection of the next-hop peer to can also be used as input to the selection of the next-hop peer to
which a request is to be routed. which a request is to be routed.
skipping to change at page 6, line 42 skipping to change at page 7, line 5
The second big difference between DOIC and Load is visibility of the The second big difference between DOIC and Load is visibility of the
DOIC or Load information within a Diameter network. DOIC information DOIC or Load information within a Diameter network. DOIC information
is sent end-to-end resulting in the ability of all nodes in the path is sent end-to-end resulting in the ability of all nodes in the path
of the answer message that carries the OC-OLR AVP to act on the of the answer message that carries the OC-OLR AVP to act on the
information, although only one node actually comsumes and reacts to information, although only one node actually comsumes and reacts to
the report. The DOIC overload reports remain in the message all the the report. The DOIC overload reports remain in the message all the
way from the reporting node to the node that is the target for the way from the reporting node to the node that is the target for the
answer message. answer message.
For the Load mechanism there are two types of load reports and only For the Load mechanism there are two types of Load reports and only
the first one is transmitted end-to-end. the first one is transmitted end-to-end.
The first is the load of the endpoint sending the answer message. The first type of load report is a HOST report which contains the
This load report is carried end-to-end to enable any nodes that make load of the endpoint sending the answer message. This Load report is
server selection decisions to use the load status of the sending carried end-to-end to enable any nodes that make server selection
endpoint as part of the server selection decision. Unlike with DOIC, decisions to use the load status of the sending endpoint as part of
more than one node may make use of the load information received. the server selection decision. Unlike with DOIC, more than one node
may make use of the load information received.
The second type of load report is a peer report. This report is used The second type of Load report is a PEER report. This report is used
by Diameter nodes as part of the logic to select the next-hop by Diameter nodes as part of the logic to select the next-hop
Diameter node and, as such, does not have significance beyond the Diameter node and, as such, does not have significance beyond the
peer node. These load reports are removed by the first supporting peer node. Load reports of type PEER are removed by the first
Diameter node to receive the report. supporting Diameter node to receive the report.
Because load reports can traverse Diameter nodes that do not support Because Load reports can traverse Diameter nodes that do not support
the Load mechanism, it is necessary to include the identity of the the Load mechanism, it is necessary to include the identity of the
node to which the load report applies as part of the load report. node to which the Load report applies as part of the Load report.
This allows for a Diameter node to verify that a load report applies This allows for a Diameter node to verify that a Load report applies
to its peer or if it should be ignored. to its peer or if it should be ignored.
The load report includes a value indicating the load of the sending The Load report includes a value indicating relative load of the
node relative load of the sending node, specified in a manner sending node, specified in a manner consistent with that defined for
consistent with that defined for DNS SRV [RFC2782]. DNS SRV [RFC2782].
The goal is to make it possible to use both the load values received The goal is to make it possible to use both the load values received
as a part of the Diameter Load mechanism and weight values received as a part of the Diameter Load mechanism and weight values received
as a result of a DNS SRV query. As a result, the Diameter load value as a result of a DNS SRV query. As a result, the Diameter load value
has a range of 0-65535. This value and DNS SRV weight values are has a range of 0-65535. This value and DNS SRV weight values are
then used in a distribution algorithm similar to that specified in then used in a distribution algorithm similar to that specified in
[RFC2782]. [RFC2782].
The DNS SRV distribution algorithm results in more messages being The DNS SRV distribution algorithm results in more messages being
sent to a node with a higher weight value. As a result, a higher sent to a node with a higher weight value. As a result, a higher
Diameter load value indicates a LOWER load on the sending node. A Diameter load value indicates a LOWER load on the sending node. A
node that is heavily loaded sends a lower Diameter load value. node that is heavily loaded sends a lower Diameter load value.
Stated another way, a node that has zero load would have a load value Stated another way, a node that has zero load would have a load value
of 65535. A node that is 100% loaded would have a load value of 0. of 65535. A node that is 100% loaded would have a load value of 0.
The distribution algorithm used by Diameter nodes supporting the The distribution algorithm used by Diameter nodes supporting the
Diameter Load mechanism is an implementation decision but it needs to Diameter Load mechanism is an implementation decision but it needs to
result in similar behavior to the algorithm described for the use of result in similar behavior to the algorithm described for the use of
weigh values specified in [RFC2782]. weight values specified in [RFC2782].
The method for calculating the load value included in the load report The method for calculating the load value included in the Load report
is also left as an implementation decision. is also left as an implementation decision.
The frequency for sending of load reports is also left as an The frequency for sending of Load reports is also left as an
implementation decision. The sending node might choose to send load implementation decision. The sending node might choose to send Load
reports in all messages or it might choose to only send load reports reports in all messages or it might choose to only send Load reports
when the load value has changed by some implementation specific when the load value has changed by some implementation specific
amount. The important consideration is that all nodes needing the amount. The important consideration is that all nodes needing the
load information have a sufficiently accurate view of the node's load information have a sufficiently accurate view of the node's
load. load.
5.1. Theory of Operation 5.1. Theory of Operation
This section outlines how the Diameter Load mechanism is expected to This section outlines how the Diameter Load mechanism is expected to
work. work.
skipping to change at page 8, line 37 skipping to change at page 8, line 45
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
|----->|----->|----->| |----->|----->|----->|
xxR xxR xxR xxR xxR xxR
Figure 2: Request Message Path Figure 2: Request Message Path
When sending the answer message, an endpoint node that supports the When sending the answer message, an endpoint node that supports the
Diameter Load mechanism includes its own load information in the Diameter Load mechanism includes its own load information in the
answer message. Because it is a Diameter endpoint it includes a HOST answer message. Because it is a Diameter endpoint it includes a HOST
load report. Load report.
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
| | |<-----| | | |<-----|
| | xxA(Load type:HOST, source:S[n]) | | xxA(Load type:HOST, source:S[n])
| | | | | | | |
Figure 3: Answer Message from S[n] Figure 3: Answer Message from S[n]
If Agent A4 supports the Load mechanism then A4's actions depend on If Agent A4 supports the Load mechanism then A4's actions depend on
whether A4 is responsible for doing server selection. If A4 is not whether A4 is responsible for doing server selection. If A4 is not
doing server selection then A4 ignores the HOST load report. If A4 doing server selection then A4 ignores the HOST Load report. If A4
is responsible for doing server selection then it stores the load is responsible for doing server selection then it stores the load
information for S[n] in its routing information for the handling of information for S[n] in its routing information for the handling of
subsequent request messages. In both cases A4 leaves the HOST report subsequent request messages. In both cases A4 leaves the HOST report
in the message. in the message.
Note: If A4 does not support the Load mechanism then it will relay Note: If A4 does not support the Load mechanism then it will relay
the answer message without doing any processing on the load the answer message without doing any processing on the load
information. In this case the load information AVPs will be information. In this case the load information AVPs will be
relayed without change. relayed without change.
skipping to change at page 9, line 31 skipping to change at page 9, line 42
| |<-----| | | |<-----| |
| xxA(Load type:PEER, source:A4) | xxA(Load type:PEER, source:A4)
| xxA(Load type:HOST, source:S[n]) | xxA(Load type:HOST, source:S[n])
| | | | | | | |
Figure 4: Answer Message from A4 Figure 4: Answer Message from A4
If A1 supports the Load mechanism then it processes each of the Load If A1 supports the Load mechanism then it processes each of the Load
reports it receives separately. reports it receives separately.
For the PEER load report, A1 first determines if the source of the For the PEER Load report, A1 first determines if the source of the
report indicated in the load report matches the DiameterIdentity of report indicated in the Load report matches the DiameterIdentity of
the Diameter node from which the request was received. If the the Diameter node from which the request was received. If the
identities do not match then the PEER load report is discarded. If identities do not match then the PEER load report is discarded. If
the identities match then A1 saves the load information in its the identities match then A1 saves the load information in its
routing information for routing of subsequent request messages. In routing information for routing of subsequent request messages. In
both cases A1 strips the PEER load report from the message. both cases A1 strips the PEER Load report from the message.
For the HOST load report, A1's actions depend on whether A1 is For the HOST Load report, A1's actions depend on whether A1 is
responsible for doing server selection. If A1 is not doing server responsible for doing server selection. If A1 is not doing server
selection then A1 ignores the HOST load report. If A1 is responsible selection then A1 ignores the HOST Load report. If A1 is responsible
for doing server selection then it stores the load information for for doing server selection then it stores the load information for
S[n] in its routing information for the handling of subsequent S[n] in its routing information for the handling of subsequent
request messages. In both cases A1 leaves the HOST report in the request messages. In both cases A1 leaves the HOST report in the
message. message.
A1 then calculates its own load information and inserts load A1 then calculates its own load information and inserts load
information AVPs of type PEER in the message before sending the information AVPs of type PEER in the message before sending the
message to C: message to C:
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
|<-----| | | |<-----| | |
xxA(Load type:PEER, source:A1) xxA(Load type:PEER, source:A1)
xxA(Load type:HOST, source:S[n]) xxA(Load type:HOST, source:S[n])
Figure 5: Answer Message from A1 Figure 5: Answer Message from A1
As with A1, C processes each load report separately. As with A1, C processes each Load report separately.
For the PEER load report, C follows the same procedure as A1 for For the PEER Load report, C follows the same procedure as A1 for
determining if the Load report was received from the peer from which determining if the Load report was received from the peer from which
the report was sent and, when finding it does, stores the load the report was sent. When finding it does, C stores the load
information for use when making future routing decisions. information for use when making future routing decisions.
For the HOST load report, C saves the load information only if it is For the HOST Load report, C saves the load information only if it is
responsible for doing server selection. responsible for doing server selection.
The Load information received by all nodes is then used for routing The Load information received by all nodes is then used for routing
of subsequent request messages. of subsequent request messages.
6. Load Mechanism Procedures 6. Load Mechanism Procedures
This section defines the normative behaviors for the Load mechanism. This section defines the normative behaviors for the Load mechanism.
6.1. Reporting Node Behavior 6.1. Reporting Node Behavior
This section defines the procedures of Diameter reporting nodes that This section defines the procedures of Diameter reporting nodes that
generate load reports. generate Load reports.
6.1.1. Endpoint Reporting Node Behavior 6.1.1. Endpoint Reporting Node Behavior
A Diameter endpoint that supports the Diameter Load mechanism MUST A Diameter endpoint that supports the Diameter Load mechanism MUST
include a load report of type HOST in sufficient answer messages to include a Load report of type HOST in sufficient answer messages to
ensure that all consumers of the load information receive timely ensure that all consumers of the load information receive timely
updates. updates.
The Diameter endpoint MUST include its own DiameterIdentity in the The Diameter endpoint MUST include its own DiameterIdentity in the
SourceID AVP included in the Load AVP. SourceID AVP included in the Load AVP.
The Diameter endpoint MUST include a Load-Type AVP of type HOST in The Diameter endpoint MUST include a Load-Type AVP of type HOST in
the Load AVP. the Load AVP.
The Diameter endpoint MUST include its load value in the Value AVP in The Diameter endpoint MUST include its load value in the Load-Value
the load AVP. AVP in the Load AVP.
The LOAD value should be calculated in a way that reflects the The LOAD value should be calculated in a way that reflects the
available load independently of the weight of each server, in order available load independently of the weight of each server, in order
to accurately compare LOAD values from different nodes. Any specific to accurately compare LOAD values from different nodes. Any specific
LOAD value needs to identify the same amount of available capacity, LOAD value needs to identify the same amount of available capacity,
regardless the Diameter node that calculates the value. regardless the Diameter node that calculates the value.
The mechanism used to calculate the LOAD value that fulfils this The mechanism used to calculate the LOAD value that fulfills this
requirement is an implementation decision. requirement is an implementation decision.
The frequency of sending load reports is an implementation decision. The frequency of sending Load reports is an implementation decision.
For instance, if the only consumer of the load reports is the For instance, if the only consumer of the Load reports is the
endpoint's peer then the endpoint can choose to only include a endpoint's peer then the endpoint can choose to only include a
load report when the load of the endpoint has changed by a Load report when the load of the endpoint has changed by a
meaningful percentage. If there are consumers of the endpoint meaningful percentage. If there are consumers of the endpoint
load report other then the endpoint's peer (this will be the case Load report other then the endpoint's peer (this will be the case
if other nodes are responsible for server selection) then the if other nodes are responsible for server selection) then the
endpoint might choose to include load reports in all answer endpoint might choose to include Load reports in all answer
messages as a way of ensuring that all nodes doing server messages as a way of ensuring that all nodes doing server
selection get accurate load information. selection get accurate load information.
6.1.2. Agent Reporting Node Behavior 6.1.2. Agent Reporting Node Behavior
A Diameter agent that supports the Diameter Load mechanism MUST A Diameter Agent that supports the Diameter Load mechanism MUST
include a PEER load report in sufficient answer messages to ensure include a PEER Load report in sufficient answer messages to ensure
that all users of the load information receive timely updates. that all users of the load information receive timely updates.
The Diameter agent MUST include its own DiameterIdentity in the The Diameter Agent MUST include its own DiameterIdentity in the
SourceID AVP included in the Load AVP. SourceID AVP included in the Load AVP.
The Diameter agent MUST include a Load-Type AVP of type PEER in the The Diameter Agent MUST include a Load-Type AVP of type PEER in the
Load AVP. Load AVP.
The Diameter agent MUST include its load value in the Load-Value AVP The Diameter Agent MUST include its load value in the Load-Value AVP
in the load AVP. in the Load AVP.
The LOAD value should be calculated in a way that reflects the The LOAD value should be calculated in a way that reflects the
available load independently of the weight of each agent, in order to available load independently of the weight of each agent, in order to
accurately compare LOAD values from different nodes. Any specific accurately compare LOAD values from different nodes. Any specific
LOAD value needs to identify the same amount of available capacity, LOAD value needs to identify the same amount of available capacity,
regardless the Diameter node that calculates the value. regardless the Diameter node that calculates the value.
The mechanism used to calculate the LOAD value that fulfils this The mechanism used to calculate the LOAD value that fulfills this
requirement is an implementation decision. requirement is an implementation decision.
The frequency of sending load reports is an implementation decision. The frequency of sending Load reports is an implementation decision.
Note: In the case of peer load reports it is only necessary to Note: In the case of peer Load reports it is only necessary to
include load reports when the load value has changed by some include Load reports when the load value has changed by some
meaningful value, as long as the agent insures that all peers meaningful value, as long as the agent ensures that all peers
receive the report. It is also acceptable to include the load receive the report. It is also acceptable to include the Load
report in every answer message handled by the Diameter agent. report in every answer message handled by the Diameter Agent.
6.2. Reacting Node Behavior 6.2. Reacting Node Behavior
This section defines the behavior of Diameter nodes processing load This section defines the behavior of Diameter nodes processing Load
reports. reports.
A Diameter node MUST be prepared to process load reports of type HOST A Diameter node MUST be prepared to process Load reports of type HOST
and of type PEER, as indicated in the Load-Type AVP included in the and of type PEER, as indicated in the Load-Type AVP included in the
Load AVP received in the same answer message or from multiple answer Load AVP received in the same answer message or from multiple answer
messages. messages.
Note that the node needs to be able to handle messages with no Note that the node needs to be able to handle messages with no
load reports, messages with just a PEER load report, messages with load reports, messages with just a PEER Load report, messages with
just an HOST load report and messages with both types of load just an HOST Load report and messages with both types of Load
reports. reports.
If the Diameter node is not responsible for doing server selection If the Diameter node is not responsible for doing server selection
then it SHOULD ignore load reports of type HOST. then it SHOULD ignore Load reports of type HOST.
If the Diameter node is responsible for doing server selection then If the Diameter node is responsible for doing server selection then
it SHOULD save the load value included in the Load-Value AVP included it SHOULD save the load value included in the Load-Value AVP included
in the Load AVP of type HOST in its routing information. in the Load AVP of type HOST in its routing information.
If the Diameter node receives a Load report of type PEER then the If the Diameter node receives a Load report of type PEER then the
Diameter node MUST determine if the Load report was inserted into the Diameter node MUST determine if the Load report was inserted into the
answer message by the peer from which the message was received. This answer message by the peer from which the message was received. This
is achieved by comparing the DiameterIdentity associated with the is achieved by comparing the DiameterIdentity associated with the
connection from which the message was received with the connection from which the message was received with the
DiameterIdentity included in the SourceID AVP in the Load report. DiameterIdentity included in the SourceID AVP in the Load report.
If the Diameter node determines that the Load report of type PEER was If the Diameter node determines that the Load report of type PEER was
not received from the peer that sent or relayed the answer message not received from the peer that sent or relayed the answer message
then the node MUST ignore the Load report. then the node MUST ignore the Load report.
If the Diameter node determines that the Load report of type PEER was If the Diameter node determines that the Load report of type PEER was
received from the peer that sent or relayed the answer message then received from the peer that sent or relayed the answer message then
the node SHOULD save the load information in its routing information. the node SHOULD save the load information in its routing information.
In all cases, a Diameter Agent MUST strip all load reports of type In all cases, a Diameter Agent MUST strip all Load reports of type
peer received in answer messages. PEER received in answer messages.
Note: This ensures that there will be precisely one load report of Note: This ensures that there will be precisely one Load report of
type peer, that of the Diameter node sending the message, in any type PEER, that of the Diameter node sending the message, in any
answer messages sent by the Diameter agent. answer messages sent by the Diameter Agent.
How a Diameter node uses load information for making routing How a Diameter node uses load information for making routing
decisions is an implementation decision. However, the distribution decisions is an implementation decision. However, the distribution
algorithm MUST result in similar behavior as the algorithm described algorithm MUST result in similar behavior as the algorithm described
for the use of weigth values in [RFC2782]. for the use of weight values in [RFC2782].
6.3. Extensibility 6.3. Extensibility
The Load mechanism can be extended to include additional information The Load mechanism can be extended to include additional information
in the load reports. in the Load reports.
Any extension may define new AVPs for use in Load reports. These new Any extension may define new AVPs for use in Load reports. These new
AVPs SHOULD be defined to be extensions to the Load AVPs defined in AVPs SHOULD be defined to be extensions to the Load AVPs defined in
this document. this document.
[RFC6733] defined Grouped AVP extension mechanisms apply. This [RFC6733] defined Grouped AVP extension mechanisms apply. This
allows, for example, defining a new feature that is mandatory to be allows, for example, defining a new feature that is mandatory to be
understood even when piggybacked on an existing application. understood even when piggybacked on an existing application.
As with any Diameter specification, [RFC6733] requires all new AVPs As with any Diameter specification, [RFC6733] requires all new AVPs
to be registered with IANA. See Section 9 for the required to be registered with IANA. See Section 9 for the required
procedures. procedures.
6.4. Addition and removal of Nodes 6.4. Addition and Removal of Nodes
When a Diameter node is added, the new node will start by advertising When a Diameter node is added, the new node will start by advertising
its load. Downstream nodes will need to factor the new load its load. Downstream nodes will need to factor the new load
information into load balancing decisions. The downstream nodes can information into load balancing decisions. The downstream nodes can
attempt to ensure a smooth increase of the traffic to the new node, attempt to ensure a smooth increase of the traffic to the new node,
avoiding an immediate spike of traffic to the new node. The method avoiding an immediate spike of traffic to the new node. The method
for handling of such a smooth increase is implementation specific but for handling of such a smooth increase is implementation specific but
it can rely on the evolution of load information received from the it can rely on the evolution of load information received from the
new node and from the other nodes. new node and from the other nodes.
skipping to change at page 14, line 26 skipping to change at page 14, line 34
[ Load-Value ] [ Load-Value ]
[ SourceID ] [ SourceID ]
* [ AVP ] * [ AVP ]
7.2. Load-Type AVP 7.2. Load-Type AVP
The Load-Type AVP (AVP code TBD2) is of type Enumerated. It is used The Load-Type AVP (AVP code TBD2) is of type Enumerated. It is used
to convey the type of Diameter node that sent the load information. to convey the type of Diameter node that sent the load information.
The following values are defined: The following values are defined:
HOST 0 The load report is for a host. HOST 0 The Load report is for a host.
PEER 1 The load report is for a peer. PEER 1 The Load report is for a peer.
7.3. Load-Value AVP 7.3. Load-Value AVP
The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used
to convey relative load information about the sender of the load to convey relative load information about the sender of the Load
report. report.
The Load-Value AVP is specified in a manner similar to the weight The Load-Value AVP is specified in a manner similar to the weight
value in DNS SRV ([RFC2782]). value in DNS SRV ([RFC2782]).
The Load-Value has a range of 0-65535. The Load-Value has a range of 0-65535.
A higher value indicates a lower load on the sending node. A lower A higher value indicates a lower load on the sending node. A lower
value indicates that the sending node is heavily loaded. value indicates that the sending node is heavily loaded.
skipping to change at page 15, line 41 skipping to change at page 15, line 45
8. Security Considerations 8. Security Considerations
Load information may be sensitive information in some cases. Load information may be sensitive information in some cases.
Depending on the mechanism, an unauthorized recipient might be able Depending on the mechanism, an unauthorized recipient might be able
to infer the topology of a Diameter network from load information. to infer the topology of a Diameter network from load information.
Load information might be useful in identifying targets for Denial of Load information might be useful in identifying targets for Denial of
Service (DoS) attacks, where a node known to be already heavily Service (DoS) attacks, where a node known to be already heavily
loaded might be a tempting target. Load information might also be loaded might be a tempting target. Load information might also be
useful as feedback about the success of an ongoing DoS attack. useful as feedback about the success of an ongoing DoS attack.
Given that routing decisions are impacted by load information, there
is potential for negative impacts on a Diameter network caused by
erroneous or malicious load reports. This includes the malicious
changing of load values by Diameter Agents.
Any load information conveyance mechanism will need to allow Any load information conveyance mechanism will need to allow
operators to avoid sending load information to nodes that are not operators to avoid sending load information to nodes that are not
authorized to receive it. Since Diameter currently only offers authorized to receive it. Since Diameter currently only offers
authentication of nodes at the transport level, any solution that authentication of nodes at the transport level, any solution that
sends load information to non-peer nodes might require a transitive- sends load information to non-peer nodes requires a transitive-trust
trust model. model.
9. IANA Considerations 9. IANA Considerations
9.1. AVP Codes 9.1. AVP Codes
New AVPs defined by this specification are listed in New AVPs defined by this specification are listed in
Section Section 7. All AVP codes are allocated from the Section Section 7. All AVP codes are allocated from the
'Authentication, Authorization, and Accounting (AAA) Parameters' AVP 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP
Codes registry. Codes registry.
 End of changes. 69 change blocks. 
113 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--------------0CF8CA1F49E37C6B8B4E8B16-- From nobody Tue Mar 7 08:34:41 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324EA1294B8 for ; Tue, 7 Mar 2017 08:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOyx6Hr2mE1S for ; Tue, 7 Mar 2017 08:34:38 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571E61294B2 for ; Tue, 7 Mar 2017 08:34:38 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id o126so2499886pfb.3 for ; Tue, 07 Mar 2017 08:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5XvtiZy6/phPjhAw0cqCKYyqyANXQw+rzBzEGkZTSnA=; b=Wihp654VpkaqmaZstiYwY+g3RxizLA03l/9dKAcXj3sbq96ieyf2Ei9plUkjX9xeMH RbpIAoobxK444m+MnHXqw4jJZvzJWe4+tq9UKSVKi0wYKFmjmEgiPQ7NV46JKr0Hl8dT xLsSvfgkD9LSeBCQ8EEx92I6S2NwFDKf9DJIU0l1cLwHPzO06+ev97cQbz9aZVjHXzh1 vNJ57GGDoPBfUefAd/qEHVQAku5TwvmA+c3k06uPbr3zLP/rfQTS6/6E4GXnWO51UArf 8/ITanpiPGB3zB4nTdY/XJB1qqvp0BHQd9ewcO9vHQei4YZLGNEHqEV2W+XOXtkguoKK k1Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5XvtiZy6/phPjhAw0cqCKYyqyANXQw+rzBzEGkZTSnA=; b=iIvQ/Jl6GAk4URBHf6wtV/DF49ERtFqPbEHG3Blxj3X9ZudaGjKXuHI8AYeyqCXC/7 84AeIgAPSK6fgfP7IpN8Rwsc4RQq5iAl1NTb7iHsgPgaM5ZYIfqiv6FDbDtBrnPyQcVW RhWvhCX47TMDE5iiL0g1gEzjoBJaZEoOvJ98/hy/XIVUp5YQxWTkLWLjjfrudkv5LBPl BlMSUXQXt5RdhfkhLzZkKuKD72oHK6gH20BnpFiieSOQp7JeJLbK2p4sAAN5l0rHWSIO ig+Q+30IyGi/gK3NZcNUioS83vXYVcLfiAEtuMoSbmoJ7taijKvDzFCeR5LWx/j5cqm+ r3Cw== X-Gm-Message-State: AMke39mi3PoB/2BYx22cP02aL8r0zBWIPZix6k07b0j+KSuFOq8rwzRPgV/DgKqCVNT/mA== X-Received: by 10.99.106.5 with SMTP id f5mr1363177pgc.110.1488904477921; Tue, 07 Mar 2017 08:34:37 -0800 (PST) Received: from [10.0.0.189] (mobile-166-171-250-009.mycingular.net. [166.171.250.9]) by smtp.gmail.com with ESMTPSA id e70sm833960pfh.84.2017.03.07.08.34.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 08:34:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "jouni.nospam" In-Reply-To: Date: Tue, 7 Mar 2017 08:34:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> References: To: Ajinkya Joshi X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dime@ietf.org Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:34:40 -0000 hi, > On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi = wrote: >=20 > Hello, >=20 > I have following questions regarding diameter RFC 6733, I would really = appreciate if someone can help me with these. >=20 > 1. Regarding diameter peer state machine - > =20 > Section 5.6.1 (Peer State Machine --> Incoming connections) = mentions that Origin-host is used for identifying peer state machine = and as per state machine, once it moves into I-Open, new CER is = rejected. This concludes, that there can't be more than one transport = connections with same diameter host (as specified by = Origin-host).=20 >=20 > Section 2.1 (Transport) mentions that "A given Diameter instance = of the peer state machine MUST NOT use more than one transport = connection to communicate with a given peer, unless multiple = instances exist on the peer, in which, case a separate connection per = process is allowed." >=20 > Questions --=20 > =E2=80=A2 Does section 2.1 implicitly assumes that multiple = diameter instances (within a peer) would correspond to different = diameter host ? Otherwise, it could contradict with section 5.6.1 it assumes one peer connection per peer state machine. so if you have a = way to =E2=80=98fork=E2=80=99 a new peer instance with its own peer = state machine per incoming connection then having =E2=80=9Cmultiple = instances=E2=80=99 is possible even if the diameteridentity is the same.=20= > =E2=80=A2 If multiple transport connections (towards the same = peer) are allowed per diameter host, is it expected that peer would do = load balancing between them? (There is a connection load balancing = section in RFC 3539 - Section 3.4.3) what you do and how you manage =E2=80=98multiple instances=E2=80=99 if = more or less left for implementation to decide. i always considered it = as a node internal compute load balancing mechanism i.e., to distribute = the compute to separate cores/blades etc. > 2. Regarding diameter peer failback procedure - >=20 > Section 5.5.4 mentions "a connection request should be = periodically attempted with the failed peer in order to = re-establish the transport connection" =20 >=20 > Question --=20 >=20 > =E2=80=A2 If the failed peer is dynamically discovered via DNS = lookup, is it expected that peer would perform DNS query before trying = to establish the connection again? Or DNS lookup is driven only by TTL = field received in the prior DNS answer ? up to your implementation and dns resolver implementation.=20 - jouni > --=20 > Regards, > Ajinkya Joshi > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Mar 7 10:30:39 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE831294AA for ; Tue, 7 Mar 2017 10:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3kL335ZWiE7 for ; Tue, 7 Mar 2017 10:30:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D881129467 for ; Tue, 7 Mar 2017 10:30:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A402BE8A; Tue, 7 Mar 2017 18:30:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ds01C2-gUL7; Tue, 7 Mar 2017 18:30:32 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 230BDBEC3; Tue, 7 Mar 2017 18:30:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488911432; bh=5YG0TXhrvAm/7KXoOS2WF49As/uTOSxFupd3xSmiMr0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=fi1ziA1w7FfeLAHLOPSSwOs9E4TwmIq6PH0EccZrj0wZAgo0208OsozCjWlnYVucz twYy23ejjDbr9IB8Uxq1Df02lAsPxHjnKOSPWnjttyJUOzrt4HbQjf1RjnyyozH7Cm zlZd3XqdLvw7IxHTke3G0m1E+/4NvIpP19n9YRtY= To: Steve Donovan , dime@ietf.org References: <148890353268.30275.13518195824298533892@ietfa.amsl.com> <3f8d76af-2169-4dca-b161-488d5684f25b@usdonovans.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1a865f84-4d53-5d2e-e661-e5ae80f8f550@cs.tcd.ie> Date: Tue, 7 Mar 2017 18:30:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <3f8d76af-2169-4dca-b161-488d5684f25b@usdonovans.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TbBfaUjkR8p0FfJqLEIS2uL9lOgJf5wpo" Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-load-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:30:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TbBfaUjkR8p0FfJqLEIS2uL9lOgJf5wpo Content-Type: multipart/mixed; boundary="omUBRDdux3ruKtgFEAJO3Q9rdnIAaJiJI"; protected-headers="v1" From: Stephen Farrell To: Steve Donovan , dime@ietf.org Message-ID: <1a865f84-4d53-5d2e-e661-e5ae80f8f550@cs.tcd.ie> Subject: Re: [Dime] I-D Action: draft-ietf-dime-load-08.txt References: <148890353268.30275.13518195824298533892@ietfa.amsl.com> <3f8d76af-2169-4dca-b161-488d5684f25b@usdonovans.com> In-Reply-To: <3f8d76af-2169-4dca-b161-488d5684f25b@usdonovans.com> --omUBRDdux3ruKtgFEAJO3Q9rdnIAaJiJI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Steve, Thanks for the updates to both drafts. S. On 07/03/17 16:23, Steve Donovan wrote: > All, >=20 > I believe that I have addressed all of the comments received on the Loa= d > draft. >=20 > I have attached a diff showing the changes made. >=20 > Regards, >=20 > Steve >=20 > On 3/7/17 10:18 AM, internet-drafts@ietf.org wrote: >> 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 >> of the IETF. >> >> Title : Diameter Load Information Conveyance >> Authors : Ben Campbell >> Steve Donovan >> Jean-Jacques Trottin >> Filename : draft-ietf-dime-load-08.txt >> Pages : 22 >> Date : 2017-03-07 >> >> Abstract: >> RFC7068 describes requirements for Overload Control in Diameter. >> This includes a requirement to allow Diameter nodes to send "load"= >> information, even when the node is not overloaded. RFC7683 (Diame= ter >> Overload Information Conveyance (DOIC)) solution describes a >> mechanism meeting most of the requirements, but does not currently= >> include the ability to send load information. This document defin= es >> a mechanism for conveying of Diameter load information. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dime-load/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-dime-load-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-load-08 >> >> >> 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/ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 --omUBRDdux3ruKtgFEAJO3Q9rdnIAaJiJI-- --TbBfaUjkR8p0FfJqLEIS2uL9lOgJf5wpo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYvvxHAAoJEC88hzaAX42iSc4H/jM7dmye7idGIBrU/zZS1+fW RHHWXcZjrckuHrU2H1wnYN0YzvccssRQXiVrREGgL5tNmQrpIoB4SDx6XyJbZQBZ U4P6LCpzFE1fMXNL9LxwXhFGag1ZIb4UtQVxdLXEqkGhwwAHgv1qUBvsIuALGdKg mp32UlFA7iRiv1mCXmhN821imPaKDbHP909D5DrTpOftmDkBJF0WsQdXgG+Czl+c JPH5XCUVy7imL2KzE3P8grGTwoCpn7KPF/HrIQnpckS1d2z3uxMLBffO/Lo95Q3o ll/1uXWenc+1jtkCBdd8DDc/pBXB2Y4HBOfJwXECL8ducNu9m1D9IrDevmBg46w= =CdIK -----END PGP SIGNATURE----- --TbBfaUjkR8p0FfJqLEIS2uL9lOgJf5wpo-- From nobody Tue Mar 7 11:44:03 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23531294A3 for ; Tue, 7 Mar 2017 11:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 uQgnAZtw_L_O for ; Tue, 7 Mar 2017 11:44:00 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C9E129426 for ; Tue, 7 Mar 2017 11:44:00 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 7 Mar 2017 14:43:58 -0500 From: Dave Dolson To: Dave Dolson , "dime@ietf.org" Thread-Topic: RFC4006bis: Using IPv4-mapped-IPv6 addresses in Redirect-Address-IPv6Address Thread-Index: AdKUXAYmPpa31PbRRT2PgzfhwBRZTwDHwAYw Date: Tue, 7 Mar 2017 19:43:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E987053C6CDwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC4006bis: Using IPv4-mapped-IPv6 addresses in Redirect-Address-IPv6Address X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:44:02 -0000 --_000_E8355113905631478EFF04F5AA706E987053C6CDwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I didn't hear any opinions on this, and since RFC5952 mentions IPv4-mapped-= IPv6, I think it is appropriate. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Friday, March 03, 2017 3:44 PM To: dime@ietf.org Subject: [Dime] RFC4006bis: Using IPv4-mapped-IPv6 addresses in Redirect-Ad= dress-IPv6Address I've been reviewing https://tools.ietf.org/id/draft-ietf-dime-rfc4006bis-01= .txt One thing I noticed is that nothing is said about whether it is acceptable = to use IPv4-mapped-IPv6 addresses in IPv6 AVPs. https://tools.ietf.org/html/rfc4291#section-2.5.5.2 Briefly, an IPv6 address like ::ffff:c000:201 (also written ::ffff.192.0.2.= 1) is used to represent an IPv4 address. This simplifies the number of AVPs required, simplifies software, and makes= IPv6 a first-class citizen. I'd like to ask this group if we can add language to explicitly permit ipv4= -mapped-ipv6 addresses in RFC4006bis. -Dave --_000_E8355113905631478EFF04F5AA706E987053C6CDwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I didn’t hear an= y opinions on this, and since RFC5952 mentions IPv4-mapped-IPv6, I think it= is appropriate.

 

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Friday, March 03, 2017 3:44 PM
To: dime@ietf.org
Subject: [Dime] RFC4006bis: Using IPv4-mapped-IPv6 addresses in Redi= rect-Address-IPv6Address

 

I’ve been reviewing https://tools.ietf.org/id/draft-ietf-dime-rfc4006bis-01.txt<= /p>

 

One thing I noticed is that nothing is said about wh= ether it is acceptable to use IPv4-mapped-IPv6 addresses in IPv6 AVPs.=

https://tools.ietf.org/html/rfc4291#section-2.5.5.2

 

Briefly, an IPv6 address like ::ffff:c000:201 (also = written ::ffff.192.0.2.1) is used to represent an IPv4 address.<= /p>

This simplifies the number of AVPs required, simplif= ies software, and makes IPv6 a first-class citizen.

 

I’d like to ask this group if we can add langu= age to explicitly permit ipv4-mapped-ipv6 addresses in RFC4006bis.

 

 

 

-Dave

 

--_000_E8355113905631478EFF04F5AA706E987053C6CDwtlexchp1sandvi_-- From nobody Tue Mar 7 11:44:36 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6AF1294AC for ; Tue, 7 Mar 2017 11:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 BTxh49B6qRB2 for ; Tue, 7 Mar 2017 11:44:34 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B2D129426 for ; Tue, 7 Mar 2017 11:44:34 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 7 Mar 2017 14:44:32 -0500 From: Dave Dolson To: Yuval Lifshitz , "dime@ietf.org" Thread-Topic: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Address type Thread-Index: AQHSlMhHrbZbVyBAnkmoG8o3lSJ5XqGJzMxA Date: Tue, 7 Mar 2017 19:44:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Address type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:44:35 -0000 OK, I'll make this change. -----Original Message----- From: Yuval Lifshitz=20 Sent: Saturday, March 04, 2017 4:18 AM To: Dave Dolson; dime@ietf.org Cc: Yuval Lifshitz Subject: RE: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using = Address type Hi Dave, I think this makes sense. Reason I added these a UTF8 is to enable easier t= ransition from the existing Redirect-Server-Address which is UTF8) to the n= ewly proposed Redirect-Address-IPv4Address and Redirect-Address-IPv6Address= AVP. However, since there are new AVPs, not part of a standard yet, it is probab= ly good time to change them. Yuval From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Friday, March 03, 2017 10:44 PM To: dime@ietf.org Subject: [Dime] RFC4006bis: new Redirect-Address- AVPs should be using Addr= ess type The draft of RFC4006bis (https://tools.ietf.org/id/draft-ietf-dime-rfc4006b= is-01.txt)=20 introduces new AVPs Redirect-Address-IPv4Address and Redirect-Address-IPv6A= ddress. These are currently defined as textual. I.e., "dotted decimal" and "RFC5952= ". I would like to propose these instead be defined to use the more compact an= d less ambiguous binary address format. Specifically, I would like to ask this group if these two fields can be con= solidated into one field, Name: Redirect-Address-IpAddress Type: Address, per https://tools.ietf.org/html/rfc6733#section-4.3.1=20 -Dave From nobody Tue Mar 7 23:19:11 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE75129481 for ; Tue, 7 Mar 2017 23:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6FmH0CSqr7D for ; Tue, 7 Mar 2017 23:19:08 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C7D129480 for ; Tue, 7 Mar 2017 23:19:08 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 02:19:06 -0500 From: Yuval Lifshitz To: jouni.nospam , Ajinkya Joshi Thread-Topic: [Dime] Questions regarding RFC 6733 Thread-Index: AQHSl1U9WpTBFpE6T0mg7Qm895f8KKGJ5o8AgACh0CA= Date: Wed, 8 Mar 2017 07:19:06 +0000 Message-ID: References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> In-Reply-To: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 07:19:10 -0000 UmVnYXJkaW5nICgxKSwgYW5vdGhlciBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiB3b3VsZCBiZSB0 aGF0IHVwb24gcmVjZWl2aW5nIGEgbmV3IGNvbm5lY3Rpb24gZnJvbSB0aGUgc2FtZSBob3N0LCB5 b3Ugd291bGQgdGVhciBkb3duIHRoZSBleGlzdGluZyBjb25uZWN0aW9uIGFuZCBhbGxvdyB0aGUg bmV3IG9uZS4gVGhpcyB3b3VsZCBiZSB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBhIGNsaWVudCBi ZWNhbWUgZGVhZGxvY2tlZCBvciBkaWRuJ3Qgc2h1dGRvd24gcHJvcGVybHksIGFuZCBhIG5ldyBj bGllbnQgdHJpZXMgdG8gdGFrZSBvdmVyIGFuZCBjb250aW51ZSB0aGUgd29yayBvZiB0aGUgc3Rh bGxlZCBvbmVzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlNRSBbbWFp bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGpvdW5pLm5vc3BhbQ0KU2Vu dDogVHVlc2RheSwgTWFyY2ggMDcsIDIwMTcgNjozNSBQTQ0KVG86IEFqaW5reWEgSm9zaGkNCkNj OiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdIFF1ZXN0aW9ucyByZWdhcmRpbmcg UkZDIDY3MzMNCg0KaGksDQoNCj4gT24gTWFyIDcsIDIwMTcsIGF0IDM6MDEgQU0sIEFqaW5reWEg Sm9zaGkgPGFqb3NoaUBkZWZpbml0aW9ubmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxv LA0KPiANCj4gSSBoYXZlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVnYXJkaW5nIGRpYW1ldGVyIFJG QyA2NzMzLCBJIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGlmIHNvbWVvbmUgY2FuIGhlbHAgbWUg d2l0aCB0aGVzZS4NCj4gDQo+IDEuIFJlZ2FyZGluZyBkaWFtZXRlciBwZWVyIHN0YXRlIG1hY2hp bmUgLQ0KPiAgICAgDQo+ICAgICBTZWN0aW9uIDUuNi4xIChQZWVyIFN0YXRlIE1hY2hpbmUgLS0+ IEluY29taW5nIGNvbm5lY3Rpb25zKSBtZW50aW9ucyB0aGF0IE9yaWdpbi1ob3N0IGlzIHVzZWQg Zm9yICAgICBpZGVudGlmeWluZyBwZWVyIHN0YXRlIG1hY2hpbmUgYW5kIGFzIHBlciBzdGF0ZSBt YWNoaW5lLCBvbmNlIGl0IG1vdmVzIGludG8gSS1PcGVuLCBuZXcgQ0VSIGlzICAgICAgIHJlamVj dGVkLiBUaGlzIGNvbmNsdWRlcywgdGhhdCB0aGVyZSBjYW4ndCBiZSBtb3JlIHRoYW4gb25lIHRy YW5zcG9ydCBjb25uZWN0aW9ucyB3aXRoIHNhbWUgICAgICAgICAgICAgICBkaWFtZXRlciBob3N0 IChhcyBzcGVjaWZpZWQgYnkgT3JpZ2luLWhvc3QpLiANCj4gDQo+ICAgICBTZWN0aW9uIDIuMSAo VHJhbnNwb3J0KSBtZW50aW9ucyB0aGF0ICJBIGdpdmVuIERpYW1ldGVyIGluc3RhbmNlIG9mIHRo ZSBwZWVyIHN0YXRlIG1hY2hpbmUgTVVTVCAgICAgIE5PVCB1c2UgbW9yZSB0aGFuIG9uZSB0cmFu c3BvcnQgY29ubmVjdGlvbiB0byBjb21tdW5pY2F0ZSB3aXRoIGEgZ2l2ZW4gcGVlciwgdW5sZXNz IG11bHRpcGxlICAgICAgICBpbnN0YW5jZXMgZXhpc3Qgb24gdGhlIHBlZXIsIGluIHdoaWNoLCBj YXNlIGEgc2VwYXJhdGUgY29ubmVjdGlvbiBwZXIgcHJvY2VzcyBpcyBhbGxvd2VkLiINCj4gDQo+ ICAgICAgUXVlc3Rpb25zIC0tIA0KPiAJ4oCiIERvZXMgc2VjdGlvbiAyLjEgaW1wbGljaXRseSBh c3N1bWVzIHRoYXQgbXVsdGlwbGUgZGlhbWV0ZXIgaW5zdGFuY2VzICh3aXRoaW4gYSBwZWVyKSB3 b3VsZCBjb3JyZXNwb25kIHRvIGRpZmZlcmVudCBkaWFtZXRlciBob3N0ID8gT3RoZXJ3aXNlLCBp dCBjb3VsZCBjb250cmFkaWN0IHdpdGggc2VjdGlvbiA1LjYuMQ0KDQppdCBhc3N1bWVzIG9uZSBw ZWVyIGNvbm5lY3Rpb24gcGVyIHBlZXIgc3RhdGUgbWFjaGluZS4gc28gaWYgeW91IGhhdmUgYSB3 YXkgdG8g4oCYZm9ya+KAmSBhIG5ldyBwZWVyIGluc3RhbmNlIHdpdGggaXRzIG93biBwZWVyIHN0 YXRlIG1hY2hpbmUgcGVyIGluY29taW5nIGNvbm5lY3Rpb24gdGhlbiBoYXZpbmcg4oCcbXVsdGlw bGUgaW5zdGFuY2Vz4oCZIGlzIHBvc3NpYmxlIGV2ZW4gaWYgdGhlIGRpYW1ldGVyaWRlbnRpdHkg aXMgdGhlIHNhbWUuIA0KDQo+IAnigKIgSWYgbXVsdGlwbGUgdHJhbnNwb3J0IGNvbm5lY3Rpb25z ICh0b3dhcmRzIHRoZSBzYW1lIHBlZXIpIGFyZSBhbGxvd2VkIHBlciBkaWFtZXRlciBob3N0LCBp cyBpdCBleHBlY3RlZCB0aGF0IHBlZXIgd291bGQgZG8gbG9hZCBiYWxhbmNpbmcgYmV0d2VlbiB0 aGVtPyAoVGhlcmUgaXMgYSBjb25uZWN0aW9uIGxvYWQgYmFsYW5jaW5nIHNlY3Rpb24gaW4gUkZD IDM1MzkgLSBTZWN0aW9uIDMuNC4zKQ0KDQp3aGF0IHlvdSBkbyBhbmQgaG93IHlvdSBtYW5hZ2Ug 4oCYbXVsdGlwbGUgaW5zdGFuY2Vz4oCZIGlmIG1vcmUgb3IgbGVzcyBsZWZ0IGZvciBpbXBsZW1l bnRhdGlvbiB0byBkZWNpZGUuIGkgYWx3YXlzIGNvbnNpZGVyZWQgaXQgYXMgYSBub2RlIGludGVy bmFsIGNvbXB1dGUgbG9hZCBiYWxhbmNpbmcgbWVjaGFuaXNtIGkuZS4sIHRvIGRpc3RyaWJ1dGUg dGhlIGNvbXB1dGUgdG8gc2VwYXJhdGUgY29yZXMvYmxhZGVzIGV0Yy4NCg0KDQo+IDIuIFJlZ2Fy ZGluZyBkaWFtZXRlciBwZWVyIGZhaWxiYWNrIHByb2NlZHVyZSAtDQo+IA0KPiAgICAgICBTZWN0 aW9uIDUuNS40IG1lbnRpb25zICJhIGNvbm5lY3Rpb24gcmVxdWVzdCBzaG91bGQgYmUgcGVyaW9k aWNhbGx5IGF0dGVtcHRlZCB3aXRoIHRoZSBmYWlsZWQgICAgICAgICAgICAgIHBlZXIgaW4gb3Jk ZXIgdG8gcmUtZXN0YWJsaXNoIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbiIgIA0KPiANCj4gICAg ICAgUXVlc3Rpb24gLS0gDQo+IA0KPiAJ4oCiIElmIHRoZSBmYWlsZWQgcGVlciBpcyBkeW5hbWlj YWxseSBkaXNjb3ZlcmVkIHZpYSBETlMgbG9va3VwLCBpcyBpdCBleHBlY3RlZCB0aGF0IHBlZXIg d291bGQgcGVyZm9ybSBETlMgcXVlcnkgYmVmb3JlIHRyeWluZyB0byBlc3RhYmxpc2ggdGhlIGNv bm5lY3Rpb24gYWdhaW4/IE9yIEROUyBsb29rdXAgaXMgZHJpdmVuIG9ubHkgYnkgVFRMIGZpZWxk IHJlY2VpdmVkIGluIHRoZSBwcmlvciBETlMgYW5zd2VyID8NCg0KdXAgdG8geW91ciBpbXBsZW1l bnRhdGlvbiBhbmQgZG5zIHJlc29sdmVyIGltcGxlbWVudGF0aW9uLiANCg0KLSBqb3VuaQ0KDQoN Cj4gLS0gDQo+IFJlZ2FyZHMsDQo+IEFqaW5reWEgSm9zaGkNCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlN RUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUg bWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RpbWUNCg== From nobody Wed Mar 8 01:37:00 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20C512944F for ; Wed, 8 Mar 2017 01:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=definitionnetworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmUKaFtmfnDg for ; Wed, 8 Mar 2017 01:36:55 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 10B6612943F for ; Wed, 8 Mar 2017 01:36:55 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id o24so27036508otb.1 for ; Wed, 08 Mar 2017 01:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=definitionnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y1BeLFiqddc4igejIFzTCBVvxJ+s9KLhRS+ZS1gy/bY=; b=GHsCrgjHl6G/9JcArqZqHBkd+VsR1RAnu4yqLFe+hykA/Egw/GRftwEJiR4hB3op/d 7ClzQ1i1v0MQsxwegD9t5lNnye130qRe94TO9vi2UQU80yAYyqRRovvlvdflSP5V+spU bJulBeDpm7hPiNCVLOX6NI96+/yY4CaPWfglCx15KSoDG9K2qpofVAwL2Ddv92E5q74R UfoaGmYw7BzNK4K0YZBYplU8Bmmofaq+8yDWqc/OWaWpF0jDYJGQ6x4BodwhtMBE6gWu apUMOo05rbpBcqrlHCTjH/0a4Sjwe2FW/GNJjPR6bocs0KpOczswKHqDsRKuK2gnRDYf G5lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y1BeLFiqddc4igejIFzTCBVvxJ+s9KLhRS+ZS1gy/bY=; b=hDinSMS9ELLmL97t7u4XZAANVLWDA8SFcJjEpvoXu/7lFzVqT2XngkU1XQw469SJnF q+/U5T72ea8RB+2cEnMR0J6gfPUKOay13O6JFaX0OziZ2eu8JHQtGlIFSrvznRSkYlY8 zSVdSwPiRy956ewLGqRdxmCNjvJ85ss/7airHxQsh1DJO/jYS1Alna/6KJ90uR0/DylK SB0D0/peGhmQbkLbYpo7Z23G5mruT6EmuOTLVUaU/7dE0dgBkbHdxROtASXIP/RtaoYk gWhCZXzAaxVJpU6ieAUAcY06rHLn+jYWrGacUAsTw1soRtssemu6LV5iZNbkl98luD0U 0qHA== X-Gm-Message-State: AFeK/H0cP4T12n6aaT1y57OQORUW4AANcTKRKiWSOijperE3Lv45IYGyX8YkbdD1HeAVMeigYPS2nkaIpasjBQ== X-Received: by 10.157.27.12 with SMTP id l12mr2691183otl.199.1488965814446; Wed, 08 Mar 2017 01:36:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.173 with HTTP; Wed, 8 Mar 2017 01:36:54 -0800 (PST) In-Reply-To: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> From: Ajinkya Joshi Date: Wed, 8 Mar 2017 15:06:54 +0530 Message-ID: To: "jouni.nospam" Content-Type: multipart/alternative; boundary=94eb2c09b5107400fe054a34de36 Archived-At: Cc: dime@ietf.org Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 09:36:59 -0000 --94eb2c09b5107400fe054a34de36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam wrote: > hi, > > > On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi > wrote: > > > > Hello, > > > > I have following questions regarding diameter RFC 6733, I would really > appreciate if someone can help me with these. > > > > 1. Regarding diameter peer state machine - > > > > Section 5.6.1 (Peer State Machine --> Incoming connections) mention= s > that Origin-host is used for identifying peer state machine and as pe= r > state machine, once it moves into I-Open, new CER is rejected. This > concludes, that there can't be more than one transport connections with > same diameter host (as specified by Origin-host). > > > > Section 2.1 (Transport) mentions that "A given Diameter instance of > the peer state machine MUST NOT use more than one transport connecti= on > to communicate with a given peer, unless multiple instances exist = on > the peer, in which, case a separate connection per process is allowed." > > > > Questions -- > > =E2=80=A2 Does section 2.1 implicitly assumes that multiple diame= ter > instances (within a peer) would correspond to different diameter host ? > Otherwise, it could contradict with section 5.6.1 > > it assumes one peer connection per peer state machine. so if you have a > way to =E2=80=98fork=E2=80=99 a new peer instance with its own peer state= machine per > incoming connection then having =E2=80=9Cmultiple instances=E2=80=99 is p= ossible even if > the diameteridentity is the same. > [ajoshi] If we fork a new peer instance with same diameteridentity, won't it create problems as per peer state machine? Because, you would have separate transport connection for each of them and each transport connection needs capability exchange and as per peer state machine, there can be only one capability exchange. I am inferring this based on section 5.3 which says "When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages". Am I missing something here? Or is it the case that two peers (identified based on their respective diameter host-names) would perform capability exchange only once, irrespective of number of transport connections they have? > > > =E2=80=A2 If multiple transport connections (towards the same pee= r) are > allowed per diameter host, is it expected that peer would do load balanci= ng > between them? (There is a connection load balancing section in RFC 3539 - > Section 3.4.3) > > what you do and how you manage =E2=80=98multiple instances=E2=80=99 if mo= re or less left > for implementation to decide. i always considered it as a node internal > compute load balancing mechanism i.e., to distribute the compute to > separate cores/blades etc. > > > > 2. Regarding diameter peer failback procedure - > > > > Section 5.5.4 mentions "a connection request should be > periodically attempted with the failed peer in order to > re-establish the transport connection" > > > > Question -- > > > > =E2=80=A2 If the failed peer is dynamically discovered via DNS lo= okup, is > it expected that peer would perform DNS query before trying to establish > the connection again? Or DNS lookup is driven only by TTL field received = in > the prior DNS answer ? > > up to your implementation and dns resolver implementation. > > - jouni > > > > -- > > Regards, > > Ajinkya Joshi > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > --=20 Regards, Ajinkya Joshi --94eb2c09b5107400fe054a34de36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <jouni.nospam@gmail= .com> wrote:
hi,

> On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <ajoshi@definitionnetworks.com> wrote:<= br> >
> Hello,
>
> I have following questions regarding diameter RFC 6733, I would really= appreciate if someone can help me with these.
>
> 1. Regarding diameter peer state machine -
>
>=C2=A0 =C2=A0 =C2=A0Section 5.6.1 (Peer State Machine --> Incoming c= onnections) mentions that Origin-host is used for=C2=A0 =C2=A0 =C2=A0identi= fying peer state machine and as per state machine, once it moves into I-Ope= n, new CER is=C2=A0 =C2=A0 =C2=A0 =C2=A0rejected. This concludes, that ther= e can't be more than one transport connections with same=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diameter host (as specified by Ori= gin-host).
>
>=C2=A0 =C2=A0 =C2=A0Section 2.1 (Transport) mentions that "A given= Diameter instance of the peer state machine MUST=C2=A0 =C2=A0 =C2=A0 NOT u= se more than one transport connection to communicate with a given peer, unl= ess multiple=C2=A0 =C2=A0 =C2=A0 =C2=A0 instances exist on the peer, in whi= ch, case a separate connection per process is allowed."
>
>=C2=A0 =C2=A0 =C2=A0 Questions --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Does section 2.1 implicitly assume= s that multiple diameter instances (within a peer) would correspond to diff= erent diameter host ? Otherwise, it could contradict with section 5.6.1

it assumes one peer connection per peer state machine. so if you hav= e a way to =E2=80=98fork=E2=80=99 a new peer instance with its own peer sta= te machine per incoming connection then having =E2=80=9Cmultiple instances= =E2=80=99 is possible even if the diameteridentity is the same.

[ajoshi] If we fork a new peer instance with same = diameteridentity, won't it create problems as per peer state machine? B= ecause, you would have separate transport connection for each of them and e= ach transport connection needs capability exchange and as per peer state ma= chine, there can be only one capability exchange. I am inferring this based= on section 5.3 which says "When two Diameter peers establish a transp= ort connection, they MUST exchange the Capabilities Exchange messages"= . Am I missing something here? Or is it the case that two peers (identified= based on their respective diameter host-names) would perform capability ex= change only once, irrespective of number of transport connections they have= ?
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If multiple transport connections = (towards the same peer) are allowed per diameter host, is it expected that = peer would do load balancing between them? (There is a connection load bala= ncing section in RFC 3539 - Section 3.4.3)

what you do and how you manage =E2=80=98multiple instances=E2=80=99 if more= or less left for implementation to decide. i always considered it as a nod= e internal compute load balancing mechanism i.e., to distribute the compute= to separate cores/blades etc.


> 2. Regarding diameter peer failback procedure -
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.5.4 mentions "a connection re= quest should be periodically attempted with the failed=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 peer in order to re-establish the transport con= nection"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question --
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If the failed peer is dynamically = discovered via DNS lookup, is it expected that peer would perform DNS query= before trying to establish the connection again? Or DNS lookup is driven o= nly by TTL field received in the prior DNS answer ?

up to your implementation and dns resolver implementation.

- jouni


> --
> Regards,
> Ajinkya Joshi
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime



--
Regards,
Ajinkya Joshi
--94eb2c09b5107400fe054a34de36-- From nobody Wed Mar 8 03:01:08 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80A129556 for ; Wed, 8 Mar 2017 03:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfhtcxcKxFYV for ; Wed, 8 Mar 2017 03:01:05 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9641270B4 for ; Wed, 8 Mar 2017 03:01:04 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 7180E404E6; Wed, 8 Mar 2017 12:01:02 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 33A111A008A; Wed, 8 Mar 2017 12:01:02 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 12:01:02 +0100 From: To: Yuval Lifshitz , jouni.nospam , Ajinkya Joshi Thread-Topic: [Dime] Questions regarding RFC 6733 Thread-Index: AQHSl1U+rua+IhzsXUSySTVeMQxEMKGJgfoAgAD3IgCAAE3uwA== Date: Wed, 8 Mar 2017 11:01:01 +0000 Message-ID: <24907_1488970862_58BFE46E_24907_189_2_6B7134B31289DC4FAF731D844122B36E0C06F1D5@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:01:07 -0000 SGkgWXV2YWwsDQoNClBlciBjb25uZWN0aW9uLCB5b3Ugd2lsbCBiZSBhYmxlIHRvIHRlc3QgdGhl IGxpdmVuZXNzIG9mIHRoZSBjb25uZWN0aW9uIChTQ1RQLCBEVywgZXRjLikuIElmIHNvbWV0aGlu ZyBpcyB3cm9uZywgeW91IHdpbGwgYmUgYWJsZSB0byBkZXRlY3QgaXQgYW5kIHRlYXIgZG93biB0 aGUgY29ubmVjdGlvbi4NCkFuZCB0aGVuIGFjY2VwdCB0aGUgbmV3IENFUiBpZiByZWNlaXZlZC4N Cg0KUmVnYXJkcywNCg0KTGlvbmVsDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUg WXV2YWwgTGlmc2hpdHoNCj4gRW52b3nDqcKgOiBtZXJjcmVkaSA4IG1hcnMgMjAxNyAwODoxOQ0K PiDDgMKgOiBqb3VuaS5ub3NwYW07IEFqaW5reWEgSm9zaGkNCj4gQ2PCoDogZGltZUBpZXRmLm9y Zw0KPiBPYmpldMKgOiBSZTogW0RpbWVdIFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDY3MzMNCj4g DQo+IFJlZ2FyZGluZyAoMSksIGFub3RoZXIgcG9zc2libGUgaW1wbGVtZW50YXRpb24gd291bGQg YmUgdGhhdCB1cG9uIHJlY2VpdmluZyBhDQo+IG5ldyBjb25uZWN0aW9uIGZyb20gdGhlIHNhbWUg aG9zdCwgeW91IHdvdWxkIHRlYXIgZG93biB0aGUgZXhpc3RpbmcNCj4gY29ubmVjdGlvbiBhbmQg YWxsb3cgdGhlIG5ldyBvbmUuIFRoaXMgd291bGQgYmUgdXNlZnVsIGluIHRoZSBjYXNlIHRoYXQg YSBjbGllbnQNCj4gYmVjYW1lIGRlYWRsb2NrZWQgb3IgZGlkbid0IHNodXRkb3duIHByb3Blcmx5 LCBhbmQgYSBuZXcgY2xpZW50IHRyaWVzIHRvIHRha2UNCj4gb3ZlciBhbmQgY29udGludWUgdGhl IHdvcmsgb2YgdGhlIHN0YWxsZWQgb25lcy4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBqb3VuaS5ub3NwYW0NCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMDcsIDIwMTcgNjozNSBQ TQ0KPiBUbzogQWppbmt5YSBKb3NoaQ0KPiBDYzogZGltZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW0RpbWVdIFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDY3MzMNCj4gDQo+IGhpLA0KPiANCj4g PiBPbiBNYXIgNywgMjAxNywgYXQgMzowMSBBTSwgQWppbmt5YSBKb3NoaSA8YWpvc2hpQGRlZmlu aXRpb25uZXR3b3Jrcy5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBJ IGhhdmUgZm9sbG93aW5nIHF1ZXN0aW9ucyByZWdhcmRpbmcgZGlhbWV0ZXIgUkZDIDY3MzMsIEkg d291bGQgcmVhbGx5DQo+IGFwcHJlY2lhdGUgaWYgc29tZW9uZSBjYW4gaGVscCBtZSB3aXRoIHRo ZXNlLg0KPiA+DQo+ID4gMS4gUmVnYXJkaW5nIGRpYW1ldGVyIHBlZXIgc3RhdGUgbWFjaGluZSAt DQo+ID4NCj4gPiAgICAgU2VjdGlvbiA1LjYuMSAoUGVlciBTdGF0ZSBNYWNoaW5lIC0tPiBJbmNv bWluZyBjb25uZWN0aW9ucykgbWVudGlvbnMgdGhhdA0KPiBPcmlnaW4taG9zdCBpcyB1c2VkIGZv ciAgICAgaWRlbnRpZnlpbmcgcGVlciBzdGF0ZSBtYWNoaW5lIGFuZCBhcyBwZXIgc3RhdGUNCj4g bWFjaGluZSwgb25jZSBpdCBtb3ZlcyBpbnRvIEktT3BlbiwgbmV3IENFUiBpcyAgICAgICByZWpl Y3RlZC4gVGhpcyBjb25jbHVkZXMsDQo+IHRoYXQgdGhlcmUgY2FuJ3QgYmUgbW9yZSB0aGFuIG9u ZSB0cmFuc3BvcnQgY29ubmVjdGlvbnMgd2l0aCBzYW1lDQo+IGRpYW1ldGVyIGhvc3QgKGFzIHNw ZWNpZmllZCBieSBPcmlnaW4taG9zdCkuDQo+ID4NCj4gPiAgICAgU2VjdGlvbiAyLjEgKFRyYW5z cG9ydCkgbWVudGlvbnMgdGhhdCAiQSBnaXZlbiBEaWFtZXRlciBpbnN0YW5jZSBvZiB0aGUgcGVl cg0KPiBzdGF0ZSBtYWNoaW5lIE1VU1QgICAgICBOT1QgdXNlIG1vcmUgdGhhbiBvbmUgdHJhbnNw b3J0IGNvbm5lY3Rpb24gdG8NCj4gY29tbXVuaWNhdGUgd2l0aCBhIGdpdmVuIHBlZXIsIHVubGVz cyBtdWx0aXBsZSAgICAgICAgaW5zdGFuY2VzIGV4aXN0IG9uIHRoZSBwZWVyLA0KPiBpbiB3aGlj aCwgY2FzZSBhIHNlcGFyYXRlIGNvbm5lY3Rpb24gcGVyIHByb2Nlc3MgaXMgYWxsb3dlZC4iDQo+ ID4NCj4gPiAgICAgIFF1ZXN0aW9ucyAtLQ0KPiA+IAnigKIgRG9lcyBzZWN0aW9uIDIuMSBpbXBs aWNpdGx5IGFzc3VtZXMgdGhhdCBtdWx0aXBsZSBkaWFtZXRlciBpbnN0YW5jZXMNCj4gKHdpdGhp biBhIHBlZXIpIHdvdWxkIGNvcnJlc3BvbmQgdG8gZGlmZmVyZW50IGRpYW1ldGVyIGhvc3QgPyBP dGhlcndpc2UsIGl0DQo+IGNvdWxkIGNvbnRyYWRpY3Qgd2l0aCBzZWN0aW9uIDUuNi4xDQo+IA0K PiBpdCBhc3N1bWVzIG9uZSBwZWVyIGNvbm5lY3Rpb24gcGVyIHBlZXIgc3RhdGUgbWFjaGluZS4g c28gaWYgeW91IGhhdmUgYSB3YXkgdG8NCj4g4oCYZm9ya+KAmSBhIG5ldyBwZWVyIGluc3RhbmNl IHdpdGggaXRzIG93biBwZWVyIHN0YXRlIG1hY2hpbmUgcGVyIGluY29taW5nDQo+IGNvbm5lY3Rp b24gdGhlbiBoYXZpbmcg4oCcbXVsdGlwbGUgaW5zdGFuY2Vz4oCZIGlzIHBvc3NpYmxlIGV2ZW4g aWYgdGhlDQo+IGRpYW1ldGVyaWRlbnRpdHkgaXMgdGhlIHNhbWUuDQo+IA0KPiA+IAnigKIgSWYg bXVsdGlwbGUgdHJhbnNwb3J0IGNvbm5lY3Rpb25zICh0b3dhcmRzIHRoZSBzYW1lIHBlZXIpIGFy ZSBhbGxvd2VkDQo+IHBlciBkaWFtZXRlciBob3N0LCBpcyBpdCBleHBlY3RlZCB0aGF0IHBlZXIg d291bGQgZG8gbG9hZCBiYWxhbmNpbmcgYmV0d2Vlbg0KPiB0aGVtPyAoVGhlcmUgaXMgYSBjb25u ZWN0aW9uIGxvYWQgYmFsYW5jaW5nIHNlY3Rpb24gaW4gUkZDIDM1MzkgLSBTZWN0aW9uIDMuNC4z KQ0KPiANCj4gd2hhdCB5b3UgZG8gYW5kIGhvdyB5b3UgbWFuYWdlIOKAmG11bHRpcGxlIGluc3Rh bmNlc+KAmSBpZiBtb3JlIG9yIGxlc3MgbGVmdCBmb3INCj4gaW1wbGVtZW50YXRpb24gdG8gZGVj aWRlLiBpIGFsd2F5cyBjb25zaWRlcmVkIGl0IGFzIGEgbm9kZSBpbnRlcm5hbCBjb21wdXRlDQo+ IGxvYWQgYmFsYW5jaW5nIG1lY2hhbmlzbSBpLmUuLCB0byBkaXN0cmlidXRlIHRoZSBjb21wdXRl IHRvIHNlcGFyYXRlDQo+IGNvcmVzL2JsYWRlcyBldGMuDQo+IA0KPiANCj4gPiAyLiBSZWdhcmRp bmcgZGlhbWV0ZXIgcGVlciBmYWlsYmFjayBwcm9jZWR1cmUgLQ0KPiA+DQo+ID4gICAgICAgU2Vj dGlvbiA1LjUuNCBtZW50aW9ucyAiYSBjb25uZWN0aW9uIHJlcXVlc3Qgc2hvdWxkIGJlIHBlcmlv ZGljYWxseQ0KPiBhdHRlbXB0ZWQgd2l0aCB0aGUgZmFpbGVkICAgICAgICAgICAgICBwZWVyIGlu IG9yZGVyIHRvIHJlLWVzdGFibGlzaCB0aGUgdHJhbnNwb3J0DQo+IGNvbm5lY3Rpb24iDQo+ID4N Cj4gPiAgICAgICBRdWVzdGlvbiAtLQ0KPiA+DQo+ID4gCeKAoiBJZiB0aGUgZmFpbGVkIHBlZXIg aXMgZHluYW1pY2FsbHkgZGlzY292ZXJlZCB2aWEgRE5TIGxvb2t1cCwgaXMgaXQNCj4gZXhwZWN0 ZWQgdGhhdCBwZWVyIHdvdWxkIHBlcmZvcm0gRE5TIHF1ZXJ5IGJlZm9yZSB0cnlpbmcgdG8gZXN0 YWJsaXNoIHRoZQ0KPiBjb25uZWN0aW9uIGFnYWluPyBPciBETlMgbG9va3VwIGlzIGRyaXZlbiBv bmx5IGJ5IFRUTCBmaWVsZCByZWNlaXZlZCBpbiB0aGUgcHJpb3INCj4gRE5TIGFuc3dlciA/DQo+ IA0KPiB1cCB0byB5b3VyIGltcGxlbWVudGF0aW9uIGFuZCBkbnMgcmVzb2x2ZXIgaW1wbGVtZW50 YXRpb24uDQo+IA0KPiAtIGpvdW5pDQo+IA0KPiANCj4gPiAtLQ0KPiA+IFJlZ2FyZHMsDQo+ID4g QWppbmt5YSBKb3NoaQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcg bGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Mar 8 03:09:16 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6805D129555 for ; Wed, 8 Mar 2017 03:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v48pHtJv5pz1 for ; Wed, 8 Mar 2017 03:09:09 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1131270B4 for ; Wed, 8 Mar 2017 03:09:08 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 30BBE404EC; Wed, 8 Mar 2017 12:09:07 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id ECFC31A0098; Wed, 8 Mar 2017 12:09:06 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 12:09:06 +0100 From: To: Ajinkya Joshi , jouni.nospam Thread-Topic: [Dime] Questions regarding RFC 6733 Thread-Index: AQHSl1U+rua+IhzsXUSySTVeMQxEMKGJgfoAgAEdogCAAChe8A== Date: Wed, 8 Mar 2017 11:09:05 +0000 Message-ID: <29819_1488971347_58BFE653_29819_5_3_6B7134B31289DC4FAF731D844122B36E0C06F1EB@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C06F1EBOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 11:09:15 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C06F1EBOPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWppbmt5YSwNCg0KVGhpcyB3aWxsIGRlcGVuZCBvbiBob3cgeW91ciAiZm9yayIgaXMgaW1w bGVtZW50ZWQgYW5kIGl0IGlzIHdoeSBpdCBpcyBjb25zaWRlcmVkIGFzICJpbXBsZW1lbnRhdGlv bi1zcGVjaWZpYyIuDQpJZiBOIGluc3RhbmNlcyBhcmUgc2hhcmluZyB0aGUgc2FtZSBEaWFtZXRl ciBpZCAoRGlhbUlkIDEpLCB5b3UgbWF5IGhhdmUgYSB3YXkgdG8gY29uc2lkZXIgdGhlIGNvbm5l Y3Rpb24gdXAgYXMgbG9uZyBhcyBvbmUgaW5zdGFuY2UgaW5zaWRlIHRoZSBwZWVyIGlzIGF2YWls YWJsZSBhbmQgYWN0aXZlLiBJbiB0aGF0IGNhc2UsIHRoZXJlIGlzIG5vIGltcGFjdCBmb3Igb3Ro ZXIgZGlhbWV0ZXIgcGVlcnMgaW4gdGhlIG5ldHdvcmsuIEZvciB0aGUgb3V0c2lkZSB3b3JsZCwg dGhlcmUgd291bGQgYmUgb25seSBvbmUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gb3BlbmVkIHdpdGgg IkRpYW1JZCAxIiwgaW5kZXBlbmRlbnRseSBvZiB0aGUgbnVtYmVyIG9mIGluc3RhbmNlIGJlaGlu ZCAiRGlhbUlkIDEiLg0KDQpMaW9uZWwNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEFqaW5reWEgSm9zaGkNCkVudm95w6kgOiBtZXJjcmVk aSA4IG1hcnMgMjAxNyAxMDozNw0Kw4AgOiBqb3VuaS5ub3NwYW0NCkNjIDogZGltZUBpZXRmLm9y Zw0KT2JqZXQgOiBSZTogW0RpbWVdIFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDY3MzMNCg0KDQoN Ck9uIFR1ZSwgTWFyIDcsIDIwMTcgYXQgMTA6MDQgUE0sIGpvdW5pLm5vc3BhbSA8am91bmkubm9z cGFtQGdtYWlsLmNvbTxtYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbT4+IHdyb3RlOg0KaGks DQoNCj4gT24gTWFyIDcsIDIwMTcsIGF0IDM6MDEgQU0sIEFqaW5reWEgSm9zaGkgPGFqb3NoaUBk ZWZpbml0aW9ubmV0d29ya3MuY29tPG1haWx0bzpham9zaGlAZGVmaW5pdGlvbm5ldHdvcmtzLmNv bT4+IHdyb3RlOg0KPg0KPiBIZWxsbywNCj4NCj4gSSBoYXZlIGZvbGxvd2luZyBxdWVzdGlvbnMg cmVnYXJkaW5nIGRpYW1ldGVyIFJGQyA2NzMzLCBJIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGlm IHNvbWVvbmUgY2FuIGhlbHAgbWUgd2l0aCB0aGVzZS4NCj4NCj4gMS4gUmVnYXJkaW5nIGRpYW1l dGVyIHBlZXIgc3RhdGUgbWFjaGluZSAtDQo+DQo+ICAgICBTZWN0aW9uIDUuNi4xIChQZWVyIFN0 YXRlIE1hY2hpbmUgLS0+IEluY29taW5nIGNvbm5lY3Rpb25zKSBtZW50aW9ucyB0aGF0IE9yaWdp bi1ob3N0IGlzIHVzZWQgZm9yICAgICBpZGVudGlmeWluZyBwZWVyIHN0YXRlIG1hY2hpbmUgYW5k IGFzIHBlciBzdGF0ZSBtYWNoaW5lLCBvbmNlIGl0IG1vdmVzIGludG8gSS1PcGVuLCBuZXcgQ0VS IGlzICAgICAgIHJlamVjdGVkLiBUaGlzIGNvbmNsdWRlcywgdGhhdCB0aGVyZSBjYW4ndCBiZSBt b3JlIHRoYW4gb25lIHRyYW5zcG9ydCBjb25uZWN0aW9ucyB3aXRoIHNhbWUgICAgICAgICAgICAg ICBkaWFtZXRlciBob3N0IChhcyBzcGVjaWZpZWQgYnkgT3JpZ2luLWhvc3QpLg0KPg0KPiAgICAg U2VjdGlvbiAyLjEgKFRyYW5zcG9ydCkgbWVudGlvbnMgdGhhdCAiQSBnaXZlbiBEaWFtZXRlciBp bnN0YW5jZSBvZiB0aGUgcGVlciBzdGF0ZSBtYWNoaW5lIE1VU1QgICAgICBOT1QgdXNlIG1vcmUg dGhhbiBvbmUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gdG8gY29tbXVuaWNhdGUgd2l0aCBhIGdpdmVu IHBlZXIsIHVubGVzcyBtdWx0aXBsZSAgICAgICAgaW5zdGFuY2VzIGV4aXN0IG9uIHRoZSBwZWVy LCBpbiB3aGljaCwgY2FzZSBhIHNlcGFyYXRlIGNvbm5lY3Rpb24gcGVyIHByb2Nlc3MgaXMgYWxs b3dlZC4iDQo+DQo+ICAgICAgUXVlc3Rpb25zIC0tDQo+ICAgICAgIOKAoiBEb2VzIHNlY3Rpb24g Mi4xIGltcGxpY2l0bHkgYXNzdW1lcyB0aGF0IG11bHRpcGxlIGRpYW1ldGVyIGluc3RhbmNlcyAo d2l0aGluIGEgcGVlcikgd291bGQgY29ycmVzcG9uZCB0byBkaWZmZXJlbnQgZGlhbWV0ZXIgaG9z dCA/IE90aGVyd2lzZSwgaXQgY291bGQgY29udHJhZGljdCB3aXRoIHNlY3Rpb24gNS42LjENCg0K aXQgYXNzdW1lcyBvbmUgcGVlciBjb25uZWN0aW9uIHBlciBwZWVyIHN0YXRlIG1hY2hpbmUuIHNv IGlmIHlvdSBoYXZlIGEgd2F5IHRvIOKAmGZvcmvigJkgYSBuZXcgcGVlciBpbnN0YW5jZSB3aXRo IGl0cyBvd24gcGVlciBzdGF0ZSBtYWNoaW5lIHBlciBpbmNvbWluZyBjb25uZWN0aW9uIHRoZW4g aGF2aW5nIOKAnG11bHRpcGxlIGluc3RhbmNlc+KAmSBpcyBwb3NzaWJsZSBldmVuIGlmIHRoZSBk aWFtZXRlcmlkZW50aXR5IGlzIHRoZSBzYW1lLg0KDQpbYWpvc2hpXSBJZiB3ZSBmb3JrIGEgbmV3 IHBlZXIgaW5zdGFuY2Ugd2l0aCBzYW1lIGRpYW1ldGVyaWRlbnRpdHksIHdvbid0IGl0IGNyZWF0 ZSBwcm9ibGVtcyBhcyBwZXIgcGVlciBzdGF0ZSBtYWNoaW5lPyBCZWNhdXNlLCB5b3Ugd291bGQg aGF2ZSBzZXBhcmF0ZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBmb3IgZWFjaCBvZiB0aGVtIGFuZCBl YWNoIHRyYW5zcG9ydCBjb25uZWN0aW9uIG5lZWRzIGNhcGFiaWxpdHkgZXhjaGFuZ2UgYW5kIGFz IHBlciBwZWVyIHN0YXRlIG1hY2hpbmUsIHRoZXJlIGNhbiBiZSBvbmx5IG9uZSBjYXBhYmlsaXR5 IGV4Y2hhbmdlLiBJIGFtIGluZmVycmluZyB0aGlzIGJhc2VkIG9uIHNlY3Rpb24gNS4zIHdoaWNo IHNheXMgIldoZW4gdHdvIERpYW1ldGVyIHBlZXJzIGVzdGFibGlzaCBhIHRyYW5zcG9ydCBjb25u ZWN0aW9uLCB0aGV5IE1VU1QgZXhjaGFuZ2UgdGhlIENhcGFiaWxpdGllcyBFeGNoYW5nZSBtZXNz YWdlcyIuIEFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8gT3IgaXMgaXQgdGhlIGNhc2UgdGhh dCB0d28gcGVlcnMgKGlkZW50aWZpZWQgYmFzZWQgb24gdGhlaXIgcmVzcGVjdGl2ZSBkaWFtZXRl ciBob3N0LW5hbWVzKSB3b3VsZCBwZXJmb3JtIGNhcGFiaWxpdHkgZXhjaGFuZ2Ugb25seSBvbmNl LCBpcnJlc3BlY3RpdmUgb2YgbnVtYmVyIG9mIHRyYW5zcG9ydCBjb25uZWN0aW9ucyB0aGV5IGhh dmU/DQoNCg0KPiAgICAgICDigKIgSWYgbXVsdGlwbGUgdHJhbnNwb3J0IGNvbm5lY3Rpb25zICh0 b3dhcmRzIHRoZSBzYW1lIHBlZXIpIGFyZSBhbGxvd2VkIHBlciBkaWFtZXRlciBob3N0LCBpcyBp dCBleHBlY3RlZCB0aGF0IHBlZXIgd291bGQgZG8gbG9hZCBiYWxhbmNpbmcgYmV0d2VlbiB0aGVt PyAoVGhlcmUgaXMgYSBjb25uZWN0aW9uIGxvYWQgYmFsYW5jaW5nIHNlY3Rpb24gaW4gUkZDIDM1 MzkgLSBTZWN0aW9uIDMuNC4zKQ0KDQp3aGF0IHlvdSBkbyBhbmQgaG93IHlvdSBtYW5hZ2Ug4oCY bXVsdGlwbGUgaW5zdGFuY2Vz4oCZIGlmIG1vcmUgb3IgbGVzcyBsZWZ0IGZvciBpbXBsZW1lbnRh dGlvbiB0byBkZWNpZGUuIGkgYWx3YXlzIGNvbnNpZGVyZWQgaXQgYXMgYSBub2RlIGludGVybmFs IGNvbXB1dGUgbG9hZCBiYWxhbmNpbmcgbWVjaGFuaXNtIGkuZS4sIHRvIGRpc3RyaWJ1dGUgdGhl IGNvbXB1dGUgdG8gc2VwYXJhdGUgY29yZXMvYmxhZGVzIGV0Yy4NCg0KDQo+IDIuIFJlZ2FyZGlu ZyBkaWFtZXRlciBwZWVyIGZhaWxiYWNrIHByb2NlZHVyZSAtDQo+DQo+ICAgICAgIFNlY3Rpb24g NS41LjQgbWVudGlvbnMgImEgY29ubmVjdGlvbiByZXF1ZXN0IHNob3VsZCBiZSBwZXJpb2RpY2Fs bHkgYXR0ZW1wdGVkIHdpdGggdGhlIGZhaWxlZCAgICAgICAgICAgICAgcGVlciBpbiBvcmRlciB0 byByZS1lc3RhYmxpc2ggdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uIg0KPg0KPiAgICAgICBRdWVz dGlvbiAtLQ0KPg0KPiAgICAgICDigKIgSWYgdGhlIGZhaWxlZCBwZWVyIGlzIGR5bmFtaWNhbGx5 IGRpc2NvdmVyZWQgdmlhIEROUyBsb29rdXAsIGlzIGl0IGV4cGVjdGVkIHRoYXQgcGVlciB3b3Vs ZCBwZXJmb3JtIEROUyBxdWVyeSBiZWZvcmUgdHJ5aW5nIHRvIGVzdGFibGlzaCB0aGUgY29ubmVj dGlvbiBhZ2Fpbj8gT3IgRE5TIGxvb2t1cCBpcyBkcml2ZW4gb25seSBieSBUVEwgZmllbGQgcmVj ZWl2ZWQgaW4gdGhlIHByaW9yIEROUyBhbnN3ZXIgPw0KDQp1cCB0byB5b3VyIGltcGxlbWVudGF0 aW9uIGFuZCBkbnMgcmVzb2x2ZXIgaW1wbGVtZW50YXRpb24uDQoNCi0gam91bmkNCg0KDQo+IC0t DQo+IFJlZ2FyZHMsDQo+IEFqaW5reWEgSm9zaGkNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRm Lm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaW1lDQoNCg0KDQotLQ0KUmVnYXJkcywNCkFqaW5reWEgSm9zaGkNCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuClRoYW5rIHlvdS4KCg== --_000_6B7134B31289DC4FAF731D844122B36E0C06F1EBOPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxl LW5hbWU6Z21haWwtO30NCnNwYW4uZ21haWwtaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmdtYWls LWhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpIEFqaW5reWEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB3aWxsIGRlcGVuZCBvbiBo b3cgeW91ciAmcXVvdDtmb3JrJnF1b3Q7IGlzIGltcGxlbWVudGVkIGFuZCBpdCBpcyB3aHkgaXQg aXMgY29uc2lkZXJlZCBhcyAmcXVvdDtpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyZxdW90Oy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIE4gaW5zdGFuY2VzIGFy ZSBzaGFyaW5nIHRoZSBzYW1lIERpYW1ldGVyIGlkIChEaWFtSWQgMSksIHlvdSBtYXkgaGF2ZSBh IHdheSB0byBjb25zaWRlciB0aGUgY29ubmVjdGlvbiB1cCBhcyBsb25nIGFzIG9uZSBpbnN0YW5j ZSBpbnNpZGUgdGhlDQogcGVlciBpcyBhdmFpbGFibGUgYW5kIGFjdGl2ZS4gSW4gdGhhdCBjYXNl LCB0aGVyZSBpcyBubyBpbXBhY3QgZm9yIG90aGVyIGRpYW1ldGVyIHBlZXJzIGluIHRoZSBuZXR3 b3JrLiBGb3IgdGhlIG91dHNpZGUgd29ybGQsIHRoZXJlIHdvdWxkIGJlIG9ubHkgb25lIHRyYW5z cG9ydCBjb25uZWN0aW9uIG9wZW5lZCB3aXRoICZxdW90O0RpYW1JZCAxJnF1b3Q7LCBpbmRlcGVu ZGVudGx5IG9mIHRoZSBudW1iZXIgb2YgaW5zdGFuY2UgYmVoaW5kICZxdW90O0RpYW1JZCAxJnF1 b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEaU1F IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gQWpp bmt5YSBKb3NoaTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSA4IG1hcnMgMjAx NyAxMDozNzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gam91bmkubm9zcGFtPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBkaW1lQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVd IFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDY3MzM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgNywgMjAxNyBhdCAxMDowNCBQTSwgam91bmkubm9z cGFtICZsdDs8YSBocmVmPSJtYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmpvdW5pLm5vc3BhbUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhpLDxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJnbWFp bC0iPiZndDsgT24gTWFyIDcsIDIwMTcsIGF0IDM6MDEgQU0sIEFqaW5reWEgSm9zaGkgJmx0Ozxh IGhyZWY9Im1haWx0bzpham9zaGlAZGVmaW5pdGlvbm5ldHdvcmtzLmNvbSI+YWpvc2hpQGRlZmlu aXRpb25uZXR3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImdtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IEhlbGxv LDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJnbWFpbC0iPiZndDsgSSBoYXZlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVnYXJkaW5n IGRpYW1ldGVyIFJGQyA2NzMzLCBJIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGlmIHNvbWVvbmUg Y2FuIGhlbHAgbWUgd2l0aCB0aGVzZS48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+ Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IDEuIFJlZ2FyZGluZyBk aWFtZXRlciBwZWVyIHN0YXRlIG1hY2hpbmUgLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21h aWwtIj4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO1NlY3Rpb24gNS42LjEgKFBlZXIgU3RhdGUgTWFjaGluZSAtLSZndDsgSW5jb21p bmcgY29ubmVjdGlvbnMpIG1lbnRpb25zIHRoYXQgT3JpZ2luLWhvc3QgaXMgdXNlZCBmb3ImbmJz cDsgJm5ic3A7ICZuYnNwO2lkZW50aWZ5aW5nIHBlZXIgc3RhdGUgbWFjaGluZSBhbmQgYXMgcGVy IHN0YXRlIG1hY2hpbmUsIG9uY2UgaXQgbW92ZXMgaW50byBJLU9wZW4sIG5ldyBDRVIgaXMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWplY3RlZC4gVGhpcyBjb25jbHVkZXMsIHRoYXQNCiB0 aGVyZSBjYW4ndCBiZSBtb3JlIHRoYW4gb25lIHRyYW5zcG9ydCBjb25uZWN0aW9ucyB3aXRoIHNh bWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZGlhbWV0ZXIgaG9zdCAoYXMgc3BlY2lmaWVkIGJ5IE9yaWdpbi1ob3N0KS48L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwt Ij4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtTZWN0aW9uIDIuMSAoVHJhbnNwb3J0KSBtZW50aW9u cyB0aGF0ICZxdW90O0EgZ2l2ZW4gRGlhbWV0ZXIgaW5zdGFuY2Ugb2YgdGhlIHBlZXIgc3RhdGUg bWFjaGluZSBNVVNUJm5ic3A7ICZuYnNwOyAmbmJzcDsgTk9UIHVzZSBtb3JlIHRoYW4gb25lIHRy YW5zcG9ydCBjb25uZWN0aW9uIHRvIGNvbW11bmljYXRlIHdpdGggYSBnaXZlbiBwZWVyLCB1bmxl c3MgbXVsdGlwbGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5zdGFuY2VzIGV4aXN0IG9u IHRoZSBwZWVyLA0KIGluIHdoaWNoLCBjYXNlIGEgc2VwYXJhdGUgY29ubmVjdGlvbiBwZXIgcHJv Y2VzcyBpcyBhbGxvd2VkLiZxdW90Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4m Z3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyBRdWVzdGlvbnMgLS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO+KAoiBEb2VzIHNlY3Rpb24gMi4xIGltcGxpY2l0bHkg YXNzdW1lcyB0aGF0IG11bHRpcGxlIGRpYW1ldGVyIGluc3RhbmNlcyAod2l0aGluIGEgcGVlcikg d291bGQgY29ycmVzcG9uZCB0byBkaWZmZXJlbnQgZGlhbWV0ZXIgaG9zdCA/IE90aGVyd2lzZSwg aXQgY291bGQgY29udHJhZGljdCB3aXRoIHNlY3Rpb24gNS42LjE8L3NwYW4+PGJyPg0KPGJyPg0K aXQgYXNzdW1lcyBvbmUgcGVlciBjb25uZWN0aW9uIHBlciBwZWVyIHN0YXRlIG1hY2hpbmUuIHNv IGlmIHlvdSBoYXZlIGEgd2F5IHRvIOKAmGZvcmvigJkgYSBuZXcgcGVlciBpbnN0YW5jZSB3aXRo IGl0cyBvd24gcGVlciBzdGF0ZSBtYWNoaW5lIHBlciBpbmNvbWluZyBjb25uZWN0aW9uIHRoZW4g aGF2aW5nIOKAnG11bHRpcGxlIGluc3RhbmNlc+KAmSBpcyBwb3NzaWJsZSBldmVuIGlmIHRoZSBk aWFtZXRlcmlkZW50aXR5IGlzIHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+W2Fqb3NoaV0gSWYgd2UgZm9yayBhIG5ldyBwZWVyIGluc3RhbmNl IHdpdGggc2FtZSBkaWFtZXRlcmlkZW50aXR5LCB3b24ndCBpdCBjcmVhdGUgcHJvYmxlbXMgYXMg cGVyIHBlZXIgc3RhdGUgbWFjaGluZT8gQmVjYXVzZSwgeW91IHdvdWxkIGhhdmUgc2VwYXJhdGUg dHJhbnNwb3J0IGNvbm5lY3Rpb24gZm9yIGVhY2ggb2YgdGhlbSBhbmQgZWFjaCB0cmFuc3BvcnQg Y29ubmVjdGlvbiBuZWVkcyBjYXBhYmlsaXR5DQogZXhjaGFuZ2UgYW5kIGFzIHBlciBwZWVyIHN0 YXRlIG1hY2hpbmUsIHRoZXJlIGNhbiBiZSBvbmx5IG9uZSBjYXBhYmlsaXR5IGV4Y2hhbmdlLiBJ IGFtIGluZmVycmluZyB0aGlzIGJhc2VkIG9uIHNlY3Rpb24gNS4zIHdoaWNoIHNheXMgJnF1b3Q7 V2hlbiB0d28gRGlhbWV0ZXIgcGVlcnMgZXN0YWJsaXNoIGEgdHJhbnNwb3J0IGNvbm5lY3Rpb24s IHRoZXkgTVVTVCBleGNoYW5nZSB0aGUgQ2FwYWJpbGl0aWVzIEV4Y2hhbmdlIG1lc3NhZ2VzJnF1 b3Q7LiBBbSBJIG1pc3NpbmcNCiBzb21ldGhpbmcgaGVyZT8gT3IgaXMgaXQgdGhlIGNhc2UgdGhh dCB0d28gcGVlcnMgKGlkZW50aWZpZWQgYmFzZWQgb24gdGhlaXIgcmVzcGVjdGl2ZSBkaWFtZXRl ciBob3N0LW5hbWVzKSB3b3VsZCBwZXJmb3JtIGNhcGFiaWxpdHkgZXhjaGFuZ2Ugb25seSBvbmNl LCBpcnJlc3BlY3RpdmUgb2YgbnVtYmVyIG9mIHRyYW5zcG9ydCBjb25uZWN0aW9ucyB0aGV5IGhh dmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO+KAoiBJZiBtdWx0aXBsZSB0cmFuc3BvcnQgY29ubmVjdGlvbnMgKHRv d2FyZHMgdGhlIHNhbWUgcGVlcikgYXJlIGFsbG93ZWQgcGVyIGRpYW1ldGVyIGhvc3QsIGlzIGl0 IGV4cGVjdGVkIHRoYXQgcGVlciB3b3VsZCBkbyBsb2FkIGJhbGFuY2luZyBiZXR3ZWVuIHRoZW0/ IChUaGVyZSBpcyBhIGNvbm5lY3Rpb24gbG9hZCBiYWxhbmNpbmcgc2VjdGlvbiBpbiBSRkMgMzUz OSAtIFNlY3Rpb24gMy40LjMpPGJyPg0KPGJyPg0Kd2hhdCB5b3UgZG8gYW5kIGhvdyB5b3UgbWFu YWdlIOKAmG11bHRpcGxlIGluc3RhbmNlc+KAmSBpZiBtb3JlIG9yIGxlc3MgbGVmdCBmb3IgaW1w bGVtZW50YXRpb24gdG8gZGVjaWRlLiBpIGFsd2F5cyBjb25zaWRlcmVkIGl0IGFzIGEgbm9kZSBp bnRlcm5hbCBjb21wdXRlIGxvYWQgYmFsYW5jaW5nIG1lY2hhbmlzbSBpLmUuLCB0byBkaXN0cmli dXRlIHRoZSBjb21wdXRlIHRvIHNlcGFyYXRlIGNvcmVzL2JsYWRlcyBldGMuPGJyPg0KPGJyPg0K PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyAyLiBSZWdhcmRpbmcgZGlhbWV0ZXIgcGVl ciBmYWlsYmFjayBwcm9jZWR1cmUgLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4m Z3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtTZWN0aW9uIDUuNS40IG1lbnRpb25zICZxdW90O2EgY29ubmVjdGlvbiByZXF1 ZXN0IHNob3VsZCBiZSBwZXJpb2RpY2FsbHkgYXR0ZW1wdGVkIHdpdGggdGhlIGZhaWxlZCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwZWVyIGluIG9yZGVy IHRvIHJlLWVzdGFibGlzaCB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24mcXVvdDs8L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21h aWwtIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UXVlc3Rpb24gLS08L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21h aWwtIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCiIElmIHRoZSBmYWlsZWQgcGVl ciBpcyBkeW5hbWljYWxseSBkaXNjb3ZlcmVkIHZpYSBETlMgbG9va3VwLCBpcyBpdCBleHBlY3Rl ZCB0aGF0IHBlZXIgd291bGQgcGVyZm9ybSBETlMgcXVlcnkgYmVmb3JlIHRyeWluZyB0byBlc3Rh Ymxpc2ggdGhlIGNvbm5lY3Rpb24gYWdhaW4/IE9yIEROUyBsb29rdXAgaXMgZHJpdmVuIG9ubHkg YnkgVFRMIGZpZWxkIHJlY2VpdmVkIGluIHRoZSBwcmlvciBETlMNCiBhbnN3ZXIgPzwvc3Bhbj48 YnI+DQo8YnI+DQp1cCB0byB5b3VyIGltcGxlbWVudGF0aW9uIGFuZCBkbnMgcmVzb2x2ZXIgaW1w bGVtZW50YXRpb24uPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFu IGNsYXNzPSJnbWFpbC1ob2VuemIiPi0gam91bmk8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPHNw YW4gY2xhc3M9ImdtYWlsLWhvZW56YiI+Jmd0OyAtLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i Z21haWwtaG9lbnpiIj4mZ3Q7IFJlZ2FyZHMsPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFp bC1ob2VuemIiPiZndDsgQWppbmt5YSBKb3NoaTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21h aWwtaG9lbnpiIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC1ob2VuemIiPiZndDsgRGlNRSBt YWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLWhvZW56YiI+Jmd0OyA8 YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvYT48L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImdtYWlsLWhvZW56YiI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvYT48L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6Ymx1ZSI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibHVlIj5Bamlua3lhIEpvc2hpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E0C06F1EBOPEXCLILM43corp_-- From nobody Wed Mar 8 05:33:39 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7959F129697 for ; Wed, 8 Mar 2017 05:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=definitionnetworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3Hs8G7JlG6o for ; Wed, 8 Mar 2017 05:33:35 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20B4129691 for ; Wed, 8 Mar 2017 05:33:34 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id i1so30722385ota.3 for ; Wed, 08 Mar 2017 05:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=definitionnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xj1u1bwXJq3nVyHix5uav/tYZykWy0tBC+X66ZsZXrY=; b=zsrwgaRZKrrUN8Hqnrvx6SSsjed3Xxwhod/TUTkEem13La8d68iAxSt/F7qCiMQthb 1M45h9bDWwBjE7nI12Q1iJyhWEpZmwQzcCUzoESHT3yCEocCOEBn8wDxUlWDNtXq5KsF iA+QTgZ1W5VlssMRyJp6ER5pckMSh/YF5a5JPO4H65QtFIHen63zF13VQ069zF+koGSd UKGV8AlMNYqkMIWvgdVJBgpnMAC0/aqbOJc6qYxfve7O55CJE0oCNIWS5r1HUmcYKmzN SmYdrLXp5hBjzl2zfhuYk/WlReVgao8y17XCwKDXRViEGUhF+msDD3FBuArUGfUveU8D kPmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xj1u1bwXJq3nVyHix5uav/tYZykWy0tBC+X66ZsZXrY=; b=KqknKLjmu+LBbWJNFCTPpt2+ys2+FKFtdUQPSW0S4sfM/JOo91TkpWyZJg9fOVJ6uN 24bLLFPpGpZwK4ELtEptNTuio+fGTVBnJhnrT1IZXe2NDJqtZDUvjZ2qHQZ6smABqtnQ IZyGPnixowqtKOQEcNAnmEHT5nxx//OZKj9GDji1mf3RIG5PNmuS71OoYgjo4IRdM7Ze 8QpvUAMkD0/QidxJ91BTV/Aj6b57sekjW+v9zdCRwG10x+8iW7hLU0Ovk/5kmEEAN8hS 8Z+kgXgueUsg7P55La92WNuU71yhJc1GPwtyQCjxZkbEjcjclSlrYok0RGjH6+LhJxMu O2dA== X-Gm-Message-State: AMke39n+ej4bgyp+6bWNxMbJbfnVHHnBAEFeJ1zMy6HnMZnf8ySvb5w/5WhtLHh7kxGlpKlHpK7nlGJzWLurwg== X-Received: by 10.157.63.119 with SMTP id m110mr3131996otc.63.1488980014133; Wed, 08 Mar 2017 05:33:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.173 with HTTP; Wed, 8 Mar 2017 05:33:33 -0800 (PST) In-Reply-To: <29819_1488971347_58BFE653_29819_5_3_6B7134B31289DC4FAF731D844122B36E0C06F1EB@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> <29819_1488971347_58BFE653_29819_5_3_6B7134B31289DC4FAF731D844122B36E0C06F1EB@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Ajinkya Joshi Date: Wed, 8 Mar 2017 19:03:33 +0530 Message-ID: To: lionel.morand@orange.com Content-Type: multipart/alternative; boundary=001a1147355cd202cb054a382c65 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 13:33:37 -0000 --001a1147355cd202cb054a382c65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lionel, I completely agree with you, if it is just one transport connection from the external world perspective, then it doesn't really matter even if there are multiple processes (instances) within that peer handling that one transport. But I feel that RFC wording doesn't really indicate that. (section 2.1) "A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed" This can get interpreted as multiple transport connections are allowed using same diameteridentity. On Wed, Mar 8, 2017 at 4:39 PM, wrote: > Hi Ajinkya, > > > > This will depend on how your "fork" is implemented and it is why it is > considered as "implementation-specific". > > If N instances are sharing the same Diameter id (DiamId 1), you may have = a > way to consider the connection up as long as one instance inside the peer > is available and active. In that case, there is no impact for other > diameter peers in the network. For the outside world, there would be only > one transport connection opened with "DiamId 1", independently of the > number of instance behind "DiamId 1". > > > > Lionel > > > > *De :* DiME [mailto:dime-bounces@ietf.org] *De la part de* Ajinkya Joshi > *Envoy=C3=A9 :* mercredi 8 mars 2017 10:37 > *=C3=80 :* jouni.nospam > *Cc :* dime@ietf.org > *Objet :* Re: [Dime] Questions regarding RFC 6733 > > > > > > > > On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam > wrote: > > hi, > > > On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi > wrote: > > > > Hello, > > > > I have following questions regarding diameter RFC 6733, I would really > appreciate if someone can help me with these. > > > > 1. Regarding diameter peer state machine - > > > > Section 5.6.1 (Peer State Machine --> Incoming connections) mention= s > that Origin-host is used for identifying peer state machine and as pe= r > state machine, once it moves into I-Open, new CER is rejected. This > concludes, that there can't be more than one transport connections with > same diameter host (as specified by Origin-host). > > > > Section 2.1 (Transport) mentions that "A given Diameter instance of > the peer state machine MUST NOT use more than one transport connecti= on > to communicate with a given peer, unless multiple instances exist = on > the peer, in which, case a separate connection per process is allowed." > > > > Questions -- > > =E2=80=A2 Does section 2.1 implicitly assumes that multiple diame= ter > instances (within a peer) would correspond to different diameter host ? > Otherwise, it could contradict with section 5.6.1 > > it assumes one peer connection per peer state machine. so if you have a > way to =E2=80=98fork=E2=80=99 a new peer instance with its own peer state= machine per > incoming connection then having =E2=80=9Cmultiple instances=E2=80=99 is p= ossible even if > the diameteridentity is the same. > > > > [ajoshi] If we fork a new peer instance with same diameteridentity, won't > it create problems as per peer state machine? Because, you would have > separate transport connection for each of them and each transport > connection needs capability exchange and as per peer state machine, there > can be only one capability exchange. I am inferring this based on section > 5.3 which says "When two Diameter peers establish a transport connection, > they MUST exchange the Capabilities Exchange messages". Am I missing > something here? Or is it the case that two peers (identified based on the= ir > respective diameter host-names) would perform capability exchange only > once, irrespective of number of transport connections they have? > > > > > > =E2=80=A2 If multiple transport connections (towards the same pee= r) are > allowed per diameter host, is it expected that peer would do load balanci= ng > between them? (There is a connection load balancing section in RFC 3539 - > Section 3.4.3) > > what you do and how you manage =E2=80=98multiple instances=E2=80=99 if mo= re or less left > for implementation to decide. i always considered it as a node internal > compute load balancing mechanism i.e., to distribute the compute to > separate cores/blades etc. > > > > 2. Regarding diameter peer failback procedure - > > > > Section 5.5.4 mentions "a connection request should be > periodically attempted with the failed peer in order to > re-establish the transport connection" > > > > Question -- > > > > =E2=80=A2 If the failed peer is dynamically discovered via DNS lo= okup, is > it expected that peer would perform DNS query before trying to establish > the connection again? Or DNS lookup is driven only by TTL field received = in > the prior DNS answer ? > > up to your implementation and dns resolver implementation. > > - jouni > > > > -- > > Regards, > > Ajinkya Joshi > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > -- > > Regards, > > Ajinkya Joshi > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 Regards, Ajinkya Joshi --001a1147355cd202cb054a382c65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lionel,

I completely agree with you,= if it is just one transport connection from the external world perspective= , then it doesn't really matter even if there are multiple processes (i= nstances) within that peer handling that one transport. But I feel that RFC= wording doesn't really indicate that. (section 2.1)
"A given Diameter instanc= e of the peer state machine MUST NOT use more=C2=A0than one transport connection to commun= icate with a given peer,=C2=A0unless multiple instances exist on the peer, in which, case = a separate conn= ection per process is allowed"=C2=A0

T= his can get interpreted as multiple transport connections are allowed using= same diameteridentity.

On Wed, Mar 8, 2017 at 4:39 PM, <lionel.morand@o= range.com> wrote:

Hi Ajinkya,=

=C2=A0

This will = depend on how your "fork" is implemented and it is why it is cons= idered as "implementation-specific".

If N insta= nces are sharing the same Diameter id (DiamId 1), you may have a way to con= sider the connection up as long as one instance inside the peer is available and active. In that case, there is no impact for other d= iameter peers in the network. For the outside world, there would be only on= e transport connection opened with "DiamId 1", independently of t= he number of instance behind "DiamId 1".

=C2= =A0

Lionel<= /u>

=C2= =A0

De=C2=A0: DiME= [mailto:dime-bo= unces@ietf.org] De la part de Ajinkya Joshi
Envoy=C3=A9=C2=A0: mercredi 8 mars 2017 10:37
=C3=80=C2=A0: jouni.nospam
Cc=C2=A0: dime@ie= tf.org
Objet=C2=A0: Re: [Dime] Questions regarding RFC 6733

=C2=A0

=C2=A0

=C2=A0

On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <jouni.nospam@gmai= l.com> wrote:

hi,

> On Mar 7, 2017, at 3:01 A= M, Ajinkya Joshi <ajoshi@definitionnetworks.com> wrote:
>
> Hello,
>
> I have following question= s regarding diameter RFC 6733, I would really appreciate if someone can hel= p me with these.
>
> 1. Regarding diameter pee= r state machine -
>
>=C2=A0 =C2=A0 =C2=A0Sectio= n 5.6.1 (Peer State Machine --> Incoming connections) mentions that Orig= in-host is used for=C2=A0 =C2=A0 =C2=A0identifying peer state machine and a= s per state machine, once it moves into I-Open, new CER is=C2=A0 =C2=A0 =C2= =A0 =C2=A0rejected. This concludes, that there can't be more than one transport connections with same=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diameter host (as specified by= Origin-host).
>
>=C2=A0 =C2=A0 =C2=A0Sectio= n 2.1 (Transport) mentions that "A given Diameter instance of the peer= state machine MUST=C2=A0 =C2=A0 =C2=A0 NOT use more than one transport con= nection to communicate with a given peer, unless multiple=C2=A0 =C2=A0 =C2= =A0 =C2=A0 instances exist on the peer, in which, case a separate connection per process is allowed."<= br> >
>=C2=A0 =C2=A0 =C2=A0 Quest= ions --
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0=E2=80=A2 Does section 2.1 implicitly assumes that multiple diameter ins= tances (within a peer) would correspond to different diameter host ? Otherw= ise, it could contradict with section 5.6.1

it assumes one peer connection per peer state machine. so if you have a way= to =E2=80=98fork=E2=80=99 a new peer instance with its own peer state mach= ine per incoming connection then having =E2=80=9Cmultiple instances=E2=80= =99 is possible even if the diameteridentity is the same.

=C2=A0

[ajoshi] If we fork a new peer instance with same di= ameteridentity, won't it create problems as per peer state machine? Bec= ause, you would have separate transport connection for each of them and eac= h transport connection needs capability exchange and as per peer state machine, there can be only one capability e= xchange. I am inferring this based on section 5.3 which says "When two= Diameter peers establish a transport connection, they MUST exchange the Ca= pabilities Exchange messages". Am I missing something here? Or is it the case that two peers (identified based on thei= r respective diameter host-names) would perform capability exchange only on= ce, irrespective of number of transport connections they have?

=C2=A0


>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If multiple transport connections = (towards the same peer) are allowed per diameter host, is it expected that = peer would do load balancing between them? (There is a connection load bala= ncing section in RFC 3539 - Section 3.4.3)

what you do and how you manage =E2=80=98multiple instances=E2=80=99 if more= or less left for implementation to decide. i always considered it as a nod= e internal compute load balancing mechanism i.e., to distribute the compute= to separate cores/blades etc.


> 2. Regarding diameter pee= r failback procedure -
>
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0Section 5.5.4 mentions "a connection request should be periodically= attempted with the failed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = peer in order to re-establish the transport connection"
>
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0Question --
>
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0=E2=80=A2 If the failed peer is dynamically discovered via DNS lookup, i= s it expected that peer would perform DNS query before trying to establish = the connection again? Or DNS lookup is driven only by TTL field received in= the prior DNS answer ?

up to your implementation and dns resolver implementation.

- jouni


> --
> Regards,
> Ajinkya Joshi
> ___________________= ____________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime=



=C2=A0

--

Regards,

Ajinkya Joshi

____________________________________________________________=
_____________________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.



--
Regards,
Ajinkya Joshi=
--001a1147355cd202cb054a382c65-- From nobody Wed Mar 8 06:38:46 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434C11296BF for ; Wed, 8 Mar 2017 06:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3HWIZVODt5s for ; Wed, 8 Mar 2017 06:38:43 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158AC1296B5 for ; Wed, 8 Mar 2017 06:38:43 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 6B34940465; Wed, 8 Mar 2017 15:38:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 3A32E1A0088; Wed, 8 Mar 2017 15:38:41 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 15:38:40 +0100 From: To: Ajinkya Joshi Thread-Topic: [Dime] Questions regarding RFC 6733 Thread-Index: AQHSl1U+rua+IhzsXUSySTVeMQxEMKGJgfoAgAEdogCAAChe8IAAGcGAgAAXsXA= Date: Wed, 8 Mar 2017 14:38:39 +0000 Message-ID: <30352_1488983921_58C01771_30352_545_1_6B7134B31289DC4FAF731D844122B36E0C06F709@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> <29819_1488971347_58BFE653_29819_5_3_6B7134B31289DC4FAF731D844122B36E0C06F1EB@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C06F709OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:38:45 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C06F709OPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgdGV4dCBtYXkgbm90IGJlIHRoZSBtb3N0IHNlbGYtZXhwbGljaXQg4pi6DQpU aGUgaW50ZW50aW9uIHdhcyB0byBjbGFyaWZ5IHRoYXQgbXVsdGlwbGUgRGlhbWV0ZXIgaW5zdGFu Y2VzIGNvdWxkIGJlIG9uIHRoZSBzYW1lIGhvc3QuDQpJdCBpcyBtYXliZSBtb3JlIGFjY3VyYXRl bHkgZGVzY3JpYmVkIGJlbG93Og0KDQogICBEaWFtZXRlcklkZW50aXR5DQoNCiAgICAgIFRoZSBE aWFtZXRlcklkZW50aXR5IGZvcm1hdCBpcyBkZXJpdmVkIGZyb20gdGhlIE9jdGV0U3RyaW5nIEJh c2ljDQogICAgICBBVlAgRm9ybWF0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICBEaWFtZXRl cklkZW50aXR5ICA9IEZRRE4vUmVhbG0NCg0KICAgVGhlIERpYW1ldGVySWRlbnRpdHkgdmFsdWUg aXMgdXNlZCB0byB1bmlxdWVseSBpZGVudGlmeSBlaXRoZXI6DQoNCiAgICAgICogIEEgRGlhbWV0 ZXIgbm9kZSBmb3IgcHVycG9zZXMgb2YgZHVwbGljYXRlIGNvbm5lY3Rpb24gYW5kDQogICAgICAg ICByb3V0aW5nIGxvb3AgZGV0ZWN0aW9uLg0KDQogICAgICAqICBBIFJlYWxtIHRvIGRldGVybWlu ZSB3aGV0aGVyIG1lc3NhZ2VzIGNhbiBiZSBzYXRpc2ZpZWQgbG9jYWxseQ0KICAgICAgICAgb3Ig d2hldGhlciB0aGV5IG11c3QgYmUgcm91dGVkIG9yIHJlZGlyZWN0ZWQuDQoNCiAgICAgIFdoZW4g YSBEaWFtZXRlcklkZW50aXR5IHZhbHVlIGlzIHVzZWQgdG8gaWRlbnRpZnkgYSBEaWFtZXRlciBu b2RlLA0KICAgICAgdGhlIGNvbnRlbnRzIG9mIHRoZSBzdHJpbmcgTVVTVCBiZSB0aGUgRnVsbHkg UXVhbGlmaWVkIERvbWFpbiBOYW1lDQogICAgICAoRlFETikgb2YgdGhlIERpYW1ldGVyIG5vZGUu ICBJZiBtdWx0aXBsZSBEaWFtZXRlciBub2RlcyBydW4gb24NCiAgICAgIHRoZSBzYW1lIGhvc3Qs IGVhY2ggRGlhbWV0ZXIgbm9kZSBNVVNUIGJlIGFzc2lnbmVkIGEgdW5pcXVlDQogICAgICBEaWFt ZXRlcklkZW50aXR5LiAgSWYgYSBEaWFtZXRlciBub2RlIGNhbiBiZSBpZGVudGlmaWVkIGJ5IHNl dmVyYWwNCiAgICAgIEZRRE5zLCBhIHNpbmdsZSBGUUROIHNob3VsZCBiZSBwaWNrZWQgYXQgc3Rh cnR1cCBhbmQgdXNlZCBhcyB0aGUNCiAgICAgIG9ubHkgRGlhbWV0ZXJJZGVudGl0eSBmb3IgdGhh dCBub2RlLCB3aGF0ZXZlciB0aGUgY29ubmVjdGlvbiBvbg0KICAgICAgd2hpY2ggaXQgaXMgc2Vu dC4gIEluIHRoaXMgZG9jdW1lbnQsIG5vdGUgdGhhdCBEaWFtZXRlcklkZW50aXR5IGlzDQogICAg ICBpbiBBU0NJSSBmb3JtIGluIG9yZGVyIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBE TlMNCiAgICAgIGluZnJhc3RydWN0dXJlLiAgU2VlIEFwcGVuZGl4IEQ8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3MzMjYXBwZW5kaXgtRD4gZm9yIGludGVyYWN0aW9ucyBiZXR3ZWVu IHRoZQ0KICAgICAgRGlhbWV0ZXIgcHJvdG9jb2wgYW5kIEludGVybmF0aW9uYWxpemVkIERvbWFp biBOYW1lcyAoSUROcykuDQoNCklmIHlvdSBoYXZlIG11bHRpcGxlIGluc3RhbmNlcyBvbiB0aGUg c2FtZSBob3N0LCBlYWNoIG9uZSB3aWxsIGhhdmUgaXRzIG93biBEaWFtZXRlciBJZCBhbmQgZWFj aCBEaWFtZXRlciBJZCBjYW4gdXNlIGEgc2luZ2xlIGNvbm5lY3Rpb24sIHdoaWNoIG1lYW5zIE4g Y29ubmVjdGlvbnMgZm9yIHRoZSBob3N0Lg0KRXZlcnl0aGluZyBlbHNlIHRoYW4gdGhlICIxIGNv bm5lY3Rpb24gcGVyIERpYW1ldGVyIElkIiBwYXJhZGlnbSBpcyBvdXQgb2YgdGhlIERpYW1ldGVy IHNwZWMuIFNhbWUgZm9yIGhvdyBjb3VsZCBpbXBsZW1lbnRlZCB0aGUgIjEgRGlhbWV0ZXIgSWQi IGluIGFuIG11bHRpcGxlIGluc3RhbmNlIGVudmlyb25tZW50LCBhcyBwb2ludGVkIG91dCBieSBK b3VuaS4NCg0KSW4gdGhlIHBlZXIgc3RhdGUgbWFjaGluZSBkZXNjcmlwdGlvbiwgaXQgaXMgY2xl YXIgdGhhdCBvbmx5IG9uZSBjb25uZWN0aW9uIGlzIGNyZWF0ZWQgcGVyIERpYW1ldGVyIElkLCBp LmUuIG9uZSBUQ1AgY29ubmVjdGlvbiBvciBvbmUgU0NUUCBhc3NvY2lhdGlvbiAod2hpY2ggY2Fu IGJlIG11bHRpLWhvbWVkKS4gQW5kIGl0IGlzIGJhc2VkIG9uIHRoaXMgcHJpbmNpcGxlIHRoYXQg Q0VSL0NFQSBhbmQgRFdSL0RXQSBhcmUgdXNlZC4NCk5vdywgaXQgaXMgYWxzbyBzYWlkOg0KDQog ICBUaGUgc3RhdGUgbWFjaGluZSBjb25zdHJhaW5zIG9ubHkgdGhlIGJlaGF2aW9yIG9mIGEgRGlh bWV0ZXINCiAgIGltcGxlbWVudGF0aW9uIGFzIHNlZW4gYnkgRGlhbWV0ZXIgcGVlcnMgdGhyb3Vn aCBldmVudHMgb24gdGhlIHdpcmUuDQoNCiAgIEFueSBpbXBsZW1lbnRhdGlvbiB0aGF0IHByb2R1 Y2VzIGVxdWl2YWxlbnQgcmVzdWx0cyBpcyBjb25zaWRlcmVkDQogICBjb21wbGlhbnQuDQoNClNv IHdoYXRldmVyIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgRGlhbWV0ZXIgbm9kZSwgZS5nLiAx IG9yIE4gaW5zdGFuY2Ugb24gdGhlIHNhbWUgaG9zdCwgMSBvciBOIERpYW1ldGVyIElkcywgdGhp cyBub2RlIHNob3VsZCBjb21wbHkgd2l0aCByZXF1aXJlbWVudHMgcmVnYXJkaW5nIHRoZSBjb25u ZWN0aW9uIG1hbmFnZW1lbnQuDQoNClJlZ2FyZHMsDQoNCkxpb25lbA0KDQpEZSA6IEFqaW5reWEg Sm9zaGkgW21haWx0bzpham9zaGlAZGVmaW5pdGlvbm5ldHdvcmtzLmNvbV0NCkVudm95w6kgOiBt ZXJjcmVkaSA4IG1hcnMgMjAxNyAxNDozNA0Kw4AgOiBNT1JBTkQgTGlvbmVsIElNVC9PTE4NCkNj IDogam91bmkubm9zcGFtOyBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJlOiBbRGltZV0gUXVlc3Rp b25zIHJlZ2FyZGluZyBSRkMgNjczMw0KDQpIaSBMaW9uZWwsDQoNCkkgY29tcGxldGVseSBhZ3Jl ZSB3aXRoIHlvdSwgaWYgaXQgaXMganVzdCBvbmUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gZnJvbSB0 aGUgZXh0ZXJuYWwgd29ybGQgcGVyc3BlY3RpdmUsIHRoZW4gaXQgZG9lc24ndCByZWFsbHkgbWF0 dGVyIGV2ZW4gaWYgdGhlcmUgYXJlIG11bHRpcGxlIHByb2Nlc3NlcyAoaW5zdGFuY2VzKSB3aXRo aW4gdGhhdCBwZWVyIGhhbmRsaW5nIHRoYXQgb25lIHRyYW5zcG9ydC4gQnV0IEkgZmVlbCB0aGF0 IFJGQyB3b3JkaW5nIGRvZXNuJ3QgcmVhbGx5IGluZGljYXRlIHRoYXQuIChzZWN0aW9uIDIuMSkN CiJBIGdpdmVuIERpYW1ldGVyIGluc3RhbmNlIG9mIHRoZSBwZWVyIHN0YXRlIG1hY2hpbmUgTVVT VCBOT1QgdXNlIG1vcmUgdGhhbiBvbmUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gdG8gY29tbXVuaWNh dGUgd2l0aCBhIGdpdmVuIHBlZXIsIHVubGVzcyBtdWx0aXBsZSBpbnN0YW5jZXMgZXhpc3Qgb24g dGhlIHBlZXIsIGluIHdoaWNoLCBjYXNlIGEgc2VwYXJhdGUgY29ubmVjdGlvbiBwZXIgcHJvY2Vz cyBpcyBhbGxvd2VkIg0KDQpUaGlzIGNhbiBnZXQgaW50ZXJwcmV0ZWQgYXMgbXVsdGlwbGUgdHJh bnNwb3J0IGNvbm5lY3Rpb25zIGFyZSBhbGxvd2VkIHVzaW5nIHNhbWUgZGlhbWV0ZXJpZGVudGl0 eS4NCg0KT24gV2VkLCBNYXIgOCwgMjAxNyBhdCA0OjM5IFBNLCA8bGlvbmVsLm1vcmFuZEBvcmFu Z2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIEFqaW5r eWEsDQoNClRoaXMgd2lsbCBkZXBlbmQgb24gaG93IHlvdXIgImZvcmsiIGlzIGltcGxlbWVudGVk IGFuZCBpdCBpcyB3aHkgaXQgaXMgY29uc2lkZXJlZCBhcyAiaW1wbGVtZW50YXRpb24tc3BlY2lm aWMiLg0KSWYgTiBpbnN0YW5jZXMgYXJlIHNoYXJpbmcgdGhlIHNhbWUgRGlhbWV0ZXIgaWQgKERp YW1JZCAxKSwgeW91IG1heSBoYXZlIGEgd2F5IHRvIGNvbnNpZGVyIHRoZSBjb25uZWN0aW9uIHVw IGFzIGxvbmcgYXMgb25lIGluc3RhbmNlIGluc2lkZSB0aGUgcGVlciBpcyBhdmFpbGFibGUgYW5k IGFjdGl2ZS4gSW4gdGhhdCBjYXNlLCB0aGVyZSBpcyBubyBpbXBhY3QgZm9yIG90aGVyIGRpYW1l dGVyIHBlZXJzIGluIHRoZSBuZXR3b3JrLiBGb3IgdGhlIG91dHNpZGUgd29ybGQsIHRoZXJlIHdv dWxkIGJlIG9ubHkgb25lIHRyYW5zcG9ydCBjb25uZWN0aW9uIG9wZW5lZCB3aXRoICJEaWFtSWQg MSIsIGluZGVwZW5kZW50bHkgb2YgdGhlIG51bWJlciBvZiBpbnN0YW5jZSBiZWhpbmQgIkRpYW1J ZCAxIi4NCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPl0gRGUgbGEgcGFydCBkZSBBamlua3lhIEpv c2hpDQpFbnZvecOpIDogbWVyY3JlZGkgOCBtYXJzIDIwMTcgMTA6MzcNCsOAIDogam91bmkubm9z cGFtDQpDYyA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJl OiBbRGltZV0gUXVlc3Rpb25zIHJlZ2FyZGluZyBSRkMgNjczMw0KDQoNCg0KT24gVHVlLCBNYXIg NywgMjAxNyBhdCAxMDowNCBQTSwgam91bmkubm9zcGFtIDxqb3VuaS5ub3NwYW1AZ21haWwuY29t PG1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tPj4gd3JvdGU6DQpoaSwNCg0KPiBPbiBNYXIg NywgMjAxNywgYXQgMzowMSBBTSwgQWppbmt5YSBKb3NoaSA8YWpvc2hpQGRlZmluaXRpb25uZXR3 b3Jrcy5jb208bWFpbHRvOmFqb3NoaUBkZWZpbml0aW9ubmV0d29ya3MuY29tPj4gd3JvdGU6DQo+ DQo+IEhlbGxvLA0KPg0KPiBJIGhhdmUgZm9sbG93aW5nIHF1ZXN0aW9ucyByZWdhcmRpbmcgZGlh bWV0ZXIgUkZDIDY3MzMsIEkgd291bGQgcmVhbGx5IGFwcHJlY2lhdGUgaWYgc29tZW9uZSBjYW4g aGVscCBtZSB3aXRoIHRoZXNlLg0KPg0KPiAxLiBSZWdhcmRpbmcgZGlhbWV0ZXIgcGVlciBzdGF0 ZSBtYWNoaW5lIC0NCj4NCj4gICAgIFNlY3Rpb24gNS42LjEgKFBlZXIgU3RhdGUgTWFjaGluZSAt LT4gSW5jb21pbmcgY29ubmVjdGlvbnMpIG1lbnRpb25zIHRoYXQgT3JpZ2luLWhvc3QgaXMgdXNl ZCBmb3IgICAgIGlkZW50aWZ5aW5nIHBlZXIgc3RhdGUgbWFjaGluZSBhbmQgYXMgcGVyIHN0YXRl IG1hY2hpbmUsIG9uY2UgaXQgbW92ZXMgaW50byBJLU9wZW4sIG5ldyBDRVIgaXMgICAgICAgcmVq ZWN0ZWQuIFRoaXMgY29uY2x1ZGVzLCB0aGF0IHRoZXJlIGNhbid0IGJlIG1vcmUgdGhhbiBvbmUg dHJhbnNwb3J0IGNvbm5lY3Rpb25zIHdpdGggc2FtZSAgICAgICAgICAgICAgIGRpYW1ldGVyIGhv c3QgKGFzIHNwZWNpZmllZCBieSBPcmlnaW4taG9zdCkuDQo+DQo+ICAgICBTZWN0aW9uIDIuMSAo VHJhbnNwb3J0KSBtZW50aW9ucyB0aGF0ICJBIGdpdmVuIERpYW1ldGVyIGluc3RhbmNlIG9mIHRo ZSBwZWVyIHN0YXRlIG1hY2hpbmUgTVVTVCAgICAgIE5PVCB1c2UgbW9yZSB0aGFuIG9uZSB0cmFu c3BvcnQgY29ubmVjdGlvbiB0byBjb21tdW5pY2F0ZSB3aXRoIGEgZ2l2ZW4gcGVlciwgdW5sZXNz IG11bHRpcGxlICAgICAgICBpbnN0YW5jZXMgZXhpc3Qgb24gdGhlIHBlZXIsIGluIHdoaWNoLCBj YXNlIGEgc2VwYXJhdGUgY29ubmVjdGlvbiBwZXIgcHJvY2VzcyBpcyBhbGxvd2VkLiINCj4NCj4g ICAgICBRdWVzdGlvbnMgLS0NCj4gICAgICAg4oCiIERvZXMgc2VjdGlvbiAyLjEgaW1wbGljaXRs eSBhc3N1bWVzIHRoYXQgbXVsdGlwbGUgZGlhbWV0ZXIgaW5zdGFuY2VzICh3aXRoaW4gYSBwZWVy KSB3b3VsZCBjb3JyZXNwb25kIHRvIGRpZmZlcmVudCBkaWFtZXRlciBob3N0ID8gT3RoZXJ3aXNl LCBpdCBjb3VsZCBjb250cmFkaWN0IHdpdGggc2VjdGlvbiA1LjYuMQ0KDQppdCBhc3N1bWVzIG9u ZSBwZWVyIGNvbm5lY3Rpb24gcGVyIHBlZXIgc3RhdGUgbWFjaGluZS4gc28gaWYgeW91IGhhdmUg YSB3YXkgdG8g4oCYZm9ya+KAmSBhIG5ldyBwZWVyIGluc3RhbmNlIHdpdGggaXRzIG93biBwZWVy IHN0YXRlIG1hY2hpbmUgcGVyIGluY29taW5nIGNvbm5lY3Rpb24gdGhlbiBoYXZpbmcg4oCcbXVs dGlwbGUgaW5zdGFuY2Vz4oCZIGlzIHBvc3NpYmxlIGV2ZW4gaWYgdGhlIGRpYW1ldGVyaWRlbnRp dHkgaXMgdGhlIHNhbWUuDQoNCltham9zaGldIElmIHdlIGZvcmsgYSBuZXcgcGVlciBpbnN0YW5j ZSB3aXRoIHNhbWUgZGlhbWV0ZXJpZGVudGl0eSwgd29uJ3QgaXQgY3JlYXRlIHByb2JsZW1zIGFz IHBlciBwZWVyIHN0YXRlIG1hY2hpbmU/IEJlY2F1c2UsIHlvdSB3b3VsZCBoYXZlIHNlcGFyYXRl IHRyYW5zcG9ydCBjb25uZWN0aW9uIGZvciBlYWNoIG9mIHRoZW0gYW5kIGVhY2ggdHJhbnNwb3J0 IGNvbm5lY3Rpb24gbmVlZHMgY2FwYWJpbGl0eSBleGNoYW5nZSBhbmQgYXMgcGVyIHBlZXIgc3Rh dGUgbWFjaGluZSwgdGhlcmUgY2FuIGJlIG9ubHkgb25lIGNhcGFiaWxpdHkgZXhjaGFuZ2UuIEkg YW0gaW5mZXJyaW5nIHRoaXMgYmFzZWQgb24gc2VjdGlvbiA1LjMgd2hpY2ggc2F5cyAiV2hlbiB0 d28gRGlhbWV0ZXIgcGVlcnMgZXN0YWJsaXNoIGEgdHJhbnNwb3J0IGNvbm5lY3Rpb24sIHRoZXkg TVVTVCBleGNoYW5nZSB0aGUgQ2FwYWJpbGl0aWVzIEV4Y2hhbmdlIG1lc3NhZ2VzIi4gQW0gSSBt aXNzaW5nIHNvbWV0aGluZyBoZXJlPyBPciBpcyBpdCB0aGUgY2FzZSB0aGF0IHR3byBwZWVycyAo aWRlbnRpZmllZCBiYXNlZCBvbiB0aGVpciByZXNwZWN0aXZlIGRpYW1ldGVyIGhvc3QtbmFtZXMp IHdvdWxkIHBlcmZvcm0gY2FwYWJpbGl0eSBleGNoYW5nZSBvbmx5IG9uY2UsIGlycmVzcGVjdGl2 ZSBvZiBudW1iZXIgb2YgdHJhbnNwb3J0IGNvbm5lY3Rpb25zIHRoZXkgaGF2ZT8NCg0KDQo+ICAg ICAgIOKAoiBJZiBtdWx0aXBsZSB0cmFuc3BvcnQgY29ubmVjdGlvbnMgKHRvd2FyZHMgdGhlIHNh bWUgcGVlcikgYXJlIGFsbG93ZWQgcGVyIGRpYW1ldGVyIGhvc3QsIGlzIGl0IGV4cGVjdGVkIHRo YXQgcGVlciB3b3VsZCBkbyBsb2FkIGJhbGFuY2luZyBiZXR3ZWVuIHRoZW0/IChUaGVyZSBpcyBh IGNvbm5lY3Rpb24gbG9hZCBiYWxhbmNpbmcgc2VjdGlvbiBpbiBSRkMgMzUzOSAtIFNlY3Rpb24g My40LjMpDQoNCndoYXQgeW91IGRvIGFuZCBob3cgeW91IG1hbmFnZSDigJhtdWx0aXBsZSBpbnN0 YW5jZXPigJkgaWYgbW9yZSBvciBsZXNzIGxlZnQgZm9yIGltcGxlbWVudGF0aW9uIHRvIGRlY2lk ZS4gaSBhbHdheXMgY29uc2lkZXJlZCBpdCBhcyBhIG5vZGUgaW50ZXJuYWwgY29tcHV0ZSBsb2Fk IGJhbGFuY2luZyBtZWNoYW5pc20gaS5lLiwgdG8gZGlzdHJpYnV0ZSB0aGUgY29tcHV0ZSB0byBz ZXBhcmF0ZSBjb3Jlcy9ibGFkZXMgZXRjLg0KDQoNCj4gMi4gUmVnYXJkaW5nIGRpYW1ldGVyIHBl ZXIgZmFpbGJhY2sgcHJvY2VkdXJlIC0NCj4NCj4gICAgICAgU2VjdGlvbiA1LjUuNCBtZW50aW9u cyAiYSBjb25uZWN0aW9uIHJlcXVlc3Qgc2hvdWxkIGJlIHBlcmlvZGljYWxseSBhdHRlbXB0ZWQg d2l0aCB0aGUgZmFpbGVkICAgICAgICAgICAgICBwZWVyIGluIG9yZGVyIHRvIHJlLWVzdGFibGlz aCB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24iDQo+DQo+ICAgICAgIFF1ZXN0aW9uIC0tDQo+DQo+ ICAgICAgIOKAoiBJZiB0aGUgZmFpbGVkIHBlZXIgaXMgZHluYW1pY2FsbHkgZGlzY292ZXJlZCB2 aWEgRE5TIGxvb2t1cCwgaXMgaXQgZXhwZWN0ZWQgdGhhdCBwZWVyIHdvdWxkIHBlcmZvcm0gRE5T IHF1ZXJ5IGJlZm9yZSB0cnlpbmcgdG8gZXN0YWJsaXNoIHRoZSBjb25uZWN0aW9uIGFnYWluPyBP ciBETlMgbG9va3VwIGlzIGRyaXZlbiBvbmx5IGJ5IFRUTCBmaWVsZCByZWNlaXZlZCBpbiB0aGUg cHJpb3IgRE5TIGFuc3dlciA/DQoNCnVwIHRvIHlvdXIgaW1wbGVtZW50YXRpb24gYW5kIGRucyBy ZXNvbHZlciBpbXBsZW1lbnRhdGlvbi4NCg0KLSBqb3VuaQ0KDQoNCj4gLS0NCj4gUmVnYXJkcywN Cj4gQWppbmt5YSBKb3NoaQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGlldGYub3JnPG1haWx0bzpE aU1FQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp bWUNCg0KDQoNCi0tDQpSZWdhcmRzLA0KQWppbmt5YSBKb3NoaQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp Lg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KDQoNCi0tDQpSZWdhcmRzLA0K QWppbmt5YSBKb3NoaQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_6B7134B31289DC4FAF731D844122B36E0C06F709OPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5tLTUxNTc0 MjIxODU4Njg2OTU0MDdnbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6bV8tNTE1NzQyMjE4NTg2ODY5 NTQwN2dtYWlsLTt9DQpzcGFuLm0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLWhvZW56Yg0KCXtt c28tc3R5bGUtbmFtZTptXy01MTU3NDIyMTg1ODY4Njk1NDA3Z21haWwtaG9lbnpiO30NCnNwYW4u UHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOp IEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpGUjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgdGV4dCBtYXkgbm90IGJlIHRoZSBtb3N0IHNlbGYtZXhw bGljaXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGUgaW50ZW50aW9uIHdhcyB0byBjbGFyaWZ5IHRoYXQgbXVsdGlwbGUgRGlhbWV0ZXIg aW5zdGFuY2VzIGNvdWxkIGJlIG9uIHRoZSBzYW1lIGhvc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBpcyBtYXliZSBtb3JlIGFjY3VyYXRlbHkgZGVzY3Jp YmVkIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgRGlhbWV0ZXJJZGVudGl0eTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIERpYW1ldGVy SWRlbnRpdHkgZm9ybWF0IGlzIGRlcml2ZWQgZnJvbSB0aGUgT2N0ZXRTdHJpbmcgQmFzaWM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBVlAgRm9ybWF0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGlhbWV0ZXJJZGVu dGl0eSZuYnNwOyA9IEZRRE4vUmVhbG08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IFRoZSBEaWFtZXRlcklkZW50aXR5IHZhbHVlIGlzIHVzZWQgdG8gdW5pcXVlbHkgaWRl bnRpZnkgZWl0aGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBBIERpYW1ldGVyIG5vZGUgZm9yIHB1cnBvc2VzIG9mIGR1 cGxpY2F0ZSBjb25uZWN0aW9uIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvdXRpbmcgbG9vcCBkZXRlY3Rpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7 IEEgUmVhbG0gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgbWVzc2FnZXMgY2FuIGJlIHNhdGlzZmllZCBs b2NhbGx5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgb3Igd2hldGhlciB0aGV5IG11c3QgYmUgcm91dGVkIG9yIHJlZGlyZWN0ZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBX aGVuIGEgRGlhbWV0ZXJJZGVudGl0eSB2YWx1ZSBpcyB1c2VkIHRvIGlkZW50aWZ5IGEgRGlhbWV0 ZXIgbm9kZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgY29u dGVudHMgb2YgdGhlIHN0cmluZyBNVVNUIGJlIHRoZSBGdWxseSBRdWFsaWZpZWQgRG9tYWluIE5h bWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoRlFETikgb2YgdGhl IERpYW1ldGVyIG5vZGUuJm5ic3A7IElmIG11bHRpcGxlIERpYW1ldGVyIG5vZGVzIHJ1biBvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBzYW1lIGhvc3QsIGVh Y2ggRGlhbWV0ZXIgbm9kZSBNVVNUIGJlIGFzc2lnbmVkIGEgdW5pcXVlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGlhbWV0ZXJJZGVudGl0eS4mbmJzcDsgSWYgYSBE aWFtZXRlciBub2RlIGNhbiBiZSBpZGVudGlmaWVkIGJ5IHNldmVyYWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGUUROcywgYSBzaW5nbGUgRlFETiBzaG91bGQgYmUg cGlja2VkIGF0IHN0YXJ0dXAgYW5kIHVzZWQgYXMgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb25seSBEaWFtZXRlcklkZW50aXR5IGZvciB0aGF0IG5vZGUsIHdo YXRldmVyIHRoZSBjb25uZWN0aW9uIG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgd2hpY2ggaXQgaXMgc2VudC4mbmJzcDsgSW4gdGhpcyBkb2N1bWVudCwgbm90ZSB0 aGF0IERpYW1ldGVySWRlbnRpdHkgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpbiBBU0NJSSBmb3JtIGluIG9yZGVyIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBleGlz dGluZyBETlM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmZyYXN0 cnVjdHVyZS4mbmJzcDsgU2VlDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzMzI2FwcGVuZGl4LUQiPjxzcGFuIGxhbmc9IkVOLVVTIj5B cHBlbmRpeCBEPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gZm9yIGlu dGVyYWN0aW9ucyBiZXR3ZWVuDQogdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRGlhbWV0ZXIgcHJvdG9jb2wgYW5kIEludGVybmF0aW9uYWxpemVkIERvbWFpbiBO YW1lcyAoSUROcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBo YXZlIG11bHRpcGxlIGluc3RhbmNlcyBvbiB0aGUgc2FtZSBob3N0LCBlYWNoIG9uZSB3aWxsIGhh dmUgaXRzIG93biBEaWFtZXRlciBJZCBhbmQgZWFjaCBEaWFtZXRlciBJZCBjYW4gdXNlIGEgc2lu Z2xlIGNvbm5lY3Rpb24sIHdoaWNoDQogbWVhbnMgTiBjb25uZWN0aW9ucyBmb3IgdGhlIGhvc3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdmVyeXRoaW5nIGVs c2UgdGhhbiB0aGUgJnF1b3Q7MSBjb25uZWN0aW9uIHBlciBEaWFtZXRlciBJZCZxdW90OyBwYXJh ZGlnbSBpcyBvdXQgb2YgdGhlIERpYW1ldGVyIHNwZWMuIFNhbWUgZm9yIGhvdyBjb3VsZCBpbXBs ZW1lbnRlZCB0aGUgJnF1b3Q7MSBEaWFtZXRlciBJZCZxdW90Ow0KIGluIGFuIG11bHRpcGxlIGlu c3RhbmNlIGVudmlyb25tZW50LCBhcyBwb2ludGVkIG91dCBieSBKb3VuaS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gdGhlIHBlZXIgc3RhdGUgbWFjaGluZSBkZXNjcmlw dGlvbiwgaXQgaXMgY2xlYXIgdGhhdCBvbmx5IG9uZSBjb25uZWN0aW9uIGlzIGNyZWF0ZWQgcGVy IERpYW1ldGVyIElkLCBpLmUuIG9uZSBUQ1AgY29ubmVjdGlvbiBvciBvbmUgU0NUUCBhc3NvY2lh dGlvbg0KICh3aGljaCBjYW4gYmUgbXVsdGktaG9tZWQpLiBBbmQgaXQgaXMgYmFzZWQgb24gdGhp cyBwcmluY2lwbGUgdGhhdCBDRVIvQ0VBIGFuZCBEV1IvRFdBIGFyZSB1c2VkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm93LCBpdCBpcyBhbHNvIHNhaWQ6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBzdGF0ZSBtYWNoaW5lIGNvbnN0cmFpbnMgb25s eSB0aGUgYmVoYXZpb3Igb2YgYSBEaWFtZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGltcGxl bWVudGF0aW9uIGFzIHNlZW4gYnkgRGlhbWV0ZXIgcGVlcnMgdGhyb3VnaCBldmVudHMgb24gdGhl IHdpcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBbnkgaW1wbGVt ZW50YXRpb24gdGhhdCBwcm9kdWNlcyBlcXVpdmFsZW50IHJlc3VsdHMgaXMgY29uc2lkZXJlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNvbXBsaWFudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gd2hhdGV2ZXIgdGhlIGltcGxl bWVudGF0aW9uIG9mIHRoZSBEaWFtZXRlciBub2RlLCBlLmcuIDEgb3IgTiBpbnN0YW5jZSBvbiB0 aGUgc2FtZSBob3N0LCAxIG9yIE4gRGlhbWV0ZXIgSWRzLCB0aGlzIG5vZGUgc2hvdWxkIGNvbXBs eSB3aXRoIHJlcXVpcmVtZW50cw0KIHJlZ2FyZGluZyB0aGUgY29ubmVjdGlvbiBtYW5hZ2VtZW50 LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBBamlua3lhIEpvc2hpIFttYWlsdG86YWpvc2hpQGRlZmluaXRpb25uZXR3 b3Jrcy5jb21dDQo8YnI+DQo8Yj5FbnY8L2I+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5vecOpJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBtZXJjcmVkaSA4IG1hcnMgMjAxNyAxNDozNDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gTU9SQU5E IExpb25lbCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBqb3VuaS5ub3NwYW07IGRpbWVA aWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbRGltZV0gUXVlc3Rpb25zIHJl Z2FyZGluZyBSRkMgNjczMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBMaW9uZWwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3UsIGlmIGl0IGlzIGp1c3Qg b25lIHRyYW5zcG9ydCBjb25uZWN0aW9uIGZyb20gdGhlIGV4dGVybmFsIHdvcmxkIHBlcnNwZWN0 aXZlLCB0aGVuIGl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciBldmVuIGlmIHRoZXJlIGFyZSBtdWx0 aXBsZSBwcm9jZXNzZXMgKGluc3RhbmNlcykgd2l0aGluIHRoYXQgcGVlciBoYW5kbGluZyB0aGF0 IG9uZSB0cmFuc3BvcnQuIEJ1dCBJDQogZmVlbCB0aGF0IFJGQyB3b3JkaW5nIGRvZXNuJ3QgcmVh bGx5IGluZGljYXRlIHRoYXQuIChzZWN0aW9uIDIuMSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj5BIGdpdmVuIERpYW1ldGVyIGluc3RhbmNlIG9mIHRoZSBwZWVy IHN0YXRlIG1hY2hpbmUgTVVTVCBOT1QgdXNlIG1vcmUmbmJzcDt0aGFuIG9uZSB0cmFuc3BvcnQg Y29ubmVjdGlvbiB0byBjb21tdW5pY2F0ZSB3aXRoIGEgZ2l2ZW4gcGVlciwmbmJzcDt1bmxlc3Mg bXVsdGlwbGUgaW5zdGFuY2VzIGV4aXN0IG9uIHRoZSBwZWVyLCBpbiB3aGljaCwgY2FzZQ0KIGEg c2VwYXJhdGUgY29ubmVjdGlvbiBwZXIgcHJvY2VzcyBpcyBhbGxvd2VkJnF1b3Q7PC9zcGFuPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGNhbiBnZXQgaW50ZXJwcmV0ZWQgYXMgbXVsdGlwbGUgdHJhbnNwb3J0IGNvbm5lY3Rp b25zIGFyZSBhbGxvd2VkIHVzaW5nIHNhbWUgZGlhbWV0ZXJpZGVudGl0eS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXIgOCwg MjAxNyBhdCA0OjM5IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBamlua3lhLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHdpbGwgZGVwZW5kIG9uIGhvdyB5b3VyICZx dW90O2ZvcmsmcXVvdDsgaXMgaW1wbGVtZW50ZWQgYW5kIGl0IGlzIHdoeSBpdCBpcyBjb25zaWRl cmVkIGFzDQogJnF1b3Q7aW1wbGVtZW50YXRpb24tc3BlY2lmaWMmcXVvdDsuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIE4gaW5zdGFuY2VzIGFyZSBzaGFy aW5nIHRoZSBzYW1lIERpYW1ldGVyIGlkIChEaWFtSWQgMSksIHlvdSBtYXkgaGF2ZSBhIHdheSB0 byBjb25zaWRlcg0KIHRoZSBjb25uZWN0aW9uIHVwIGFzIGxvbmcgYXMgb25lIGluc3RhbmNlIGlu c2lkZSB0aGUgcGVlciBpcyBhdmFpbGFibGUgYW5kIGFjdGl2ZS4gSW4gdGhhdCBjYXNlLCB0aGVy ZSBpcyBubyBpbXBhY3QgZm9yIG90aGVyIGRpYW1ldGVyIHBlZXJzIGluIHRoZSBuZXR3b3JrLiBG b3IgdGhlIG91dHNpZGUgd29ybGQsIHRoZXJlIHdvdWxkIGJlIG9ubHkgb25lIHRyYW5zcG9ydCBj b25uZWN0aW9uIG9wZW5lZCB3aXRoICZxdW90O0RpYW1JZCAxJnF1b3Q7LCBpbmRlcGVuZGVudGx5 DQogb2YgdGhlIG51bWJlciBvZiBpbnN0YW5jZSBiZWhpbmQgJnF1b3Q7RGlhbUlkIDEmcXVvdDsu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW9uZWw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g RGlNRSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5kaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwv Yj4gQWppbmt5YSBKb3NoaTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSA4IG1h cnMgMjAxNyAxMDozNzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gam91bmkubm9zcGFtPGJyPg0KPGI+ Q2MmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RpbWVd IFF1ZXN0aW9ucyByZWdhcmRpbmcgUkZDIDY3MzM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIE1hciA3LCAyMDE3IGF0IDEwOjA0IFBNLCBq b3VuaS5ub3NwYW0gJmx0OzxhIGhyZWY9Im1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+am91bmkubm9zcGFtQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmhpLDxicj4N Cjxicj4NCjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDsgT24g TWFyIDcsIDIwMTcsIGF0IDM6MDEgQU0sIEFqaW5reWEgSm9zaGkgJmx0OzxhIGhyZWY9Im1haWx0 bzpham9zaGlAZGVmaW5pdGlvbm5ldHdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFqb3NoaUBk ZWZpbml0aW9ubmV0d29ya3MuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxicj4NCjxzcGFuIGNs YXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0OyBIZWxsbyw8L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0Ozwvc3Bhbj48 YnI+DQo8c3BhbiBjbGFzcz0ibS01MTU3NDIyMTg1ODY4Njk1NDA3Z21haWwtIj4mZ3Q7IEkgaGF2 ZSBmb2xsb3dpbmcgcXVlc3Rpb25zIHJlZ2FyZGluZyBkaWFtZXRlciBSRkMgNjczMywgSSB3b3Vs ZCByZWFsbHkgYXBwcmVjaWF0ZSBpZiBzb21lb25lIGNhbiBoZWxwIG1lIHdpdGggdGhlc2UuPC9z cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDs8 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0 OyAxLiBSZWdhcmRpbmcgZGlhbWV0ZXIgcGVlciBzdGF0ZSBtYWNoaW5lIC08L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0ibS01MTU3NDIyMTg1ODY4Njk1NDA3Z21haWwtIj4mZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtTZWN0aW9uIDUuNi4xIChQZWVyIFN0YXRlIE1hY2hpbmUgLS0mZ3Q7IEluY29t aW5nIGNvbm5lY3Rpb25zKSBtZW50aW9ucyB0aGF0IE9yaWdpbi1ob3N0IGlzIHVzZWQgZm9yJm5i c3A7ICZuYnNwOyAmbmJzcDtpZGVudGlmeWluZyBwZWVyIHN0YXRlIG1hY2hpbmUgYW5kIGFzIHBl ciBzdGF0ZSBtYWNoaW5lLCBvbmNlIGl0IG1vdmVzIGludG8gSS1PcGVuLCBuZXcgQ0VSIGlzJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVqZWN0ZWQuDQogVGhpcyBjb25jbHVkZXMsIHRoYXQg dGhlcmUgY2FuJ3QgYmUgbW9yZSB0aGFuIG9uZSB0cmFuc3BvcnQgY29ubmVjdGlvbnMgd2l0aCBz YW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2RpYW1ldGVyIGhvc3QgKGFzIHNwZWNpZmllZCBieSBPcmlnaW4taG9zdCkuPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDs8L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7U2VjdGlvbiAyLjEgKFRyYW5zcG9ydCkgbWVudGlvbnMgdGhhdCAmcXVvdDtB IGdpdmVuIERpYW1ldGVyIGluc3RhbmNlIG9mIHRoZSBwZWVyIHN0YXRlIG1hY2hpbmUgTVVTVCZu YnNwOyAmbmJzcDsgJm5ic3A7IE5PVCB1c2UgbW9yZSB0aGFuIG9uZSB0cmFuc3BvcnQgY29ubmVj dGlvbiB0byBjb21tdW5pY2F0ZSB3aXRoIGEgZ2l2ZW4gcGVlciwgdW5sZXNzIG11bHRpcGxlJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluc3RhbmNlcw0KIGV4aXN0IG9uIHRoZSBwZWVyLCBp biB3aGljaCwgY2FzZSBhIHNlcGFyYXRlIGNvbm5lY3Rpb24gcGVyIHByb2Nlc3MgaXMgYWxsb3dl ZC4mcXVvdDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dt YWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibS01MTU3NDIyMTg1ODY4Njk1NDA3 Z21haWwtIj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUXVlc3Rpb25zIC0tPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDvigKIgRG9lcyBzZWN0aW9uIDIuMSBpbXBsaWNpdGx5IGFzc3VtZXMg dGhhdCBtdWx0aXBsZSBkaWFtZXRlciBpbnN0YW5jZXMgKHdpdGhpbiBhIHBlZXIpIHdvdWxkIGNv cnJlc3BvbmQgdG8gZGlmZmVyZW50IGRpYW1ldGVyIGhvc3QgPyBPdGhlcndpc2UsIGl0IGNvdWxk IGNvbnRyYWRpY3Qgd2l0aCBzZWN0aW9uIDUuNi4xPC9zcGFuPjxicj4NCjxicj4NCml0IGFzc3Vt ZXMgb25lIHBlZXIgY29ubmVjdGlvbiBwZXIgcGVlciBzdGF0ZSBtYWNoaW5lLiBzbyBpZiB5b3Ug aGF2ZSBhIHdheSB0byDigJhmb3Jr4oCZIGEgbmV3IHBlZXIgaW5zdGFuY2Ugd2l0aCBpdHMgb3du IHBlZXIgc3RhdGUgbWFjaGluZSBwZXIgaW5jb21pbmcgY29ubmVjdGlvbiB0aGVuIGhhdmluZyDi gJxtdWx0aXBsZSBpbnN0YW5jZXPigJkgaXMgcG9zc2libGUgZXZlbiBpZiB0aGUgZGlhbWV0ZXJp ZGVudGl0eSBpcyB0aGUgc2FtZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5bYWpvc2hpXSBJZiB3ZSBmb3JrIGEgbmV3IHBlZXIgaW5zdGFuY2Ugd2l0 aCBzYW1lIGRpYW1ldGVyaWRlbnRpdHksIHdvbid0IGl0IGNyZWF0ZSBwcm9ibGVtcyBhcyBwZXIg cGVlciBzdGF0ZSBtYWNoaW5lPyBCZWNhdXNlLCB5b3Ugd291bGQgaGF2ZSBzZXBhcmF0ZSB0cmFu c3BvcnQgY29ubmVjdGlvbiBmb3INCiBlYWNoIG9mIHRoZW0gYW5kIGVhY2ggdHJhbnNwb3J0IGNv bm5lY3Rpb24gbmVlZHMgY2FwYWJpbGl0eSBleGNoYW5nZSBhbmQgYXMgcGVyIHBlZXIgc3RhdGUg bWFjaGluZSwgdGhlcmUgY2FuIGJlIG9ubHkgb25lIGNhcGFiaWxpdHkgZXhjaGFuZ2UuIEkgYW0g aW5mZXJyaW5nIHRoaXMgYmFzZWQgb24gc2VjdGlvbiA1LjMgd2hpY2ggc2F5cyAmcXVvdDtXaGVu IHR3byBEaWFtZXRlciBwZWVycyBlc3RhYmxpc2ggYSB0cmFuc3BvcnQgY29ubmVjdGlvbiwgdGhl eQ0KIE1VU1QgZXhjaGFuZ2UgdGhlIENhcGFiaWxpdGllcyBFeGNoYW5nZSBtZXNzYWdlcyZxdW90 Oy4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlPyBPciBpcyBpdCB0aGUgY2FzZSB0aGF0IHR3 byBwZWVycyAoaWRlbnRpZmllZCBiYXNlZCBvbiB0aGVpciByZXNwZWN0aXZlIGRpYW1ldGVyIGhv c3QtbmFtZXMpIHdvdWxkIHBlcmZvcm0gY2FwYWJpbGl0eSBleGNoYW5nZSBvbmx5IG9uY2UsIGly cmVzcGVjdGl2ZSBvZiBudW1iZXIgb2YgdHJhbnNwb3J0IGNvbm5lY3Rpb25zDQogdGhleSBoYXZl PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDvigKIgSWYgbXVsdGlwbGUgdHJhbnNwb3J0IGNvbm5lY3Rpb25z ICh0b3dhcmRzIHRoZSBzYW1lIHBlZXIpIGFyZSBhbGxvd2VkIHBlciBkaWFtZXRlciBob3N0LCBp cyBpdCBleHBlY3RlZCB0aGF0IHBlZXIgd291bGQgZG8gbG9hZCBiYWxhbmNpbmcgYmV0d2VlbiB0 aGVtPyAoVGhlcmUgaXMgYSBjb25uZWN0aW9uIGxvYWQgYmFsYW5jaW5nIHNlY3Rpb24gaW4gUkZD IDM1MzkgLSBTZWN0aW9uIDMuNC4zKTxicj4NCjxicj4NCndoYXQgeW91IGRvIGFuZCBob3cgeW91 IG1hbmFnZSDigJhtdWx0aXBsZSBpbnN0YW5jZXPigJkgaWYgbW9yZSBvciBsZXNzIGxlZnQgZm9y IGltcGxlbWVudGF0aW9uIHRvIGRlY2lkZS4gaSBhbHdheXMgY29uc2lkZXJlZCBpdCBhcyBhIG5v ZGUgaW50ZXJuYWwgY29tcHV0ZSBsb2FkIGJhbGFuY2luZyBtZWNoYW5pc20gaS5lLiwgdG8gZGlz dHJpYnV0ZSB0aGUgY29tcHV0ZSB0byBzZXBhcmF0ZSBjb3Jlcy9ibGFkZXMgZXRjLjxicj4NCjxi cj4NCjxicj4NCjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDsg Mi4gUmVnYXJkaW5nIGRpYW1ldGVyIHBlZXIgZmFpbGJhY2sgcHJvY2VkdXJlIC08L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0Ozwvc3Bhbj48 YnI+DQo8c3BhbiBjbGFzcz0ibS01MTU3NDIyMTg1ODY4Njk1NDA3Z21haWwtIj4mZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2VjdGlvbiA1LjUuNCBtZW50aW9ucyAmcXVvdDthIGNvbm5l Y3Rpb24gcmVxdWVzdCBzaG91bGQgYmUgcGVyaW9kaWNhbGx5IGF0dGVtcHRlZCB3aXRoIHRoZSBm YWlsZWQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcGVl ciBpbiBvcmRlciB0byByZS1lc3RhYmxpc2ggdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uJnF1b3Q7 PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZn dDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+ Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1F1ZXN0aW9uIC0tPC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC0iPiZndDs8L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLSI+Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO+KAoiBJZiB0aGUgZmFpbGVkIHBlZXIgaXMgZHluYW1pY2FsbHkgZGlz Y292ZXJlZCB2aWEgRE5TIGxvb2t1cCwgaXMgaXQgZXhwZWN0ZWQgdGhhdCBwZWVyIHdvdWxkIHBl cmZvcm0gRE5TIHF1ZXJ5IGJlZm9yZSB0cnlpbmcgdG8gZXN0YWJsaXNoIHRoZSBjb25uZWN0aW9u IGFnYWluPyBPciBETlMgbG9va3VwIGlzIGRyaXZlbiBvbmx5IGJ5IFRUTCBmaWVsZCByZWNlaXZl ZA0KIGluIHRoZSBwcmlvciBETlMgYW5zd2VyID88L3NwYW4+PGJyPg0KPGJyPg0KdXAgdG8geW91 ciBpbXBsZW1lbnRhdGlvbiBhbmQgZG5zIHJlc29sdmVyIGltcGxlbWVudGF0aW9uLjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS01MTU3NDIyMTg1 ODY4Njk1NDA3Z21haWwtaG9lbnpiIj4tIGpvdW5pPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxz cGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC1ob2VuemIiPiZndDsgLS08L3Nw YW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLWhvZW56YiI+ Jmd0OyBSZWdhcmRzLDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibS01MTU3NDIyMTg1ODY4Njk1 NDA3Z21haWwtaG9lbnpiIj4mZ3Q7IEFqaW5reWEgSm9zaGk8L3NwYW4+PGJyPg0KPHNwYW4gY2xh c3M9Im0tNTE1NzQyMjE4NTg2ODY5NTQwN2dtYWlsLWhvZW56YiI+Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFz cz0ibS01MTU3NDIyMTg1ODY4Njk1NDA3Z21haWwtaG9lbnpiIj4mZ3Q7IERpTUUgbWFpbGluZyBs aXN0PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIxODU4Njg2OTU0MDdnbWFpbC1o b2VuemIiPiZndDsgPGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCkRpTUVAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTUxNTc0MjIx ODU4Njg2OTU0MDdnbWFpbC1ob2VuemIiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibHVlIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymx1ZSI+QWppbmt5YSBKb3No aTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy PG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3By ZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsdWUiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymx1ZSI+QWppbmt5YSBKb3NoaTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_6B7134B31289DC4FAF731D844122B36E0C06F709OPEXCLILM43corp_-- From nobody Wed Mar 8 12:08:04 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F863129588 for ; Wed, 8 Mar 2017 12:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMbWQSALKPTR for ; Wed, 8 Mar 2017 12:08:01 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B83129594 for ; Wed, 8 Mar 2017 12:07:59 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id a6so19465281lfa.0 for ; Wed, 08 Mar 2017 12:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Th8m1dIlJ4bZw3GjtltQT35kdiXbQJDUHnphrX2Nbo0=; b=r0a+NHyo/KcUhmFNr1LCmYFL2DAoSPZx117oV7bWICQloTmCoMvlIL8TuxRUIiR1Wh kXuQDfZRPHJJC1ajhzJR8ISlhd3erfgFCeaQBvm/IX6Pm/EKmZFmUSlVJ+3luPOIxUZW zXZRLzA+zO9K+aCxVxWqbo0CtO1pvwYsisDrZ5shkoiFrFd8napc6MkyCYgWHvkgS4dT XkG3SbT2OZKnq3KDucBDSDPvXrQtjInnCCXN7Rx8JpXw9lvU+BONwqEJZFz0+6S3P9BH PbXjLDh1UkvJmV9nZK2y72SQRKuJ7GPSW4fEPQttUyG1Wj0UZ3OGsKgLbGIhumxi4DBo f4cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Th8m1dIlJ4bZw3GjtltQT35kdiXbQJDUHnphrX2Nbo0=; b=CjB+FJG1NozhGK+WXpbTDK8SEfRnAWe80awni+sRO8Nz12hv97pujuMjUD+ksiANs5 HY0eygQn9iPROCTu0UXGuDnTLDgcJbK1ZD8ZiiV7/aV12fnNRdS1l6j2tK9IoCHHuqZ7 NAvM+qfI1AhyjZNzuZyL9Ro6j3vNOToR1P5UU30omtdT+QfgzKID4opUaU0P8uqoHcj9 H2waNB17YWsJTmAfvtk+KYqDR8GpgiFmU5l0wCqyIsPqr6okkulvIoFjRwRCv6LdgB9o bR5UwL9I/larbg+b8INgG5X/qPWt5/0EHOuMp6N9UPWEGW3cSP5kyPC5klbxr+pT8Ydo Q6kA== X-Gm-Message-State: AMke39lVSDjbic+bcQLrbzv5YR2gRsFIRqURt6Hfa9HnXaFmv7nIe2qdPE88D203xkXFxVrVK9ewBz+6UUtbPw== X-Received: by 10.25.125.132 with SMTP id y126mr2376775lfc.102.1489003677615; Wed, 08 Mar 2017 12:07:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.1 with HTTP; Wed, 8 Mar 2017 12:07:57 -0800 (PST) In-Reply-To: <3cc40001-cf24-be8c-ef1a-e6138f1b8351@usdonovans.com> References: <148648420573.16333.15352530276464414850.idtracker@ietfa.amsl.com> <3cc40001-cf24-be8c-ef1a-e6138f1b8351@usdonovans.com> From: Misha Zaytsev Date: Wed, 8 Mar 2017 23:07:57 +0300 Message-ID: To: Steve Donovan Content-Type: multipart/alternative; boundary=001a114afaf2461609054a3daf54 Archived-At: Cc: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-agent-overload-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 20:08:03 -0000 --001a114afaf2461609054a3daf54 Content-Type: text/plain; charset=UTF-8 Hi Steve, I'm OK with all your answers, except one: SRD> A report is carried in a request. The DiameterIdentity contained in the SourceID is compared to the DiameterIdentity of the entity that sent the message that carried the report. I have changed "request" to "response message" to be correct here. [Misha]: You mean an overload report can be carried in a request? If so, I'm a bit confused to hear that... Anyhow, you have already corrected "request" to "response message" that will be interpreted in the only possible way. Thanks! 2017-03-07 17:45 GMT+03:00 Steve Donovan : > Misha, > > See my comments inline. > > Steve > > On 2/22/17 12:56 PM, Misha Zaytsev wrote: > > Hi Steve, > > Let me also reply to your edits when you were applying my comments. I > still have some concerns. > I will use the old numbering of the comments from my previous mails. > > 8. section 4 > LOSS" Is it a new type defined in the scope of this draft? > > SRD> Loss is defined in the DOIC specification (RFC 7683) > > [Misha]: All mentions about "LOSS" in the RFC7683 are related to loss > algorithm. > Nothing is mentioned in relation to report type like in this section. So, > I think my comment is still valid. > > SRD> I agree the wording is bad. I've changed it to teh following -- > "This is especially a concern if both > reports indicate the LOSS abatement algorithm." > > 15. section 5.2.3 > Still thinking that it is more correct to change "request" to "report" in > 2nd and 3rd paragraphs. > > If a reacting node receives an OC-OLR AVP of type peer and the > SourceID matches the DiameterIdentity of the Diameter peer from which > the *report *was received then the report was generated by a Diameter > peer. > > If a reacting node receives an OC-OLR AVP of type peer and the > SourceID does not match the DiameterIdentity of the Diameter peer > from which the *report *was received then the reacting node MUST > ignore the overload report. > > This will be aligned with 1st paragraph in this case. If you still do no > agree, then please explain what request is meant here since the 1st > paragraph is saying about "report". > > SRD> A report is carried in a request. The DiameterIdentity contained in > the SourceID is compared to the DiameterIdentity of the entity that sent > the message that carried the report. I have changed "request" to "response > message" to be correct here. > > > Could you check this particular section? > I think you can easily find the places where these 3 different terms are > used in the section text: "Peer Report OLR", "OC-OLR AVP", "OLR" > > Here is just one example: > > If the *Peer Report OLR *was received from a Diameter peer then the > reacting node MUST determine if it is for an existing or new overload > condition. > > My proposal was to use the only term "peer report" for all such > occurrences. > The reason behind is to avoid multiplying the usage of the different terms > that are about the same entity and just use the only one. > > SRD> Done. > > > 16. section 5.2.3 + 22. section 6.2 > How may it happen that peer report reacting node receives a peer report > not from the peer that generated it? > Peer reports can be sent only to peer report reacting node, right? And > peer reports are not relayed, right? > > SRD> This is to handle cases where there are agents in the network that do > not support the peer report feature. These agents would relay peer > reports, as they would any other AVP they don't understand. > > SRD> It is correct that a DOIC node should *not (?)* send a peer report > to a non supporting node. We, however, are paranoid, and left the wording > in the specification to handle miss behaving DOIC nodes, given that bad > things can happen when erroneous or malicious overload reports are inserted > into the network. > > [Misha]: If peer report cannot/should not be sent thru an agent that does > not support peer report feature and the only reason to leave such wording > in the spec is protect against potential malicious reports inserted somehow > in the network, then I'm proposing to explicitly state such things in the > spec. Otherwise, this wording may be misleading/contradicting (with other > parts of the spec) when reading the spec > > SRD> I've added the following note to clarify -- "Note: Under normal > circumstances, a Diameter node will not add a peer report when sending to a > peer that does not support this extension. This requirement is to handle > the case where peer reports are erroneously or maliciously inserted into > response messages. > > Best regards, > > /Misha > > 2017-02-07 21:10 GMT+03:00 Misha Zaytsev : > >> Hi Steve, >> >> It looks that some of my comments (which I did not send in the first 2 >> mail) were lost. >> So, I'm putting them here: >> >> 24. section 6.1.1. "OC-Feature-Vector" -> "OC-Feature-Vector AVP" in the >> header. >> >> 25. section 6.1.2 "OC-Peer-Algo" -> "OC-Peer-Algo AVP" in the header >> >> 26. section 6.2 corrected AVP names >> >> This extension makes no changes to the *OC-Sequence-Number* or >> *OC-Validity-Duration* AVPs in the OC-OLR AVP. >> >> 27. section 6.3 >> >> Probably, it is the matter of preference, but I would still propose to >> rename SourceID to Source-Identity. >> >> 28. section 6.4. >> >> 6.4. Attribute Value Pair *F*lag *R*ules >> >> 29. section 7.1 >> >> 7.1. AVP *C*odes >> >> >> 30. section 7.2 >> >> 7.2. New *R*egistries >> >> >> Also I will check your answers on my applied comments in detail and come >> back to you if I still have any concerns. >> >> /Misha >> >> >> 2017-02-07 19:19 GMT+03:00 Steve Donovan : >> >>> I've attached the diff file for this version of the draft. >>> >>> Regards, >>> >>> Steve >>> >>> >>> On 2/7/17 10:16 AM, internet-drafts@ietf.org wrote: >>> >>>> 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 of >>>> the IETF. >>>> >>>> Title : Diameter Agent Overload and the Peer >>>> Overload Report >>>> Author : Steve Donovan >>>> Filename : draft-ietf-dime-agent-overload-09.txt >>>> Pages : 17 >>>> Date : 2017-02-07 >>>> >>>> Abstract: >>>> This specification documents an extension to RFC 7683 (Diameter >>>> Overload Indication Conveyance (DOIC)) base solution. The extension >>>> defines the Peer overload report type. The initial use case for the >>>> Peer report is the handling of occurrences of overload of a Diameter >>>> agent. >>>> >>>> Requirements >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-dime-agent-overload-09 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-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/ >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> >> > > --001a114afaf2461609054a3daf54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Steve,

I'm OK= with all your answers, except one:

SRD&= gt; A report is carried in a request.=C2=A0 The DiameterIdentity contained = in the SourceID is compared to the DiameterIdentity of the entity that sent= the message that carried the report.=C2=A0 I have changed "request&qu= ot; to "response message" to be correct here.

[Misha]: You mean an overl= oad report can be carried in a request? If so, I'm a bit confused to he= ar that...
Anyhow, you have alr= eady corrected "request" to "response message" that wil= l be interpreted in the only possible way.=C2=A0

Thanks!

2017-03-07 17:45= GMT+03:00 Steve Donovan <srdonovan@usdonovans.com>:<= br>
=20 =20 =20
Misha,

See my comments inline.

Steve

On 2/22/17 12:56 P= M, Misha Zaytsev wrote:
Hi Steve,

Let me also reply to your edits when you were applying my comments. I still have some concerns.
I will use the old numbering of the comments from my previous mails.

8. section 4
LOSS" Is it a new type defined in the scope of this draft= ?

SRD> Loss is defined in the DOIC specification (RFC 7683)

[Mish= a]: All mentions about "LOSS" in the RFC7683 are relate= d to loss algorithm.
Nothi= ng is mentioned in relation to report type like in this section. So, I think my comment is still valid.

 SRD> I agree the wording is bad.=C2=A0 I've changed it to teh following -- "This is especially a concern if both
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reports indicate the LOSS ab= atement algorithm."
15. section 5.2.3
Still thinking that it is more correct to change "request" = to "report" in 2nd and 3rd paragraphs.

If a reacting node receives an OC-OLR AVP of type peer and the
=C2=A0 =C2=A0SourceID matches the DiameterIdentity of the Diamete= r peer from which
=C2=A0 =C2=A0the report was received then the report was generated by a Diameter
=C2=A0 =C2=A0peer.

=C2=A0 =C2=A0If a reacting node receives an OC-OLR AVP of type pe= er and the
=C2=A0 =C2=A0SourceID does not match the DiameterIdentity of the Diameter peer
=C2=A0 =C2=A0from which the report was received then the reacting node MUST
=C2=A0 =C2=A0ignore the overload report.

This will be aligned with 1st paragraph in this case. If you still do no agree, then please explain what request is meant here since the 1st paragraph is saying about "report".<= br>
SRD> A report is carried in a request.=C2=A0 The DiameterIdentity contained in the SourceID is compared to the DiameterIdentity of the entity that sent the message that carried the report.=C2=A0 I have changed "request" to "response message" to be corre= ct here.

Could you check this particular section?
I think you can easily find the places where these 3 different terms are used in the section text: "Peer Report OLR", "OC-OLR AVP", "OLR"

Here is just one example:

If the Peer Report OLR was received from a Diameter peer then the
reacting node MUST determine if it is for an existing or new overload
condition.

My proposal was to use the only term "peer report" for all such occurrences.
The reason behind is to avoid multiplying the usage of the different terms that are about the same entity and just use the only one.
 SRD> Done.

16. section 5.2.3 + 22. section 6.2
How may it happen that peer report reacting node receives a peer report not from the peer that generated it?
Peer reports can be sent only to peer report reacting node, right? And peer reports are not relayed, right?
SRD> This is to handle cases where there are agents in the network that do not support the peer report feature.=C2=A0 These agents would relay peer reports, as they would any other AVP they don't understand.

SRD> It is correct that a DOIC node should not (?) send a peer report to a non supporting node.=C2=A0 We, however, are paranoid, and left the wording in the specification to handle miss behaving DOIC nodes, given that bad things can happen when erroneous or malicious overload reports are inserted into the network.

[Misha]: If peer report cannot/should not be sent thru an agent that does not support peer report feature and the only reason to leave such wording in the spec is protect against potential malicious reports inserted somehow in the network, then I'm proposing to explicitly state such things in the spec. Otherwise, this wording may be misleading/contradicting (with other parts of the spec) when reading the spec
 SRD> I've added the following note to clarify -- "Note: Und= er normal circumstances, a Diameter node will not add a peer report when sending to a peer that does not support this extension.=C2=A0 This requirement is to handle the case where peer reports are erroneously or maliciously inserted into response messages.
<= br>
Best regards,

/Misha

2017-02-07 21:10 GMT+03:00 Misha Zaytsev <misha.zaytsev.rus@gmail.com>:
Hi Steve,

It looks that some of my comments (which I did not send in the first 2 mail) were lost.
So, I'm putting them here:

24. section 6.1.1. "OC-Feature-Vector"= -> "OC-Feature-Vector AVP" in the header.
25. section 6.1.2 "OC-Peer-Algo" -> "OC-Peer-Algo AVP" in the header

26. section 6.2 corrected AVP names

This extension makes no changes to the=C2=A0OC-Seque= nce-Number=C2=A0or=C2=A0OC-Validity-Duration=C2=A0AVPs in the OC-OLR AVP.

27. section 6.3

Probably, it is the matter of preference, but I would still propose to rename SourceID to Source-Identity.

28. section 6.4.

6.4.  Attribute Value Pair Flag Rules
29. section 7.1

7.1.  AVP Codes=

30. section 7.2

7.2.  New Registries

Also I will check your answers on my applied comments in detail and come back to you if I still have any concerns.

/Misha


2017-02-07 19:19 GMT+03:00 Steve Donovan <srdonovan@usdonovans.com>= :
I've attached the diff file for this version of the draft.

Regards,

Steve


On 2/7/17 10:16 AM, internet-drafts@ietf.org wrote:
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 of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Diameter Agent Overload and the Peer Overload Report
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Steve Donovan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2= =A0 =C2=A0 =C2=A0 : draft-ietf-dime-agent-overload-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017-02-07

Abstract:
=C2=A0 =C2=A0 This specification documents an extension to RFC 7683 (Diameter
=C2=A0 =C2=A0 Overload Indication Conveyance (D= OIC)) base solution.=C2=A0 The extension
=C2=A0 =C2=A0 defines the Peer overload report = type.=C2=A0 The initial use case for the
=C2=A0 =C2=A0 Peer report is the handling of occurrences of overload of a Diameter
=C2=A0 =C2=A0 agent.

Requirements

The IETF datatracker status page for this draft is:
https://= datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/

There's also a htmlized version available at:
https://too= ls.ietf.org/html/draft-ietf-dime-agent-overload-09

A diff from the previous version is available at:
htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-agent-overload-0= 9


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-draf= ts/

__________________________________________= _____
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/l= istinfo/dime


_______________________________________________<= br> DiME mailing list
Di= ME@ietf.org
https://www.ietf.org/mailman/li= stinfo/dime





--001a114afaf2461609054a3daf54-- From nobody Wed Mar 8 14:00:09 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE41293F5 for ; Wed, 8 Mar 2017 14:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZVM0F_sLlWZ for ; Wed, 8 Mar 2017 14:00:07 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 10B001289B0 for ; Wed, 8 Mar 2017 14:00:07 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n11so42117050wma.0 for ; Wed, 08 Mar 2017 14:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=imNecxCLWt69Zcy2A62EmtcBWTnkePSFJ3vYqJQ++mk=; b=aR6Qv/Zf0sNEYjVLwUTRRpir/beck7sf0pGbybzbRTlppWPcDR0jbEaIfo/JG/RwNW 3yDeyCHOnl4MQwBTz+3Ncql3uxhH/Tn2nTnLr799G1WqZrmVYQkYJ/rwe8iTNoGst2Zf 8TGHB32ivOS8JSquXD2ijukgPiG/fE1792gSUeygxmTjbQp6/6ylDAm6z9N/bux7THfH CS7iXz2SkoZfLc9IwzSHnDmstpxzJufUUYIlHMlNj959fRkJsY5i9f5++sQNaRWcKHuC I8q/NvsRVj8m0KXWmG1FRinXM0EDnq0A10G7rjT3L8nuD3ebodC4gU+61d3sikQtB/lw vpmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=imNecxCLWt69Zcy2A62EmtcBWTnkePSFJ3vYqJQ++mk=; b=a5BaDQeSJGV1ZvoWw7L1pQiP1RnzY9oDaCgEzHPi77qMsgDM/ShsrxOif3YXLxK6pC f9jgMC4AwydTAYygV9VvfJ8d/x8NRrjI6gxEYeZn4WhfEeFVzZrVCvMoWOCMyuu9qKFI 9gAMyWhiiiYmpw0YpMri0XHR4ibR9wtbm2tdjL2f/7IcNQ/8DW5cT32u22E99SPfL92M 2SmYzPC8wRaGtq6wL6ABQi7I+fpvyVY+PbF4DJEyzDITOcWbwk2f9ggNOiLfkydN+CSK 58Wgi6fBxG2JdHeZvn5RD3yF0MXfzWyNtM6dk6uUMcvtbImjsBenUVseKYr5wXf9S+1u Vadg== X-Gm-Message-State: AMke39mNx9mAfGy3SE2h+8jakqnMvrLaUyskq1o7ISKqwRoFxtCI44GPOSIygQENof7hOqiRu21vjN6YUZYrew== X-Received: by 10.28.187.68 with SMTP id l65mr7506100wmf.24.1489010405563; Wed, 08 Mar 2017 14:00:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.166.135 with HTTP; Wed, 8 Mar 2017 14:00:05 -0800 (PST) In-Reply-To: References: <70007418-7349-4560-828C-3FDD8894C239@gmail.com> From: jouni korhonen Date: Wed, 8 Mar 2017 14:00:05 -0800 Message-ID: To: Ajinkya Joshi Content-Type: multipart/alternative; boundary=001a114b09dc4a643c054a3f4037 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] Questions regarding RFC 6733 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 22:00:09 -0000 --001a114b09dc4a643c054a3f4037 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I specifically said that you would need to instantiate new peer state machines.. otherwise it does not really work. - Jouni On Wed, Mar 8, 2017 at 1:36 AM, Ajinkya Joshi wrote: > > > On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam > wrote: > >> hi, >> >> > On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi < >> ajoshi@definitionnetworks.com> wrote: >> > >> > Hello, >> > >> > I have following questions regarding diameter RFC 6733, I would really >> appreciate if someone can help me with these. >> > >> > 1. Regarding diameter peer state machine - >> > >> > Section 5.6.1 (Peer State Machine --> Incoming connections) >> mentions that Origin-host is used for identifying peer state machine >> and as per state machine, once it moves into I-Open, new CER is >> rejected. This concludes, that there can't be more than one transport >> connections with same diameter host (as specified by >> Origin-host). >> > >> > Section 2.1 (Transport) mentions that "A given Diameter instance o= f >> the peer state machine MUST NOT use more than one transport connect= ion >> to communicate with a given peer, unless multiple instances exist= on >> the peer, in which, case a separate connection per process is allowed." >> > >> > Questions -- >> > =E2=80=A2 Does section 2.1 implicitly assumes that multiple diam= eter >> instances (within a peer) would correspond to different diameter host ? >> Otherwise, it could contradict with section 5.6.1 >> >> it assumes one peer connection per peer state machine. so if you have a >> way to =E2=80=98fork=E2=80=99 a new peer instance with its own peer stat= e machine per >> incoming connection then having =E2=80=9Cmultiple instances=E2=80=99 is = possible even if >> the diameteridentity is the same. >> > > [ajoshi] If we fork a new peer instance with same diameteridentity, won't > it create problems as per peer state machine? Because, you would have > separate transport connection for each of them and each transport > connection needs capability exchange and as per peer state machine, there > can be only one capability exchange. I am inferring this based on section > 5.3 which says "When two Diameter peers establish a transport connection, > they MUST exchange the Capabilities Exchange messages". Am I missing > something here? Or is it the case that two peers (identified based on the= ir > respective diameter host-names) would perform capability exchange only > once, irrespective of number of transport connections they have? > > >> >> > =E2=80=A2 If multiple transport connections (towards the same pe= er) are >> allowed per diameter host, is it expected that peer would do load balanc= ing >> between them? (There is a connection load balancing section in RFC 3539 = - >> Section 3.4.3) >> >> what you do and how you manage =E2=80=98multiple instances=E2=80=99 if m= ore or less left >> for implementation to decide. i always considered it as a node internal >> compute load balancing mechanism i.e., to distribute the compute to >> separate cores/blades etc. >> >> >> > 2. Regarding diameter peer failback procedure - >> > >> > Section 5.5.4 mentions "a connection request should be >> periodically attempted with the failed peer in order to >> re-establish the transport connection" >> > >> > Question -- >> > >> > =E2=80=A2 If the failed peer is dynamically discovered via DNS l= ookup, is >> it expected that peer would perform DNS query before trying to establish >> the connection again? Or DNS lookup is driven only by TTL field received= in >> the prior DNS answer ? >> >> up to your implementation and dns resolver implementation. >> >> - jouni >> >> >> > -- >> > Regards, >> > Ajinkya Joshi >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www.ietf.org/mailman/listinfo/dime >> >> > > > -- > Regards, > Ajinkya Joshi > --001a114b09dc4a643c054a3f4037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I specifically said that you would need to instantiate new peer state m= achines.. otherwise it does not really work.

<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace;font-s= ize:x-small">- Jouni

On Wed, Mar 8, 2017 at 1:36 AM, Ajinkya Joshi &l= t;ajoshi= @definitionnetworks.com> wrote:


On Tue, Mar 7, 2017 at 10:04 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
hi,

> On Mar 7, 2017, at 3:01 AM, Ajinkya Joshi <ajoshi@definitionnetworks.com> wrote:
>
> Hello,
>
> I have following questions regarding diameter RFC 6733, I would really= appreciate if someone can help me with these.
>
> 1. Regarding diameter peer state machine -
>
>=C2=A0 =C2=A0 =C2=A0Section 5.6.1 (Peer State Machine --> Incoming c= onnections) mentions that Origin-host is used for=C2=A0 =C2=A0 =C2=A0identi= fying peer state machine and as per state machine, once it moves into I-Ope= n, new CER is=C2=A0 =C2=A0 =C2=A0 =C2=A0rejected. This concludes, that ther= e can't be more than one transport connections with same=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0diameter host (as specified by Ori= gin-host).
>
>=C2=A0 =C2=A0 =C2=A0Section 2.1 (Transport) mentions that "A given= Diameter instance of the peer state machine MUST=C2=A0 =C2=A0 =C2=A0 NOT u= se more than one transport connection to communicate with a given peer, unl= ess multiple=C2=A0 =C2=A0 =C2=A0 =C2=A0 instances exist on the peer, in whi= ch, case a separate connection per process is allowed."
>
>=C2=A0 =C2=A0 =C2=A0 Questions --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Does section 2.1 implicitly assume= s that multiple diameter instances (within a peer) would correspond to diff= erent diameter host ? Otherwise, it could contradict with section 5.6.1

it assumes one peer connection per peer state machine. so if you hav= e a way to =E2=80=98fork=E2=80=99 a new peer instance with its own peer sta= te machine per incoming connection then having =E2=80=9Cmultiple instances= =E2=80=99 is possible even if the diameteridentity is the same.

[ajoshi] If we fork a new peer instance wit= h same diameteridentity, won't it create problems as per peer state mac= hine? Because, you would have separate transport connection for each of the= m and each transport connection needs capability exchange and as per peer s= tate machine, there can be only one capability exchange. I am inferring thi= s based on section 5.3 which says "When two Diameter peers establish a= transport connection, they MUST exchange the Capabilities Exchange message= s". Am I missing something here? Or is it the case that two peers (ide= ntified based on their respective diameter host-names) would perform capabi= lity exchange only once, irrespective of number of transport connections th= ey have?
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If multiple transport connections = (towards the same peer) are allowed per diameter host, is it expected that = peer would do load balancing between them? (There is a connection load bala= ncing section in RFC 3539 - Section 3.4.3)

what you do and how you manage =E2=80=98multiple instances=E2=80=99 if more= or less left for implementation to decide. i always considered it as a nod= e internal compute load balancing mechanism i.e., to distribute the compute= to separate cores/blades etc.


> 2. Regarding diameter peer failback procedure -
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 5.5.4 mentions "a connection re= quest should be periodically attempted with the failed=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 peer in order to re-establish the transport con= nection"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question --
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If the failed peer is dynamically = discovered via DNS lookup, is it expected that peer would perform DNS query= before trying to establish the connection again? Or DNS lookup is driven o= nly by TTL field received in the prior DNS answer ?

up to your implementation and dns resolver implementation.
<= br> - jouni


> --
> Regards,
> Ajinkya Joshi
> _______________________________________________
> DiME mailing list
> DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime



--
Regards,
Ajinkya Joshi

--001a114b09dc4a643c054a3f4037-- From nobody Thu Mar 9 11:17:05 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2375D129857 for ; Thu, 9 Mar 2017 11:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq1KvmRE8LUv for ; Thu, 9 Mar 2017 11:16:54 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0092.outbound.protection.outlook.com [104.47.33.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56A8129858 for ; Thu, 9 Mar 2017 11:16:53 -0800 (PST) Received: from CY1PR05CA0020.namprd05.prod.outlook.com (10.166.186.158) by CY1PR05MB2745.namprd05.prod.outlook.com (10.167.18.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 9 Mar 2017 19:16:52 +0000 Received: from SN1NAM01FT049.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::204) by CY1PR05CA0020.outlook.office365.com (2a01:111:e400:c5a4::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.961.8 via Frontend Transport; Thu, 9 Mar 2017 19:16:52 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) 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.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by SN1NAM01FT049.mail.protection.outlook.com (10.152.64.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.7 via Frontend Transport; Thu, 9 Mar 2017 19:16:52 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v29J3qUZ046468 for ; Thu, 9 Mar 2017 13:16:51 -0600 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by plsapdm2.corp.sprint.com with ESMTP id 29181jft00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 09 Mar 2017 13:16:51 -0600 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 14:16:50 -0500 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.1210.000; Thu, 9 Mar 2017 13:16:50 -0600 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: New version (03) for draft-bertz-dime-policygroups Thread-Index: AdKZCZrNLavjGFikREaFAs5d7u2Nzw== Date: Thu, 9 Mar 2017 19:16:49 +0000 Message-ID: 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_e02c20eb3cea464291154988141c5b08plswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(2980300002)(438002)(199003)(189002)(9170700003)(8676002)(512954002)(790700001)(7696004)(4546004)(260700001)(8936002)(189998001)(6306002)(102836003)(6916009)(6116002)(1730700003)(38730400002)(54896002)(53936002)(2900100001)(7736002)(106466001)(2351001)(2501003)(86362001)(54356999)(81166006)(110136004)(2906002)(3846002)(5250100002)(5640700003)(108616004)(356003)(84326002)(5660300001)(50986999)(33646002)(230783001)(5000100001)(24736003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2745; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT049; 1:KOBDw/VaL7eHp/SSyRm6Gg8IRd0Tk1iFGss2NC4OfOJhuT7Zxnv2Vq33GG8ocRVDVBni92lTOUnh9j9HoBaIQDPjxXLMwZ8ZwUMxXs84MVZe9+s7eb0VIQYJsOb+pEJ7Zo/KXZSjfS2dVqR+r15S4h7ZJQK1viCUBf9c75bi59JdAgsLvYbGYXsT0NZD9oMX2eU88T5XzYU0DJtMejEjPaIgIMSFUv2mNauOKtr/FFz8sMkYhaAaDgJ/EEi6gXrk7wPCxoxUC1WfqG7Tks4S0Yn9+DticyiWp9T0xe1TZ8UppRp8xMmwhiSfirxr9JsCtEYh2o3HjylqwfldlYZNi5KJ3CjNqYaNIHA8n++mUZBOZfoCejlq4vDIxVSgYTlKEldKJKnGxW5I7jCT7ZCYosGsG8F+v6p6GaRtGXtNdLSWmX3CanekHSJxXa3iR8d2plDjf1FlKuwTBNQsNxpGc4sCgrhft95L/ElzmbzjOLaU/G88DobipC2m+C0k23bC2rK+1YSxfsbHwhkz8mcNjfR1OMgYyiuag1xeDl0ENiwSTdoDPdMJoJrb/R6pitC5 X-MS-Office365-Filtering-Correlation-Id: a5e737cc-8a11-4b24-cceb-08d46720d7bb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:CY1PR05MB2745; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2745; 3:XQ0L8JHT7nrPdFBf2JV+80dqNfDT19ap/PgL9UQ5IRZRZ/5i5eeRU9zfsY1Eka5wbiklWI8wtqzTTuB/39I4um4FkDaQQG0LoR5CiJMbT1tDTEtfbAq/1h5UTsZNMIvenR5vB802MvHBL4cRqoGenjjK5Xhy9AMXgt5xKRr3zOu8YOitDAaL+umw8x70MIO2FQluLFemuZ2GQ17O6ZRiPbzF+F6R/rNthrpGTQjiDc3lo21SjrO6kebwGJoVKJbPi4XvJBDn+gulf0Kx9aegZGaz6I8wnubfUeJ9KApN+/jF7jiFRN1NS69YBN05v8tWapj797xoe9EM99WkxictP2/HnsucXuxPsYbuzqjicBq5BmkZ1jQY5Zs7KgBsvYB+PFQZGdEUyDgMa9muEvnyAg==; 25:PNpG2q9bF2EHcPEtr37UxuHo1sbZEw+FjzimsSk3v7x6+ZLQT6yCueIZyRm+kU7tCSloqYK+6E3HjmEroxhiaEdxWXcqgWhgdCh8msY2IBaJAkAeOVVbSScGSoJk3auJJYsFQqSIg3dbjdh/+6vANWosu+p8GeSUeP7FBuZiChwXbWbF76iSltesHsMbbAztgVNxlldLYj5MAMuFfyEIs1JZ1MLFX+4uxaBEzXLd7GsVN1J9hkuKvHPog8cjibAi8yDdItHrOzGTDXX3ZQQa6C/F34ztD4nurNtzV/fNeYAXP9tGKHZCh7aln9NOr7hrY0zQpDTnjI7k+AZbBWjKCUCkrUz/HhlXygzTACkh7c1JkIRovUtF7xU5dLQ7z7Ht7UNfXq4jWecFJKyzddVCDogTMG/5I3WHlD5m/qg6sixBR+Y7qH+VJzSpTE0dwPKG8bsUzKToviE8gJgCgesFkQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2745; 31:SnvB7xrf3sELXRFhimhl07Jk9EGMrykCKHUSAY/6FXBFT5qAfsD2oEAXC/mlT1LhGYU36zU1WoL8AmrNRZmRVluWskN5R1U42qSbHktJExGPDWRWN7gjjtShrVEl40+jYr+3Q/KRkVuCHXX9Lg1AY6ymKXlHkcD2crO9Kz6y7lYuTWB0bnZW0j/9f3Gsqm/slemYLZBk+8pSWsCdlktr9TS6G7lL8y9QHhcpqntPnTKUZm9l1CUdsXK2MWMtknGflaVr8MFOc9EQz12Wsh8k3w==; 20:GM36fw5bgxQmfn6xLTNg2OA4yaKtc1HRud+ED+xUlPWTvvcCoTn4yIVMejGlAEFCSdY+6fHGEInStan8YobZjxtAllMfKfiJ0kAw9CjPCH/RYnRGF/yG/PPhOjdCZNLt67ElCDx7RjzW3bufpPsAYsz/MlLGjXywsdQzXKl1TUD0hZLcVwQsjHXCQTBC52OMbmVnsTXI4SuhswVeLRxJmvbHhcw/x9jOgwg3OHFN5rMCXhGORZZ4JGEdjbVXYrg0ytOsO4G0l36ipoU8NbQjgCM9rO+zz2UwVhWCL/SAo5yJ8/02bfT5vgnUlnvitq4YpTaw+ugKiB3u0ailizDgJOi3oEOkQ/qjSRjasKrDCVdzF3SuQ93s7vDuuXFv6vyT8JS7TB/57mLZq9xGIH/DZNtF226o6xBSZye3z0fS5+ywO1WLbN1Qzkx0c6QJSNGY5RhAY9FScbcQBx1Vkmru3WeST2l4bBFnjAb1evLolIN0PDYycVp3SXlBIh31dlf7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13018025)(13017025)(13015025)(13023025)(5005006)(13024025)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR05MB2745; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2745; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2745; 4:RLKc8Hz4A2mL5uJNT0VmEcMHxNyb461DDVYwVMWr7Qg58uws6rwjzqHAW4GEVks/Nml6AowE4JmsmAYXha1StJiNO7G+5ysYOpYpGCMLHHdjJw7V98HwuJFL50h3PNLXzHJokNtbuGJKjm7w1N9RdC1P3kPrFuFRlgHT4JPdQznqrG5aOMJo/pgX2a1kSgWXkdjogIxVzlHnZOaVlrLsA6GGqfqF8RZB/da7xzbuNk41DPk1M9bPGRAmnJQFJnzNlF9wSE7myNDVpnHJl/5AOVoURQdk6eoc48Jm+I5GA3cxhF3WH8RE/H2pKYlagH4GErFzvhr1wM089q0Zpp03M8nGmOQokZLI5LZtwxvC9i3G69xUeQ0pdZ/bDM3j8FGiS7M6ZWVwN9riDAsQFuQLWRR8nyzrZPE5Y8Q74+LjP5VdPkBoLx3IjAxaOvBvrOX267M8z8hFKj5Tg4ZrNDnwfVxSKFZjmYnbsFn/l/D+ftzEWxtGmA1TuQfvXe3KkzBQ66R1Ck8EywnWicqFh8LxffA+wIUHBlqQBAI3HXz1ui19N8LLibdriGxldpJiKbBCy8cvTfSpvWM2ndFJ0Xw219cKaWOANO06N3ZeLOpDk7A4OZScZSS/0/S0hnl97f++wmLJVPJu8+joEnOwT4Iaoss65+93uECwgOznxNdeU61XphQlHEGIjjxY3e+2Yz8k3bi2McV4Q1TUeFDdyBYKt/dFaUai1+bCQunRIW7FftfGxzSViSQEqMpyp9KB8916yINXjafBIaSbhKWaPD+YIw== X-Forefront-PRVS: 0241D5F98C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2745; 23:dz0vpsuN/Ii6kumzVuPNe89KYrgSj7GVsG1wJdLj+?= =?us-ascii?Q?erThEVI3NbgMCqUPZ7yPbDhZHqFfukZdapSeYOyHctuKYpqea/6eL4+6uhD1?= =?us-ascii?Q?NMyhbV3/MiYtzkCF7ksiZYkNYx+Er5wBrci6lkjQTy6Ss8yjtPWp3iDj/5VK?= =?us-ascii?Q?4ZTai7om4Ks47KyrRXvuLQRpWNklSVRNelj9xQeSnBpSkyrQHjNuGRWMjpoO?= =?us-ascii?Q?aZP6tw+FxDA3mYPSqlhQHAu4DVvMK9N177fwhEyy/EWVkw0LVlt5MLXV0fjS?= =?us-ascii?Q?xG7zFXZFr26HpKgoQ8LTNQPp0HJB0RN5IbGQVFZs3HwfNZVeVOz/DLq3QoVC?= =?us-ascii?Q?vpOi0SsskrAHUsEFAqY1k3xjAg4sJM/iFsnmdVoix9vmGpUmy1AudPCt1lV7?= =?us-ascii?Q?c6mGArv4YNz2hb6RArgrocjgNycVH6LxhD+K5RYa5UGBLlSavkwIfNRuE2zE?= =?us-ascii?Q?pJV0yCleKJ2I6IdMO3yejR6/P0+3SsyeinXmVGUntHzUnDPgAZdX2UUWrQZC?= =?us-ascii?Q?hh1QzYqOYxTRvuUTO9VHAuZ0tSCFopznxFS7h3aJhXA4YXXhzE8d0Um5u/13?= =?us-ascii?Q?Q+J7RNFVpK7l7jQcXxfWRJqFhtwB3os7b/MLUbAyiY3IgM147kaUPXttXV4s?= =?us-ascii?Q?BV4GzUN2+yV6uNaU+oui4eD45izi1B8xNQNKGKKvA1KXZvGo8zxY/k+FbM36?= =?us-ascii?Q?ptqPB9KEODjrUnDI8mZ99XUsJvqt9c80oxbFsCFjknvIy8IANLgkumZrMBI0?= =?us-ascii?Q?I9hXm5/hUhMG90GWMGtfIgdmptwoucENp8GlCdXM3opXz58h9+SBqnpyPDg2?= =?us-ascii?Q?9hGCamrYW/h2bKzEgGu+HHESQO+//ulyQycTbA2IFHT7yUSekxCUKyE/ZJPE?= =?us-ascii?Q?nHBfLKcJCWGJMlymK3X5bnMvCfoOpqQVxZ4/Br4TRl7dXJoxkiPX9QR8tkZI?= =?us-ascii?Q?r9G8D0pRVdQHE8y+pj+fdn2whUkihGjIejPHAKwoPJyP6QmEHbxk/L47w1rw?= =?us-ascii?Q?z4l8vmLQMhoaTNe4FxxUerXY/5H09eRYvaV8gsD7bKlIreAjPY24PkLnvGaE?= =?us-ascii?Q?0Ew0yXQ7aml25x52xZ/dO14zDAuJXHbiPUCqFLTpfnUUouj0OqpX+XwQGKoP?= =?us-ascii?Q?USoClwmuXUd7RKQdOfJy70aUHktAu0tveeqveOvriEbGEZsPq+wyLkHzf6QJ?= =?us-ascii?Q?TN/PTcclh6nmlbtUV0r/exM4wZoGnBnZcos?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2745; 6:MTocr9R0MzeHUCrTETN+EF/isrhQtxLuGV0BwmOOwpHYrXIunn8nrQLpsCgFmlIIS0BywLXS2mvleXPuyWaXV4Ac0tGE+H244XknuZwIMjcDsB4un9u+pLjGRVYweWZUsDJjSAwTMIZIH+meQZfXuOCNfKBckUi9Yoq7cbPxHJbMUcp9wNWHUDkQF/qGBerjlOhNuMC2wBOzJB6hKEFXwh6DZhMchIQ+yAe9swlQz9dyZsNIbhQwuRxyPuYxki+aze6Z3gB3c3goNfsuCM0YgCPTOHoii7sBddqUoQnC2pGxmHeBL5paDwqJNqOboyIi5paOZ5isNhD0SDCCFvulaj4ekPGRUGeMIAueCkqrGTlqqgcnp56rxU4fhXW0S8oZGAzuRoZ4cuSpDLGNXCcCqUAXUbdu73sYUFzYhmP97a8=; 5:omNSuICgxh0m+qOx+sNwwF8KGAmQVRnZtYzS9ZXTGKgwKF23BGw2ARu6bxIKoAdCYog3NruaJB1vYbS7twEmmoIL24xL4f4LvjInXRkq7KAJ1DDkV8eXyK94+enwIRQUEBekp//+zbwSAkQT8wUpn8GJGQGm+GcIMHlkRbcPw+Y=; 24:fGAtFK9WoZ/pnVccvPENIU5N91gTycXKXF25s2G/l0oeLpAxd/CxcG76FmX3rsU+dLHzQHdEtLs2h3xeu7h3+tlam5jFbyDwmV1sXXx5f7E= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2745; 7:aIRSeHXSBcxK80aoqrN311oxe6gXYDw7W4kGYVcwa+EN8kIlNY06EvY9SsE7kN63M35GceRxUWC5jrFx+9RhgaTEXC9sXYUHLTAjCZKaPYvzDNKZx1IT8H4n1dK0KKIKyxmLr3TnEuOK/XW1qiisnEsQwjSTylsPBdIxYz2DVsrmJH3Ukq7WRjU+9Z+1AMGcTWi4ni31BV33Gj7xfimlaxB3hHf2iZvKGS+u/BxoQASOV/tDD+gYV1p7nnVwsdlQtcf99p/X91+MXLTh/RgKuiFEqSIH9iEMAPMOS9oR67skUgO4Vd5B7bkATBWpFH2RE7mhZEn3qsQ0kxlIZ2XUpg== X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2017 19:16:52.0543 (UTC) 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.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2745 Archived-At: Subject: [Dime] New version (03) for draft-bertz-dime-policygroups X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:17:03 -0000 --_000_e02c20eb3cea464291154988141c5b08plswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, A new version is out. It adds Mark Bales as a co-author and has no other c= hanges. Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_e02c20eb3cea464291154988141c5b08plswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,


A new version is out.  It adds Mark Bales as a co-author and has no ot= her changes.

 

Lyle



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_e02c20eb3cea464291154988141c5b08plswe13m04adsprintcom_-- From nobody Thu Mar 9 12:25:03 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23D1293EE; Thu, 9 Mar 2017 12:25:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148909110247.5786.8225148400314873649@ietfa.amsl.com> Date: Thu, 09 Mar 2017 12:25:02 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:25:02 -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 of the IETF. Title : Diameter Credit-Control Application Authors : Lyle Bertz David Dolson Yuval Lifshitz Filename : draft-ietf-dime-rfc4006bis-02.txt Pages : 121 Date : 2017-03-09 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-rfc4006bis-02 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 Thu Mar 9 12:32:24 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAF312949F for ; Thu, 9 Mar 2017 12:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 9B3JNaaRh7P9 for ; Thu, 9 Mar 2017 12:32:22 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB83B12947A for ; Thu, 9 Mar 2017 12:32:21 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 9 Mar 2017 15:32:20 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 15:32:20 -0500 From: Dave Dolson To: "dime@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dime-rfc4006bis-02.txt Thread-Index: AQHSmRM8p74Y2wkEGkO1BPFYIDEYXqGM9Wyg Date: Thu, 9 Mar 2017 20:32:18 +0000 Message-ID: References: <148909110262.5786.9183455242172068412.idtracker@ietfa.amsl.com> In-Reply-To: <148909110262.5786.9183455242172068412.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Dime] FW: New Version Notification for draft-ietf-dime-rfc4006bis-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:32:23 -0000 RGlhbWV0ZXIgd29ya2luZyBncm91cCwNCg0KQSBuZXcgdmVyc2lvbiBvZiBSRkM0MDA2YmlzIGlz IGF2YWlsYWJsZSBhdCB0aGUgcmVmZXJlbmNlcyBiZWxvdy4NCg0KSWYgeW91IGFyZSB2aWV3aW5n IHRoZSBkaWZmcywgeW91IG1pZ2h0IHdvbmRlciBhYm91dCB0aGUgY2hhbmdlcyB0byB0aGUgc3Rh dGUgbWFjaGluZS4NClRoZXNlIGNoYW5nZXMgZml4IGFuIGVhcmxpZXIgdHJhbnNjcmlwdGlvbiBl cnJvci4gDQpUaGUgdGFibGVzIGluIFJGQzQwMDZiaXMgYXJlIGludGVuZGVkIHRvIGJlIHRoZSBz YW1lIGFzIHRoZSBvcmlnaW5hbCBSRkM0MDA2Lg0KDQpPdGhlcndpc2UsIHRoZXJlIGFyZSBhIG51 bWJlciBvZiBlZGl0b3JpYWwgY2hhbmdlcyBhbmQgY2hhbmdlcyBkaXNjdXNzZWQgb24gdGhlIG1h aWxpbmcgbGlzdC4NCg0KDQotRGF2ZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDA5LCAyMDE3IDM6MjUgUE0NClRvOiBEYXZl IERvbHNvbjsgWXV2YWwgTGlmc2hpdHo7IFl1dmFsIExpZnNoaXR6OyBkaW1lLWNoYWlyc0BpZXRm Lm9yZzsgTHlsZSBCZXJ0eg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLWRpbWUtcmZjNDAwNmJpcy0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDZiaXMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IERhdmlkIERvbHNvbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDZiaXMNClJldmlzaW9uOgkw Mg0KVGl0bGU6CQlEaWFtZXRlciBDcmVkaXQtQ29udHJvbCBBcHBsaWNhdGlvbg0KRG9jdW1lbnQg ZGF0ZToJMjAxNy0wMy0wOQ0KR3JvdXA6CQlkaW1lDQpQYWdlczoJCTEyMQ0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRpbWUt cmZjNDAwNmJpcy0wMi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRpbWUtcmZjNDAwNmJpcy8NCkh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDZiaXMtMDIN CkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1kaW1lLXJmYzQwMDZiaXMtMDINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyBhIERpYW1ldGVyIGFwcGxpY2F0aW9uIHRoYXQgY2FuIGJlIHVzZWQgdG8NCiAgIGlt cGxlbWVudCByZWFsLXRpbWUgY3JlZGl0LWNvbnRyb2wgZm9yIGEgdmFyaWV0eSBvZiBlbmQgdXNl ciBzZXJ2aWNlcw0KICAgc3VjaCBhcyBuZXR3b3JrIGFjY2VzcywgU2Vzc2lvbiBJbml0aWF0aW9u IFByb3RvY29sIChTSVApIHNlcnZpY2VzLA0KICAgbWVzc2FnaW5nIHNlcnZpY2VzLCBhbmQgZG93 bmxvYWQgc2VydmljZXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Mar 10 09:09:19 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7DB1296A3; Fri, 10 Mar 2017 09:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFKNx92R7nqY; Fri, 10 Mar 2017 09:09:06 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D018129981; Fri, 10 Mar 2017 09:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34578; q=dns/txt; s=iport; t=1489165745; x=1490375345; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ep1jxM6kOmq0/wY/hhqhIHkqgaX1ronBqkNtaZoGq1Y=; b=brnqI1jbaCHYVDmQNOV46S+l6VCUcBFdMVYdRO8px3hzhEifp7Av6GcV ATsl/G09va/02ireWLzVhRDKbwa6+Fd0LUPkwKGVeEt1o1/DC0c65kvom vzou5rv1pRYgUSO+ew2l4pu8FQ48qr85saR3qcSUcL+QMagXVGBicE2QV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQBS3cJY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuOYELKmCNbnOQXYgNixyCD4IOKoV4AoMAGAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAycGTBALEQMBAiEBBgchJQkIBgEMBgIBAYlkAxUOMbMgOiuHDw2DI?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToIFgWGBCYE8gRVGgQQLEQE8DAqFEB8?= =?us-ascii?q?FiRoRhi6BS4RYhgY6jg2EK4F7hSWDMYZTiESCEF+DbIQhHzgVZggiFggXFRiEf?= =?us-ascii?q?A0QgWQ/NQETh1iCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="scan'208,217";a="651355360" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 17:09:02 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2AH91cX005063; Fri, 10 Mar 2017 17:09:02 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <1c695767-703d-bd22-73e0-b66a0ae92941@cisco.com> Date: Fri, 10 Mar 2017 18:09:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------051572ADF26BB37FF97DEB84" Archived-At: Cc: "dime@ietf.org" , "holger+ietf@freyther.de" Subject: Re: [Dime] [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:09:14 -0000 This is a multi-part message in MIME format. --------------051572ADF26BB37FF97DEB84 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Holger, Can you please update the errata with the information below. Regards, Benoit > > This errata report is correct on the inconsistency regarding the > definition of the command header and AVP header and how they are used > in the rest of the document in the ABNF description of commands and > Grouped AVPs. > > For commands, the header is defined as follow: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > whereas " > Same for Grouped AVP. It is defined as follow: > > header = "<" "AVP-Header:" avpcode [vendor] ">" > > whereas " > Considering that most (if not all) the ABNF descriptions have been > copied from the commands and Grouped AVPs defined in the RFC3588 or > RFC6733, I would be in favor to correct the specification by modifying > the definition of the headers, i.e. > > --> In section 3.2. Command Code Format Specification > > OLD: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > NEW: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > --> And in section 4.4 > > OLD: > > header = "<" "AVP-Header:" avpcode [vendor] ">" > > NEW: > > header = "<" "AVP Header:" avpcode [vendor] ">" > > ******************* > > There are other issues pointed out in this report. > > For command-def = "<" command-name ">" "::=" diameter-message, I > would propose to simply correct the example as all the command > definitions given in the document are following the command-def > definition. > > For the grouped-avp-def, I don't know what would be the best approach. > We could follow the same approach and require the addition of "<>" but > I don't know what would be the impacts on existing Grouped AVPs > defined without. > > Regards, > > Lionel. > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Editorial Errata Reported] RFC6733 (4803) > > *Date: * > > > > Tue, 13 Sep 2016 14:42:13 -0700 > > *From: * > > > > RFC Errata System > > > *To: * > > > > vf0213@gmail.com , jari.arkko@ericsson.com > , john.loughney@nokia.com > , glenzorn@gmail.com > , bclaise@cisco.com > , joelja@bogus.com > , jouni.nospam@gmail.com > , lionel.morand@orange.com > > > *CC: * > > > > holger+ietf@freyther.de , > dime@ietf.org , rfc-editor@rfc-editor.org > > > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803 > -------------------------------------- > Type: Editorial > Reported by: Holger Freyther > Section: 3.2 > Original Text > ------------- > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > { User-Name } > 1* { Origin-Host } > * [ AVP ] > Corrected Text > -------------- > ::= < Diameter-Header: 9999999, REQ, PXY > > { User-Name } > 1* { Origin-Host } > * [ AVP ] > Notes > ----- > I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. > header = " [r-bit] [p-bit] [e-bit] [application-id]">" > But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:". > command-def = "<" command-name ">" "::=" diameter-message > but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name. > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > _________________________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------051572ADF26BB37FF97DEB84 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Holger,

Can you please update the errata with the information below.

Regards, Benoit

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

For commands, the header is defined as follow:

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

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

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

Same for Grouped AVP. It is defined as follow:

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

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

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

--> In section 3.2. Command Code Format Specification

OLD:

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

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

NEW:

header = "<Diameter Header:" command-id

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

--> And in section 4.4

OLD:

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

NEW:

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

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

There are other issues pointed out in this report.

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

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

Regards,

Lionel.


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

Subject:

[Editorial Errata Reported] RFC6733 (4803)

Date:

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

From:

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

To:

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

CC:

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

 

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
Section: 3.2
Original Text
-------------
 Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
 { User-Name }
 1* { Origin-Host }
 * [ AVP ]
Corrected Text
--------------
 <Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
 { User-Name }
 1* { Origin-Host }
 * [ AVP ]
Notes
-----
I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. 
 header = "<Diameter-Header:" command-id
 [r-bit] [p-bit] [e-bit] [application-id]">"
But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".
 command-def = "<" command-name ">" "::=" diameter-message
but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title : Diameter Base Protocol
Publication Date : October 2012
Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category : PROPOSED STANDARD
Source : Diameter Maintenance and Extensions
Area : Operations and Management
Stream : IETF
Verifying Party : IESG
.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------051572ADF26BB37FF97DEB84-- From nobody Sat Mar 11 23:47:49 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0DA1294DB; Sat, 11 Mar 2017 23:47:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148930486813.2995.11930249317187128075@ietfa.amsl.com> Date: Sat, 11 Mar 2017 23:47:48 -0800 Archived-At: Cc: draft-ietf-dime-load.all@ietf.org, dime@ietf.org, ietf@ietf.org Subject: [Dime] Review of draft-ietf-dime-load-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 07:47:48 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dime-load-?? Reviewer: Roni Even Review Date: 2017-03-11 IETF LC End Date: 2017-02-27 IESG Telechat date: 2017-03-16 Summary: The document is ready for publication as a standard track RFC Major issues: Minor issues: Nits/editorial comments: From holger@freyther.de Sat Mar 11 02:45:24 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658ED129422; Sat, 11 Mar 2017 02:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, 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 EWec3v9KaGT2; Sat, 11 Mar 2017 02:45:22 -0800 (PST) Received: from gandharva.secretlabs.de (gandharva.secretlabs.de [IPv6:2a01:4f8:161:8201::2:4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEBE1204D9; Sat, 11 Mar 2017 02:45:22 -0800 (PST) Received: from [10.0.1.5] (ip127-36-210-87.adsl2.static.versatel.nl [87.210.36.127]) by gandharva.secretlabs.de (Postfix) with ESMTPSA id 1BF2CAA73F; Sat, 11 Mar 2017 10:45:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Holger Freyther In-Reply-To: <1c695767-703d-bd22-73e0-b66a0ae92941@cisco.com> Date: Sat, 11 Mar 2017 11:45:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6460C3D4-3DAD-4D95-A4D5-8265C9E8C74C@freyther.de> References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1c695767-703d-bd22-73e0-b66a0ae92941@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Sun, 12 Mar 2017 16:55:49 -0700 Cc: "aaa-doctors@ietf.org" , "sec-ads@ietf.org" , "dime@ietf.org" Subject: Re: [Dime] [AAA-DOCTORS] [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 10:46:20 -0000 > On 10 Mar 2017, at 18:09, Benoit Claise wrote: > > Holger, Hi!, > Can you please update the errata with the information below. I am not sure how/where to do it. Can you point me into the right direction? thank you holger From nobody Mon Mar 13 14:18:17 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93708129B98; Mon, 13 Mar 2017 14:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943989559.20337.4822755871711788913@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:18:15 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:18:15 -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 of the IETF. Title : Diameter Group Signaling Authors : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-08.txt Pages : 26 Date : 2017-03-13 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-group-signaling-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-group-signaling-08 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 Mar 14 02:19:41 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97624129531 for ; Tue, 14 Mar 2017 02:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjLwfBMBpXg6 for ; Tue, 14 Mar 2017 02:19:34 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E103312952E for ; Tue, 14 Mar 2017 02:19:33 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id y193so73686839lfd.3 for ; Tue, 14 Mar 2017 02:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PJyl9vXfqJqzEhjGBqcX52NGpZiJ6+yA+YMLjOsG2nI=; b=jzEL65rx06wVklfGfA5D/448d+Gf7atSZ+asT6oMxuz2FGVd+WtR5oeGvogDvWd8Cn ddIjgJpId2/yrr789W8mMFudcz3rQKE3BCwwd4JXetNE364RGTYJZQEiR6LNBw3+Bs0K HWGWQjvUYH2qNhKyXQSKhE7OhC4fcL/DzWLXZz3BgpnF1wiPCScXBe1Zw1pJX4IL3bB3 8DDVvOABolTIgYUJr+UZpF4ixRDamS7JTYYNEPlhi9vYNXMsWrKx7J0a+z82o2j/Qhta AAy7xHn7R9H+tAmOAnh513eLjjrWkXgnK1Gppzb3nimDmqtqAxQ5gdIWaHCiiG1jEpJK Ynbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PJyl9vXfqJqzEhjGBqcX52NGpZiJ6+yA+YMLjOsG2nI=; b=ky+jpq9mRrsUdYyPVK7pJqSIbPbFIVP0wBM2IEHo6geNwzlgPR/uxf8rohDUOEynOm w76i+ejY/K7wXjiE+Vjhtanhio+DxbxpirLy8AkJDPKGYY6n5yeD0fhJho/zX9moOqPp hN6cDHcdY5UkSCxrsugldh0Tjj6vNMKIjs7mI5CxDWN0TLsm3pe+vwQ3vE0dVPPJe0so EoOhkaG18IuKbUJayyaoMVL6/uFtx61F4UUD5GpaySheDFNYndMu3K1ORRoR43GwbL4O FxzAnMC125rUe/wOPu793ORRPQUokM/TzZjXlU9Hg4C+PI86YFXJ0erUtpJvmtAIpYZG ekIg== X-Gm-Message-State: AMke39l7+9+reCD9IDz+S69bJ9TvlTYux+NWTV8Vuy/DEUDaRdVqHGBaFc9wQnvruzrhbq0eBJFFACvet8ki+w== X-Received: by 10.46.92.8 with SMTP id q8mr11583806ljb.52.1489483172132; Tue, 14 Mar 2017 02:19:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.1 with HTTP; Tue, 14 Mar 2017 02:19:31 -0700 (PDT) In-Reply-To: <148943989559.20337.4822755871711788913@ietfa.amsl.com> References: <148943989559.20337.4822755871711788913@ietfa.amsl.com> From: Misha Zaytsev Date: Tue, 14 Mar 2017 12:19:31 +0300 Message-ID: To: dime@ietf.org, marco.liebsch@neclab.eu, mark@azu.ca, "ext lionel.morand@orange.com" Content-Type: multipart/alternative; boundary=94eb2c1b5ec45fc042054aad5340 Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-group-signaling-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 09:19:37 -0000 --94eb2c1b5ec45fc042054aad5340 Content-Type: text/plain; charset=UTF-8 Hi All, Am I right saying that the intention of this draft is to logically group multiple sessions? And there is no aim to physically bundle several session-related requests/answers into one? If so, this approach may decrease processing on communicating nodes (but that will depend on implementation), but will not "reduce signaling" among the involved parties. Please clarify this point? Thanks a lot in advance! /Misha --94eb2c1b5ec45fc042054aad5340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

Am I ri= ght saying that the intention of this draft is to logically group multiple = sessions?
And there is no aim to physically bundle several session= -related requests/answers into one?

If so, this approach may d= ecrease processing on communicating nodes (but that will depend on implemen= tation), but will not "reduce signaling" among the involved parti= es.

Please clarify this point?

Thanks a lot in ad= vance!

/Misha

--94eb2c1b5ec45fc042054aad5340-- From nobody Tue Mar 14 05:16:35 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EBD129582 for ; Tue, 14 Mar 2017 05:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpT3WkcaiUEo for ; Tue, 14 Mar 2017 05:16:32 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65C8126D73 for ; Tue, 14 Mar 2017 05:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E294C10215F; Tue, 14 Mar 2017 13:16:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmAVlQdf05s7; Tue, 14 Mar 2017 13:16:29 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id ACCB1102158; Tue, 14 Mar 2017 13:16:21 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 13:16:21 +0100 From: Marco Liebsch To: Misha Zaytsev , "dime@ietf.org" , "mark@azu.ca" , "ext lionel.morand@orange.com" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-group-signaling-08.txt Thread-Index: AQHSnD9Yu5eDhnY/U0275LFxBv55ZaGT/uqAgABAtIA= Date: Tue, 14 Mar 2017 12:16:20 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DAF0C1649@PALLENE.office.hd> References: <148943989559.20337.4822755871711788913@ietfa.amsl.com> In-Reply-To: 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: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26DAF0C1649PALLENEofficehd_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-group-signaling-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 12:16:34 -0000 --_000_69756203DDDDE64E987BC4F70B71A26DAF0C1649PALLENEofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlzaGEsDQoNCnRoZSBkcmFmdCBzcGVjaWZpZXMgaG93IHRvIGFzc2lnbiBzZXNzaW9ucyB0 byBzZXNzaW9uIGdyb3VwcywgY29ycmVjdC4gSXQgYWxzbyBzcGVjaWZpZXMgaG93IHRvDQphcHBs eSBhIGNvbW1hbmQgKHJlcXVlc3QvcmVzcG9uc2UpIHRvIGEgc2Vzc2lvbiBncm91cC4gSW4gY2Fz ZSB0aGUgZ3JvdXAgaG9sZHMgMTAgc2Vzc2lvbnMsDQpEaWFtZXRlciBwZWVycyBleGNoYW5nZSBv bmx5IGEgc2luZ2xlIGluc3RlYWQgb2YgMTAgY29tbWFuZHMsIGhlbmNlIGNhbiBoZWxwIHRvIHJl ZHVjZQ0Kc2lnbmFsaW5nIGxvYWQgYmV0d2VlbiBEaWFtZXRlciBwZWVycy4NCg0KSSBob3BlIHRo YXQgY2xhcmlmaWVzIHlvdXIgcXVlc3Rpb24uDQoNCm1hcmNvDQoNCkZyb206IE1pc2hhIFpheXRz ZXYgW21haWx0bzptaXNoYS56YXl0c2V2LnJ1c0BnbWFpbC5jb21dDQpTZW50OiBEaWVuc3RhZywg MTQuIE3DpHJ6IDIwMTcgMTA6MjANClRvOiBkaW1lQGlldGYub3JnOyBNYXJjbyBMaWVic2NoOyBt YXJrQGF6dS5jYTsgZXh0IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbQ0KU3ViamVjdDogUmU6IFtE aW1lXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRpbWUtZ3JvdXAtc2lnbmFsaW5nLTA4LnR4dA0K DQpIaSBBbGwsDQpBbSBJIHJpZ2h0IHNheWluZyB0aGF0IHRoZSBpbnRlbnRpb24gb2YgdGhpcyBk cmFmdCBpcyB0byBsb2dpY2FsbHkgZ3JvdXAgbXVsdGlwbGUgc2Vzc2lvbnM/DQpBbmQgdGhlcmUg aXMgbm8gYWltIHRvIHBoeXNpY2FsbHkgYnVuZGxlIHNldmVyYWwgc2Vzc2lvbi1yZWxhdGVkIHJl cXVlc3RzL2Fuc3dlcnMgaW50byBvbmU/DQpJZiBzbywgdGhpcyBhcHByb2FjaCBtYXkgZGVjcmVh c2UgcHJvY2Vzc2luZyBvbiBjb21tdW5pY2F0aW5nIG5vZGVzIChidXQgdGhhdCB3aWxsIGRlcGVu ZCBvbiBpbXBsZW1lbnRhdGlvbiksIGJ1dCB3aWxsIG5vdCAicmVkdWNlIHNpZ25hbGluZyIgYW1v bmcgdGhlIGludm9sdmVkIHBhcnRpZXMuDQpQbGVhc2UgY2xhcmlmeSB0aGlzIHBvaW50Pw0KVGhh bmtzIGEgbG90IGluIGFkdmFuY2UhDQovTWlzaGENCg== --_000_69756203DDDDE64E987BC4F70B71A26DAF0C1649PALLENEofficehd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1pc2hhLDxicj4NCjxicj4NCnRo ZSBkcmFmdCBzcGVjaWZpZXMgaG93IHRvIGFzc2lnbiBzZXNzaW9ucyB0byBzZXNzaW9uIGdyb3Vw cywgY29ycmVjdC4gSXQgYWxzbyBzcGVjaWZpZXMgaG93IHRvPGJyPg0KYXBwbHkgYSBjb21tYW5k IChyZXF1ZXN0L3Jlc3BvbnNlKSB0byBhIHNlc3Npb24gZ3JvdXAuIEluIGNhc2UgdGhlIGdyb3Vw IGhvbGRzIDEwIHNlc3Npb25zLDxicj4NCkRpYW1ldGVyIHBlZXJzIGV4Y2hhbmdlIG9ubHkgYSBz aW5nbGUgaW5zdGVhZCBvZiAxMCBjb21tYW5kcywgaGVuY2UgY2FuIGhlbHAgdG8gcmVkdWNlPGJy Pg0Kc2lnbmFsaW5nIGxvYWQgYmV0d2VlbiBEaWFtZXRlciBwZWVycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBob3BlIHRoYXQgY2xhcmlmaWVzIHlvdXIgcXVlc3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm1hcmNvPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBNaXNoYSBaYXl0c2V2IFttYWlsdG86bWlzaGEuemF5dHNldi5ydXNAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IERpZW5zdGFnLCAxNC4gTcOkcnogMjAxNyAxMDoyMDxi cj4NCjxiPlRvOjwvYj4gZGltZUBpZXRmLm9yZzsgTWFyY28gTGllYnNjaDsgbWFya0BhenUuY2E7 IGV4dCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtE aW1lXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRpbWUtZ3JvdXAtc2lnbmFsaW5nLTA4LnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgQWxs LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSBJIHJpZ2h0 IHNheWluZyB0aGF0IHRoZSBpbnRlbnRpb24gb2YgdGhpcyBkcmFmdCBpcyB0byBsb2dpY2FsbHkg Z3JvdXAgbXVsdGlwbGUgc2Vzc2lvbnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW5kIHRoZXJlIGlzIG5v IGFpbSB0byBwaHlzaWNhbGx5IGJ1bmRsZSBzZXZlcmFsIHNlc3Npb24tcmVsYXRlZCByZXF1ZXN0 cy9hbnN3ZXJzIGludG8gb25lPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHNvLCB0aGlzIGFwcHJvYWNo IG1heSBkZWNyZWFzZSBwcm9jZXNzaW5nIG9uIGNvbW11bmljYXRpbmcgbm9kZXMgKGJ1dCB0aGF0 IHdpbGwgZGVwZW5kIG9uIGltcGxlbWVudGF0aW9uKSwgYnV0IHdpbGwgbm90ICZxdW90O3JlZHVj ZSBzaWduYWxpbmcmcXVvdDsgYW1vbmcgdGhlIGludm9sdmVkIHBhcnRpZXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+UGxlYXNlIGNsYXJpZnkgdGhpcyBwb2ludD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3Mg YSBsb3QgaW4gYWR2YW5jZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4vTWlzaGE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_69756203DDDDE64E987BC4F70B71A26DAF0C1649PALLENEofficehd_-- From nobody Wed Mar 15 06:12:17 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A19E13149D; Wed, 15 Mar 2017 06:12:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-dime-load@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org, liushucheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148958353529.24282.6291713453276344230.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 06:12:15 -0700 Archived-At: Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-load-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:12:15 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dime-load-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - From the shepherd writeup: The document would benefit from a review by AAA Doctors. I wonder if it happened? - OLD: The DIME working group explicitly chose not to fulfill these requirements in DOIC due to several reasons. NEW: The DIME working group explicitly chose not to fulfill these requirements when publishing DOIC [RFC7683] due to several reasons. - pay attention to the consistency of Load versus load trough out the document. From nobody Wed Mar 15 12:54:25 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D439113172C; Wed, 15 Mar 2017 12:54:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dime-agent-overload@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148960765886.14225.10614749426778815326.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 12:54:18 -0700 Archived-At: Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-agent-overload-10=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:54:19 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-agent-overload-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One rather important comment: While the security considerations section describes a possible attack, it does not say anything about how to handle this attack and the actually impact this attack might have. Please add more text! And then some mostly editorial high level comments: All in all, I had a rather hard time reading this document because it seems on the one hand sightly over-specified and over structured, while not giving very concrete guidance in some cases. E.g. in section 5.2.5; "In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that if the reporting node has explicitly signaled the end of the overload condition then abatement associated with the OCS entry MUST be ended in a controlled fashion." I don't think normative language is needed here because there is no impact of interoperation. But then is does't explain what "in a controlled fashion means". So I wouldn't even know how to implement that MUST correctly. Another example in section 4: " In this scenario, when doing abatement on the PEER report, the reacting node SHOULD take into consideration the number of messages already throttled by the handling of the HOST/ REALM report abatement." How to take that into consideration? And why is this normative? Or here in section 5.2.3: "When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine if the report was generated by the Diameter peer from which the report was received. If a reacting node receives an OC-OLR AVP of type peer and the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received then the report was generated by a Diameter peer." Why don't you just say the following: "When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine that the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received." Also the indentation used is sometimes confusing. In some cases you should probably really use real listings with bullet points. From nobody Wed Mar 15 12:57:03 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D791317F5; Wed, 15 Mar 2017 12:57:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dime-agent-overload@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148960782113.14109.16015551690235593288.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 12:57:01 -0700 Archived-At: Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-agent-overload-10=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 19:57:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-agent-overload-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Resending because I forgot one more high-level comment; see at the bottom.) One rather important comment: While the security considerations section describes a possible attack, it does not say anything about how to handle this attack and the actually impact this attack might have. Please add more text! And then some mostly editorial high level comments: All in all, I had a rather hard time reading this document because it seems on the one hand sightly over-specified and over structured, while not giving very concrete guidance in some cases. E.g. in section 5.2.5; "In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that if the reporting node has explicitly signaled the end of the overload condition then abatement associated with the OCS entry MUST be ended in a controlled fashion." I don't think normative language is needed here because there is no impact of interoperation. But then is does't explain what "in a controlled fashion means". So I wouldn't even know how to implement that MUST correctly. Another example in section 4: " In this scenario, when doing abatement on the PEER report, the reacting node SHOULD take into consideration the number of messages already throttled by the handling of the HOST/ REALM report abatement." How to take that into consideration? And why is this normative? Or here in section 5.2.3: "When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine if the report was generated by the Diameter peer from which the report was received. If a reacting node receives an OC-OLR AVP of type peer and the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received then the report was generated by a Diameter peer." Why don't you just say the following: "When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine that the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received." Also the indentation used is sometimes confusing. In some cases you should probably really use real listings with bullet points. Please also double-check all normative language: as indicated above there are some cases where the normative language is probably not really needed and there are other cases where an additional upper letter MUST or SHOULD would make things clearer. From nobody Wed Mar 15 13:27:56 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5B13182C; Wed, 15 Mar 2017 13:27:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dime-load@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148960967368.14169.15606031033957049654.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 13:27:53 -0700 Archived-At: Subject: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dime-load-08=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:27:54 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dime-load-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- More or less editorial comments: 1) These two MUSTs are actually hard to "ensure" and should probably be SHOULDs or lower case musts: sec 6.1.1: "A Diameter endpoint that supports the Diameter Load mechanism MUST include a Load report of type HOST in sufficient answer messages to ensure that all consumers of the load information receive timely updates." sec 6.1.2: "A Diameter Agent that supports the Diameter Load mechanism MUST include a PEER Load report in sufficient answer messages to ensure that all users of the load information receive timely updates." 2) This part also seems hard to realize (in sections 6.1.1. and 6.1.2): "The LOAD value should be calculated in a way that reflects the available load independently of the weight of each server, in order to accurately compare LOAD values from different nodes. Any specific LOAD value needs to identify the same amount of available capacity, regardless the Diameter node that calculates the value. The mechanism used to calculate the LOAD value that fulfills this requirement is an implementation decision." 3) I don't think you can require this for all diameter nodes (as they might not implement this extension): "A Diameter node MUST be prepared to process Load reports of type HOST and of type PEER" Just remove the sentence or at least don't use normative language. Side note: This MUST as well as the ones above are like saying "A node that implements/complies to this spec MUST implement this spec". It not really necessary to say this. From nobody Wed Mar 15 13:35:05 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E5C131825; Wed, 15 Mar 2017 13:35:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-dime-load@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148961010415.14173.6368458424881153781.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 13:35:04 -0700 Archived-At: Subject: [Dime] Kathleen Moriarty's No Objection on draft-ietf-dime-load-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 20:35:04 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dime-load-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Since DIME doesn't have end-to-end security, shouldn't the security considerations section mention that as well? It seems to fit the security considerations and would serve as a reminder of this problem. From nobody Wed Mar 15 22:12:40 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7002120227; Wed, 15 Mar 2017 22:12:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Shucheng LIU To: Cc: draft-ietf-dime-agent-overload.all@ietf.org, dime@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148964114787.14141.11366451118403466758@ietfa.amsl.com> Date: Wed, 15 Mar 2017 22:12:27 -0700 Archived-At: Subject: [Dime] Review of draft-ietf-dime-agent-overload-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 05:12:28 -0000 Reviewer: Shucheng LIU Review result: Has Nits Hi all, (Sorry for being late that I reviewed this draft with a printed one on my flight to home last month, however, I left paper there…) I have reviewed draft-ietf-dime-agent-overload-08 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. “This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent.” My overall view of the document is 'Ready with nits' for publication. ** Technical ** No. ** Editorial ** *Section 2, page 4 > A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 > Diameter Agent. s/ RFC6733/ [RFC6733] Similar changes should also be made in this section to get consistent with section 1 and the last sentence in section 2(therein you were using [RFC6733]). * Section 3.1.1, page 4: > +-+ +-+ +-+ > |c|----|a|----|s| > +-+ +-+ +-+ Though I can easily guess what does “c, a, s” mean here, I still suggest to put full words or at least add a sentence below the figure to explain. The same issue should be fixed in all the figures below in entire section 3. * Section 3.1.2, page 6: > In the case where one of the agents in the above scenario becomes > overloaded s/ scenario becomes/ scenarios become If I understand correctly , here you were referring to two scenarios above? > When the client has an active and a standby connection to the two > agents then an alternative strategy for responding to an overload > report from an agent is to change to standby connection to active and > route all traffic through the new active connection. I would suggest to split this sentence in case of misunderstanding. * Section 3.1.3, page 7: > Handling of overload of one or both of agents a11 or a12 in this case > is equivalent to that discussed in section 2.2. Tried hard to find section 2.2, but there is no such section. * Section 5.1.1, page 8: > When sending a Diameter request a DOIC node that supports the > OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP > an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. Full name of AVP should be put into terminology. From nobody Thu Mar 16 00:31:43 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF3B1204DA; Thu, 16 Mar 2017 00:31:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-dime-agent-overload@ietf.org, Jouni Korhonen , dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org, liushucheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148964950177.14261.3754433156143797957.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 00:31:41 -0700 Archived-At: Subject: [Dime] Benoit Claise's No Objection on draft-ietf-dime-agent-overload-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 07:31:42 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dime-agent-overload-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Below is the OPS DIR review by Will. ** Editorial ** *Section 2, page 4 > A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 > Diameter Agent. s/ RFC6733/ [RFC6733] Similar changes should also be made in this section to get consistent with section 1 and the last sentence in section 2(therein you were using [RFC6733]). * Section 3.1.1, page 4: > +-+ +-+ +-+ > |c|----|a|----|s| > +-+ +-+ +-+ Though I can easily guess what does “c, a, s” mean here, I still suggest to put full words or at least add a sentence below the figure to explain. The same issue should be fixed in all the figures below in entire section 3. * Section 3.1.2, page 6: > In the case where one of the agents in the above scenario becomes > overloaded s/ scenario becomes/ scenarios become If I understand correctly , here you were referring to two scenarios above? > When the client has an active and a standby connection to the two > agents then an alternative strategy for responding to an overload > report from an agent is to change to standby connection to active and > route all traffic through the new active connection. I would suggest to split this sentence in case of misunderstanding. * Section 3.1.3, page 7: > Handling of overload of one or both of agents a11 or a12 in this case > is equivalent to that discussed in section 2.2. Tried hard to find section 2.2, but there is no such section. * Section 5.1.1, page 8: > When sending a Diameter request a DOIC node that supports the > OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP > an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. Full name of AVP should be put into terminology. From nobody Wed Mar 22 13:00:30 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14C129C14 for ; Wed, 22 Mar 2017 13:00:29 -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, 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 0V2Uy9_Xqoq8 for ; Wed, 22 Mar 2017 13:00:27 -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 8598A129BF7 for ; Wed, 22 Mar 2017 13:00:26 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62356 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqmQc-0045mw-QL for dime@ietf.org; Wed, 22 Mar 2017 13:00:26 -0700 To: dime@ietf.org References: <148960765886.14225.10614749426778815326.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <0b7867f6-4842-ce23-6add-890b4fa0a59d@usdonovans.com> Date: Wed, 22 Mar 2017 15:00:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148960765886.14225.10614749426778815326.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dime-agent-overload-10=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 20:00:29 -0000 Mirja, Thank you for your review. Please see my comments inline. Regards, Steve On 3/15/17 2:54 PM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-dime-agent-overload-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > One rather important comment: > While the security considerations section describes a possible attack, it > does not say anything about how to handle this attack and the actually > impact this attack might have. Please add more text! I've added the following: "The impacts of this attack, as well as the mitigation strategies, are the same as outlined in RFC7683. > > And then some mostly editorial high level comments: > All in all, I had a rather hard time reading this document because it > seems on the one hand sightly over-specified and over structured, while > not giving very concrete guidance in some cases. > > E.g. in section 5.2.5; > "In the case that the OCS entry validity duration expires or has a > validity duration of zero ("0"), meaning that if the reporting node > has explicitly signaled the end of the overload condition then > abatement associated with the OCS entry MUST be ended in a > controlled > fashion." > I don't think normative language is needed here because there is no > impact of interoperation. But then is does't explain what "in a > controlled fashion means". So I wouldn't even know how to implement that > MUST correctly. The draft is an extension of RFC7683 and, as such, doesn't always repeat this from that RFC. There is wording in RFC7683 that discusses what a controlled fashion means. > > Another example in section 4: > " In this scenario, when doing abatement on the > PEER report, the reacting node SHOULD take into consideration the > number of messages already throttled by the handling of the HOST/ > REALM report abatement." > How to take that into consideration? And why is this normative? The reacting node is the one doing the abatement on both the HOST/REALM report and the PEER report. As such, it has all of the information it needs to adjust the abatement for the PEER report based on what abatement has already happened based on the HOST/REALM reports. It is normative to ensure similar abatement behavior across all Diameter nodes implementing this mechanism. > > Or here in section 5.2.3: > "When a reacting node receives an OC-OLR AVP with a report type of > peer it MUST determine if the report was generated by the Diameter > peer from which the report was received. > > If a reacting node receives an OC-OLR AVP of type peer and the > SourceID matches the DiameterIdentity of the Diameter peer from > which > the response message was received then the report was generated by a > Diameter peer." > Why don't you just say the following: > "When a reacting node receives an OC-OLR AVP with a report type of > peer it MUST determine that the SourceID matches the DiameterIdentity > of the Diameter peer from which > the response message was received." That would have been another way of specifying the requirement. I'm more comfortable with sticking with what has already been agreed to by the working group. > > Also the indentation used is sometimes confusing. In some cases you > should probably really use real listings with bullet points. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Mar 22 13:14:02 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF321129BF7 for ; Wed, 22 Mar 2017 13:14:00 -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, 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 158c6qul_RdR for ; Wed, 22 Mar 2017 13:13:59 -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 9BFB7129AA2 for ; Wed, 22 Mar 2017 13:13:59 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62482 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqmdh-004Hd8-Sl for dime@ietf.org; Wed, 22 Mar 2017 13:13:59 -0700 To: dime@ietf.org References: <148964114787.14141.11366451118403466758@ietfa.amsl.com> From: Steve Donovan Message-ID: <2520ac8e-04c6-0d99-e120-8e741d05d193@usdonovans.com> Date: Wed, 22 Mar 2017 15:13:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148964114787.14141.11366451118403466758@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Review of draft-ietf-dime-agent-overload-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 20:14:01 -0000 Shucheng, Thank you for your review. See my comments inline. Regards, Steve On 3/16/17 12:12 AM, Shucheng LIU wrote: > Reviewer: Shucheng LIU > Review result: Has Nits > > Hi all, > > (Sorry for being late that I reviewed this draft with a printed one on > my flight to home last month, however, I left paper there…) > I have reviewed draft-ietf-dime-agent-overload-08 as part of the > Operational directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written with the > intent of improving the operational aspects of the IETF drafts. > Comments that are not addressed in last call may be included in AD > reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. > > “This specification documents an extension to RFC 7683 (Diameter > Overload Indication Conveyance (DOIC)) base solution. The > extension > defines the Peer overload report type. The initial use case for > the > Peer report is the handling of occurrences of overload of a > Diameter > agent.” > > My overall view of the document is 'Ready with nits' for publication. > > > ** Technical ** > No. > > > ** Editorial ** > > *Section 2, page 4 >> A RFC6733 Diameter Client, an RFC6733 Diameter Server, and > RFC6733 >> Diameter Agent. > s/ RFC6733/ [RFC6733] > Similar changes should also be made in this section to get consistent > with section 1 and the last sentence in section 2(therein you were > using [RFC6733]). Change made. > > > * Section 3.1.1, page 4: > >> +-+ +-+ +-+ >> |c|----|a|----|s| >> +-+ +-+ +-+ > Though I can easily guess what does “c, a, s” mean here, I still > suggest to put full words or at least add a sentence below the figure > to explain. > The same issue should be fixed in all the figures below in entire > section 3. I've added the following in section 3. In the figures in this section, elements labeled "c" are Diameter Clients, elements labeled "a" are Diameter Agents and elements labeled "s" are Diameter Servers. > > > * Section 3.1.2, page 6: > >> In the case where one of the agents in the above scenario becomes >> overloaded > s/ scenario becomes/ scenarios become > > If I understand correctly , here you were referring to two scenarios > above? Change made. > >> When the client has an active and a standby connection to the two >> agents then an alternative strategy for responding to an overload >> report from an agent is to change to standby connection to active > and >> route all traffic through the new active connection. > I would suggest to split this sentence in case of misunderstanding. Changed to: When the client has an active and a standby connection to the two agents then an alternative strategy for responding to an overload report from an agent is to change the standby connection to active. This will result in all traffic being routed through the new active connection. > > * Section 3.1.3, page 7: > >> Handling of overload of one or both of agents a11 or a12 in this > case >> is equivalent to that discussed in section 2.2. > Tried hard to find section 2.2, but there is no such section. This was fixed in the last version of the draft. > > > * Section 5.1.1, page 8: > >> When sending a Diameter request a DOIC node that supports the >> OC_PEER_REPORT feature MUST include in the OC-Supported-Features > AVP >> an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. > Full name of AVP should be put into terminology. Change made. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Mar 22 13:31:52 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEE6128D44; Wed, 22 Mar 2017 13:31:51 -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.48.00 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149021471147.7645.15511065690337354878@ietfa.amsl.com> Date: Wed, 22 Mar 2017 13:31:51 -0700 Archived-At: Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:31:51 -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 of the IETF. Title : Diameter Agent Overload and the Peer Overload Report Author : Steve Donovan Filename : draft-ietf-dime-agent-overload-11.txt Pages : 18 Date : 2017-03-22 Abstract: This specification documents an extension to RFC 7683 (Diameter Overload Indication Conveyance (DOIC)) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ There's also a htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dime-agent-overload-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-11 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 22 13:40:37 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D3C128BB7 for ; Wed, 22 Mar 2017 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 2MBw462tMfDa for ; Wed, 22 Mar 2017 13:40:33 -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 D273612894A for ; Wed, 22 Mar 2017 13:40:32 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62743 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqn3N-000FjI-R1 for dime@ietf.org; Wed, 22 Mar 2017 13:40:32 -0700 References: <148958353529.24282.6291713453276344230.idtracker@ietfa.amsl.com> Cc: dime@ietf.org From: Steve Donovan Message-ID: <662e33fb-053d-ee05-3ad9-c3e4634daec5@usdonovans.com> Date: Wed, 22 Mar 2017 15:40:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148958353529.24282.6291713453276344230.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Benoit Claise's No Objection on draft-ietf-dime-load-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 20:40:35 -0000 Benoit, Thank you for the review. Please see my comments inline. Regards, Steve On 3/15/17 8:12 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-dime-load-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-load/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - From the shepherd writeup: > The document would benefit from a review by AAA Doctors. > > I wonder if it happened? > > - > OLD: > > The DIME working group explicitly chose not to fulfill these > requirements in DOIC due to several reasons. > > NEW: > > The DIME working group explicitly chose not to fulfill these > requirements when publishing DOIC [RFC7683] due to several reasons. Change made. > - pay attention to the consistency of Load versus load trough out the > document. Changes made. > > From nobody Wed Mar 22 13:51:46 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5655128E19 for ; Wed, 22 Mar 2017 13:51:44 -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, 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 NCPWN2cq7mbB for ; Wed, 22 Mar 2017 13:51:43 -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 A4E8D128BBB for ; Wed, 22 Mar 2017 13:51:43 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:62966 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqnEE-000O4G-QY for dime@ietf.org; Wed, 22 Mar 2017 13:51:43 -0700 To: dime@ietf.org References: <148960967368.14169.15606031033957049654.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: Date: Wed, 22 Mar 2017 15:51:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148960967368.14169.15606031033957049654.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dime-load-08=3A_=28with_COMMENT=29?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 20:51:45 -0000 Mirja, Thank you for your review. Please see my comments inline. Regars, Steve On 3/15/17 3:27 PM, Mirja Kühlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-dime-load-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-load/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > More or less editorial comments: > > 1) These two MUSTs are actually hard to "ensure" and should probably be > SHOULDs or lower case musts: > sec 6.1.1: "A Diameter endpoint that supports the Diameter Load mechanism > MUST > include a Load report of type HOST in sufficient answer messages to > ensure that all consumers of the load information receive timely > updates." > sec 6.1.2: "A Diameter Agent that supports the Diameter Load mechanism > MUST > include a PEER Load report in sufficient answer messages to ensure > that all users of the load information receive timely updates." Given were we are in the review process, I'm not comfortable changing these from MUST to SHOULD. As such, I'd prefer to go ahead with MUSTs. > > 2) This part also seems hard to realize (in sections 6.1.1. and 6.1.2): > "The LOAD value should be calculated in a way that reflects the > available load independently of the weight of each server, in order > to accurately compare LOAD values from different nodes. Any > specific > LOAD value needs to identify the same amount of available capacity, > regardless the Diameter node that calculates the value. > > The mechanism used to calculate the LOAD value that fulfills this > requirement is an implementation decision." I don't understand the proposal. This is not normative so I don't see an issue. > > 3) I don't think you can require this for all diameter nodes (as they > might not implement this extension): > "A Diameter node MUST be prepared to process Load reports of type HOST > and of type PEER" > Just remove the sentence or at least don't use normative language. > Side note: This MUST as well as the ones above are like saying "A node > that implements/complies to this spec MUST implement this spec". It not > really necessary to say this. This requirement is included to address discussions that occurred within the working group. Many assumed that there would only ever be a single report in any message. I've added "...that supports the Diameter Load mechanism..." > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Mar 22 13:57:31 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03634128BBB for ; Wed, 22 Mar 2017 13:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vieb0Igqpq-Y for ; Wed, 22 Mar 2017 13:57:28 -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 CE88312778D for ; Wed, 22 Mar 2017 13:57:28 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:63016 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqnJk-000Rvt-W7 for dime@ietf.org; Wed, 22 Mar 2017 13:57:28 -0700 To: dime@ietf.org References: <148961010415.14173.6368458424881153781.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <1c20090a-a7a3-e19f-9e77-bb1b3e31c9b3@usdonovans.com> Date: Wed, 22 Mar 2017 15:57:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148961010415.14173.6368458424881153781.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------F4BD02D947CD1092535F1E6F" X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Kathleen Moriarty's No Objection on draft-ietf-dime-load-08: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 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, 22 Mar 2017 20:57:30 -0000 This is a multi-part message in MIME format. --------------F4BD02D947CD1092535F1E6F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Kathleen, Thanks for your review of the draft. Please see my comments below. Regards, Steve On 3/15/17 3:35 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-dime-load-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-load/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Since DIME doesn't have end-to-end security, shouldn't the security > considerations section mention that as well? It seems to fit the > security considerations and would serve as a reminder of this problem. This was, maybe insufficiently addressed with the last sentence in the section: Since Diameter currently only offers authentication of nodes at the transport level, any solution that sends load information to non-peer nodes requires a transitive-trust model. I've modified it as follows: Since Diameter currently only offers authentication of nodes at the transport level and does not support end-to-end security mechanisms, any solution that sends load information to non-peer nodes requires a transitive-trust model. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------F4BD02D947CD1092535F1E6F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Kathleen,

Thanks for your review of the draft. Please see my comments below.

Regards,

Steve

On 3/15/17 3:35 PM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-dime-load-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-load/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Since DIME doesn't have end-to-end security, shouldn't the security
considerations section mention that as well?  It seems to fit the
security considerations and would serve as a reminder of this problem.
This was, maybe insufficiently addressed with the last sentence in the section:

Since Diameter currently only offers
   authentication of nodes at the transport level, any solution that
   sends load information to non-peer nodes requires a transitive-trust
   model.

I've modified it as follows:

Since Diameter currently only offers
   authentication of nodes at the transport level and does not support end-to-end
   security mechanisms, any solution that
   sends load information to non-peer nodes requires a transitive-trust
   model.






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






--------------F4BD02D947CD1092535F1E6F--


From nobody Wed Mar 22 13:59:01 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125F12778D for ; Wed, 22 Mar 2017 13:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 xPPQ15sREyBB for ; Wed, 22 Mar 2017 13:58:57 -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 EB940120326 for ; Wed, 22 Mar 2017 13:58:56 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:63047 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqnLD-000SvR-Aw for dime@ietf.org; Wed, 22 Mar 2017 13:58:56 -0700
To: dime@ietf.org
References: <149021471147.7645.15511065690337354878@ietfa.amsl.com>
From: Steve Donovan 
Message-ID: 
Date: Wed, 22 Mar 2017 15:58:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149021471147.7645.15511065690337354878@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="------------6F4266EA245B06C373A93F8F"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] I-D Action: draft-ietf-dime-agent-overload-11.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Mar 2017 20:59:00 -0000

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

All,

I've attached the diff file for this revision of the draft.  The updates 
resulted from IESG ballot comments.

Regards,

Steve

On 3/22/17 3:31 PM, internet-drafts@ietf.org wrote:
> 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 of the IETF.
>
>          Title           : Diameter Agent Overload and the Peer Overload Report
>          Author          : Steve Donovan
> 	Filename        : draft-ietf-dime-agent-overload-11.txt
> 	Pages           : 18
> 	Date            : 2017-03-22
>
> Abstract:
>     This specification documents an extension to RFC 7683 (Diameter
>     Overload Indication Conveyance (DOIC)) base solution.  The extension
>     defines the Peer overload report type.  The initial use case for the
>     Peer report is the handling of occurrences of overload of a Diameter
>     agent.
>
> Requirements
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/
>
> There's also a htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dime-agent-overload-11
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-11
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the diff is 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


--------------6F4266EA245B06C373A93F8F
Content-Type: text/html; charset=UTF-8;
 name="Diff_ draft-ietf-dime-agent-overload-10.txt -
 draft-ietf-dime-agent-overload-11.html"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-agent-overload-10.txt - draft-ietf-dim";
 filename*1="e-agent-overload-11.html"








 
   
   
  Diff: draft-ietf-dime-agent-overload-10.txt - draft-ietf-dime-agent-overload-11.txt 
   
      
 
 
  
 
  
< draft-ietf-dime-agent-overload-10.txt   draft-ietf-dime-agent-overload-11.txt >
 
      
 

      
Diameter Maintenance and Extensions (DIME)                    S. Donovan Diameter Maintenance and Extensions (DIME)                    S. Donovan

      
Internet-Draft                                                    Oracle Internet-Draft                                                    Oracle

      

      
Updates: RFC7683 (if approved)                             March 7, 2017 Updates: RFC7683 (if approved)                            March 22, 2017

      
Intended status: Standards Track Intended status: Standards Track

      

      
Expires: September 8, 2017 Expires: September 23, 2017

      
 

      
          Diameter Agent Overload and the Peer Overload Report           Diameter Agent Overload and the Peer Overload Report

      

      
                 draft-ietf-dime-agent-overload-10.txt                  draft-ietf-dime-agent-overload-11.txt

      
 

      
Abstract Abstract

      
 

      
   This specification documents an extension to RFC 7683 (Diameter    This specification documents an extension to RFC 7683 (Diameter

      
   Overload Indication Conveyance (DOIC)) base solution.  The extension    Overload Indication Conveyance (DOIC)) base solution.  The extension

      
   defines the Peer overload report type.  The initial use case for the    defines the Peer overload report type.  The initial use case for the

      
   Peer report is the handling of occurrences of overload of a Diameter    Peer report is the handling of occurrences of overload of a Diameter

      
   agent.    agent.

      
 

      
Requirements Requirements

      
 

      
skipping to change at page 1, line 41 skipping to change at page 1, line 41

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on September 8, 2017.    This Internet-Draft will expire on September 23, 2017.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2017 IETF Trust and the persons identified as the    Copyright (c) 2017 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
 

      
skipping to change at page 2, line 18 skipping to change at page 2, line 18

      
   include Simplified BSD License text as described in Section 4.e of    include Simplified BSD License text as described in Section 4.e of

      
   the Trust Legal Provisions and are provided without warranty as    the Trust Legal Provisions and are provided without warranty as

      
   described in the Simplified BSD License.    described in the Simplified BSD License.

      
 

      
Table of Contents Table of Contents

      
 

      
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

      
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   3    2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   3

      
   3.  Peer Report Use Cases . . . . . . . . . . . . . . . . . . . .   4    3.  Peer Report Use Cases . . . . . . . . . . . . . . . . . . . .   4

      
     3.1.  Diameter Agent Overload Use Cases . . . . . . . . . . . .   4      3.1.  Diameter Agent Overload Use Cases . . . . . . . . . . . .   4

      

      
       3.1.1.  Single Agent  . . . . . . . . . . . . . . . . . . . .   4        3.1.1.  Single Agent  . . . . . . . . . . . . . . . . . . . .   5

      
       3.1.2.  Redundant Agents  . . . . . . . . . . . . . . . . . .   5        3.1.2.  Redundant Agents  . . . . . . . . . . . . . . . . . .   6

      
       3.1.3.  Agent Chains  . . . . . . . . . . . . . . . . . . . .   7        3.1.3.  Agent Chains  . . . . . . . . . . . . . . . . . . . .   7

      

      
     3.2.  Diameter Endpoint Use Cases . . . . . . . . . . . . . . .   7      3.2.  Diameter Endpoint Use Cases . . . . . . . . . . . . . . .   8

      
       3.2.1.  Hop-by-hop Abatement Algorithms . . . . . . . . . . .   8        3.2.1.  Hop-by-hop Abatement Algorithms . . . . . . . . . . .   8

      
   4.  Interaction Between Host/Realm and Peer Overload Reports  . .   8    4.  Interaction Between Host/Realm and Peer Overload Reports  . .   8

      
   5.  Peer Report Behavior  . . . . . . . . . . . . . . . . . . . .   8    5.  Peer Report Behavior  . . . . . . . . . . . . . . . . . . . .   8

      

      
     5.1.  Capability Announcement . . . . . . . . . . . . . . . . .   8      5.1.  Capability Announcement . . . . . . . . . . . . . . . . .   9

      
       5.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .   8        5.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .   9

      
       5.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .   9        5.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .   9

      
     5.2.  Peer Overload Report Handling . . . . . . . . . . . . . .  10      5.2.  Peer Overload Report Handling . . . . . . . . . . . . . .  10

      
       5.2.1.  Overload Control State  . . . . . . . . . . . . . . .  10        5.2.1.  Overload Control State  . . . . . . . . . . . . . . .  10

      
       5.2.2.  Reporting Node Maintenance of Peer Report OCS . . . .  11        5.2.2.  Reporting Node Maintenance of Peer Report OCS . . . .  11

      
       5.2.3.  Reacting Node Maintenance of Peer Report OCS  . . . .  11        5.2.3.  Reacting Node Maintenance of Peer Report OCS  . . . .  11

      
       5.2.4.  Peer-Report Reporting Node Behavior . . . . . . . . .  12        5.2.4.  Peer-Report Reporting Node Behavior . . . . . . . . .  12

      

      
       5.2.5.  Peer-Report Reacting Node Behavior  . . . . . . . . .  12        5.2.5.  Peer-Report Reacting Node Behavior  . . . . . . . . .  13

      
   6.  Peer Report AVPs  . . . . . . . . . . . . . . . . . . . . . .  13    6.  Peer Report AVPs  . . . . . . . . . . . . . . . . . . . . . .  14

      
     6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  13      6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  14

      
       6.1.1.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . .  14        6.1.1.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . .  14

      
       6.1.2.  OC-Peer-Algo AVP  . . . . . . . . . . . . . . . . . .  14        6.1.2.  OC-Peer-Algo AVP  . . . . . . . . . . . . . . . . . .  14

      

      
     6.2.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  14      6.2.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  15

      
       6.2.1.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . .  15        6.2.1.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . .  15

      
     6.3.  SourceID AVP  . . . . . . . . . . . . . . . . . . . . . .  15      6.3.  SourceID AVP  . . . . . . . . . . . . . . . . . . . . . .  15

      

      
     6.4.  Attribute Value Pair Flag Rules . . . . . . . . . . . . .  15      6.4.  Attribute Value Pair Flag Rules . . . . . . . . . . . . .  16

      
   7.  IANA  Considerations  . . . . . . . . . . . . . . . . . . . .  16    7.  IANA  Considerations  . . . . . . . . . . . . . . . . . . . .  16

      
     7.1.  AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .  16      7.1.  AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .  16

      
     7.2.  New Registries  . . . . . . . . . . . . . . . . . . . . .  16      7.2.  New Registries  . . . . . . . . . . . . . . . . . . . . .  16

      
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16    8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16

      
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17    9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17

      
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17

      
     10.1.  Informative References . . . . . . . . . . . . . . . . .  17      10.1.  Informative References . . . . . . . . . . . . . . . . .  17

      
     10.2.  Normative References . . . . . . . . . . . . . . . . . .  17      10.2.  Normative References . . . . . . . . . . . . . . . . . .  17

      

      
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

      
 

      
1.  Introduction 1.  Introduction

      
 

      
   This specification documents an extension to the Diameter Overload    This specification documents an extension to the Diameter Overload

      
   Indication Conveyance (DOIC) [RFC7683] base solution.  The extension    Indication Conveyance (DOIC) [RFC7683] base solution.  The extension

      
   defines the Peer overload report type.  The initial use case for the    defines the Peer overload report type.  The initial use case for the

      
   Peer report is the handling of occurrences of overload of a Diameter    Peer report is the handling of occurrences of overload of a Diameter

      
   agent.    agent.

      
 

      
   This document defines the behavior of Diameter nodes when Diameter    This document defines the behavior of Diameter nodes when Diameter

      
 

      
skipping to change at page 3, line 50 skipping to change at page 3, line 50

      
   the Diameter Overload Requirements [RFC7068].    the Diameter Overload Requirements [RFC7068].

      
 

      
   This document defines a new overload report type to communicate    This document defines a new overload report type to communicate

      
   occurrences of agent overload.  This report type works for the "Loss"    occurrences of agent overload.  This report type works for the "Loss"

      
   overload mitigation algorithm defined in [RFC7683] and is expected to    overload mitigation algorithm defined in [RFC7683] and is expected to

      
   work for other overload abatement algorithms defined in extensions to    work for other overload abatement algorithms defined in extensions to

      
   the DOIC solution.    the DOIC solution.

      
 

      
2.  Terminology and Abbreviations 2.  Terminology and Abbreviations

      
 

      

      
    AVP

      
 

      
       Attribute Value Pair

      
                                                                          

      
   Diameter Node    Diameter Node

      

      
      A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733                                                                          

      
      Diameter Agent.       A [RFC7683] Diameter Client, an [RFC7683] Diameter Server, and

      
       [RFC7683] Diameter Agent.

      
 

      
   Diameter Endpoint    Diameter Endpoint

      
 

      

      
      An RFC6733 Diameter Client and RFC6733 Diameter Server.       An [RFC7683] Diameter Client and [RFC7683] Diameter Server.

      
 

      
   Diameter Agent    Diameter Agent

      
 

      

      
      An RFC6733 Diameter Agent.       An [RFC7683] Diameter Agent.

      
 

      
   Reporting Node    Reporting Node

      
 

      
      A DOIC Node that sends an overload report in a Diameter answer       A DOIC Node that sends an overload report in a Diameter answer

      
      message.       message.

      
 

      
   Reacting Node    Reacting Node

      
 

      
      A DOIC Node that receives and acts on a DOIC overload report.       A DOIC Node that receives and acts on a DOIC overload report.

      
 

      
 

      
skipping to change at page 4, line 43 skipping to change at page 4, line 46

      
 

      
   There are two primary classes of use cases currently identified,    There are two primary classes of use cases currently identified,

      
   those involving the overload of agents and those involving overload    those involving the overload of agents and those involving overload

      
   of Diameter endpoints.  In both cases the goal is to use an overload    of Diameter endpoints.  In both cases the goal is to use an overload

      
   algorithm that controls traffic sent towards peers.    algorithm that controls traffic sent towards peers.

      
 

      
3.1.  Diameter Agent Overload Use Cases 3.1.  Diameter Agent Overload Use Cases

      
 

      
   The peer report needs to support the following use cases.    The peer report needs to support the following use cases.

      
 

      

      
    In the figures in this section, elements labeled "c" are Diameter

      
    Clients, elements labeled "a" are Diameter Agents and elements

      
    labeled "s" are Diameter Servers.

      
                                                                          

      
3.1.1.  Single Agent 3.1.1.  Single Agent

      
 

      
   This use case is illustrated in Figure 1.  In this case, the client    This use case is illustrated in Figure 1.  In this case, the client

      
   sends all traffic through the single agent.  If there is a failure in    sends all traffic through the single agent.  If there is a failure in

      
   the agent then the client is unable to send Diameter traffic toward    the agent then the client is unable to send Diameter traffic toward

      
   the server.    the server.

      
 

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

      
                              |c|----|a|----|s|                               |c|----|a|----|s|

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

      
 

      
skipping to change at page 6, line 32 skipping to change at page 6, line 42

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

      
                                   --|a1|---|s|                                    --|a1|---|s|

      
                              +-+ /  +--+\ /+-+                               +-+ /  +--+\ /+-+

      
                              |c|-        x                               |c|-        x

      
                              +-+ \  +--+/ \+-+                               +-+ \  +--+/ \+-+

      
                                   --|a2|---|s|                                    --|a2|---|s|

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

      
 

      
                                 Figure 4                                  Figure 4

      
 

      

      
   In the case where one of the agents in the above scenario becomes    In the case where one of the agents in the above scenarios become

      
   overloaded, the client should reduce the amount of traffic sent to    overloaded, the client should reduce the amount of traffic sent to

      
   the overloaded agent by the amount requested.  This traffic should    the overloaded agent by the amount requested.  This traffic should

      
   instead be routed through the non-overloaded agent.  For example,    instead be routed through the non-overloaded agent.  For example,

      
   assume that the overloaded agent requests a reduction of 10 percent.    assume that the overloaded agent requests a reduction of 10 percent.

      
   The client should send 10 percent of the traffic that would have been    The client should send 10 percent of the traffic that would have been

      
   routed to the overloaded agent through the non-overloaded agent.    routed to the overloaded agent through the non-overloaded agent.

      
 

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

      
   agents then an alternative strategy for responding to an overload    agents then an alternative strategy for responding to an overload

      

      
   report from an agent is to change the standby connection to active    report from an agent is to change the standby connection to active.

      
   and route all traffic through the new active connection.    This will result in all traffic being routed through the new active

      
    connection.

      
 

      
   In the case where both agents are reporting overload, the client may    In the case where both agents are reporting overload, the client may

      
   need to start decreasing the total traffic sent to the agents.  This    need to start decreasing the total traffic sent to the agents.  This

      
   would be done in a similar fashion as discussed in Section 3.1.1 The    would be done in a similar fashion as discussed in Section 3.1.1 The

      
   amount of traffic depends on the combined reduction requested by the    amount of traffic depends on the combined reduction requested by the

      
   two agents.    two agents.

      
 

      
3.1.3.  Agent Chains 3.1.3.  Agent Chains

      
 

      
   There are also deployment scenarios where there can be multiple    There are also deployment scenarios where there can be multiple

      
 

      
skipping to change at page 17, line 5 skipping to change at page 17, line 16

      
   report could have a bigger impact on a Diameter network as agents can    report could have a bigger impact on a Diameter network as agents can

      
   be concentration points in a Diameter network.  Where an end-point    be concentration points in a Diameter network.  Where an end-point

      
   report would impact the traffic sent to a single Diameter server, for    report would impact the traffic sent to a single Diameter server, for

      
   example, a peer report could throttle all traffic to the Diameter    example, a peer report could throttle all traffic to the Diameter

      
   network.    network.

      
 

      
   This impact is amplified in an agent that sits at the edge of a    This impact is amplified in an agent that sits at the edge of a

      
   Diameter network that serves as the entry point from all other    Diameter network that serves as the entry point from all other

      
   Diameter networks.    Diameter networks.

      
 

      

      
    The impacts of this attack, as well as the mitigation strategies, are

      
    the same as outlined in [RFC7683].

      
                                                                          

      
9.  Acknowledgements 9.  Acknowledgements

      
 

      
   Adam Roach and Eric McMurry for the work done in defining a    Adam Roach and Eric McMurry for the work done in defining a

      
   comprehensive Diameter overload solution in draft-roach-dime-    comprehensive Diameter overload solution in draft-roach-dime-

      
   overload-ctrl-03.txt.    overload-ctrl-03.txt.

      
 

      
   Ben Campbell for his insights and review of early versions of this    Ben Campbell for his insights and review of early versions of this

      
   document.    document.

      
 

      
10.  References 10.  References


     
 

     
 End of changes. 19 change blocks. 

     
22 lines changed or deleted 35 lines changed or added

     

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   

--------------6F4266EA245B06C373A93F8F--


From nobody Wed Mar 22 14:16:32 2017
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9881C128C83; Wed, 22 Mar 2017 14:16:24 -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.48.00
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149021738457.7572.3300869140176156396@ietfa.amsl.com>
Date: Wed, 22 Mar 2017 14:16:24 -0700
Archived-At: 
Subject: [Dime] I-D Action: draft-ietf-dime-load-09.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Mar 2017 21:16:25 -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 of the IETF.

        Title           : Diameter Load Information Conveyance
        Authors         : Ben Campbell
                          Steve Donovan
                          Jean-Jacques Trottin
	Filename        : draft-ietf-dime-load-09.txt
	Pages           : 22
	Date            : 2017-03-22

Abstract:
   RFC7068 describes requirements for Overload Control in Diameter.
   This includes a requirement to allow Diameter nodes to send "load"
   information, even when the node is not overloaded.  RFC7683 (Diameter
   Overload Information Conveyance (DOIC)) solution describes a
   mechanism meeting most of the requirements, but does not currently
   include the ability to send load information.  This document defines
   a mechanism for conveying of Diameter load information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-load/

There's also a htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dime-load-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-09


Please note that it may take a couple of minutes from the time of submission
until the diff is available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Mar 22 14:24:53 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B85128B88 for ; Wed, 22 Mar 2017 14:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 YKXKy5bRaahE for ; Wed, 22 Mar 2017 14:24:48 -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 D3679127097 for ; Wed, 22 Mar 2017 14:24:48 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:63455 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqnkE-000lmy-0Z for dime@ietf.org; Wed, 22 Mar 2017 14:24:48 -0700
To: dime@ietf.org
References: <149021738457.7572.3300869140176156396@ietfa.amsl.com>
From: Steve Donovan 
Message-ID: 
Date: Wed, 22 Mar 2017 16:24:37 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149021738457.7572.3300869140176156396@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="------------71A74E225ED9027EAB318CF7"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] I-D Action: draft-ietf-dime-load-09.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Mar 2017 21:24:52 -0000

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

All,

I've attached the diff file for this version of the draft.  The updates 
were based on comments received during IESG ballot.

Regards,

Steve

On 3/22/17 4:16 PM, internet-drafts@ietf.org wrote:
> 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 of the IETF.
>
>          Title           : Diameter Load Information Conveyance
>          Authors         : Ben Campbell
>                            Steve Donovan
>                            Jean-Jacques Trottin
> 	Filename        : draft-ietf-dime-load-09.txt
> 	Pages           : 22
> 	Date            : 2017-03-22
>
> Abstract:
>     RFC7068 describes requirements for Overload Control in Diameter.
>     This includes a requirement to allow Diameter nodes to send "load"
>     information, even when the node is not overloaded.  RFC7683 (Diameter
>     Overload Information Conveyance (DOIC)) solution describes a
>     mechanism meeting most of the requirements, but does not currently
>     include the ability to send load information.  This document defines
>     a mechanism for conveying of Diameter load information.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-load/
>
> There's also a htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dime-load-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-09
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the diff is 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


--------------71A74E225ED9027EAB318CF7
Content-Type: text/html; charset=UTF-8;
 name="Diff_ draft-ietf-dime-load-08.txt - draft-ietf-dime-load-09.html"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-load-08.txt - draft-ietf-dime-load-09.";
 filename*1="html"








 
   
   
  Diff: draft-ietf-dime-load-08.txt - draft-ietf-dime-load-09.txt 
   
      
 
 
  
 
  
< draft-ietf-dime-load-08.txt   draft-ietf-dime-load-09.txt >
 
      
 

      
Internet Engineering Task Force                              B. Campbell Internet Engineering Task Force                              B. Campbell

      
Internet-Draft                                           S. Donovan, Ed. Internet-Draft                                           S. Donovan, Ed.

      
Intended status: Standards Track                                  Oracle Intended status: Standards Track                                  Oracle

      

      
Expires: September 8, 2017                                   JJ. Trottin Expires: September 23, 2017                                  JJ. Trottin

      
                                                                   Nokia                                                                    Nokia

      

      
                                                           March 7, 2017                                                           March 22, 2017

      
 

      
                  Diameter Load Information Conveyance                   Diameter Load Information Conveyance

      

      
                        draft-ietf-dime-load-08                         draft-ietf-dime-load-09

      
 

      
Abstract Abstract

      
 

      
   RFC7068 describes requirements for Overload Control in Diameter.    RFC7068 describes requirements for Overload Control in Diameter.

      
   This includes a requirement to allow Diameter nodes to send "load"    This includes a requirement to allow Diameter nodes to send "load"

      
   information, even when the node is not overloaded.  RFC7683 (Diameter    information, even when the node is not overloaded.  RFC7683 (Diameter

      
   Overload Information Conveyance (DOIC)) solution describes a    Overload Information Conveyance (DOIC)) solution describes a

      
   mechanism meeting most of the requirements, but does not currently    mechanism meeting most of the requirements, but does not currently

      
   include the ability to send load information.  This document defines    include the ability to send load information.  This document defines

      
   a mechanism for conveying of Diameter load information.    a mechanism for conveying of Diameter load information.

      
 

      
skipping to change at page 1, line 38 skipping to change at page 1, line 38

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on September 8, 2017.    This Internet-Draft will expire on September 23, 2017.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2017 IETF Trust and the persons identified as the    Copyright (c) 2017 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
 

      
skipping to change at page 3, line 29 skipping to change at page 3, line 29

      
 

      
      REQ 24: The solution MUST provide a mechanism for indicating load       REQ 24: The solution MUST provide a mechanism for indicating load

      
      levels, even when not in an overload condition, to assist nodes in       levels, even when not in an overload condition, to assist nodes in

      
      making decisions to prevent overload conditions from occurring.       making decisions to prevent overload conditions from occurring.

      
 

      
   There are several other requirements in [RFC7068] that mention both    There are several other requirements in [RFC7068] that mention both

      
   overload and load information that are only partially fulfilled by    overload and load information that are only partially fulfilled by

      
   DOIC.    DOIC.

      
 

      
   The DIME working group explicitly chose not to fulfill these    The DIME working group explicitly chose not to fulfill these

      

      
   requirements in DOIC due to several reasons.  A principal reason was    requirements when publishing DOIC [RFC7683] due to several reasons.

      
   that the working group did not agree on a general approach for    A principal reason was that the working group did not agree on a

      
   conveying load information.  It chose to progress the rest of DOIC,    general approach for conveying load information.  It chose to

      
   and deferred load information conveyance to a DOIC extension or a    progress the rest of DOIC, and deferred load information conveyance

      
   separate mechanism.    to a DOIC extension or a separate mechanism.

      
 

      
   This document defines a mechanism that addresses the load-related    This document defines a mechanism that addresses the load-related

      
   requirements from RFC 7068.    requirements from RFC 7068.

      
 

      
2.  Terminology and Abbreviations 2.  Terminology and Abbreviations

      
 

      
   AVP    AVP

      
 

      
      Attribute Value Pair       Attribute Value Pair

      
 

      
 

      
skipping to change at page 6, line 24 skipping to change at page 6, line 24

      
      information received from these hosts to make the selection.       information received from these hosts to make the selection.

      
 

      
   Just as load information can be used as part of server selection, it    Just as load information can be used as part of server selection, it

      
   can also be used as input to the selection of the next-hop peer to    can also be used as input to the selection of the next-hop peer to

      
   which a request is to be routed.    which a request is to be routed.

      
 

      
   It should be noted that a Diameter node will need to process both    It should be noted that a Diameter node will need to process both

      
   Load reports and Overload reports from the same Diameter node.  The    Load reports and Overload reports from the same Diameter node.  The

      
   reacting node for the Overload report always has the responsibility    reacting node for the Overload report always has the responsibility

      
   to reduce the amount of Diameter traffic sent to the overloaded node.    to reduce the amount of Diameter traffic sent to the overloaded node.

      

      
   If, or how, the reacting node uses Load information to achieve this    If, or how, the reacting node uses load information to achieve this

      
   is left as an implementation decision.    is left as an implementation decision.

      
 

      
5.  Solution Overview 5.  Solution Overview

      
 

      
   The mechanism defined here for the conveyance of load information is    The mechanism defined here for the conveyance of load information is

      
   similar in some ways to the mechanism defined for DOIC and is    similar in some ways to the mechanism defined for DOIC and is

      
   different in other ways.    different in other ways.

      
 

      

      
   As with DOIC, load information is conveyed by piggy-backing the load    As with DOIC, load information is conveyed by piggy-backing the Load

      
   AVPs on existing Diameter applications.    AVPs on existing Diameter applications.

      
 

      
   There are two primary differences.  First, there is no capability    There are two primary differences.  First, there is no capability

      
   negotiation process for load.  The sender of the load information is    negotiation process for load.  The sender of the load information is

      
   sending it with the expectation that any supporting nodes will use it    sending it with the expectation that any supporting nodes will use it

      
   when making routing decisions.  If there are no nodes that support    when making routing decisions.  If there are no nodes that support

      
   the Load mechanism then the load information is ignored.    the Load mechanism then the load information is ignored.

      
 

      
   The second big difference between DOIC and Load is visibility of the    The second big difference between DOIC and Load is visibility of the

      

      
   DOIC or Load information within a Diameter network.  DOIC information    DOIC or load information within a Diameter network.  DOIC information

      
   is sent end-to-end resulting in the ability of all nodes in the path    is sent end-to-end resulting in the ability of all nodes in the path

      
   of the answer message that carries the OC-OLR AVP to act on the    of the answer message that carries the OC-OLR AVP to act on the

      
   information, although only one node actually comsumes and reacts to    information, although only one node actually comsumes and reacts to

      
   the report.  The DOIC overload reports remain in the message all the    the report.  The DOIC overload reports remain in the message all the

      
   way from the reporting node to the node that is the target for the    way from the reporting node to the node that is the target for the

      
   answer message.    answer message.

      
 

      
   For the Load mechanism there are two types of Load reports and only    For the Load mechanism there are two types of Load reports and only

      
   the first one is transmitted end-to-end.    the first one is transmitted end-to-end.

      
 

      

      
   The first type of load report is a HOST report which contains the    The first type of Load report is a HOST report which contains the

      
   load of the endpoint sending the answer message.  This Load report is    load of the endpoint sending the answer message.  This Load report is

      
   carried end-to-end to enable any nodes that make server selection    carried end-to-end to enable any nodes that make server selection

      
   decisions to use the load status of the sending endpoint as part of    decisions to use the load status of the sending endpoint as part of

      
   the server selection decision.  Unlike with DOIC, more than one node    the server selection decision.  Unlike with DOIC, more than one node

      
   may make use of the load information received.    may make use of the load information received.

      
 

      
   The second type of Load report is a PEER report.  This report is used    The second type of Load report is a PEER report.  This report is used

      
   by Diameter nodes as part of the logic to select the next-hop    by Diameter nodes as part of the logic to select the next-hop

      
   Diameter node and, as such, does not have significance beyond the    Diameter node and, as such, does not have significance beyond the

      
   peer node.  Load reports of type PEER are removed by the first    peer node.  Load reports of type PEER are removed by the first

      
 

      
skipping to change at page 9, line 45 skipping to change at page 9, line 45

      
         |      |      |      |          |      |      |      |

      
 

      
                     Figure 4: Answer Message from A4                      Figure 4: Answer Message from A4

      
 

      
   If A1 supports the Load mechanism then it processes each of the Load    If A1 supports the Load mechanism then it processes each of the Load

      
   reports it receives separately.    reports it receives separately.

      
 

      
   For the PEER Load report, A1 first determines if the source of the    For the PEER Load report, A1 first determines if the source of the

      
   report indicated in the Load report matches the DiameterIdentity of    report indicated in the Load report matches the DiameterIdentity of

      
   the Diameter node from which the request was received.  If the    the Diameter node from which the request was received.  If the

      

      
   identities do not match then the PEER load report is discarded.  If    identities do not match then the PEER Load report is discarded.  If

      
   the identities match then A1 saves the load information in its    the identities match then A1 saves the load information in its

      
   routing information for routing of subsequent request messages.  In    routing information for routing of subsequent request messages.  In

      
   both cases A1 strips the PEER Load report from the message.    both cases A1 strips the PEER Load report from the message.

      
 

      
   For the HOST Load report, A1's actions depend on whether A1 is    For the HOST Load report, A1's actions depend on whether A1 is

      
   responsible for doing server selection.  If A1 is not doing server    responsible for doing server selection.  If A1 is not doing server

      
   selection then A1 ignores the HOST Load report.  If A1 is responsible    selection then A1 ignores the HOST Load report.  If A1 is responsible

      
   for doing server selection then it stores the load information for    for doing server selection then it stores the load information for

      
   S[n] in its routing information for the handling of subsequent    S[n] in its routing information for the handling of subsequent

      
   request messages.  In both cases A1 leaves the HOST report in the    request messages.  In both cases A1 leaves the HOST report in the

      
 

      
skipping to change at page 10, line 35 skipping to change at page 10, line 35

      
   As with A1, C processes each Load report separately.    As with A1, C processes each Load report separately.

      
 

      
   For the PEER Load report, C follows the same procedure as A1 for    For the PEER Load report, C follows the same procedure as A1 for

      
   determining if the Load report was received from the peer from which    determining if the Load report was received from the peer from which

      
   the report was sent.  When finding it does, C stores the load    the report was sent.  When finding it does, C stores the load

      
   information for use when making future routing decisions.    information for use when making future routing decisions.

      
 

      
   For the HOST Load report, C saves the load information only if it is    For the HOST Load report, C saves the load information only if it is

      
   responsible for doing server selection.    responsible for doing server selection.

      
 

      

      
   The Load information received by all nodes is then used for routing    The load information received by all nodes is then used for routing

      
   of subsequent request messages.    of subsequent request messages.

      
 

      
6.  Load Mechanism Procedures 6.  Load Mechanism Procedures

      
 

      
   This section defines the normative behaviors for the Load mechanism.    This section defines the normative behaviors for the Load mechanism.

      
 

      
6.1.  Reporting Node Behavior 6.1.  Reporting Node Behavior

      
 

      
   This section defines the procedures of Diameter reporting nodes that    This section defines the procedures of Diameter reporting nodes that

      
   generate Load reports.    generate Load reports.

      
 

      
skipping to change at page 12, line 27 skipping to change at page 12, line 27

      
      include Load reports when the load value has changed by some       include Load reports when the load value has changed by some

      
      meaningful value, as long as the agent ensures that all peers       meaningful value, as long as the agent ensures that all peers

      
      receive the report.  It is also acceptable to include the Load       receive the report.  It is also acceptable to include the Load

      
      report in every answer message handled by the Diameter Agent.       report in every answer message handled by the Diameter Agent.

      
 

      
6.2.  Reacting Node Behavior 6.2.  Reacting Node Behavior

      
 

      
   This section defines the behavior of Diameter nodes processing Load    This section defines the behavior of Diameter nodes processing Load

      
   reports.    reports.

      
 

      

      
   A Diameter node MUST be prepared to process Load reports of type HOST    A Diameter node that supports the Diameter Load mechanism MUST be

      
   and of type PEER, as indicated in the Load-Type AVP included in the    prepared to process Load reports of type HOST and of type PEER, as

      
   Load AVP received in the same answer message or from multiple answer    indicated in the Load-Type AVP included in the Load AVP received in

      
   messages.    the same answer message or from multiple answer messages.

      
 

      
      Note that the node needs to be able to handle messages with no       Note that the node needs to be able to handle messages with no

      
      load reports, messages with just a PEER Load report, messages with       load reports, messages with just a PEER Load report, messages with

      
      just an HOST Load report and messages with both types of Load       just an HOST Load report and messages with both types of Load

      
      reports.       reports.

      
 

      
   If the Diameter node is not responsible for doing server selection    If the Diameter node is not responsible for doing server selection

      
   then it SHOULD ignore Load reports of type HOST.    then it SHOULD ignore Load reports of type HOST.

      
 

      
   If the Diameter node is responsible for doing server selection then    If the Diameter node is responsible for doing server selection then

      
 

      
skipping to change at page 15, line 47 skipping to change at page 15, line 47

      
   Load information may be sensitive information in some cases.    Load information may be sensitive information in some cases.

      
   Depending on the mechanism, an unauthorized recipient might be able    Depending on the mechanism, an unauthorized recipient might be able

      
   to infer the topology of a Diameter network from load information.    to infer the topology of a Diameter network from load information.

      
   Load information might be useful in identifying targets for Denial of    Load information might be useful in identifying targets for Denial of

      
   Service (DoS) attacks, where a node known to be already heavily    Service (DoS) attacks, where a node known to be already heavily

      
   loaded might be a tempting target.  Load information might also be    loaded might be a tempting target.  Load information might also be

      
   useful as feedback about the success of an ongoing DoS attack.    useful as feedback about the success of an ongoing DoS attack.

      
 

      
   Given that routing decisions are impacted by load information, there    Given that routing decisions are impacted by load information, there

      
   is potential for negative impacts on a Diameter network caused by    is potential for negative impacts on a Diameter network caused by

      

      
   erroneous or malicious load reports.  This includes the malicious    erroneous or malicious Load reports.  This includes the malicious

      
   changing of load values by Diameter Agents.    changing of load values by Diameter Agents.

      
 

      
   Any load information conveyance mechanism will need to allow    Any load information conveyance mechanism will need to allow

      
   operators to avoid sending load information to nodes that are not    operators to avoid sending load information to nodes that are not

      
   authorized to receive it.  Since Diameter currently only offers    authorized to receive it.  Since Diameter currently only offers

      

      
   authentication of nodes at the transport level, any solution that    authentication of nodes at the transport level and does not support

      
   sends load information to non-peer nodes requires a transitive-trust    end-to-end security mechanisms, any solution that sends load

      
   model.    information to non-peer nodes requires a transitive-trust model.

      
 

      
9.  IANA Considerations 9.  IANA Considerations

      
 

      
9.1.  AVP Codes 9.1.  AVP Codes

      
 

      
   New AVPs defined by this specification are listed in    New AVPs defined by this specification are listed in

      
   Section Section 7.  All AVP codes are allocated from the    Section Section 7.  All AVP codes are allocated from the

      
   'Authentication, Authorization, and Accounting (AAA) Parameters' AVP    'Authentication, Authorization, and Accounting (AAA) Parameters' AVP

      
   Codes registry.    Codes registry.

      
 


     
 

     
 End of changes. 14 change blocks. 

     
23 lines changed or deleted 23 lines changed or added

     

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   

--------------71A74E225ED9027EAB318CF7--


From nobody Wed Mar 22 15:03:00 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57201293DA for ; Wed, 22 Mar 2017 15:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, 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 iqNt7j5SIIT6 for ; Wed, 22 Mar 2017 15:02:57 -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 E197C129851 for ; Wed, 22 Mar 2017 15:02:57 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:64001 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqoL7-001Ebu-Uy for dime@ietf.org; Wed, 22 Mar 2017 15:02:57 -0700
References: <148727508790.1071.1263646507149967833.idtracker@ietfa.amsl.com> <46a97b6d-a4bd-0275-10db-b321dd4d95ed@usdonovans.com>  
Cc: "dime@ietf.org" 
From: Steve Donovan 
Message-ID: 
Date: Wed, 22 Mar 2017 17:02:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0C8C2FA3EA13BB6314E880E4"
X-OutGoing-Spam-Status: No, score=0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-05.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Mar 2017 22:03:00 -0000

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

MIsha,

See my comments inline.

Regards,

Steve

On 2/18/17 2:43 AM, Misha Zaytsev wrote:
> Hi Steve,
>
> I'm OK with most your edits, just some extra comments from my side:
>
> The following comment was just partially applied. There are still 
> section titles that are not in an upper case.
> 13. Upper case in section titles for section 7.3.1, 7.3.2, 7.3.3, 8.1 
> and 8.2
> In addition to the listed ones, section 6.3 title is also under the 
> comment.
>
I believe I have captured all of the section titles in the next version. 
   I'm sure the RFC editor will correct any that I missed.
> One new comment:
>
> Following the procedures defined in [draft-ietf-dime-doic]
>
> Are we talking about RFC7683 here?
Yes, change made.
>
> All in all, I'm OK with your edits, but I still have concern about the 
> text taken from SIP RFC.
> As I noted, I think it would be better to have it reworked deeper and 
> not just updated with minor changes to be aligned with DOIC concept. 
> But it looks this is a matter of preference...
Noted.
>
> Best regards,
>
> /Misha
>
>
>
> 2017-02-18 2:23 GMT+03:00 jouni.nospam  >:
>
>     Thanks Steve.
>
>     - Jouni
>
>     > On Feb 16, 2017, at 12:00 PM, Steve Donovan
>     > wrote:
>     >
>     > All,
>     >
>     > I've updated the rate control draft based on comments received
>     during the most recent last call.
>     >
>     > I've attached a diff file showing the changes.
>     >
>     > Regards,
>     >
>     > Steve
>     >
>     > On 2/16/17 1:58 PM, internet-drafts@ietf.org
>      wrote:
>     >> 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 of the IETF.
>     >>
>     >>         Title           : Diameter Overload Rate Control
>     >>         Authors         : Steve Donovan
>     >>                           Eric Noel
>     >>      Filename        : draft-ietf-dime-doic-rate-control-05.txt
>     >>      Pages           : 19
>     >>      Date            : 2017-02-16
>     >>
>     >> Abstract:
>     >>    This specification documents an extension to the Diameter
>     Overload
>     >>    Indication Conveyance (DOIC) [RFC7683] base solution.  This
>     extension
>     >>    adds a new overload control abatement algorithm.  This abatement
>     >>    algorithm allows for a DOIC reporting node to specify a
>     maximum rate
>     >>    at which a DOIC reacting node sends Diameter requests to the
>     DOIC
>     >>    reporting node.
>     >>
>     >> Requirements
>     >>
>     >> The IETF datatracker status page for this draft is:
>     >>
>     https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/
>     
>     >>
>     >> There's also a htmlized version available at:
>     >>
>     https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-05
>     
>     >>
>     >> A diff from the previous version is available at:
>     >>
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-05
>     
>     >>
>     >>
>     >> 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/
>     
>     >>
>     >> _______________________________________________
>     >> DiME mailing list
>     >> DiME@ietf.org 
>     >> https://www.ietf.org/mailman/listinfo/dime
>     
>     >
>     >      draft-ietf-dime-doic-rate-control-05.txt>_______________________________________________
>     > DiME mailing list
>     > DiME@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/dime
>     
>
>     _______________________________________________
>     DiME mailing list
>     DiME@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dime
>     
>
>


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


  
    
  
  
    MIsha,

    

    See my comments inline.

    

    Regards,

    

    Steve

    

    
On 2/18/17 2:43 AM, Misha Zaytsev
      wrote:

    

    

      
Hi Steve,
        


        

        
I'm OK with most your edits, just some extra comments from
          my side:

        


        

        
The following comment was just partially applied. There are
          still section titles that are not in an upper case.

        
13. Upper case in section titles for section 7.3.1, 7.3.2,
          7.3.3, 8.1 and 8.2

        
In addition to the listed ones, section 6.3 title is also
          under the comment.

        


        

      

    

    I believe I have captured all of the section titles in the next
    version.   I'm sure the RFC editor will correct any that I missed.

    

      

        
One new comment:

        


        

        

          
Following the procedures defined in [draft-ietf-dime-doic]

        

        


        

      

    

    

      

        
Are we talking about RFC7683 here?

      

    

    Yes, change made.

    

      

        


        

        
All in all, I'm OK with your edits, but I still have
          concern about the text taken from SIP RFC.

        
As I noted, I think it would be better to have it reworked
          deeper and not just updated with minor changes to be aligned
          with DOIC concept. But it looks this is a matter of
          preference...

      

    

    Noted.

    

      

        


        

        
Best regards,

        


        

        
/Misha

        


        

        


        

      

      


        
2017-02-18 2:23 GMT+03:00 jouni.nospam
          <jouni.nospam@gmail.com>:

          
Thanks
            Steve.

            

            - Jouni

            

              


                > On Feb 16, 2017, at 12:00 PM, Steve Donovan <srdonovan@usdonovans.com>
                wrote:

                >

                > All,

                >

                > I've updated the rate control draft based on
                comments received during the most recent last call.

                >

                > I've attached a diff file showing the changes.

                >

                > Regards,

                >

                > Steve

                >

                > On 2/16/17 1:58 PM, internet-drafts@ietf.org
                wrote:

                >> 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 of the IETF.

                >>

                >>         Title           : Diameter Overload
                Rate Control

                >>         Authors         : Steve Donovan

                >>                           Eric Noel

                >>      Filename        :
                draft-ietf-dime-doic-rate-control-05.txt

                >>      Pages           : 19

                >>      Date            : 2017-02-16

                >>

                >> Abstract:

                >>    This specification documents an extension to
                the Diameter Overload

                >>    Indication Conveyance (DOIC) [RFC7683] base
                solution.  This extension

                >>    adds a new overload control abatement
                algorithm.  This abatement

                >>    algorithm allows for a DOIC reporting node
                to specify a maximum rate

                >>    at which a DOIC reacting node sends Diameter
                requests to the DOIC

                >>    reporting node.

                >>

                >> Requirements

                >>

                >> The IETF datatracker status page for this draft
                is:

                >> https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/

                >>

                >> There's also a htmlized version available at:

                >> https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-05

                >>

                >> A diff from the previous version is available
                at:

                >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-05

                >>

                >>

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

                >>

                >> _______________________________________________

                >> DiME mailing list

                >> DiME@ietf.org

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

                >

              

            

            > <Diff_ draft-ietf-dime-doic-rate-control-04.txt
            - draft-ietf-dime-doic-rate-control-05.txt>_______________________________________________

            

              
> DiME mailing list

                > DiME@ietf.org

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

                

                _______________________________________________

                DiME mailing list

                DiME@ietf.org

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

              

            

          

        

        

      

    

    

  


--------------0C8C2FA3EA13BB6314E880E4--


From nobody Thu Mar 23 18:52:23 2017
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D85131512; Thu, 23 Mar 2017 18:52:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.48.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: The IESG , jouni.nospam@gmail.com, Jouni Korhonen , dime-chairs@ietf.org, dime@ietf.org,  draft-ietf-dime-agent-overload@ietf.org, rfc-editor@rfc-editor.org, stephen.farrell@cs.tcd.ie
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149032033311.22411.15276838090602224364.idtracker@ietfa.amsl.com>
Date: Thu, 23 Mar 2017 18:52:13 -0700
Archived-At: 
Subject: [Dime] Protocol Action: 'Diameter Agent Overload and the Peer Overload Report' to Proposed Standard (draft-ietf-dime-agent-overload-11.txt)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 01:52:13 -0000

The IESG has approved the following document:
- 'Diameter Agent Overload and the Peer Overload Report'
  (draft-ietf-dime-agent-overload-11.txt) as Proposed Standard

This document is the product of the Diameter Maintenance and Extensions
Working Group.

The IESG contact persons are Stephen Farrell, Benoit Claise and Joel
Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/




Technical Summary

  This document specifies an extension to RFC7683, which adds 
  a peer overload report type with the intended use case to cover
  a Diameter agent overload situation.

Working Group Summary

  The document has full support of the DIME WG and was discussed
  in length in the WG.

Document Quality

   No currently known implementations (the AVP code allocations are not done
   yet, for example). The document extends RFC7683, which is part of 3GPP
   Diameter based AAA interfaces specifications.

Personnel

   Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
   Stephen Farrell  is the responsible AD.  


From nobody Thu Mar 23 18:54:16 2017
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1613131588; Thu, 23 Mar 2017 18:54:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.48.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: The IESG , draft-ietf-dime-load@ietf.org, jouni.nospam@gmail.com, dime-chairs@ietf.org, Jouni Korhonen , dime@ietf.org, rfc-editor@rfc-editor.org, stephen.farrell@cs.tcd.ie
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149032045565.22427.12355185289291801751.idtracker@ietfa.amsl.com>
Date: Thu, 23 Mar 2017 18:54:15 -0700
Archived-At: 
Subject: [Dime] Protocol Action: 'Diameter Load Information Conveyance' to Proposed Standard (draft-ietf-dime-load-09.txt)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Mar 2017 01:54:16 -0000

The IESG has approved the following document:
- 'Diameter Load Information Conveyance'
  (draft-ietf-dime-load-09.txt) as Proposed Standard

This document is the product of the Diameter Maintenance and Extensions
Working Group.

The IESG contact persons are Stephen Farrell, Benoit Claise and Joel
Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-load/





Technical Summary

   This document defines a mechanism for conveying of Diameter load
   information. RFC7683 (DOIC) decided not to address load information
   delivery. This document fills that gap.

Working Group Summary

   The document had extensive discussion on the email reflector and there
   is working group support behind the documented solution. It is worth
   noting that Diameter experts from other SDOs (3GPP) also participated
   actively to the discussion.

Document Quality

   The specification is a natural extension to DOIC mechanism, which is 
   already adopted by 3GPP standards. 

   No specific reviews have been requested or carried out by
   different directorates. 

Personnel

   Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.
   Stephen Farrell (stephen.farrell@cs.tcd.ie) is the responsible AD.


From nobody Mon Mar 27 15:53:19 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA1126E3A for ; Mon, 27 Mar 2017 15:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJdhliR7w8BP for ; Mon, 27 Mar 2017 15:53:16 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 23A2C1296C0 for ; Mon, 27 Mar 2017 15:53:06 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id y18so376190itc.1 for ; Mon, 27 Mar 2017 15:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=YO5lL//hzPnRBQWN+b4k9CmifNw4MMZPXwxso0apKVo=; b=e0eqawbd5zy5nKpkq5tARhA8bzWg/IFYlj3hVBGg0cKXzpQsVE/9Y329+tZA+93+Vr Uy7ot7FYYjH+8Vg5U/vTPOVDoAp9Q6L3freYLyB7daPWMOcQwTXRbmP8hXOROaFG0frh zLIh5sGy2Ai5tzVQztXMKR5hFx7G5ql13n3cOk3xfX862QY+VweTasFOvKUWXF9vRGV8 pbYdBfiurC0yBK/zzV5F6E6Ypno+eJxliobn4qcemnNcF114IgD8XvWPOVAcJKBHZOov ApSiUJ6S14Eo5M63ZrERbm6L9dNxqy9lNx/TyZPG+DFBXplSVP1QiKgKCPrgCe6Xz5TV GeUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=YO5lL//hzPnRBQWN+b4k9CmifNw4MMZPXwxso0apKVo=; b=aAZx3zsTdptXiYGV/qaMZ/MvINpf41C21z/IQI/PL1LrOvDf448Uz4u/BZjeGU0VGA /jrV7t7g51VCr63ziz1kRCSMOAoDKHiYlGh2q3HG+zRCualxDN4noAXd2oYCMLGrPE4c 2a+2849w1sSTTpnqTYtafa1YP/nzvmF35VDAsZp8HQ01LslBTzDVz0yuNuO19RoWCreM wYK1T3S52+s77aetkDXkQ4j4M6De7YGu0a+GBezfcHFb4uJJAypp+XmSE310yr024kYO d5XJeyVIT2GsexrqXJL8zsQdSlxEkub+j47pIO5KRLrjrDw1TOrDKSp3mm1z3kkCak13 1xVQ==
X-Gm-Message-State: AFeK/H3ve9chGsHyTpPyCYgRUw2EeRewU7aZiaGNZPDaVUgUAzdCwqfpjCQrdToBeVBs+A==
X-Received: by 10.107.181.87 with SMTP id e84mr23482799iof.156.1490655185250;  Mon, 27 Mar 2017 15:53:05 -0700 (PDT)
Received: from t2001067c0370012844128b5662d2be21.v6.meeting.ietf.org (t2001067c0370012844128b5662d2be21.v6.meeting.ietf.org. [2001:67c:370:128:4412:8b56:62d2:be21]) by smtp.gmail.com with ESMTPSA id s194sm526296ita.12.2017.03.27.15.53.04 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 15:53:04 -0700 (PDT)
From: jouni korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <4D6FCD1C-B255-4394-B84E-7653BDCE11F0@gmail.com>
Date: Mon, 27 Mar 2017 15:53:03 -0700
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: [Dime] Slides plz
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Mar 2017 22:53:18 -0000

Folks,

Those on IETF 98 DIME agenda, send your slides latest Wednesday evening.

- JOuni & Lionel


From nobody Mon Mar 27 20:22:38 2017
Return-Path: 
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D81293DB; Mon, 27 Mar 2017 20:22:36 -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.48.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149067135681.30549.18219521655664787389@ietfa.amsl.com>
Date: Mon, 27 Mar 2017 20:22:36 -0700
Archived-At: 
Subject: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-06.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Mar 2017 03:22:37 -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 of the IETF.

        Title           : Diameter Overload Rate Control
        Authors         : Steve Donovan
                          Eric Noel
	Filename        : draft-ietf-dime-doic-rate-control-06.txt
	Pages           : 19
	Date            : 2017-03-27

Abstract:
   This specification documents an extension to the Diameter Overload
   Indication Conveyance (DOIC) [RFC7683] base solution.  This extension
   adds a new overload control abatement algorithm.  This abatement
   algorithm allows for a DOIC reporting node to specify a maximum rate
   at which a DOIC reacting node sends Diameter requests to the DOIC
   reporting node.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-06
https://datatracker.ietf.org/doc/html/draft-ietf-dime-doic-rate-control-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-06


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 Mar 27 20:25:38 2017
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93E126DED for ; Mon, 27 Mar 2017 20:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] 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 ZoNn5YEb5G_8 for ; Mon, 27 Mar 2017 20:25:33 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (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 BF08212922E for ; Mon, 27 Mar 2017 20:25:33 -0700 (PDT)
Received: from [61.35.169.149] (port=21475 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cshl4-002IIQ-1b for dime@ietf.org; Mon, 27 Mar 2017 20:25:33 -0700
To: dime@ietf.org
References: <149067135681.30549.18219521655664787389@ietfa.amsl.com>
From: Steve Donovan 
Message-ID: 
Date: Tue, 28 Mar 2017 12:25:20 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149067135681.30549.18219521655664787389@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="------------BD41DB94888FAC6D6968F330"
X-OutGoing-Spam-Status: No, score=2.5
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] I-D Action: draft-ietf-dime-doic-rate-control-06.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Mar 2017 03:25:36 -0000

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

I've submitted a new version of the rate control draft.  It has minor 
changes as shown in the attached diff file.  I believe all comments 
received during the last round of reviews has been incorporated into the 
draft.

Regards,

Steve

On 3/28/17 12:22 PM, internet-drafts@ietf.org wrote:
> 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 of the IETF.
>
>          Title           : Diameter Overload Rate Control
>          Authors         : Steve Donovan
>                            Eric Noel
> 	Filename        : draft-ietf-dime-doic-rate-control-06.txt
> 	Pages           : 19
> 	Date            : 2017-03-27
>
> Abstract:
>     This specification documents an extension to the Diameter Overload
>     Indication Conveyance (DOIC) [RFC7683] base solution.  This extension
>     adds a new overload control abatement algorithm.  This abatement
>     algorithm allows for a DOIC reporting node to specify a maximum rate
>     at which a DOIC reacting node sends Diameter requests to the DOIC
>     reporting node.
>
> Requirements
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-06
> https://datatracker.ietf.org/doc/html/draft-ietf-dime-doic-rate-control-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-06
>
>
> 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/
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------BD41DB94888FAC6D6968F330
Content-Type: text/html; charset=UTF-8;
 name="Diff_ draft-ietf-dime-doic-rate-control-05.txt -
 draft-ietf-dime-doic-rate-control-06.html"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-doic-rate-control-05.txt - draft-ietf-";
 filename*1="dime-doic-rate-control-06.html"








 
   
   
  Diff: draft-ietf-dime-doic-rate-control-05.txt - draft-ietf-dime-doic-rate-control-06.txt 
   
      
 
 
  
 
  
< draft-ietf-dime-doic-rate-control-05.txt   draft-ietf-dime-doic-rate-control-06.txt >
 
      
 

      
Diameter Maintenance and Extensions (DIME)               S. Donovan, Ed. Diameter Maintenance and Extensions (DIME)               S. Donovan, Ed.

      
Internet-Draft                                                    Oracle Internet-Draft                                                    Oracle

      
Intended status: Standards Track                                 E. Noel Intended status: Standards Track                                 E. Noel

      

      
Expires: August 20, 2017                                       AT&T Labs Expires: September 23, 2017                                    AT&T Labs

      
                                                       February 16, 2017                                                           March 22, 2017

      
 

      
                     Diameter Overload Rate Control                      Diameter Overload Rate Control

      

      
                draft-ietf-dime-doic-rate-control-05.txt                 draft-ietf-dime-doic-rate-control-06.txt

      
 

      
Abstract Abstract

      
 

      
   This specification documents an extension to the Diameter Overload    This specification documents an extension to the Diameter Overload

      
   Indication Conveyance (DOIC) [RFC7683] base solution.  This extension    Indication Conveyance (DOIC) [RFC7683] base solution.  This extension

      
   adds a new overload control abatement algorithm.  This abatement    adds a new overload control abatement algorithm.  This abatement

      
   algorithm allows for a DOIC reporting node to specify a maximum rate    algorithm allows for a DOIC reporting node to specify a maximum rate

      
   at which a DOIC reacting node sends Diameter requests to the DOIC    at which a DOIC reacting node sends Diameter requests to the DOIC

      
   reporting node.    reporting node.

      
 

      
 

      
skipping to change at page 1, line 42 skipping to change at page 1, line 42

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on August 20, 2017.    This Internet-Draft will expire on September 23, 2017.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2017 IETF Trust and the persons identified as the    Copyright (c) 2017 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
   carefully, as they describe your rights and restrictions with respect    carefully, as they describe your rights and restrictions with respect

      
   to this document.  Code Components extracted from this document must    to this document.  Code Components extracted from this document must

      
   include Simplified BSD License text as described in Section 4.e of    include Simplified BSD License text as described in Section 4.e of

      
   the Trust Legal Provisions and are provided without warranty as    the Trust Legal Provisions and are provided without warranty as

      
   described in the Simplified BSD License.    described in the Simplified BSD License.

      
 

      
Table of Contents Table of Contents

      
 

      
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

      
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4    2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4

      

      
   3.  Interaction with DOIC report types  . . . . . . . . . . . . .   5    3.  Interaction with DOIC Report Rypes  . . . . . . . . . . . . .   5

      
   4.  Capability Announcement . . . . . . . . . . . . . . . . . . .   5    4.  Capability Announcement . . . . . . . . . . . . . . . . . . .   5

      
   5.  Overload Report Handling  . . . . . . . . . . . . . . . . . .   6    5.  Overload Report Handling  . . . . . . . . . . . . . . . . . .   6

      
     5.1.  Reporting Node Overload Control State . . . . . . . . . .   6      5.1.  Reporting Node Overload Control State . . . . . . . . . .   6

      
     5.2.  Reacting Node Overload Control State  . . . . . . . . . .   6      5.2.  Reacting Node Overload Control State  . . . . . . . . . .   6

      
     5.3.  Reporting Node Maintenance of Overload Control State  . .   7      5.3.  Reporting Node Maintenance of Overload Control State  . .   7

      
     5.4.  Reacting Node Maintenance of Overload Control State . . .   7      5.4.  Reacting Node Maintenance of Overload Control State . . .   7

      
     5.5.  Reporting Node Behavior for Rate Abatement Algorithm  . .   7      5.5.  Reporting Node Behavior for Rate Abatement Algorithm  . .   7

      
     5.6.  Reacting Node Behavior for Rate Abatement Algorithm . . .   8      5.6.  Reacting Node Behavior for Rate Abatement Algorithm . . .   8

      
   6.  Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . .   8    6.  Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . .   8

      
     6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .   8      6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .   8

      
       6.1.1.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . .   8        6.1.1.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . .   8

      
     6.2.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .   9      6.2.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .   9

      
       6.2.1.  OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . .   9        6.2.1.  OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . .   9

      

      
     6.3.  Attribute Value Pair flag rules . . . . . . . . . . . . .   9      6.3.  Attribute Value Pair Flag Rules . . . . . . . . . . . . .   9

      
   7.  Rate Based Abatement Algorithm  . . . . . . . . . . . . . . .  10    7.  Rate Based Abatement Algorithm  . . . . . . . . . . . . . . .  10

      
     7.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10      7.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10

      
     7.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  10      7.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  10

      
     7.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  11      7.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  11

      
       7.3.1.  Default Algorithm . . . . . . . . . . . . . . . . . .  11        7.3.1.  Default Algorithm . . . . . . . . . . . . . . . . . .  11

      
       7.3.2.  Priority Treatment  . . . . . . . . . . . . . . . . .  14        7.3.2.  Priority Treatment  . . . . . . . . . . . . . . . . .  14

      
       7.3.3.  Optional Enhancement: Avoidance of Resonance  . . . .  16        7.3.3.  Optional Enhancement: Avoidance of Resonance  . . . .  16

      
   8.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .  17    8.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .  17

      

      
     8.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  17      8.1.  AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .  17

      
     8.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  17      8.2.  New Registries  . . . . . . . . . . . . . . . . . . . . .  17

      
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17

      
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18    10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18

      
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18    11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18

      
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18      11.1.  Normative References . . . . . . . . . . . . . . . . . .  18

      
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18      11.2.  Informative References . . . . . . . . . . . . . . . . .  18

      
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

      
 

      
1.  Introduction 1.  Introduction

      
 

      
   This document defines a new Diameter overload control abatement    This document defines a new Diameter overload control abatement

      
 

      
skipping to change at page 5, line 5 skipping to change at page 5, line 5

      
      [RFC7683].       [RFC7683].

      
 

      
   Reporting Node    Reporting Node

      
 

      
      A DOIC Node that sends a DOIC overload report.       A DOIC Node that sends a DOIC overload report.

      
 

      
   Reacting Node    Reacting Node

      
 

      
      A DOIC Node that receives and acts on a DOIC overload report.       A DOIC Node that receives and acts on a DOIC overload report.

      
 

      

      
3.  Interaction with DOIC report types 3.  Interaction with DOIC Report Rypes

      
 

      
   As of the publication of this specification there are two DOIC report    As of the publication of this specification there are two DOIC report

      
   types defined with the specification of a third in progress:    types defined with the specification of a third in progress:

      
 

      
   1.  Host - Overload of a specific Diameter Application at a specific    1.  Host - Overload of a specific Diameter Application at a specific

      
       Diameter Node as defined in [RFC7683].        Diameter Node as defined in [RFC7683].

      
 

      
   2.  Realm - Overload of a specific Diameter Application at a specific    2.  Realm - Overload of a specific Diameter Application at a specific

      
       Diameter Realm as defined in [RFC7683].        Diameter Realm as defined in [RFC7683].

      
 

      
 

      
skipping to change at page 9, line 36 skipping to change at page 9, line 36

      
   algorithm.    algorithm.

      
 

      
6.2.1.  OC-Maximum-Rate AVP 6.2.1.  OC-Maximum-Rate AVP

      
 

      
   The OC-Maximum-Rate AVP (AVP code TBD1) is of type Unsigned32 and    The OC-Maximum-Rate AVP (AVP code TBD1) is of type Unsigned32 and

      
   describes the maximum rate that the sender is requested to send    describes the maximum rate that the sender is requested to send

      
   traffic.  This is specified in terms of requests per second.    traffic.  This is specified in terms of requests per second.

      
 

      
   A value of zero indicates that no traffic is to be sent.    A value of zero indicates that no traffic is to be sent.

      
 

      

      
6.3.  Attribute Value Pair flag rules 6.3.  Attribute Value Pair Flag Rules

      
 

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

      
                                                             |AVP flag |                                                              |AVP flag |

      
                                                             |rules    |                                                              |rules    |

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

      
                            AVP   Section                    |    |MUST|                             AVP   Section                    |    |MUST|

      
    Attribute Name          Code  Defined  Value Type        |MUST| NOT|     Attribute Name          Code  Defined  Value Type        |MUST| NOT|

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

      
   |OC-Maximum-Rate         TBD1    6.2    Unsigned32        |    | V  |    |OC-Maximum-Rate         TBD1    6.2    Unsigned32        |    | V  |

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

      
 

      
skipping to change at page 10, line 16 skipping to change at page 10, line 16

      
 

      
   This section is pulled from [RFC7415], with minor changes needed to    This section is pulled from [RFC7415], with minor changes needed to

      
   make it apply to the Diameter protocol.    make it apply to the Diameter protocol.

      
 

      
7.1.  Overview 7.1.  Overview

      
 

      
   The reporting node is the one protected by the overload control    The reporting node is the one protected by the overload control

      
   algorithm defined here.  The reacting node is the one that abates    algorithm defined here.  The reacting node is the one that abates

      
   traffic towards the server.    traffic towards the server.

      
 

      

      
   Following the procedures defined in [draft-ietf-dime-doic], the    Following the procedures defined in [RFC7683], the reacting node and

      
   reacting node and reporting node signal one another support for rate-    reporting node signal one another support for rate-based overload

      
   based overload control.    control.

      
 

      
   Then periodically, the reporting node relies on internal measurements    Then periodically, the reporting node relies on internal measurements

      
   (e.g.  CPU utilization or queuing delay) to evaluate its overload    (e.g.  CPU utilization or queuing delay) to evaluate its overload

      
   state and estimate a target maximum Diameter request rate in number    state and estimate a target maximum Diameter request rate in number

      
   of requests per second (as opposed to target percent reduction in the    of requests per second (as opposed to target percent reduction in the

      
   case of loss-based abatement).    case of loss-based abatement).

      
 

      
   When in an overloaded state, the reporting node uses the OC-OLR AVP    When in an overloaded state, the reporting node uses the OC-OLR AVP

      
   to inform reacting nodes of its overload state and of the target    to inform reacting nodes of its overload state and of the target

      
   Diameter request rate.    Diameter request rate.

      
 

      
skipping to change at page 17, line 37 skipping to change at page 17, line 37

      
      minimum time between admissions is uniformly distributed over       minimum time between admissions is uniformly distributed over

      
      [T/2, 3T/2], and the mean time between admissions is the same,       [T/2, 3T/2], and the mean time between admissions is the same,

      
      i.e. T+1/R where R is the request arrival rate.       i.e. T+1/R where R is the request arrival rate.

      
 

      
   o  At high load randomization rarely occurs, so there is no loss of    o  At high load randomization rarely occurs, so there is no loss of

      
      precision of the admitted rate, even though the randomized       precision of the admitted rate, even though the randomized

      
      'phasing' of the buckets remains.       'phasing' of the buckets remains.

      
 

      
8.  IANA Consideration 8.  IANA Consideration

      
 

      

      
8.1.  AVP codes 8.1.  AVP Codes

      
 

      
   New AVPs defined by this specification are listed in Section 6.  All    New AVPs defined by this specification are listed in Section 6.  All

      
   AVP codes are allocated from the 'Authentication, Authorization, and    AVP codes are allocated from the 'Authentication, Authorization, and

      
   Accounting (AAA) Parameters' AVP Codes registry.    Accounting (AAA) Parameters' AVP Codes registry.

      
 

      

      
8.2.  New registries 8.2.  New Registries

      
 

      
   There are no new IANA registries introduced by this document.    There are no new IANA registries introduced by this document.

      
 

      
9.  Security Considerations 9.  Security Considerations

      
 

      
   The rate overload abatement mechanism is an extension to the base    The rate overload abatement mechanism is an extension to the base

      
   Diameter overload mechanism.  As such, all of the security    Diameter overload mechanism.  As such, all of the security

      
   considerations outlined in [RFC7683] apply to the rate overload    considerations outlined in [RFC7683] apply to the rate overload

      
   abatement mechanism.    abatement mechanism.

      
 


     
 

     
 End of changes. 11 change blocks. 

     
15 lines changed or deleted 15 lines changed or added

     

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   

--------------BD41DB94888FAC6D6968F330--