From iesg-secretary@ietf.org Wed Oct 2 06:32:03 2013 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 AD54C21E8093; Wed, 2 Oct 2013 06:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.004 X-Spam-Level: X-Spam-Status: No, score=-102.004 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te0TBrrHnhQS; Wed, 2 Oct 2013 06:31:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAAF21E80B3; Wed, 2 Oct 2013 06:27:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002132753.20697.3516.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 06:27:53 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Document Action: 'Diameter Overload Control Requirements' to Informational RFC (draft-ietf-dime-overload-reqs-13.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:32:03 -0000 The IESG has approved the following document: - 'Diameter Overload Control Requirements' (draft-ietf-dime-overload-reqs-13.txt) as Informational RFC This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs/ Technical Summary The document sets normative requirements for Diameter overload control solutions. The existing Diameter mechanisms for an overload control are not sufficient for a practical solution. The document also goes into lengths explaining why Diameter overload control functionality is needed and describes the limitations of the existing mechanisms in the Diameter Base Protocol. Working Group Summary The working group reached a consensus on the document. The discussion was extensive. Since this document is a requirements document, possible technical solution space issues are left for future documents and discussions. There is an obvious decision point ahead that got quite a bit of attention, which relates to the dissemination of the overload control information: whether an explicit overload application is needed for proper end-to-end signaling semantics or whether everything is piggybacked on top of existing signaling between adjacent peers in hop-by-hop fashion. However, this is for the solution space and the requirements document currently allows both approaches. Document Quality The document has greater industry interest behind, specifically from the cellular industry. Since the document is a requirement document there are no standardised solutions available yet due to the absence of the protocol specification. There is definitive interest from both operators and vendors to have a standard solution for Diameter overload control. The requirements document has been extensively reviewed by the 3GPP CT4 working group, which is the main AAA protocol group in 3GPP. Personnel Jouni Korhonen is the document shepherd. The responsible area director is Benoit Claise. No IANA experts required. From internet-drafts@ietf.org Wed Oct 2 15:47:02 2013 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 ABE8621F95D0; Wed, 2 Oct 2013 15:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyPyy+Cmu6aQ; Wed, 2 Oct 2013 15:46:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF56F21F8F2A; Wed, 2 Oct 2013 15:46:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002224634.20697.79406.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 15:46:34 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 22:47:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Realm-Based Redirection In Diameter Author(s) : Tina Tsou Ruibing Hao Tom Taylor Filename : draft-ietf-dime-realm-based-redirect-13.txt Pages : 9 Date : 2013-10-02 Abstract: The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when S-NAPTR is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server". This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-realm-based-redirect-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-13 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 tom.taylor.stds@gmail.com Wed Oct 2 15:59:41 2013 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 91F4E21F9DA9 for ; Wed, 2 Oct 2013 15:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bajg9wN3pqmS for ; Wed, 2 Oct 2013 15:59:30 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A233E21F9EC8 for ; Wed, 2 Oct 2013 15:58:19 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so1130710qeu.5 for ; Wed, 02 Oct 2013 15:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zXxLsBHOXnzgPIuwmDcpWPUtXLxsKRGdOH0RBSxD7ng=; b=qykqmjxEknjOUN22IXP5up8ZWhEf+umfzRdqQLawNWrEuRq5ige6c8FEUNrw2X3JFE jeweOaeaZ8ujOSKgoIs7YO2y7DnczGTfbxPKD+duFLLx34WlUacifwBPNaiKYU7YZbsn yxcIaKrXvjla30n49fhKvILtYc72DX6GyMie8WkZAYVJ4wPQiFqMcNVDUE+IB2hfwQnw uYIOStaEEoGmzCjDFlfqRJ5Ema5Df+pIEFroDhAX2BIAUVwHHDmqj+8GE3oyxHTQderl C2nfHduWgXNnmbbFtvBegysf57jJGJUTCRitLrSxfkuz2g75UP+q+oGHhQ5HtdRAtbsL 3UfA== X-Received: by 10.224.165.20 with SMTP id g20mr6576427qay.17.1380754699101; Wed, 02 Oct 2013 15:58:19 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id x8sm10274476qam.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 15:58:18 -0700 (PDT) Message-ID: <524CA506.8030006@gmail.com> Date: Wed, 02 Oct 2013 18:58:14 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dime@ietf.org References: <20131002224634.20697.79406.idtracker@ietfa.amsl.com> In-Reply-To: <20131002224634.20697.79406.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 22:59:42 -0000 The latest updates respond to IESG comments. Some editorial, beefed up the Security Considerations section. Thanks to Lionel for pulling things together. Tom Taylor On 02/10/2013 6:46 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 Working Group of the IETF. > > Title : Realm-Based Redirection In Diameter > Author(s) : Tina Tsou > Ruibing Hao > Tom Taylor > Filename : draft-ietf-dime-realm-based-redirect-13.txt > Pages : 9 > Date : 2013-10-02 > ... From jouni.nospam@gmail.com Wed Oct 2 23:37:50 2013 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 85C9321F8613 for ; Wed, 2 Oct 2013 23:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKgvXnG+Onn7 for ; Wed, 2 Oct 2013 23:37:43 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 180C921F9DCA for ; Wed, 2 Oct 2013 23:37:25 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id x18so1645867lbi.3 for ; Wed, 02 Oct 2013 23:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ldk6y2qxtjoOf+fXy5XsAmlWAsNg7XZViByOW08VYmc=; b=FymmWgXM4qoxnqXFUxhd7Pe23W6H72TVnQRATvU+zAOK10hI670n/1M/LxpnwoO9Lx 5BsAk/V29qX3bZg3y9mFUuNjA5EszI8+PNHtvwQjHQAGOltf6NMxz3MBxIaEdvzkSTPp SGc5nVBN5EEli8MMJtnJgWIi2b8xGkwGLUnh0YBTsyxehnp7bLYN6L0m3RpWmVHb4Qj6 NH0yM6SH26aR+PxJo55vnjq3E5BiiN8gIhKvvuvW/OjRw5Zit9DYLeB8FYTjHT8NmiCc ZqPxNuYksjxGYuT1LCj8QUF+PsbeBCh6yLAO7P6LZl1H7cZCMxqRUlIeboU6YzXspAUq fL6w== X-Received: by 10.152.30.74 with SMTP id q10mr5531024lah.27.1380782243858; Wed, 02 Oct 2013 23:37:23 -0700 (PDT) Received: from [192.168.250.229] ([194.100.71.98]) by mx.google.com with ESMTPSA id b1sm4838044lah.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 23:37:23 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 3 Oct 2013 09:37:23 +0300 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] IETF88 in Vancouver X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 06:37:50 -0000 Folks, We have requested for 2.5h WG slot for IETF88. Folks who have WG items obviously need to prepare for a status update (slide or few). If you want to present some individual I-D or topic just lets the chairs know. The usual prioritization for presentation slots is FIFO with chartered topics having preference over non-chartered topics. Jouni & Lionel From internet-drafts@ietf.org Fri Oct 4 09:49:22 2013 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 D07B521F9AA7; Fri, 4 Oct 2013 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlN6nR739cAr; Fri, 4 Oct 2013 09:49:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5621F8D20; Fri, 4 Oct 2013 09:49:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004164922.12797.83595.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 09:49:22 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-20.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:49:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-20.txt Pages : 24 Date : 2013-10-04 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. It is meant as a guidelines document and therefore as informative in nature. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lionel.morand@orange.com Mon Oct 7 04:23:03 2013 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 4D1DA21E80FD for ; Mon, 7 Oct 2013 04:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEW7rdAptWe8 for ; Mon, 7 Oct 2013 04:22:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 017C721E8064 for ; Mon, 7 Oct 2013 04:22:57 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 919EB22C11B for ; Mon, 7 Oct 2013 13:22:56 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7484B27C053 for ; Mon, 7 Oct 2013 13:22:56 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 7 Oct 2013 13:22:56 +0200 From: To: "dime@ietf.org" Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: AQHOw08BbYQEft+0w0G074OEjvgG8ZnpF7wQ Date: Mon, 7 Oct 2013 11:22:55 +0000 Message-ID: <8966_1381144976_52529990_8966_1146_1_6B7134B31289DC4FAF731D844122B36E284672@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E284672PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: [Dime] TR: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 11:23:03 -0000 --_000_6B7134B31289DC4FAF731D844122B36E284672PEXCVZYM13corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBGb2xrcywNCg0KVGhpcyBpcyBhbiBpbXBvcnRhbnQgcHJvY2VzcyB3aXRoaW4gSUVURi4N ClBsZWFzZSBmZWVsIGZyZWUgdG8gYWN0aXZlbHkgY29udHJpYnV0ZSBieSBub21pbmF0aW5nIHNv bWUgcG90ZW50aWFsIGNhbmRpZGF0ZXMuDQoNClJlZ2FyZHMsDQoNCkpvdW5pICYgTGlvbmVsDQoN Cg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDoNCg0KTk9NQ09N IDIwMTMgLSBTZWNvbmQgQ2FsbCBmb3IgTm9taW5hdGlvbnMgLSB0d28gd2Vla3MgbGVmdA0KDQpE YXRlOg0KDQpGcmksIDQgT2N0IDIwMTMgMTA6MzE6NDkgLTA3MDANCg0KRnJvbToNCg0KTm9tQ29t IENoYWlyIDIwMTMgPG5vbWNvbS1jaGFpci0yMDEzQGlldGYub3JnPjxtYWlsdG86bm9tY29tLWNo YWlyLTIwMTNAaWV0Zi5vcmc+DQoNClJlcGx5LVRvOg0KDQo8aWV0ZkBpZXRmLm9yZz48bWFpbHRv OmlldGZAaWV0Zi5vcmc+LCA8Tm9tY29tQGlldGZhLmFtc2wuY29tPjxtYWlsdG86Tm9tY29tQGll dGZhLmFtc2wuY29tPiwgPENoYWlyQGlldGZhLmFtc2wuY29tPjxtYWlsdG86Q2hhaXJAaWV0ZmEu YW1zbC5jb20+LCA8IjIwMTMgPG5vbWNvbS1jaGFpci0yMDEzIkBpZXRmLm9yZz4NCg0KVG86DQoN CklFVEYgQW5ub3VuY2VtZW50IExpc3QgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+PG1haWx0bzpp ZXRmLWFubm91bmNlQGlldGYub3JnPg0KDQpDQzoNCg0KSUVURiBEaXNjdXNzIExpc3QgPGlldGZA aWV0Zi5vcmc+PG1haWx0bzppZXRmQGlldGYub3JnPg0KDQoNCg0KTm9taW5hdGlvbnMgZm9yIHRo ZSBJRVNHLCBJQUIsIGFuZCBJQU9DIGFyZSBkdWUgdG8gdGhlIE5vbWNvbSBieSBGcmlkYXksIDE4 IE9jdG9iZXIsIDIwMTMuDQoNCg0KDQpJcyB0aGVyZSBzb21lb25lIHlvdSB3b3JrIHdpdGggYXQg SUVURiB3aG8gaGFzIGxlYWRlcnNoaXAgcG90ZW50aWFsIGFuZCBhIGdyb3dpbmcgdHJhY2sgcmVj b3JkPyBQbGVhc2UgcmVhZCB0aGUgTm9tY29tIGNhbGwgZm9yIG5vbWluYXRpb25zIGFuZCBjb25z aWRlciBub21pbmF0aW5nIGhlciBvciBoaW0uIE9yIHNldmVyYWwgZm9sa3MhIERlYWRsaW5lIGZv ciBub21pbmF0aW9ucyBpcyBPY3RvYmVyIDE4LiAgTm9taW5hdGUgc29vbiB0byBnaXZlIHlvdXIg bm9taW5lZShzKSBwbGVudHkgdGltZSB0byBmaWxsIGluIHRoZSBxdWVzdGlvbm5haXJlLiBJbmZv cm1hdGlvbiBhYm91dCB0aGUgZGVzaXJlZCBleHBlcnRpc2UgZm9yIHBvc2l0aW9ucyBpcyBoZXJl Og0KDQogICAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTMv ZXhwZXJ0aXNlDQoNCg0KDQpMb3RzIG1vcmUsIGluY2x1ZGluZyB3aGljaCBwb3NpdGlvbnMgYXJl IG9wZW4sIGhvdyB0byBtYWtlIGEgbm9taW5hdGlvbiwgYW5kIGhvdyB0bw0KDQpzZW5kIHVzIHlv dXIgZmVlZGJhY2sgb24gdGhlIGRlc2lyZWQgZXhwZXJ0aXNlLCBmb2xsb3dzLg0KDQoNCg0KSUVU RmVycywgbGV0J3MgaGVhciBmcm9tIHlvdSEgIE1ha2Ugbm9taW5hdGlvbnMsIGFjY2VwdCBub21p bmF0aW9ucyENCg0KDQoNCklmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgYWJvdXQgdGhlIHByb2Nl c3MsIGZlZWwgZnJlZSB0byBnZXQgaW4gdG91Y2ggd2l0aCBtZS4NCg0KDQoNCkJlc3QgcmVnYXJk cywNCg0KDQoNCkFsbGlzb24gZm9yIHRoZSBOb21jb20NCg0KDQoNCkFsbGlzb24gTWFua2luDQoN Ck5vbWNvbSBDaGFpciAyMDEzLTE0DQoNCg0KDQotLS0tLSBUaGUgSW5mbyBZb3UgTmVlZCBmb3Ig Tm9taW5hdGluZyAtLS0tLQ0KDQoNCg0KVGhlIDIwMTMtMTQgTm9taW5hdGluZyBDb21taXR0ZWUg KE5vbWNvbSkgaXMgc2Vla2luZyBub21pbmF0aW9ucw0KDQpmcm9tIG5vdyB1bnRpbCBPY3RvYmVy IDE4LCAyMDEzLiBUaGUgb3BlbiBwb3NpdGlvbnMgYmVpbmcgY29uc2lkZXJlZA0KDQpieSB0aGlz IHllYXIncyBOb21jb20gY2FuIGJlIGZvdW5kIGxhdGVyIGluIHRoaXMgc2VjdGlvbiwgYW5kIGFs c28gb24NCg0KdGhpcyB5ZWFyJ3MgTm9tY29tIHdlYnNpdGU6DQoNCg0KDQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzLw0KDQoNCg0KTm9taW5hdGlvbnMgbWF5IGJlIG1h ZGUgYnkgc2VsZWN0aW5nIHRoZSBOb21pbmF0ZSBsaW5rIGF0IHRoZSB0b3Agb2YNCg0KdGhlIE5v bWNvbSAyMDEzIGhvbWUgcGFnZSwgb3IgYnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6DQoN Cg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL25vbWluYXRlLw0K DQoNCg0KTm90ZSB0aGF0IG5vbWluYXRpb25zIG1hZGUgdXNpbmcgdGhlIHdlYiB0b29sIHJlcXVp cmUgYW4gaWV0Zi5vcmcNCg0KZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91IGNhbiBjcmVhdGUgYSBk YXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50DQoNCmlmIHlvdSBkb24ndCBoYXZlIG9uZSBhbHJl YWR5IGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KDQoNCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvDQoNCg0KDQpOb21pbmF0aW9ucyBtYXkgYWxz byBiZSBtYWRlIGJ5IGVtYWlsIHRvIG5vbWNvbTEzIGF0IGlldGYub3JnLg0KDQpJZiB5b3Ugbm9t aW5hdGUgYnkgZW1haWwsIHBsZWFzZSBpbmNsdWRlIHRoZSB3b3JkICJOb21pbmF0ZSIgaW4gdGhl IFN1YmplY3QNCg0KYW5kIGluZGljYXRlIGluIHRoZSBlbWFpbCB3aG8gaXMgYmVpbmcgbm9taW5h dGVkLCB0aGVpciBlbWFpbCBhZGRyZXNzICh0bw0KDQpjb25maXJtIGFjY2VwdGFuY2Ugb2YgdGhl IG5vbWluYXRpb24pLCBhbmQgdGhlIHBvc2l0aW9uIGZvciB3aGljaCB5b3UNCg0KYXJlIG1ha2lu ZyB0aGUgbm9taW5hdGlvbi4gSWYgeW91IHVzZSBlbWFpbCwgcGxlYXNlIHVzZSBhIHNlcGFyYXRl IGVtYWlsIGZvcg0KDQplYWNoIHBlcnNvbiB5b3Ugbm9taW5hdGUsIGFuZCBmb3IgZWFjaCBwb3Np dGlvbiAoaWYgeW91IGFyZSBub21pbmF0aW5nIG9uZQ0KDQpwZXJzb24gZm9yIG11bHRpcGxlIHBv c2l0aW9ucykuDQoNCg0KDQpTZWxmLW5vbWluYXRpb24gaXMgd2VsY29tZSEgIE5vIG5lZWQgdG8g YmUgc2h5Lg0KDQoNCg0KTm9tY29tIDIwMTMtMTQgd2lsbCBmb2xsb3cgdGhlIHBvbGljeSBmb3Ig Ik9wZW4gRGlzY2xvc3VyZSBvZiBXaWxsaW5nDQoNCk5vbWluZWVzIiBkZXNjcmliZWQgaW4gUkZD IDU2ODAuICBBcyBzdGF0ZWQgaW4gUkZDIDU2ODA6ICJUaGUgbGlzdCBvZg0KDQpub21pbmVlcyB3 aWxsaW5nIHRvIGJlIGNvbnNpZGVyZWQgZm9yIHBvc2l0aW9ucyB1bmRlciByZXZpZXcgaW4gdGhl DQoNCmN1cnJlbnQgTm9tY29tIGN5Y2xlIGlzIG5vdCBjb25maWRlbnRpYWwiLiBXaWxsaW5nIG5v bWluZWVzIGZvciBlYWNoDQoNCnBvc2l0aW9uIHdpbGwgYmUgbGlzdGVkIGluIGEgcHVibGljbHkg YWNjZXNzaWJsZSB3YXkgLSBhbnlvbmUgd2l0aCBhDQoNCmRhdGF0cmFja2VyIGFjY291bnQgbWF5 IGFjY2VzcyB0aGUgbGlzdHMuICBJbiBhbGwgb3RoZXIgd2F5cywgdGhlDQoNCmNvbmZpZGVudGlh bGl0eSByZXF1aXJlbWVudHMgb2YgUkZDIDM3NzcvQkNQMTAgcmVtYWluIGluIGVmZmVjdC4gIEFs bA0KDQpmZWVkYmFjayBhbmQgYWxsIE5vbWNvbSBkZWxpYmVyYXRpb25zIHdpbGwgcmVtYWluIGNv bmZpZGVudGlhbCBhbmQgd2lsbA0KDQpub3QgYmUgZGlzY2xvc2VkLg0KDQoNCg0KSW4gb3JkZXIg dG8gZW5zdXJlIHRpbWUgdG8gY29sbGVjdCBzdWZmaWNpZW50IGNvbW11bml0eSBmZWVkYmFjayBh Ym91dA0KDQplYWNoIG9mIHRoZSB3aWxsaW5nIG5vbWluZWVzLCBub21pbmF0aW9ucyBtdXN0IGJl IHJlY2VpdmVkIGJ5IHRoZQ0KDQpOb21jb20gb24gb3IgYmVmb3JlIE9jdG9iZXIgMTgsIDIwMTMu ICBQbGVhc2Ugc3VibWl0IHlvdXIgbm9taW5hdGlvbnMNCg0KYXMgZWFybHkgYXMgcG9zc2libGUg Zm9yIHRoZSBzYWtlIG9mIHlvdXIgbm9taW5lZXMsIGFzIHdlJ3ZlIHNldCB0aGUNCg0KcXVlc3Rp b25uYWlyZSBzdWJtaXNzaW9uIGRlYWRsaW5lIGZvciBPY3RvYmVyIDI1LCAyMDEzLg0KDQoNCg0K VGhlIGxpc3Qgb2YgcGVvcGxlIGFuZCBwb3N0cyB3aG9zZSB0ZXJtcyBlbmQgd2l0aCB0aGUgTWFy Y2ggMjAxNCBJRVRGIG1lZXRpbmcsDQoNCmFuZCB0aHVzIHRoZSBwb3NpdGlvbnMgZm9yIHdoaWNo IHdlIGFyZSBhY2NlcHRpbmcgbm9taW5hdGlvbnM6DQoNCg0KDQpJQU9DDQoNCkNocmlzIEdyaWZm aXRocw0KDQoNCg0KSUFCDQoNCkJlcm5hcmQgQWJvYmENCg0KTWFyYyBCbGFuY2hldA0KDQpSb3Nz IENhbGxvbg0KDQpFbGlvdCBMZWFyDQoNCkhhbm5lcyBUc2Nob2ZlbmlnDQoNCg0KDQpJRVNHDQoN CkJhcnJ5IExlaWJhIChBcHBsaWNhdGlvbnMpDQoNCkJyaWFuIEhhYmVybWFuIChJbnRlcm5ldCkN Cg0KQmVub2l0IENsYWlzZSAoT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCkNCg0KR29uemFsbyBD YW1hcmlsbG8gKFJBSSkNCg0KU3Rld2FydCBCcnlhbnQgKFJvdXRpbmcpDQoNClNlYW4gVHVybmVy IChTZWN1cml0eSkNCg0KTWFydGluIFN0aWVtZXJsaW5nIChUcmFuc3BvcnQpDQoNCg0KDQpQbGVh c2UgYmUgcmVzb3VyY2VmdWwgaW4gaWRlbnRpZnlpbmcgcG9zc2libGUgY2FuZGlkYXRlcyBmb3Ig dGhlc2UNCg0KcG9zaXRpb25zLCBhcyBkZXZlbG9waW5nIG91ciB0YWxlbnQgaXMgYSB2ZXJ5IGNy dWNpYWwgcmVxdWlyZW1lbnQgZm9yDQoNCnRoZSBJRVRGLiAgQWxzbywgcGxlYXNlIGdpdmUgc2Vy aW91cyBjb25zaWRlcmF0aW9uIHRvIGFjY2VwdGluZyBub21pbmF0aW9ucw0KDQp5b3UgcmVjZWl2 ZS4NCg0KDQoNClRoZSBzdW1tYXJpZXMgb2YgdGhlIGRlc2lyZWQgZXhwZXJ0aXNlIGZvciB0aGUg cG9zaXRpb25zLCBkZXZlbG9wZWQgYnkgdGhlDQoNCnJlc3BlY3RpdmUgYm9kaWVzLCBhcmUgZm91 bmQgYXQ6DQoNCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL2V4 cGVydGlzZS8NCg0KDQoNCkluIGFkZGl0aW9uIHRvIG5vbWluYXRpb25zLCB0aGUgTm9tY29tIHNl ZWtzIGNvbW11bml0eSBpbnB1dCBvbg0KDQp0aGUgcG9zaXRpb25zIHRoZW1zZWx2ZXMuICBXZSBu ZWVkIGFuZCB3ZWxjb21lIHRoZSBjb21tdW5pdHkncw0KDQp2aWV3cyBhbmQgaW5wdXQgb24gdGhl IGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0aW9uLiBJZiB5b3UNCg0KaGF2ZSBpZGVhcyBvbiB0 aGUgcG9zaXRpb25zJyByZXNwb25zaWJpbGl0aWVzIChtb3JlLCBsZXNzLA0KDQpkaWZmZXJlbnQp LCBwbGVhc2UgbGV0IHVzIGtub3cuICBZb3UgY2FuIHNlbmQgdXMgZW1haWwgYWJvdXQgdGhpcyB0 bw0KDQpub21jb20xMyBhdCBpZXRmLm9yZywgYW5kIHdlIHdpbGwgdXNlIHRoaXMgZmVlZGJhY2sg YWN0aXZlbHkuDQoNCg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCBpbiBub21pbmF0aW5nIGEg Z3JlYXQgcG9vbCBvZiBzdHJvbmcgYW5kIGludGVyZXN0aW5nDQoNCm5vbWluZWVzIQ0KDQoNCg0K DQoNCg0KDQouDQoNCg0KDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_6B7134B31289DC4FAF731D844122B36E284672PEXCVZYM13corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy IDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1 biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVw dCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBGb2xrcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhbiBpbXBvcnRhbnQgcHJvY2Vz cyB3aXRoaW4gSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlBsZWFzZSBmZWVsIGZyZWUgdG8gYWN0aXZlbHkgY29udHJpYnV0ZSBieSBub21pbmF0aW5nIHNv bWUgcG90ZW50aWFsIGNhbmRpZGF0ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Sm91bmkgJmFt cDsgTGlvbmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBj bSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl PSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+U3ViamVjdDoNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Tk9NQ09N IDIwMTMgLSBTZWNvbmQgQ2FsbCBmb3IgTm9taW5hdGlvbnMgLSB0d28gd2Vla3MgbGVmdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxp Z249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5EYXRlOg0KPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQg c3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5GcmksIDQgT2N0IDI8L3NwYW4+MDEzIDEwOjMxOjQ5IC0wNzAwPG86 cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0 b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwv bzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob21Db20gQ2hhaXIgMjAxMyA8YSBocmVmPSJtYWlsdG86 bm9tY29tLWNoYWlyLTIwMTNAaWV0Zi5vcmciPg0KJmx0O25vbWNvbS1jaGFpci0yMDEzQGlldGYu b3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxi PlJlcGx5LVRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86 aWV0ZkBpZXRmLm9yZyI+Jmx0O2lldGZAaWV0Zi5vcmcmZ3Q7PC9hPiwgPGEgaHJlZj0ibWFpbHRv Ok5vbWNvbUBpZXRmYS5hbXNsLmNvbSI+DQombHQ7Tm9tY29tQGlldGZhLmFtc2wuY29tJmd0Ozwv YT4sIDxhIGhyZWY9Im1haWx0bzpDaGFpckBpZXRmYS5hbXNsLmNvbSI+Jmx0O0NoYWlyQGlldGZh LmFtc2wuY29tJmd0OzwvYT4sICZsdDsmcXVvdDsyMDEzICZsdDtub21jb20tY2hhaXItMjAxMyZx dW90O0BpZXRmLm9yZyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxiPlRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JRVRGIEFubm91bmNlbWVu dCBMaXN0IDxhIGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIj4NCiZsdDtpZXRm LWFubm91bmNlQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQt YWxpZ246cmlnaHQiPjxiPkNDOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JRVRGIERp c2N1c3MgTGlzdCA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+Jmx0O2lldGZAaWV0Zi5v cmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cHJlPk5vbWluYXRpb25zIGZvciB0aGUgSUVTRywgSUFCLCBh bmQgSUFPQyBhcmUgZHVlIHRvIHRoZSBOb21jb20gYnkgRnJpZGF5LCAxOCBPY3RvYmVyLCAyMDEz LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklz IHRoZXJlIHNvbWVvbmUgeW91IHdvcmsgd2l0aCBhdCBJRVRGIHdobyBoYXMgbGVhZGVyc2hpcCBw b3RlbnRpYWwgYW5kIGEgZ3Jvd2luZyB0cmFjayByZWNvcmQ/IFBsZWFzZSByZWFkIHRoZSBOb21j b20gY2FsbCBmb3Igbm9taW5hdGlvbnMgYW5kIGNvbnNpZGVyIG5vbWluYXRpbmcgaGVyIG9yIGhp bS4gT3Igc2V2ZXJhbCBmb2xrcyEgRGVhZGxpbmUgZm9yIG5vbWluYXRpb25zIGlzIE9jdG9iZXIg MTguJm5ic3A7IE5vbWluYXRlIHNvb24gdG8gZ2l2ZSB5b3VyIG5vbWluZWUocykgcGxlbnR5IHRp bWUgdG8gZmlsbCBpbiB0aGUgcXVlc3Rpb25uYWlyZS4gSW5mb3JtYXRpb24gYWJvdXQgdGhlIGRl c2lyZWQgZXhwZXJ0aXNlIGZvciBwb3NpdGlvbnMgaXMgaGVyZTogPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21j b20vMjAxMy9leHBlcnRpc2UiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIw MTMvZXhwZXJ0aXNlPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPkxvdHMgbW9yZSwgaW5jbHVkaW5nIHdoaWNoIHBvc2l0aW9ucyBhcmUgb3Bl biwgaG93IHRvIG1ha2UgYSBub21pbmF0aW9uLCBhbmQgaG93IHRvIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnNlbmQgdXMgeW91ciBmZWVkYmFjayBvbiB0aGUgZGVzaXJlZCBleHBlcnRpc2UsIGZv bGxvd3MuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+SUVURmVycywgbGV0J3MgaGVhciBmcm9tIHlvdSEmbmJzcDsgTWFrZSBub21pbmF0aW9ucywg YWNjZXB0IG5vbWluYXRpb25zITxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPklmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgYWJvdXQgdGhlIHByb2Nl c3MsIGZlZWwgZnJlZSB0byBnZXQgaW4gdG91Y2ggd2l0aCBtZS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWxsaXNvbiBmb3Ig dGhlIE5vbWNvbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPkFsbGlzb24gTWFua2luIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5vbWNvbSBDaGFp ciAyMDEzLTE0PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+LS0tLS0gVGhlIEluZm8gWW91IE5lZWQgZm9yIE5vbWluYXRpbmcgLS0tLS08bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgMjAxMy0x NCBOb21pbmF0aW5nIENvbW1pdHRlZSAoTm9tY29tKSBpcyBzZWVraW5nIG5vbWluYXRpb25zPG86 cD48L286cD48L3ByZT4NCjxwcmU+ZnJvbSBub3cgdW50aWwgT2N0b2JlciAxOCwgMjAxMy4gVGhl IG9wZW4gcG9zaXRpb25zIGJlaW5nIGNvbnNpZGVyZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5i eSB0aGlzIHllYXIncyBOb21jb20gY2FuIGJlIGZvdW5kIGxhdGVyIGluIHRoaXMgc2VjdGlvbiwg YW5kIGFsc28gb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzIHllYXIncyBOb21jb20gd2Vi c2l0ZTogPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy8iPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTMvPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5vbWluYXRpb25zIG1heSBi ZSBtYWRlIGJ5IHNlbGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9wIG9mPG86cD48 L286cD48L3ByZT4NCjxwcmU+dGhlIE5vbWNvbSAyMDEzIGhvbWUgcGFnZSwgb3IgYnkgdmlzaXRp bmcgdGhlIGZvbGxvd2luZyBVUkw6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bm9tY29tLzIwMTMvbm9taW5hdGUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNv bS8yMDEzL25vbWluYXRlLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT5Ob3RlIHRoYXQgbm9taW5hdGlvbnMgbWFkZSB1c2luZyB0aGUgd2Vi IHRvb2wgcmVxdWlyZSBhbiBpZXRmLm9yZyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kYXRhdHJh Y2tlciBhY2NvdW50LiBZb3UgY2FuIGNyZWF0ZSBhIGRhdGF0cmFja2VyIGlldGYub3JnIGFjY291 bnQgPG86cD48L286cD48L3ByZT4NCjxwcmU+aWYgeW91IGRvbid0IGhhdmUgb25lIGFscmVhZHkg YnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBVUkw6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Fj Y291bnRzL2NyZWF0ZS88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+Tm9taW5hdGlvbnMgbWF5IGFsc28gYmUgbWFkZSBieSBlbWFpbCB0byBu b21jb20xMyBhdCBpZXRmLm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3Ugbm9taW5h dGUgYnkgZW1haWwsIHBsZWFzZSBpbmNsdWRlIHRoZSB3b3JkICZxdW90O05vbWluYXRlJnF1b3Q7 IGluIHRoZSBTdWJqZWN0PG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kIGluZGljYXRlIGluIHRo ZSBlbWFpbCB3aG8gaXMgYmVpbmcgbm9taW5hdGVkLCB0aGVpciBlbWFpbCBhZGRyZXNzICh0bzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbmZpcm0gYWNjZXB0YW5jZSBvZiB0aGUgbm9taW5hdGlv biksIGFuZCB0aGUgcG9zaXRpb24gZm9yIHdoaWNoIHlvdTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmFyZSBtYWtpbmcgdGhlIG5vbWluYXRpb24uIElmIHlvdSB1c2UgZW1haWwsIHBsZWFzZSB1c2Ug YSBzZXBhcmF0ZSBlbWFpbCBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lYWNoIHBlcnNvbiB5 b3Ugbm9taW5hdGUsIGFuZCBmb3IgZWFjaCBwb3NpdGlvbiAoaWYgeW91IGFyZSBub21pbmF0aW5n IG9uZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBlcnNvbiBmb3IgbXVsdGlwbGUgcG9zaXRpb25z KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5T ZWxmLW5vbWluYXRpb24gaXMgd2VsY29tZSEmbmJzcDsgTm8gbmVlZCB0byBiZSBzaHkuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Tm9tY29tIDIw MTMtMTQgd2lsbCBmb2xsb3cgdGhlIHBvbGljeSBmb3IgJnF1b3Q7T3BlbiBEaXNjbG9zdXJlIG9m IFdpbGxpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ob21pbmVlcyZxdW90OyBkZXNjcmliZWQg aW4gUkZDIDU2ODAuJm5ic3A7IEFzIHN0YXRlZCBpbiBSRkMgNTY4MDogJnF1b3Q7VGhlIGxpc3Qg b2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ub21pbmVlcyB3aWxsaW5nIHRvIGJlIGNvbnNpZGVy ZWQgZm9yIHBvc2l0aW9ucyB1bmRlciByZXZpZXcgaW4gdGhlPG86cD48L286cD48L3ByZT4NCjxw cmU+Y3VycmVudCBOb21jb20gY3ljbGUgaXMgbm90IGNvbmZpZGVudGlhbCZxdW90Oy4gV2lsbGlu ZyBub21pbmVlcyBmb3IgZWFjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBvc2l0aW9uIHdpbGwg YmUgbGlzdGVkIGluIGEgcHVibGljbHkgYWNjZXNzaWJsZSB3YXkgLSBhbnlvbmUgd2l0aCBhPG86 cD48L286cD48L3ByZT4NCjxwcmU+ZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkgYWNjZXNzIHRoZSBs aXN0cy4mbmJzcDsgSW4gYWxsIG90aGVyIHdheXMsIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5jb25maWRlbnRpYWxpdHkgcmVxdWlyZW1lbnRzIG9mIFJGQyAzNzc3L0JDUDEwIHJlbWFpbiBp biBlZmZlY3QuJm5ic3A7IEFsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZlZWRiYWNrIGFuZCBh bGwgTm9tY29tIGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50aWFsIGFuZCB3aWxs PG86cD48L286cD48L3ByZT4NCjxwcmU+bm90IGJlIGRpc2Nsb3NlZC4mbmJzcDsgPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SW4gb3JkZXIgdG8g ZW5zdXJlIHRpbWUgdG8gY29sbGVjdCBzdWZmaWNpZW50IGNvbW11bml0eSBmZWVkYmFjayBhYm91 dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmVhY2ggb2YgdGhlIHdpbGxpbmcgbm9taW5lZXMsIG5v bWluYXRpb25zIG11c3QgYmUgcmVjZWl2ZWQgYnkgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pk5vbWNvbSBvbiBvciBiZWZvcmUgT2N0b2JlciAxOCwgMjAxMy4mbmJzcDsgUGxlYXNlIHN1Ym1p dCB5b3VyIG5vbWluYXRpb25zJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFzIGVhcmx5 IGFzIHBvc3NpYmxlIGZvciB0aGUgc2FrZSBvZiB5b3VyIG5vbWluZWVzLCBhcyB3ZSd2ZSBzZXQg dGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnF1ZXN0aW9ubmFpcmUgc3VibWlzc2lvbiBkZWFk bGluZSBmb3IgT2N0b2JlciAyNSwgMjAxMy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgbGlzdCBvZiBwZW9wbGUgYW5kIHBvc3RzIHdob3Nl IHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaCAyMDE0IElFVEYgbWVldGluZywgPG86cD48L286cD48 L3ByZT4NCjxwcmU+YW5kIHRodXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggd2UgYXJlIGFjY2Vw dGluZyBub21pbmF0aW9uczombmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+SUFPQzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNocmlzIEdy aWZmaXRoczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPklBQjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJlcm5hcmQgQWJvYmE8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5NYXJjIEJsYW5jaGV0PG86cD48L286cD48L3ByZT4NCjxwcmU+Um9zcyBDYWxs b248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5FbGlvdCBMZWFyPG86cD48L286cD48L3ByZT4NCjxw cmU+SGFubmVzIFRzY2hvZmVuaWc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT5JRVNHPG86cD48L286cD48L3ByZT4NCjxwcmU+QmFycnkgTGVpYmEg KEFwcGxpY2F0aW9ucyk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CcmlhbiBIYWJlcm1hbiAoSW50 ZXJuZXQpPG86cD48L286cD48L3ByZT4NCjxwcmU+QmVub2l0IENsYWlzZSAoT3BlcmF0aW9ucyBh bmQgTWFuYWdlbWVudCk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Hb256YWxvIENhbWFyaWxsbyAo UkFJKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN0ZXdhcnQgQnJ5YW50IChSb3V0aW5nKTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPlNlYW4gVHVybmVyIChTZWN1cml0eSk8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5NYXJ0aW4gU3RpZW1lcmxpbmcgKFRyYW5zcG9ydCk8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2UgYmUgcmVzb3VyY2VmdWwg aW4gaWRlbnRpZnlpbmcgcG9zc2libGUgY2FuZGlkYXRlcyBmb3IgdGhlc2U8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5wb3NpdGlvbnMsIGFzIGRldmVsb3Bpbmcgb3VyIHRhbGVudCBpcyBhIHZlcnkg Y3J1Y2lhbCByZXF1aXJlbWVudCBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgSUVURi4m bmJzcDsgQWxzbywgcGxlYXNlIGdpdmUgc2VyaW91cyBjb25zaWRlcmF0aW9uIHRvIGFjY2VwdGlu ZyBub21pbmF0aW9uczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnlvdSByZWNlaXZlLiZuYnNwOyA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUg c3VtbWFyaWVzIG9mIHRoZSBkZXNpcmVkIGV4cGVydGlzZSBmb3IgdGhlIHBvc2l0aW9ucywgZGV2 ZWxvcGVkIGJ5IHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXNwZWN0aXZlIGJvZGllcywg YXJlIGZvdW5kIGF0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIw MTMvZXhwZXJ0aXNlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy9l eHBlcnRpc2UvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPkluIGFkZGl0aW9uIHRvIG5vbWluYXRpb25zLCB0aGUgTm9tY29tIHNlZWtzIGNv bW11bml0eSBpbnB1dCBvbiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgcG9zaXRpb25zIHRo ZW1zZWx2ZXMuJm5ic3A7IFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11bml0eSdzIDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnZpZXdzIGFuZCBpbnB1dCBvbiB0aGUgam9icyB3aXRoaW4gZWFj aCBvcmdhbml6YXRpb24uIElmIHlvdSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5oYXZlIGlkZWFz IG9uIHRoZSBwb3NpdGlvbnMnIHJlc3BvbnNpYmlsaXRpZXMgKG1vcmUsIGxlc3MsIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPmRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4mbmJzcDsgWW91 IGNhbiBzZW5kIHVzIGVtYWlsIGFib3V0IHRoaXMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5u b21jb20xMyBhdCBpZXRmLm9yZywgYW5kIHdlIHdpbGwgdXNlIHRoaXMgZmVlZGJhY2sgYWN0aXZl bHkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ VGhhbmsgeW91IGZvciB5b3VyIGhlbHAgaW4gbm9taW5hdGluZyBhIGdyZWF0IHBvb2wgb2Ygc3Ry b25nIGFuZCBpbnRlcmVzdGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5vbWluZWVzITxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_6B7134B31289DC4FAF731D844122B36E284672PEXCVZYM13corpora_-- From jouni.nospam@gmail.com Mon Oct 7 06:02:04 2013 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 CE85421E81A8 for ; Mon, 7 Oct 2013 06:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8GTCGIKzc41 for ; Mon, 7 Oct 2013 06:02:04 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1421E8191 for ; Mon, 7 Oct 2013 06:02:02 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id es20so5420776lab.24 for ; Mon, 07 Oct 2013 06:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=/JmdBMqDjA3wyUwgr5RiXJca8iNSHk1eHVi5IF+GF/U=; b=iIVmYYeIpveTYi8JIhkL/uTg8honCWc8Zmbds0ZV/WFVINKjcP/4u9oyGEKybctl/k RZbT2eHUCsus6MA0BjAapLLUkdsXQiwhuDQyOTQsuNkc0sncy1lyUjaFrR4ZA9L9PsDP tYErNpM8GJFCbMBq9mUava4riVyfvXtWGWfeCrX4N9nUwZcjEv3WEeI4rAV8k9nePI/l A3APsMxF+sEjuNBi07eCFKM1n0tGmMBuUNwI2LaTRdxp53hfn8kWEYFlM3dG/c7eq/i0 d5pVVq6OXu7BychJxoucn8+5nXHwJ/iTGbVyCda0amlMobGi2hUWkW665lC3xkrQssgM TBrg== X-Received: by 10.112.190.1 with SMTP id gm1mr2099548lbc.30.1381150922100; Mon, 07 Oct 2013 06:02:02 -0700 (PDT) Received: from [192.168.250.211] ([194.100.71.98]) by mx.google.com with ESMTPSA id e4sm18951424lba.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 06:02:01 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Oct 2013 16:01:59 +0300 References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> To: "dime@ietf.org" Message-Id: <81CE2414-4812-43B3-8CEB-9AB1DE54E3B2@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 13:02:04 -0000 FYI Begin forwarded message: > From: NomCom Chair 2013 > Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left > Date: October 4, 2013 8:31:49 PM GMT+03:00 > To: IETF Announcement List > Cc: IETF Discuss List > Reply-To: ietf@ietf.org, Nomcom@ietfa.amsl.com, Chair@ietfa.amsl.com, = "2013 =20 > Nominations for the IESG, IAB, and IAOC are due to the Nomcom by = Friday, 18 October, 2013. >=20 > Is there someone you work with at IETF who has leadership potential = and a growing track record? Please read the Nomcom call for nominations = and consider nominating her or him. Or several folks! Deadline for = nominations is October 18. Nominate soon to give your nominee(s) plenty = time to fill in the questionnaire. Information about the desired = expertise for positions is here:=20 > https://datatracker.ietf.org/nomcom/2013/expertise >=20 > Lots more, including which positions are open, how to make a = nomination, and how to=20 > send us your feedback on the desired expertise, follows. >=20 > IETFers, let's hear from you! Make nominations, accept nominations! >=20 > If you have any questions about the process, feel free to get in touch = with me. >=20 > Best regards, >=20 > Allison for the Nomcom >=20 > Allison Mankin=20 > Nomcom Chair 2013-14 >=20 > ----- The Info You Need for Nominating ----- >=20 > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website:=20 >=20 > https://datatracker.ietf.org/nomcom/2013/ >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL:=20 >=20 > https://datatracker.ietf.org/nomcom/2013/nominate/ >=20 > Note that nominations made using the web tool require an ietf.org=20 > datatracker account. You can create a datatracker ietf.org account=20 > if you don't have one already by visiting the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the = Subject > and indicate in the email who is being nominated, their email address = (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate = email for > each person you nominate, and for each position (if you are nominating = one > person for multiple positions). >=20 > Self-nomination is welcome! No need to be shy. >=20 > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the=20 > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and = will > not be disclosed. =20 >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the=20 > Nomcom on or before October 18, 2013. Please submit your nominations =20= > as early as possible for the sake of your nominees, as we've set the=20= > questionnaire submission deadline for October 25, 2013. >=20 > The list of people and posts whose terms end with the March 2014 IETF = meeting,=20 > and thus the positions for which we are accepting nominations: =20 >=20 > IAOC > Chris Griffiths >=20 > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting = nominations > you receive. =20 >=20 > The summaries of the desired expertise for the positions, developed by = the=20 > respective bodies, are found at: >=20 > https://datatracker.ietf.org/nomcom/2013/expertise/ >=20 > In addition to nominations, the Nomcom seeks community input on=20 > the positions themselves. We need and welcome the community's=20 > views and input on the jobs within each organization. If you=20 > have ideas on the positions' responsibilities (more, less,=20 > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. >=20 > Thank you for your help in nominating a great pool of strong and = interesting > nominees! >=20 >=20 >=20 From isj-dime@i1.dk Mon Oct 7 06:35:03 2013 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 CDE0D21E80AB for ; Mon, 7 Oct 2013 06:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAD_CREDIT=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBK15FOKg6tG for ; Mon, 7 Oct 2013 06:35:02 -0700 (PDT) Received: from i1.dk (isjsys5-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:20d:93ff:fe73:ac12]) by ietfa.amsl.com (Postfix) with ESMTP id 30BEE21E80A6 for ; Mon, 7 Oct 2013 06:35:01 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 4B4AD5C008E for ; Mon, 7 Oct 2013 15:34:57 +0200 (CEST) Received: from isjsys.int.i1.dk (unknown [IPv6:2001:16d8:dd31:1:e90c:94f7:d1b4:faed]) by i1.dk (Postfix) with ESMTP for ; Mon, 7 Oct 2013 15:34:57 +0200 (CEST) Received: from isjsys.int.i1.dk (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id 23AE326F2D for ; Mon, 7 Oct 2013 15:34:57 +0200 (CEST) From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= To: "dime@ietf.org" Date: Mon, 07 Oct 2013 15:34:57 +0200 Message-ID: <1720276.jsW5J3PGYs@isjsys.int.i1.dk> User-Agent: KMail/4.10.5 (Linux/3.7.10-1.16-desktop; KDE/4.10.5; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [Dime] Diameter Credit-Control/3GPP Gy: FUI and Result-Code X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 13:35:03 -0000 I'm doing some integration toward Gy client (PCEF), and encountered an unclear area. I'm not sure if it is unclear in RFC 4006 or the 3GPP TS32.299 or both. Scenario: A user logs on. The user has no credit left for a rating-group 42. CCR-initial and CCA-initial: Nothing interesting. In Gy it is typically just "empty" requests for the purpose of registering the user session. The user then attempts to use rating-group 32: CCR-update: Multiple-Services-Credit-Control { Rating-Group = 42 Requested-Service-Unit { } } to which the OCS (Gy server) would normally respond: CCA-update: Result-Code = 2001 (success) Multiple-Services-Credit-Control { Rating-Group = 42 Result-Code = 4012 (credit-limit-reached) Final-Unit-Indication { ... } } However, the Gy specification says that a zero-grant is needed, which to me sounds a bit odd, but nevertheless: Result-Code = 2001 (success) Multiple-Services-Credit-Control { Rating-Group = 42 Result-Code = 4012 (credit-limit-reached) Granted-Service-Unit { CC-Total-Octets = 0 } Final-Unit-Indication { ... } } Now, the Gy client vendor says that the result-code inside the MSCC must be 2001 (success). It sort of makes sense because there is a grant. But that made me wonder: In which case would result-code=4012 make sense? Is it just 3GPP who has "mangled" diameter-credit-control in the Gy application? Regards, Ivan From iesg-secretary@ietf.org Mon Oct 7 14:19:12 2013 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 3A6C011E8135; Mon, 7 Oct 2013 14:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpmx7KPCsu0x; Mon, 7 Oct 2013 14:19:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 649B011E8177; Mon, 7 Oct 2013 14:19:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007211908.30013.95641.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 14:19:08 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Realm-Based Redirection In Diameter' to Proposed Standard (draft-ietf-dime-realm-based-redirect-13.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 21:19:12 -0000 The IESG has approved the following document: - 'Realm-Based Redirection In Diameter' (draft-ietf-dime-realm-based-redirect-13.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/ Technical Summary The Diameter protocol allows a Diameter redirect agent to return to the message sender one or more individual hosts as destinations of the redirected message. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. Working Group Summary The working group reached a consensus on the document. There are existing Service requirements for such a mechanism and the document is the result of the discussion between Diameter experts. The document has been reviewed several times, with no major issues raised as soon as the document was stable. Document Quality The proposed mechanism is a slight modification of the existing mechanism defined in the Diameter base protocol (RFC 6733). The technical content of this document relies then tightly to the existing standard specification. The problem statement has been discussed between experts inside a design team discussing Diameter enhancements and the resulting document is aligned with the output of this discussion. Several reviews of the document have been performed and the last version captures the technical agreement reached inside the Dime WG. Personnel Lionel MORAND is the document shepherd. The responsible area director is Benoit Claise. The IANA Expert(s) for the registries in this document are Lionel Morand (primary) and Jouni Korhonen (secondary). From maria.cruz.bartolome@ericsson.com Thu Oct 17 08:13:27 2013 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 3255711E826F for ; Thu, 17 Oct 2013 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdQ6x7fsEpcA for ; Thu, 17 Oct 2013 08:13:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 637FD11E820C for ; Thu, 17 Oct 2013 08:13:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-90-525ffe8a6ce0 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 25.74.16099.A8EFF525; Thu, 17 Oct 2013 17:13:15 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.29]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 17 Oct 2013 17:13:14 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [DIME] number of transport connections among two Diameter peers Thread-Index: Ac7LS13n3AMba1KRQ9+N3shpOAyalg== Date: Thu, 17 Oct 2013 15:13:14 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920DF89F@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920DF89FESESSMB101ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW73v/ggg/0fmS3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxupG44L7hhW73z1gaWBcqd3FyMkhIWAicbGzlQXCFpO4cG89 WxcjF4eQwGFGiWM/m5ghnMWMElsfTGMEqWITsJO4dPoFUxcjB4eIgLLE6V8OIGFhAQ+JnYf+ soPYIgK+Em8uNLBA2HoSay+1sILYLAKqEjO3LwAbwyvgLfH400UwmxFo8fdTa5hAbGYBcYlb T+YzQRwkILFkz3lmCFtU4uXjf6wQtpLEiu2XGCHq8yXmPvrIDjFTUOLkzCcsExiFZiEZNQtJ 2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI3tuYmZOernhJkZg0B/c8lt3B+Op cyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBjWwLFPp0THesUrl9N7 b5wXSYyyWXtF66ho4E0dz5r+c1EHL1eVnjx8eXH9tISTB41v+EZsVWxW2BTPve1dEwfPrk4u wUnfdFNijvuluNkKhErd6f6Q1+y4snBWgGJNenp2wMnlJksfG3fP4lyVFdW0eeFCO7G9Lv4v 7C84brhgaNmtvDLiihJLcUaioRZzUXEiABXqDbdIAgAA Subject: [Dime] [DIME] number of transport connections among two Diameter peers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 15:13:27 -0000 --_000_087A34937E64E74E848732CFF8354B920DF89FESESSMB101ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Diameter experts and funs, I have a question on the interpretation of the highlighted red text in foll= owing paragraph from RFC 6733 section 2.1 "Transport": 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. My interpretation is that it refers to the possibility for two Diam. peers = (each of them identified by its "valid" DiameterIdentity -as set in section= 5.1-) to establish more than one transport connections (i.e. several TCP c= onnections or several SCTP associations -e.g. the "initiator/client" using = different TCP/SCTP source ports for each of them-). In line with this, also CER/CEA, DWR/DWA and DPR/DPA procedures must be man= aged per established TCP conn/SCTP assoc (as set in section 5.6) ... but (D= iameter) Application specific request and answers can be sent from one peer= to the other using whatever transport connection established among them (f= or the shared/common supported Application-Ids, of course). Could you confirm this is the shared understanding? A part from that, in that case, I got the following question: is it mandat= ed that responses are sent through the same transport connection from where= the (related) request-command was received? Thanks a lot in advance /MCruz --_000_087A34937E64E74E848732CFF8354B920DF89FESESSMB101ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Diameter experts and funs,

 

I have a question on the interpretation of the highl= ighted red text in following paragraph from RFC 6733 section 2.1 “Tra= nsport”:

 

   A given Diamete= r 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 t= he peer, in which, case a
   separate connection per process is allowed.<= /span>

 =

 =

My interpretation is t= hat it refers to the possibility for two Diam. peers (each of them identified by its = "valid" DiameterIdentity -as set in section 5.1-) to establish more than one transport connections (i.e. several TCP connections or= several SCTP associations -e.g. the "initiator/client" using dif= ferent TCP/SCTP source ports for each of them-).

 

In line with this, als= o CER/CEA, DWR/DWA and DPR/DPA procedures must be managed per established T= CP conn/SCTP assoc (as set in section 5.6) ... but (Diameter) Applicatio= n specific request and answers can be sent from one peer to the other using whatever transport connection establ= ished among them (for the shared/common supported Application-Ids, of c= ourse).

 

Could you confirm this= is the shared understanding?

 

A part from that, in t= hat case, I got the following question:  is it mandated that responses= are sent through the same transport connection from where the (related) re= quest-command was received?  

 

Thanks a lot in advance

/MCruz

--_000_087A34937E64E74E848732CFF8354B920DF89FESESSMB101ericsso_-- From lionel.morand@orange.com Thu Oct 17 08:57:03 2013 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 535EE21F9CA8 for ; Thu, 17 Oct 2013 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDmUUOw7xXKC for ; Thu, 17 Oct 2013 08:56:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id CEC5421F9C4F for ; Thu, 17 Oct 2013 08:56:13 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C06B52AC826; Thu, 17 Oct 2013 17:56:12 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 9F528C8067; Thu, 17 Oct 2013 17:56:12 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 17:56:12 +0200 From: To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] [DIME] number of transport connections among two Diameter peers Thread-Index: Ac7LS13n3AMba1KRQ9+N3shpOAyalgAA9U9Q Date: Thu, 17 Oct 2013 15:56:12 +0000 Message-ID: <28151_1382025372_5260089C_28151_17435_1_6B7134B31289DC4FAF731D844122B36E29FF38@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <087A34937E64E74E848732CFF8354B920DF89F@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920DF89F@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E29FF38PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.17.3915 Subject: Re: [Dime] [DIME] number of transport connections among two Diameter peers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 15:57:04 -0000 --_000_6B7134B31289DC4FAF731D844122B36E29FF38PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Maria Cruz, The interpretation is that ONE instance is uniquely identified by ONE Diame= ter Identity and between two diameter instances ONLY ONE transport connecti= on can be established. Multiple diameter instances can be collocated in the same "peer" (actually = "peer" is misused here, should be "node"), each diameter instance being ide= ntified by a unique Diameter identity. It is the reason why CER, DWR and DPR are not sent to a specific Destinatio= n-Host. It is implicit that the diameter identity is the one identified by = the transport connection in the peer table. It is acknowledged that there are some existing implementations in the fiel= d that are not following the statement given in the RFC6733 and allow multi= ple connections between two diameter identities. These implementations are = not compliant with the RFC and iIt is therefore up to theses implementation= s to carefully maintain the peer tables, the state machines and use the CER= /CEA, DWR/DWA and DPR/DPA. And to accommodate the fact that a node complian= t with the RFC6733 will only accept one transport connection with a given d= iameter identity. For your last question: "is it mandated that responses are sent through the= same transport connection from where the (related) request-command was rec= eived? ", the answer is "yes" if the implementation is compliant with the R= FC6733. It is implicit because the answer is forwarded back using the trans= port connection on which the request was received. And as only one transpor= t connection is in place, there is no question. My Best Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Mar= ia Cruz Bartolome Envoy=E9 : jeudi 17 octobre 2013 17:13 =C0 : dime@ietf.org Objet : [Dime] [DIME] number of transport connections among two Diameter pe= ers Hello Diameter experts and funs, I have a question on the interpretation of the highlighted red text in foll= owing paragraph from RFC 6733 section 2.1 "Transport": 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. My interpretation is that it refers to the possibility for two Diam. peers = (each of them identified by its "valid" DiameterIdentity -as set in section= 5.1-) to establish more than one transport connections (i.e. several TCP c= onnections or several SCTP associations -e.g. the "initiator/client" using = different TCP/SCTP source ports for each of them-). In line with this, also CER/CEA, DWR/DWA and DPR/DPA procedures must be man= aged per established TCP conn/SCTP assoc (as set in section 5.6) ... but (D= iameter) Application specific request and answers can be sent from one peer= to the other using whatever transport connection established among them (f= or the shared/common supported Application-Ids, of course). Could you confirm this is the shared understanding? A part from that, in that case, I got the following question: is it mandat= ed that responses are sent through the same transport connection from where= the (related) request-command was received? Thanks a lot in advance /MCruz ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E29FF38PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Ma= ria Cruz,

&n= bsp;

The int= erpretation is that ONE instance is uniquely identified by ONE Diameter Ide= ntity and between two diameter instances ONLY ONE transport connection can = be established.

Multipl= e diameter instances can be collocated in the same "peer" (actual= ly "peer" is misused here, should be "node"), each diam= eter instance being identified by a unique Diameter identity.

&n= bsp;

It is t= he reason why CER, DWR and DPR are not sent to a specific Destination-Host.= It is implicit that the diameter identity is the one identified by the tra= nsport connection in the peer table.

&n= bsp;

It is a= cknowledged that there are some existing implementations in the field that = are not following the statement given in the RFC6733 and allow multiple con= nections between two diameter identities. These implementations are not compliant with the RFC and iIt is therefore = up to theses implementations to carefully maintain the peer tables, the sta= te machines and use the CER/CEA, DWR/DWA and DPR/DPA. And to accommodate th= e fact that a node compliant with the RFC6733 will only accept one transport connection with a given diamete= r identity.

&n= bsp;

For you= r last question: "is it mandated that resp= onses are sent through the same transport connection from where the (relate= d) request-command was received? ", the answer is "yes" if the implementation is compliant with the = RFC6733. It is implicit because the answer is forwarded back using the tran= sport connection on which the request was received. And as only one transpo= rt connection is in place, there is no question.

&n= bsp;

My Best= Regards,

&n= bsp;

Lionel =

&n= bsp;

De : dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : jeudi 17 octobre 2013 17:13
=C0 : dime@ietf.org
Objet : [Dime] [DIME] number of transport connections among two= Diameter peers

 

Hello Diameter experts and funs= ,

 

I have a question on the interp= retation of the highlighted red text in following paragraph from RFC 6733 s= ection 2.1 “Transport”:

 

   = 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 t= he peer, in which, case a
   separate connection per process is allowed.<= /span>

 

 

M= y interpretation is that it refers to the possibility for two Diam. peers (each of them identified by its = "valid" DiameterIdentity -as set in section 5.1-) to establish more than one transport connections (i.e. several TCP connections or= several SCTP associations -e.g. the "initiator/client" using dif= ferent TCP/SCTP source ports for each of them-).

<= o:p> 

I= n line with this, also CER/CEA, DWR/DWA and DPR/DPA procedures must be mana= ged per established TCP conn/SCTP assoc (as set in section 5.6) ... but (Di= ameter) Application specific request and answers can be sent from one peer to the other using whatever transpor= t connection established among them (for the shared/common supported Ap= plication-Ids, of course).

<= o:p> 

C= ould you confirm this is the shared understanding?

<= o:p> 

A= part from that, in that case, I got the following question:  is it ma= ndated that responses are sent through the same transport connection from w= here the (related) request-command was received?  

 

Thanks a lot in advance

/MCruz

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E29FF38PEXCVZYM13corpora_-- From lionel.morand@orange.com Thu Oct 17 11:38:28 2013 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 2B1C421F8FD2 for ; Thu, 17 Oct 2013 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, SARE_URGBIZ=0.725, UNPARSEABLE_RELAY=0.001, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylT3nPTwLkWz for ; Thu, 17 Oct 2013 11:38:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6503011E82CA for ; Thu, 17 Oct 2013 11:38:17 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 360702AC805 for ; Thu, 17 Oct 2013 20:38:15 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1FC88384069 for ; Thu, 17 Oct 2013 20:38:15 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 20:38:15 +0200 From: To: "dime@ietf.org" Thread-Topic: NOMCOM - Critical shortage of nominees for multiple areas Thread-Index: AQHOy2XjkjWa+9SXikix87+mmmb9KZn5ODPw Date: Thu, 17 Oct 2013 18:38:14 +0000 Message-ID: <8519_1382035095_52602E97_8519_12082_1_6B7134B31289DC4FAF731D844122B36E2A04FE@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.10.17.3915 Subject: [Dime] Fwd: NOMCOM - Critical shortage of nominees for multiple areas X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2013 18:38:28 -0000 Hi Folks, Please seriously consider the nomination of someone of interest or yourself= for a position at the IESG. It is important in the NOMCOM process. Best Regards, Lionel -------- Original Message -------- Subject: NOMCOM - Critical shortage of nominees for multiple areas Date: Thu, 17 Oct 2013 07:24:34 -0700 From: NomCom Chair 2013 Reply-To: , , , <"2013 To: IETF Announcement List CC: IETF Discuss [Catchier Subject line - apologies to those offended by a duplicate] A critically low number of people have accepted nominations for some of the IESG open positions. There is only one nominee per slot in APP, OPS and TSV, only two in INT and RAI. Many folks have declined nominations. While the Nomcom appreciates that support for two years of intense service is hard to assure, and while we are aware that there is much support for the incumbents who are standing, the IETF should continually be considering which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation. Therefore, we urgently request that more nominees come forward. DEADLINES Nominations - October 18 Questionnaires from nominees - October 25 Not coincidentally, this is a good time to think over and send your comments about the current statements of desired expertise of positions - this is part of the Nomcom's annual review process as well. Send them to nomcom13@ietf.org. Definitive location [*] of the current statements on desired expertise: https://datatracker.ietf.org/nomcom/2013/expertise/ Instructions and details on nomination [**]: https://datatracker.ietf.org/ann/nomcom/60602/ Thanks, everyone, Allison for the Nomcom [*] This year the Nomcom tools were recoded, and also transitioned into the datatracker. Apologies for a number of places where we didn't catch reference errors. [**] Yes, alas, the previous call for nominations used "OAM" instead of "OPS," but we have* corrected this (chair's pilot) error where it occurred in the Nomcom pages. _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jouni.nospam@gmail.com Sat Oct 19 13:17:52 2013 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 AE6B111E828C for ; Sat, 19 Oct 2013 13:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbBwXg-7pCBE for ; Sat, 19 Oct 2013 13:17:52 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1425611E8281 for ; Sat, 19 Oct 2013 13:17:50 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ea20so395347lab.38 for ; Sat, 19 Oct 2013 13:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Zd/ohGEc9hLcoF9KgYslrIf0VIIrFLLkRyLCiruw2oM=; b=Y3Y+CAnb/N3AZYQP65D68Vi3OAAjdMPcl6uy29iF6MHSTscZJ0hTUBwSvsqCgHALCS 2BDBb47IwPtVfeGfQlbV7iVU9kHG7J+hlJ694Hrgdm3LwpkpAjIo+4o5ZwcrCg+iPOoV LiPJWm2PFjwmlDlyDBrDoTXTlcVABkgFgfyPcbRo9AKOHoov7LW7ylCGHjI8/qqKSZ1e viuFG+eZPszxj58VETwxLed3CrNaIfOzhcvYCLbue3LD+mDxm22yra3j+iZ/LHBoJN1L l4xMQQ/RRCuyarvH2JlCxrcxviH4wtXuHStXtqb5xa641qr0Tsy3oXmnS+FJ7uePkt5N bccA== X-Received: by 10.112.234.168 with SMTP id uf8mr2728921lbc.35.1382213870051; Sat, 19 Oct 2013 13:17:50 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id o1sm7820754lah.8.2013.10.19.13.17.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 13:17:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Sat, 19 Oct 2013 23:17:46 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: "dime@ietf.org" X-Mailer: Apple Mail (2.1510) Subject: Re: [Dime] IETF88 in Vancouver X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2013 20:17:52 -0000 Folks, Just a reminder. - JOuni On Oct 3, 2013, at 9:37 AM, Jouni Korhonen wrote: > Folks, > > We have requested for 2.5h WG slot for IETF88. Folks > who have WG items obviously need to prepare for a > status update (slide or few). If you want to present > some individual I-D or topic just lets the chairs know. > The usual prioritization for presentation slots is FIFO > with chartered topics having preference over non-chartered > topics. > > Jouni & Lionel From internet-drafts@ietf.org Sun Oct 20 22:54:18 2013 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 6085711E84B4; Sun, 20 Oct 2013 22:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTsmhYunix43; Sun, 20 Oct 2013 22:54:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A911811E8174; Sun, 20 Oct 2013 22:54:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021055407.8769.86927.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 22:54:07 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 05:54:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter AVP Level Security: Scenarios and Requirements Author(s) : Hannes Tschofenig Jouni Korhonen Glen Zorn Kervin Pillay Filename : draft-ietf-dime-e2e-sec-req-01.txt Pages : 9 Date : 2013-10-20 Abstract: This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-e2e-sec-req-01 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 hannes.tschofenig@gmx.net Sun Oct 20 23:25:22 2013 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 D4EB811E814C for ; Sun, 20 Oct 2013 23:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0RjN8f-MDBA for ; Sun, 20 Oct 2013 23:25:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 827D711E834A for ; Sun, 20 Oct 2013 23:25:16 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MPlsg-1Vd70b1BC6-004z3q for ; Mon, 21 Oct 2013 08:25:15 +0200 Message-ID: <5264C8E7.6060500@gmx.net> Date: Mon, 21 Oct 2013 08:25:43 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OssqSe2beVf7rzUyrVBRIIKPFpqK5U0cK0wCiIRegZPOCYwbxYV hOYJoJ7ITuM6VvnnuiHOY0UdROmjZiCEy6LnHI8TLJ7FSIFgvOVNwZu3l/t3mgXlqejEo1R iajobR9HJhD8QadQ6Lcs1Y3e6kAufx9dVwdYRGzEp+Ufnp31scie+JKvxr/6VktnVsWBJfX 6BZbxLnTuu/A4dgDFCL0Q== Subject: [Dime] draft-ietf-dime-e2e-sec-req-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 06:25:23 -0000 Hi all, I have just submitted version -01 of the 'Diameter AVP Level Security' document. The new draft version can be found here: http://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-01 I have made the following changes: * Added text regarding threats (which was previously in the text only implicitly) * Editorial fixes * Affiliation update * Relabelled two requirements as open issues I would be particularly interested to hear feedback regarding the new threat description. Ciao Hannes From bill.wu@huawei.com Mon Oct 21 00:49:41 2013 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 CAD7511E8183 for ; Mon, 21 Oct 2013 00:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeXkrsRlyPQv for ; Mon, 21 Oct 2013 00:49:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B748D11E835F for ; Mon, 21 Oct 2013 00:49:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA02556; Mon, 21 Oct 2013 07:49:32 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 08:49:22 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 08:49:28 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 15:49:21 +0800 From: Qin Wu To: "dime@ietf.org" Thread-Topic: using the string "+apX" for the application identifiers in RFC6408 Thread-Index: Ac7OMg2F9KQn/ljaRfmlrfaa1ABlKQ== Date: Mon, 21 Oct 2013 07:49:21 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C0D4FDnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Dime] using the string "+apX" for the application identifiers in RFC6408 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 07:49:41 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C0D4FDnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,Dimer: Can anybody tell me why use the string "+apX" for the application identifie= rs in RFC6408? Why not use some kind of acronym for them? E.g., Can I change 'aaa+apX' in the following "(S-NAPTR) Application Servi= ce Tag" registry table +------------------+----------------------------+ | Tag | Diameter Application | +------------------+----------------------------+ | aaa+ap1 | NASREQ [RFC3588] | | aaa+ap2 | Mobile IPv4 [RFC4004] | +------------------+----------------------------+ as "aaa+aconym" as follows: +------------------+----------------------------+ | Tag | Diameter Application | +------------------+----------------------------+ | aaa+nasreq | NASREQ [RFC3588] | | aaa+mip4 | Mobile IPv4 [RFC4004] | +------------------+----------------------------+ Regards! -Qin --_000_B8F9A780D330094D99AF023C5877DABA43C0D4FDnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,Dimer:

Can anybody tell me why use the string "+ap= X" for the application identifiers in RFC6408? Why not use some kind o= f acronym for them?

E.g., Can I change =
216;aaa+apX’ in the following "(S-NAPTR)  Application Service Tag" registry table
           =
;  +------------------+----------------------------+<=
/o:p>
           =
;  | Tag          &n=
bsp;   | Diameter Application      =
 |
           =
;  +------------------+----------------------------+<=
/o:p>
           =
;  | aaa+ap1         =
 | NASREQ [RFC3588]      =
;     |
           =
;  | aaa+ap2         =
 | Mobile IPv4 [RFC4004]   &n=
bsp;  |=

           =
;  +------------------+----------------------------+<=
/o:p>
 
as “aaa+aconym” as follows:

 


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


           =
;  | Tag          &n=
bsp;   | Diameter Application      =
 |


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


           =
;  | aaa+nasre=
q   &nbs=
p;   | NASREQ [RFC3588]   &nb=
sp;       |


           =
;  | aaa+mip4<=
/span>    =
     | Mobile IPv4 [RFC4004<=
/a>]      |


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


 


Regards!


-Qin
--_000_B8F9A780D330094D99AF023C5877DABA43C0D4FDnkgeml501mbschi_-- From jouni.nospam@gmail.com Mon Oct 21 01:02:24 2013 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 D7E8311E8490 for ; Mon, 21 Oct 2013 01:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qWyvSqeIrSa for ; Mon, 21 Oct 2013 01:02:24 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id BE64C11E817E for ; Mon, 21 Oct 2013 01:02:23 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id x18so3312585lbi.40 for ; Mon, 21 Oct 2013 01:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQ0u4a+F2gHVhdnyIcUuZLrSjluJ0e5ePDPqZhuxMKI=; b=0ifsTIB1ZHxcfe9nphzoElK4vN2MrclDADjK0PBaK9ag6Am+jNA/DxPyOJgaSvWJbr fjNUsp3EZ6H10ZKCCwNpvhuByIAtkedk4BZnICpKo7M8XXrKjmDfv+Ls9QC/FfwKA50x Rd8PjvTawFoeZrh4vWyzEz/AzD6dA1+oAW8LeaJ+/cjauAQ6OxzEGvszJ/ig7/FSn0zE P9KV2ID1vY3MoO0A6y439EmfaZ5e/Mk607Yke/AcTLoqo+RfRlSiOgxuwlM7hKKl+8yT Iz8sbHfsjEhaNMiX26ThMT1b2gr9LMh/EGmg4MWqVdymNrm+H163zOfZXyXmcl27KcyD iU4w== X-Received: by 10.152.29.201 with SMTP id m9mr12924918lah.6.1382342542514; Mon, 21 Oct 2013 01:02:22 -0700 (PDT) Received: from [192.168.250.241] ([194.100.71.98]) by mx.google.com with ESMTPSA id u18sm11373315lbp.4.2013.10.21.01.02.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 01:02:22 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 21 Oct 2013 11:02:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7482F40D-9A5F-4DE3-801D-6ADC81F167C1@gmail.com> References: To: Qin Wu X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] using the string "+apX" for the application identifiers in RFC6408 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 08:02:25 -0000 The "apX" directly identified the application identifier number. Therefore there is no need to maintain mapping between human readable acronyms and actual application identifier numbers. - Jouni On Oct 21, 2013, at 10:49 AM, Qin Wu wrote: > Hi,Dimer: > Can anybody tell me why use the string "+apX" for the application = identifiers in RFC6408? Why not use some kind of acronym for them? > E.g., Can I change =91aaa+apX=92 in the following "(S-NAPTR) = Application Service Tag" registry table > +------------------+----------------------------+ > | Tag | Diameter Application | > +------------------+----------------------------+ > | aaa+ap1 | NASREQ [RFC3588] | > | aaa+ap2 | Mobile IPv4 [RFC4004] | > +------------------+----------------------------+ > =20 > as =93aaa+aconym=94 as follows: > =20 > +------------------+----------------------------+ > | Tag | Diameter Application | > +------------------+----------------------------+ > | aaa+nasreq | NASREQ [RFC3588] | > | aaa+mip4 | Mobile IPv4 [RFC4004] | > +------------------+----------------------------+ > =20 > Regards! > -Qin > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From kristian.poscic@alcatel-lucent.com Mon Oct 21 11:31:30 2013 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 E2E6F11E857E for ; Mon, 21 Oct 2013 11:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4JcLguDXOrS for ; Mon, 21 Oct 2013 11:31:23 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 92AD511E856E for ; Mon, 21 Oct 2013 11:31:16 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9LIVD80026169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 21 Oct 2013 13:31:14 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r9LIVDOU018857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 14:31:13 -0400 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.30]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 21 Oct 2013 14:31:13 -0400 From: "Poscic, Kristian (Kristian)" To: "dime@ietf.org" Thread-Topic: counters in Diameter accounting Thread-Index: Ac7Oiv8bJORCxt8cTgeLaXXI15HrIg== Date: Mon, 21 Oct 2013 18:31:12 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AC806E7@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AC806E7US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Dime] counters in Diameter accounting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 21 Oct 2013 18:31:31 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AC806E7US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe I'm missing something but it seems like RFC 6733 does not define AVPs= used to convey counter information (for volume accounting) to the accounti= ng server. Does this mean that one can adopt for Diameter accounting application: : - Acct-input/output-octets from RFC 2866 (Rad standard acct attrib= utes)? - Or cc-input/output/total-octets from RFC 4006? - Or custom defined counters? Thanks, Kris --_000_7921F977B17D5B49B8DCC955A339D2F02AC806E7US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Maybe I’m missing something but it seems like = RFC 6733 does not define AVPs used to convey counter information (for volum= e accounting) to the accounting server.

Does this mean that one can adopt for Diameter accou= nting application: :

-     &= nbsp;    Acct-input/output-octets from RFC 2866 (Rad standar= d acct attributes)?

-     &= nbsp;    Or cc-input/output/total-octets from RFC 4006?=

-     &= nbsp;    Or custom defined counters?

Thanks,

Kris

--_000_7921F977B17D5B49B8DCC955A339D2F02AC806E7US70UWXCHMBA05z_-- From internet-drafts@ietf.org Mon Oct 21 15:04:03 2013 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 A994C11E873E; Mon, 21 Oct 2013 15:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXrsvUJ0e5ZB; Mon, 21 Oct 2013 15:04:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E28CD11E875B; Mon, 21 Oct 2013 15:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021220356.32521.70611.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:03:56 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:04:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Group Signaling Author(s) : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-02.txt Pages : 23 Date : 2013-10-21 Abstract: In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-group-signaling-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-group-signaling-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 jouni.nospam@gmail.com Mon Oct 21 22:34:47 2013 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 C457C11E80DE for ; Mon, 21 Oct 2013 22:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63NTom+Mz43h for ; Mon, 21 Oct 2013 22:34:46 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3111E845E for ; Mon, 21 Oct 2013 22:34:41 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so7362919wes.24 for ; Mon, 21 Oct 2013 22:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=4j9I8AnadPUB04VoUWf5FebBK2757TV9Zrslp5l+zZ8=; b=lelhIXF7RNiEL1mZzUrMjUdUZhi+vVMmhb+g1W4rKFWGbrPjufH3e49+chuXBGe3q+ epFwTp50G1UQnsgvIwQEIhDEKa5wKzRoXn6mNSMe5uKjaFPYTC29B5FtZ5ZgddwTrdXJ x5OTzmAu+QUBXrko3VsVSAmwdN+S3yy3QRAJJIIxW7b5OF8yLgY1AfYg05pk5IdHYkVy hIG/tNoerdtnK8we7FZYUZr4Iw8NcMtiO7Zhmax529QWWS4JL9brRvZDqXckzhpgbEam emxBHPxmJO1IWETkX6Mm9tz+5Mbi05VknssWSAtwkjmluOMjTKILs4UuOWlnFuG5ziGn ydQg== X-Received: by 10.194.170.133 with SMTP id am5mr4889716wjc.42.1382420080562; Mon, 21 Oct 2013 22:34:40 -0700 (PDT) Received: from [10.62.144.71] ([81.253.38.196]) by mx.google.com with ESMTPSA id d11sm2621345wic.4.2013.10.21.22.34.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 22:34:37 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Oct 2013 08:34:37 +0300 References: <20131021212409.32455.33272.idtracker@ietfa.amsl.com> To: "dime@ietf.org" Message-Id: <80A6D68E-F6A5-40D5-92DB-4C70EE487600@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] Fwd: New Version Notification for draft-docdt-dime-ovli-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 05:34:47 -0000 FYI The Diameter Overload Control DT has worked extensively past weeks to reach consensus and ship the first version of the DT overload control solution proposal. The I-D is still in progress and more work is needed to complete the details and fill in the missing parts. Have a look at the I-D. We hope to submit a revision during the IETF week based on the comments and progress between now and the start of the IETF88. We also hope to be in state where we can call for an adoption call after the IETF. Regards, DOC-DT Begin forwarded message: > A new version of I-D, draft-docdt-dime-ovli-00.txt > has been successfully submitted by Jouni Korhonen and posted to the > IETF repository. >=20 > Filename: draft-docdt-dime-ovli > Revision: 00 > Title: Diameter Overload Indication Conveyance > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 31 > URL: = http://www.ietf.org/internet-drafts/draft-docdt-dime-ovli-00.txt > Status: http://datatracker.ietf.org/doc/draft-docdt-dime-ovli > Htmlized: http://tools.ietf.org/html/draft-docdt-dime-ovli-00 >=20 >=20 > Abstract: > This specification documents a Diameter Overload Information > Conveyance (DOIC) base solution and the dissemination of the = overload > report information. >=20 From srdonovan@usdonovans.com Tue Oct 22 05:33:02 2013 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 7649411E8370 for ; Tue, 22 Oct 2013 05:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+eL4GINURvY for ; Tue, 22 Oct 2013 05:32:57 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id AA36211E8164 for ; Tue, 22 Oct 2013 05:32:55 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57264 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VYb8l-0002E9-Qo for dime@ietf.org; Tue, 22 Oct 2013 05:32:53 -0700 Message-ID: <52667074.5030103@usdonovans.com> Date: Tue, 22 Oct 2013 07:32:52 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dime@ietf.org References: <20131021214906.32495.1023.idtracker@ietfa.amsl.com> In-Reply-To: <20131021214906.32495.1023.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131021214906.32495.1023.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020809050109080006000901" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-agent-overload-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 12:33:02 -0000 This is a multi-part message in MIME format. --------------020809050109080006000901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit All, I have created a new draft addressing Diameter Agent Overload. This is an extension of the output from the Diameter Overload Control design team and draft-docdt-dime-ovli-00.txt Regards, Steve -------- Original Message -------- Subject: New Version Notification for draft-donovan-dime-agent-overload-00.txt Date: Mon, 21 Oct 2013 14:49:06 -0700 From: internet-drafts@ietf.org To: Steve Donovan A new version of I-D, draft-donovan-dime-agent-overload-00.txt has been successfully submitted by Steve Donovan and posted to the IETF repository. Filename: draft-donovan-dime-agent-overload Revision: 00 Title: Diameter Agent Overload Creation date: 2013-10-21 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-00.txt Status: http://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload Htmlized: http://tools.ietf.org/html/draft-donovan-dime-agent-overload-00 Abstract: This specification documents an extension to the Diameter Overload Control (DOC) base solution. The extension addresses the handling of agent overload. Requirements Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------020809050109080006000901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit All,

I have created a new draft addressing Diameter Agent Overload.  This is an extension of the output from the Diameter Overload Control design team and draft-docdt-dime-ovli-00.txt

Regards,

Steve

-------- Original Message --------
Subject: New Version Notification for draft-donovan-dime-agent-overload-00.txt
Date: Mon, 21 Oct 2013 14:49:06 -0700
From: internet-drafts@ietf.org
To: Steve Donovan <srdonovan@usdonovans.com> 


A new version of I-D, draft-donovan-dime-agent-overload-00.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Filename:	 draft-donovan-dime-agent-overload
Revision:	 00
Title:		 Diameter Agent Overload
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-00.txt
Status:          http://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload
Htmlized:        http://tools.ietf.org/html/draft-donovan-dime-agent-overload-00


Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  The extension addresses the handling of
   agent overload.

Requirements
                                                                                  


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

The IETF Secretariat


--------------020809050109080006000901-- From jouni.nospam@gmail.com Tue Oct 22 10:48:53 2013 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 7E41811E84C2 for ; Tue, 22 Oct 2013 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57CNWdFfdRAX for ; Tue, 22 Oct 2013 10:48:53 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D71D011E81E3 for ; Tue, 22 Oct 2013 10:48:43 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id h11so6114721wiv.10 for ; Tue, 22 Oct 2013 10:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ylUKkWMYMC9gDMCZSUGs7uUbSTFQlgETRcowacMd3sw=; b=L1nAH0b0CuMNH0S2TMkBXhwivQjFUSyMZDo8VJolg1+d3dNS0Rlqb5AtDpEM/eWdx1 cQerZAVbaoP6/cxAkbYSGXyeIIoFoBE1Smbi4xniOGonfd8dKgXRubwu6RfynElz1XGe zfjz3ZA4ZqktYLmjp1X/v6xtwSpiSr1x+9brmTAiA5frNZwzDsJfnZTiafYMkcFAZ/CM a1eoDY8r7HI6YMhaptlPNhkQc8vd/AcqAW36fejPWiiVpHDn7jn8sguIy96yQKx3FdbE JgV4AaFVnawzmIRXBnGEyGgAyhY2IA7XXCzbiLLlla5hARxffdBT96eI2FlIJsd2GOdX gumQ== X-Received: by 10.180.108.131 with SMTP id hk3mr4463306wib.10.1382464121077; Tue, 22 Oct 2013 10:48:41 -0700 (PDT) Received: from [10.62.144.89] ([81.253.57.139]) by mx.google.com with ESMTPSA id ft19sm8647581wic.5.2013.10.22.10.48.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 10:48:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AC806E7@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Tue, 22 Oct 2013 20:48:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7921F977B17D5B49B8DCC955A339D2F02AC806E7@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Poscic, Kristian (Kristian)" X-Mailer: Apple Mail (2.1510) Cc: "dime@ietf.org" Subject: Re: [Dime] counters in Diameter accounting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 17:48:53 -0000 Hi You can reuse RADIUS attributes as such with Diameter. See RFC6733 = Section 4.1. - Jouni On Oct 21, 2013, at 9:31 PM, "Poscic, Kristian (Kristian)" = wrote: > Maybe I=92m missing something but it seems like RFC 6733 does not = define AVPs used to convey counter information (for volume accounting) = to the accounting server. > Does this mean that one can adopt for Diameter accounting application: = : > - Acct-input/output-octets from RFC 2866 (Rad standard acct = attributes)? > - Or cc-input/output/total-octets from RFC 4006? > - Or custom defined counters? > Thanks, > Kris > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From srdonovan@usdonovans.com Wed Oct 23 10:02:02 2013 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 6023F11E8457 for ; Wed, 23 Oct 2013 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm0HiEchXGbC for ; Wed, 23 Oct 2013 10:01:57 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9F26D11E83C3 for ; Wed, 23 Oct 2013 10:01:57 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54447 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VZ1oe-0001Sp-Jv; Wed, 23 Oct 2013 10:01:55 -0700 Message-ID: <52680100.5060802@usdonovans.com> Date: Wed, 23 Oct 2013 12:01:52 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , dime@ietf.org References: <20131021214906.32495.1023.idtracker@ietfa.amsl.com> <52667074.5030103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066805EE9B@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066805EE9B@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------090304080004090501070504" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] Fwd: New Version Notification for draft-donovan-dime-agent-overload-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 17:02:02 -0000 This is a multi-part message in MIME format. --------------090304080004090501070504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Ulrich, Thank you for the review. I have added the DIME mailing list to my response. I have addressed your points below. Regards, Steve ----- Section 3.4 - The interaction between end-point overload and agent overload is a two step process. The first step is to determine how much traffic targeted for the end-point is actually sent. The end-point overload report is used for this purpose. The second step is to determine the route that traffic takes. The agent overload report is used for this purpose. On capability negotiation -- The goal is to have a single negotiation mechanism for Diameter overload. Your suggestion of using CER/CEA for the negotiation for the peer overload report type would work but it requires splitting the negotiation mechanism in two. This is something that should be discussed further as there are pro's and con's to both mechanisms. Section 4.2 - Agent overload (or peer overload) is indeed hop-by-hop, but the solution must also handle the case where there are hops that do not support overload. Section 5.2 - The comment on use of the loss algorithm can probably be better worded but the point is that the same abatement strategy/algorithm can be used by the reactor. Agent overload does not imply a different algorithm. On 10/23/13 9:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > Steve, > > > > please find my comments attached. > > > > Best regards > > Ulrich > > > > *From:*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On Behalf > Of *ext Steve Donovan > *Sent:* Tuesday, October 22, 2013 2:33 PM > *To:* dime@ietf.org > *Subject:* [Dime] Fwd: New Version Notification for > draft-donovan-dime-agent-overload-00.txt > > > > All, > > I have created a new draft addressing Diameter Agent Overload. This > is an extension of the output from the Diameter Overload Control > design team and draft-docdt-dime-ovli-00.txt > > > Regards, > > Steve > > -------- Original Message -------- > > *Subject: * > > > > New Version Notification for draft-donovan-dime-agent-overload-00.txt > > *Date: * > > > > Mon, 21 Oct 2013 14:49:06 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Steve Donovan > > > > A new version of I-D, draft-donovan-dime-agent-overload-00.txt > has been successfully submitted by Steve Donovan and posted to the > IETF repository. > > Filename: draft-donovan-dime-agent-overload > Revision: 00 > Title: Diameter Agent Overload > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-00.txt > Status: http://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload > Htmlized: http://tools.ietf.org/html/draft-donovan-dime-agent-overload-00 > > > Abstract: > This specification documents an extension to the Diameter Overload > Control (DOC) base solution. The extension addresses the handling of > agent overload. > > Requirements > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > > --------------090304080004090501070504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Ulrich,

Thank you for the review.  I have added the DIME mailing list to my response.  I have addressed your points below.

Regards,

Steve

-----

Section 3.4 - The interaction between end-point overload and agent overload is a two step process.  The first step is to determine how much traffic targeted for the end-point is actually sent.  The end-point overload report is used for this purpose.  The second step is to determine the route that traffic takes.  The agent overload report is used for this purpose.

On capability negotiation -- The goal is to have a single negotiation mechanism for Diameter overload.  Your suggestion of using CER/CEA for the negotiation for the peer overload report type would work but it requires splitting the negotiation mechanism in two.  This is something that should be discussed further as there are pro's and con's to both mechanisms.

Section 4.2 - Agent overload (or peer overload) is indeed hop-by-hop, but the solution must also handle the case where there are hops that do not support overload.

Section 5.2 - The comment on use of the loss algorithm can probably be better worded but the point is that the same abatement strategy/algorithm can be used by the reactor.  Agent overload does not imply a different algorithm.
On 10/23/13 9:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve,

 

please find my  comments attached.

 

Best regards

Ulrich

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, October 22, 2013 2:33 PM
To: dime@ietf.org
Subject: [Dime] Fwd: New Version Notification for draft-donovan-dime-agent-overload-00.txt

 

All,

I have created a new draft addressing Diameter Agent Overload.  This is an extension of the output from the Diameter Overload Control design team and draft-docdt-dime-ovli-00.txt


Regards,

Steve

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

Subject:

New Version Notification for draft-donovan-dime-agent-overload-00.txt

Date:

Mon, 21 Oct 2013 14:49:06 -0700

From:

internet-drafts@ietf.org

To:

Steve Donovan <srdonovan@usdonovans.com>

 

A new version of I-D, draft-donovan-dime-agent-overload-00.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.
 
Filename:       draft-donovan-dime-agent-overload
Revision:       00
Title:          Diameter Agent Overload
Creation date:  2013-10-21
Group:          Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-donovan-dime-agent-overload-00.txt
Status:          http://datatracker.ietf.org/doc/draft-donovan-dime-agent-overload
Htmlized:        http://tools.ietf.org/html/draft-donovan-dime-agent-overload-00
 
 
Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  The extension addresses the handling of
   agent overload.
 
Requirements
                                                                                  
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
The IETF Secretariat
 
 

 

 


--------------090304080004090501070504-- From jouni.korhonen@iki.fi Thu Oct 24 07:11:02 2013 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 3C6B011E8334 for ; Thu, 24 Oct 2013 07:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxPP0px7YGYe for ; Thu, 24 Oct 2013 07:10:58 -0700 (PDT) Received: from smtp-68.nebula.fi (smtp.nebula.fi [IPv6:2001:1bc8:100c:f220::66]) by ietfa.amsl.com (Postfix) with ESMTP id C03A511E8328 for ; Thu, 24 Oct 2013 07:10:48 -0700 (PDT) Received: from [188.117.15.108] (unknown [188.117.15.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-68.nebula.fi (Postfix) with ESMTP id 4AD1532B003F for ; Thu, 24 Oct 2013 17:10:43 +0300 (EEST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <66473BDC-6D90-4CD1-8282-6540142B7BDD@iki.fi> Date: Thu, 24 Oct 2013 17:10:42 +0300 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] Draft agenda available X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2013 14:11:02 -0000 Folks, The draft meeting agenda is now available: http://www.ietf.org/proceedings/88/agenda/agenda-88-dime - Jouni & Lionel From sdanda@cisco.com Sun Oct 27 23:04:27 2013 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 E803E11E8193 for ; Sun, 27 Oct 2013 23:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxA9XBzKLK1d for ; Sun, 27 Oct 2013 23:04:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 145F211E80F5 for ; Sun, 27 Oct 2013 23:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1557; q=dns/txt; s=iport; t=1382940263; x=1384149863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SlFz6Dk5blFUsxXW/1rjcPonDNOCIXBL41THz9jMs8E=; b=lonnPOhh42ELaRgkm+9EmgSCOnkiT7rUM9DRzHF3S/WcAGqCZo5vlze5 S/XAyWCpG7Lj/HnoZHcMbSMdr3cdD2rFff9eaiitOAgtzbYVuviDK3XC/ lnwxN8XVldkV36U3JPM7TId/HyBtaxN9Chn3CB8ezFCLsM29mSy6okJPx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAPH9bVKtJV2d/2dsb2JhbABZgwc4VL5egR0WdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBCxQJBycLFAkIAQEEDgUIh3kGDbgYBI8kMQcGgxmBDQOqEYMmgio X-IronPort-AV: E=Sophos;i="4.93,584,1378857600"; d="scan'208";a="277158384" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 28 Oct 2013 06:04:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9S64Mfe017187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 06:04:22 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 01:04:22 -0500 From: "Satyanarayana Danda (sdanda)" To: Jouni Korhonen , "Poscic, Kristian (Kristian)" Thread-Topic: [Dime] counters in Diameter accounting Thread-Index: Ac7Oiv8bJORCxt8cTgeLaXXI15HrIgA7dkOAAQp3nCA= Date: Mon, 28 Oct 2013 06:04:21 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AC806E7@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.105.196] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] counters in Diameter accounting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 28 Oct 2013 06:04:28 -0000 I feel, there is a little bit confusion on the Base protocol mentioning abo= ut accounting and NASREQ talks about Radius like AAA services including acc= ounting. Since base accounting counters to be used are of RFC 2866, does it make sen= se to mention these as part of NASREQ (RFC 4005) application or Base protoc= ol itself? Thanks Satya -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: Tuesday, October 22, 2013 11:19 PM To: Poscic, Kristian (Kristian) Cc: dime@ietf.org Subject: Re: [Dime] counters in Diameter accounting Hi You can reuse RADIUS attributes as such with Diameter. See RFC6733 Section = 4.1. - Jouni On Oct 21, 2013, at 9:31 PM, "Poscic, Kristian (Kristian)" wrote: > Maybe I'm missing something but it seems like RFC 6733 does not define AV= Ps used to convey counter information (for volume accounting) to the accoun= ting server. > Does this mean that one can adopt for Diameter accounting application: : > - Acct-input/output-octets from RFC 2866 (Rad standard acct attr= ibutes)? > - Or cc-input/output/total-octets from RFC 4006? > - Or custom defined counters? > Thanks, > Kris > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime