From tom.taylor.stds@gmail.com  Tue Jun  4 11:35:18 2013
Return-Path: <tom.taylor.stds@gmail.com>
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 0755021F8C40 for <dime@ietfa.amsl.com>; Tue,  4 Jun 2013 11:35:18 -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 4c-tzGoAvH2H for <dime@ietfa.amsl.com>; Tue,  4 Jun 2013 11:35:17 -0700 (PDT)
Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BF0F221F9985 for <dime@ietf.org>; Tue,  4 Jun 2013 11:18:32 -0700 (PDT)
Received: by mail-ob0-f175.google.com with SMTP id xn12so967714obc.20 for <dime@ietf.org>; Tue, 04 Jun 2013 11:18:32 -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:cc:subject :content-type:content-transfer-encoding; bh=ovdpq7M+NmGBk+kq+O7SwKzsVCnyEl/ZcafbQwX/saI=; b=Q4CHgz+C6Mlt7Kpfrurcv3pdkACimxfQLv5UbXAuAH2/i48I+FZ62ZhHSV+89RBygY W9Fb4LAVuDBaVjLo50//AFGlR8Qn0OFTaxSb6UtYpXSwqoQKm6YZgo5MjcLzJT2rTSL2 RFvwocpQGdj9o5B+w0ZGG4MXqxhdMsFOS4K4cU2bSrj/zWa7+++Zccp+M0fuQq7Khpsj K5oJfCxDf4UGoO/kVYmyzT6Zfsngqa7FzMXUfxzab3KyeGCMmZHZKcKEQ40PeCgmnd5h H4g90Bz+GSSamIF+qrq6Vb1Z4OEunydOyU3Citwqa1IU6n8Lvny5DDI4H7uSLQQKzUOc zaow==
X-Received: by 10.182.137.196 with SMTP id qk4mr12701451obb.53.1370369912188;  Tue, 04 Jun 2013 11:18:32 -0700 (PDT)
Received: from [192.168.1.64] (dsl-173-206-2-36.tor.primus.ca. [173.206.2.36]) by mx.google.com with ESMTPSA id kz3sm5446041obb.6.2013.06.04.11.18.31 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 11:18:31 -0700 (PDT)
Message-ID: <51AE2F76.8070905@gmail.com>
Date: Tue, 04 Jun 2013 14:18:30 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "dime@ietf.org" <dime@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <gwz@net-zen.net>
Subject: [Dime] IPR in RFC 6159 Session-Specific Explicit Diameter Request Routing
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 18:35:18 -0000

Huawei will shortly make a formal IPR announcement against RFC 6159, 
Session-Specific Explicit Diameter Request Routing. This is the result 
of an internal review. The authors wish to assure you that they had no 
knowledge of the patent claim concerned -- it was filed by a different 
business unit. Our regrets for the late notification.

Tom Taylor
Tina Tsou
Glen Zorn.

From internet-drafts@ietf.org  Thu Jun  6 12:03:06 2013
Return-Path: <internet-drafts@ietf.org>
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 CD7BC21F96EF; Thu,  6 Jun 2013 12:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.41
X-Spam-Level: 
X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.190, 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 t6Rj1VehQgSK; Thu,  6 Jun 2013 12:03:06 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F1721F909A; Thu,  6 Jun 2013 12:02:54 -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.50
Message-ID: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>
Date: Thu, 06 Jun 2013 12:02:54 -0700
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 19:03:07 -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-18.txt
	Pages           : 21
	Date            : 2013-06-06

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-18


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


From lionel.morand@orange.com  Thu Jun  6 12:13:55 2013
Return-Path: <lionel.morand@orange.com>
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 0FB1421E80BE; Thu,  6 Jun 2013 12:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AUoQ5jyzm1Dn; Thu,  6 Jun 2013 12:13:50 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4611E80ED; Thu,  6 Jun 2013 12:13:50 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 18B48325333; Thu,  6 Jun 2013 21:13:47 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CF7684C015; Thu,  6 Jun 2013 21:13:46 +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; Thu, 6 Jun 2013 21:09:28 +0200
From: <lionel.morand@orange.com>
To: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Thread-Topic: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
Thread-Index: AQHOYuieLu/LsrlW5UynTjOMMw8dF5kpC3wQ
Date: Thu, 6 Jun 2013 19:09:28 +0000
Message-ID: <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>
In-Reply-To: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 19:13:55 -0000

Hi,

The version covers the changes proposed by the detailed review done by Hann=
es (thank you!).
Most of them are OK and taken into account in this new version... except on=
e:

In the RFC 6733, the correct wording used is "the Diameter base protocol" a=
nd not "Diameter Base Protocol". I have received the same comment in the re=
cent past! :)

Hannes, please confirm that this version is OK. If it is, the WGLC on this =
document is finished and we can move forward.

Regards,

Lionel

-----Message d'origine-----
De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de i=
nternet-drafts@ietf.org
Envoy=E9=A0: jeudi 6 juin 2013 21:03
=C0=A0: i-d-announce@ietf.org
Cc=A0: dime@ietf.org
Objet=A0: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Diameter Maintenance and Extensions 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-18.txt
	Pages           : 21
	Date            : 2013-06-06

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-18


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

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

___________________________________________________________________________=
______________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From internet-drafts@ietf.org  Thu Jun  6 13:09:11 2013
Return-Path: <internet-drafts@ietf.org>
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 4271E21E80B6; Thu,  6 Jun 2013 13:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.331
X-Spam-Level: 
X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.042, 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 x46g3FGZT4xQ; Thu,  6 Jun 2013 13:09:10 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFE221E8050; Thu,  6 Jun 2013 13:09:10 -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.50
Message-ID: <20130606200910.11050.67975.idtracker@ietfa.amsl.com>
Date: Thu, 06 Jun 2013 13:09:10 -0700
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-07.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 20:09:11 -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 Overload Control Requirements
	Author(s)       : Eric McMurry
                          Ben Campbell
	Filename        : draft-ietf-dime-overload-reqs-07.txt
	Pages           : 27
	Date            : 2013-06-06

Abstract:
   When a Diameter server or agent becomes overloaded, it needs to be
   able to gracefully reduce its load, typically by informing clients to
   reduce sending traffic for some period of time.  Otherwise, it must
   continue to expend resources parsing and responding to Diameter
   messages, possibly resulting in congestion collapse.  The existing
   Diameter mechanisms, listed in Section 3 are not sufficient for this
   purpose.  This document describes the limitations of the existing
   mechanisms in Section 4.  Requirements for new overload management
   mechanisms are provided in Section 7.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-07


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


From emcmurry@computer.org  Thu Jun  6 13:10:58 2013
Return-Path: <emcmurry@computer.org>
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 6624621E80C4 for <dime@ietfa.amsl.com>; Thu,  6 Jun 2013 13:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level: 
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227]
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 fQf8UWDTS6fS for <dime@ietfa.amsl.com>; Thu,  6 Jun 2013 13:10:53 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBAB21E80CF for <dime@ietf.org>; Thu,  6 Jun 2013 13:10:49 -0700 (PDT)
Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <emcmurry@computer.org>) id 1UkgWG-00067Q-HR for dime@ietf.org; Thu, 06 Jun 2013 20:10:48 +0000
Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id AC58A3791745 for <dime@ietf.org>; Thu,  6 Jun 2013 15:10:47 -0500 (CDT)
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 76.184.161.215
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+lK7vWbp2Xe6cb4UfTLGgdoqjgQKPTCHE=
X-Virus-Scanned: amavisd-new at casamcmurry.com
Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIi3kEmeDcSf for <dime@ietf.org>; Thu,  6 Jun 2013 15:10:47 -0500 (CDT)
Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id A4ADF3791727 for <dime@ietf.org>; Thu,  6 Jun 2013 15:10:44 -0500 (CDT)
From: Eric McMurry <emcmurry@computer.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A08ECA13-AEB0-42F2-9005-AE02B262CB75"
Message-Id: <F0CDFEAE-F5E5-485D-98AF-9629B3959772@computer.org>
Date: Thu, 6 Jun 2013 15:10:33 -0500
To: "dime@ietf.org" <dime@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [Dime] overload control reqs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 20:10:58 -0000

--Apple-Mail=_A08ECA13-AEB0-42F2-9005-AE02B262CB75
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

There is a new version of the overload control reqs.  This contains only =
minor editorial changes resulting from proto writeup.


Filename:	 draft-ietf-dime-overload-reqs
Revision:	 07
Title:		 Diameter Overload Control Requirements
Creation date:	 2013-06-06
Group:		 dime
Number of pages: 27
URL:             =
http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-07.txt
Status:          =
http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs
Htmlized:        =
http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-07
Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-07



--Apple-Mail=_A08ECA13-AEB0-42F2-9005-AE02B262CB75
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">There =
is a new version of the overload control reqs. &nbsp;This contains only =
minor editorial changes resulting from proto =
writeup.<div><br></div><div><br></div><div><span style=3D"font-family: =
monospace; ">Filename:</span><span class=3D"Apple-tab-span" =
style=3D"font-family: monospace; white-space: pre; ">	</span><span =
style=3D"font-family: monospace; =
">&nbsp;draft-ietf-dime-overload-reqs</span><br style=3D"font-family: =
monospace; "><span style=3D"font-family: monospace; =
">Revision:</span><span class=3D"Apple-tab-span" style=3D"font-family: =
monospace; white-space: pre; ">	</span><span style=3D"font-family: =
monospace; ">&nbsp;07</span><br style=3D"font-family: monospace; "><span =
style=3D"font-family: monospace; ">Title:</span><span =
class=3D"Apple-tab-span" style=3D"font-family: monospace; white-space: =
pre; ">	</span><span class=3D"Apple-tab-span" style=3D"font-family: =
monospace; white-space: pre; ">	</span><span style=3D"font-family: =
monospace; ">&nbsp;Diameter Overload Control Requirements</span><br =
style=3D"font-family: monospace; "><span style=3D"font-family: =
monospace; ">Creation date:</span><span class=3D"Apple-tab-span" =
style=3D"font-family: monospace; white-space: pre; ">	</span><span =
style=3D"font-family: monospace; ">&nbsp;2013-06-06</span><br =
style=3D"font-family: monospace; "><span style=3D"font-family: =
monospace; ">Group:</span><span class=3D"Apple-tab-span" =
style=3D"font-family: monospace; white-space: pre; ">	</span><span =
class=3D"Apple-tab-span" style=3D"font-family: monospace; white-space: =
pre; ">	</span><span style=3D"font-family: monospace; =
">&nbsp;dime</span><br style=3D"font-family: monospace; "><span =
style=3D"font-family: monospace; ">Number of pages: 27</span><br =
style=3D"font-family: monospace; "><span style=3D"font-family: =
monospace; ">URL: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
span><a =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-=
07.txt" style=3D"font-family: monospace; =
">http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-07.txt=
</a><br style=3D"font-family: monospace; "><span style=3D"font-family: =
monospace; ">Status: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><a =
href=3D"http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs" =
style=3D"font-family: monospace; =
">http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs</a><br =
style=3D"font-family: monospace; "><span style=3D"font-family: =
monospace; ">Htmlized: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><a =
href=3D"http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-07" =
style=3D"font-family: monospace; =
">http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-07</a><br =
style=3D"font-family: monospace; "><span style=3D"font-family: =
monospace; ">Diff: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span><=
a =
href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-0=
7" style=3D"font-family: monospace; =
">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-07</a><=
br style=3D"font-family: monospace; =
"></div><div><br></div><div><br></div></body></html>=

--Apple-Mail=_A08ECA13-AEB0-42F2-9005-AE02B262CB75--

From jouni.nospam@gmail.com  Thu Jun  6 13:23:26 2013
Return-Path: <jouni.nospam@gmail.com>
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 D5D5D21E8050 for <dime@ietfa.amsl.com>; Thu,  6 Jun 2013 13:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
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 xm0cysHYIgFU for <dime@ietfa.amsl.com>; Thu,  6 Jun 2013 13:23:26 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C92C311E8108 for <dime@ietf.org>; Thu,  6 Jun 2013 13:23:25 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id d15so2992086eaj.6 for <dime@ietf.org>; Thu, 06 Jun 2013 13:23:18 -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:x-mailer; bh=za8ETHWKqODr2bhGZyzYThE1dSNAlGyjf77raAH/lO8=; b=lOJNkoEg0U9budc1JaCXjvblKD02iWbHyemUpzl1DbwePMUye6U4zIOVsgjGqLoxXS m29XWGcsfjd2VyRp0ZbSMtOCnyGHi9YoUnLLW69DTNlaI6rOEq6xfDuNALPqRXSgucWS 0QS9Uk6cbUr4yiERIyh1pp0g8TxzsIkkFXbLy33N8LbKdk4gDEv1c7BpQC5NlfMzchfB U2wREWmFQuIdO0CnNohpw1ReNvs3l/TbVNNspMIQe2je4xvmMFp5a+obtRFwMw2X7X4h HC4qGojx38n+XsBZfyUwKF1M3vYTjVnwtt1ZkA6at+/LsdA+7Rwrm2Zo4DBYwl/UG6Lz vq7g==
X-Received: by 10.15.65.14 with SMTP id p14mr5699860eex.30.1370550198104; Thu, 06 Jun 2013 13:23:18 -0700 (PDT)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id b14sm37796206ees.16.2013.06.06.13.23.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 13:23:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <F0CDFEAE-F5E5-485D-98AF-9629B3959772@computer.org>
Date: Thu, 6 Jun 2013 23:23:14 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <F150B330-73F7-4208-9DE2-F070EFF60C7A@gmail.com>
References: <F0CDFEAE-F5E5-485D-98AF-9629B3959772@computer.org>
To: Eric McMurry <emcmurry@computer.org>
X-Mailer: Apple Mail (2.1503)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] overload control reqs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 20:23:27 -0000

Thanks Eric.

- Jouni

On Jun 6, 2013, at 11:10 PM, Eric McMurry <emcmurry@computer.org> wrote:

> There is a new version of the overload control reqs.  This contains =
only minor editorial changes resulting from proto writeup.
>=20
>=20
> Filename:	 draft-ietf-dime-overload-reqs
> Revision:	 07
> Title:		 Diameter Overload Control Requirements
> Creation date:	 2013-06-06
> Group:		 dime
> Number of pages: 27
> URL:             =
http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-07.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs
> Htmlized:        =
http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-07
> Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-07
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From ben@nostrum.com  Thu Jun  6 14:58:59 2013
Return-Path: <ben@nostrum.com>
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 2CC2421F93C4 for <dime@ietfa.amsl.com>; Thu,  6 Jun 2013 14:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 OoukJqs8Obkx for <dime@ietfa.amsl.com>; Thu,  6 Jun 2013 14:58:56 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 035FF21F93BA for <dime@ietf.org>; Thu,  6 Jun 2013 14:58:54 -0700 (PDT)
Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r56Lwog5030354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 16:58:50 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <20130606214928.23822.22145.idtracker@ietfa.amsl.com>
Date: Thu, 6 Jun 2013 16:58:50 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <12139FBB-2A3C-483A-90B3-4E795CBBB922@nostrum.com>
References: <20130606214928.23822.22145.idtracker@ietfa.amsl.com>
To: "dime@ietf.org" <dime@ietf.org>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: Re: [Dime] New Version Notification for draft-campbell-dime-overload-issues-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 21:58:59 -0000

Hi everyone,

I just submitted an individual submission draft related to the Diameter =
overload control work. It discusses some issues concerning ability to =
send non-adjacent overload reports  (i.e. reports across non-supporting =
intermediaries--Req 34 in the requirements draft.). It also goes into =
some detail on overload scopes, since that's helpful background for some =
of the non-adjacent issues.  =20

I hope this will help spark some discussion, so that we can make =
progress towards the overload control solution or solutions.

Thanks!

Ben.

On Jun 6, 2013, at 4:49 PM, internet-drafts@ietf.org wrote:

>=20
> A new version of I-D, draft-campbell-dime-overload-issues-00.txt
> has been successfully submitted by Ben Campbell and posted to the
> IETF repository.
>=20
> Filename:	 draft-campbell-dime-overload-issues
> Revision:	 00
> Title:		 Diameter Overload Control Solution Issues
> Creation date:	 2013-06-06
> Group:		 Individual Submission
> Number of pages: 16
> URL:             =
http://www.ietf.org/internet-drafts/draft-campbell-dime-overload-issues-00=
.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-campbell-dime-overload-issues
> Htmlized:        =
http://tools.ietf.org/html/draft-campbell-dime-overload-issues-00
>=20
>=20
> Abstract:
>   The Diameter Maintenance and Extensions (DIME) working group has
>   undertaken an "overload control" work item, with the goal of
>   standardizing a mechanism to allow Diameter nodes to report overload
>   information among themselves.  Requirements currently include, among
>   others, the need to accurately report the scope of overload
>   conditions, and the ability to report overload information between
>   nodes that are not directly connected at the transport layer.  These
>   requirements introduce complex issues.  This document describes =
those
>   issues, in the hope that it will assist the working group's decision
>   process.
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20


From subtlechen@gmail.com  Mon Jun 10 17:20:22 2013
Return-Path: <subtlechen@gmail.com>
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 36AA121F994E for <dime@ietfa.amsl.com>; Mon, 10 Jun 2013 17:20:22 -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, HTML_MESSAGE=0.001, NO_RELAYS=-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 6+Ff6-4uALDE for <dime@ietfa.amsl.com>; Mon, 10 Jun 2013 17:20:21 -0700 (PDT)
Received: from mail-qa0-x242.google.com (mail-qa0-x242.google.com [IPv6:2607:f8b0:400d:c00::242]) by ietfa.amsl.com (Postfix) with ESMTP id 65CBB21F994A for <dime@ietf.org>; Mon, 10 Jun 2013 17:20:21 -0700 (PDT)
Received: by mail-qa0-f66.google.com with SMTP id d13so900907qak.1 for <dime@ietf.org>; Mon, 10 Jun 2013 17:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vs905D433Suh1GojY07KfLkUeAczdrg+ExC6+Dw4hiA=; b=mXDTQsWhruhUVqdMt6bQYT3pO+8Lktwvvv724Me5mQGfyNKFaB6NIyyt6X4I+BJ5xb k94Ykzx6meRNLSn/Olm4W35WGypCh6VhmFCbbth4a5d71gi4yqnptWjDdLY1/X3/Jeau CSiC/B1RA+LvtfiRenbvfWzTodTEgLhqkWeb06mAo4aOa3Img0FMNDmoC1jf97L8so84 Txse8+MoL9rBTD0WIgXmtlPwsKvfHMa42ijcCK+Ur4TOyN3YuBx1qT6tJH1qnSvt6v/G BXWFptmeWOchd6d7ryDUnIzQ8AsMJkjNS3DfSNz3jRoEPHO+W+D06XBLyAoRwk/14WLR idZQ==
MIME-Version: 1.0
X-Received: by 10.224.172.1 with SMTP id j1mr15826627qaz.15.1370910016629; Mon, 10 Jun 2013 17:20:16 -0700 (PDT)
Received: by 10.224.78.147 with HTTP; Mon, 10 Jun 2013 17:20:16 -0700 (PDT)
Date: Tue, 11 Jun 2013 08:20:16 +0800
Message-ID: <CAAb1NgdFaC-iXv6+rDa88j2V5=p-ScHry8avffHJ-tEX0bAdHw@mail.gmail.com>
From: Yan Chen <subtlechen@gmail.com>
To: dime@ietf.org
Content-Type: multipart/alternative; boundary=001a11c2befe8f8be804ded5dc2e
X-Mailman-Approved-At: Mon, 10 Jun 2013 18:37:13 -0700
Subject: [Dime] Some questions regarding RFC 3539
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 00:23:25 -0000

--001a11c2befe8f8be804ded5dc2e
Content-Type: text/plain; charset=ISO-8859-1

Hi, all

I am studying RFC 3539. While I have some difficulties to understand
"Appendix A - Detailed Watchdog Algorithm". Please provide some help.

1) Does AAA client or AAA Server (direct connection scenario) need to
follow the algorithm?
In section 3.4 we have: "The watchdog is used in order to enable a AAA
client or agent to determine when to resend on another connection." Does it
mean the algorithm is only required in AAA client? Without following the
algorithm AAA server would utilize the newly connected link earlier than
AAA client, which would cause some AAA server initiated procedures, such as
RAR, result in failure.

2) If the algorithm is required in AAA server, how to avoid the infinite
loop when both AAA client and AAA server enter "REOPEN" phase?
If the "connection up" event indicates to AAA client and AAA server, both
of them would send DWR to verify the link and enter "REOPEN" phase. While
in this phase only DWA is allowed to be a signal to trigger the state
machine going forward. It seems to me that both sides would discard the DWR
sent by their peer and run into an infinite loop.

3) If the DWR was out of the scope of Non-DWA, how to avoid the
inconsistent states between 2 AAA peers?
The total link verification time by the algorithm would be 2 x Tw + 3 x
(time of DWA - time of DWR). If one side sets its Tw much longer than the
other, it would run into the similar consequence of my question 1) - one
side would utilize the newly connected link earlier than the other.

4) Is RFC 3539 so strictly binding to RFC 3588?
RFC 3588 has many statements referring to RFC 3539, especially in its
transport description. I am quite confused about the coordination between
the state machine logic in the Section 5.6 of RFC 3588 and that in the
Appendix A of RFC 3539. I am wondering the strong binding is necessary to
the application of AAA or very diameter application.

Thanks...

BRs
Chen Yan

--001a11c2befe8f8be804ded5dc2e
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">Hi, all<br><br>I am studying RFC 3539. While I have some difficulties to 
understand &quot;Appendix A - Detailed Watchdog Algorithm&quot;. Please provide 
some help.<br><br>1) Does AAA client or AAA Server (direct connection scenario) need to follow the algorithm?<br>In
 section 3.4 we have: &quot;The watchdog is used in order to enable a AAA 
client or agent to determine when to resend on another connection.&quot; Does
 it mean the algorithm is only required in AAA client? Without following
 the algorithm AAA server would utilize the newly connected link earlier
 than AAA client, which would cause some AAA server initiated 
procedures, such as RAR, result in failure.<br><br>2) If the algorithm is 
required in AAA server, how to avoid the infinite loop when both AAA 
client and AAA server enter &quot;REOPEN&quot; phase?<br>If the &quot;connection up&quot; 
event indicates to AAA client and AAA server, both of them would send 
DWR to verify the link and enter &quot;REOPEN&quot; phase. While in this phase 
only DWA is allowed to be a signal to trigger the state machine going 
forward. It seems to me that both sides would discard the DWR sent by 
their peer and run into an infinite loop.<br><br>3) If the DWR was out of the scope of Non-DWA, how to avoid the inconsistent states between 2 AAA peers?<br>The
 total link verification time by the algorithm would be 2 x Tw + 3 x 
(time of DWA - time of DWR). If one side sets its Tw much longer than 
the other, it would run into the similar consequence of my question 1) -
 one side would utilize the newly connected link earlier than the other.<br><br>4) Is RFC 3539 so strictly binding to RFC 3588?<br>RFC
 3588 has many statements referring to RFC 3539, especially in its 
transport description. I am quite confused about the coordination 
between the state machine logic in the Section 5.6 of RFC 3588 and that 
in the Appendix A of RFC 3539. I am wondering the strong binding is 
necessary to the application of AAA or very diameter application.<br><br>Thanks... <br><br>BRs<br>Chen Yan</div>

--001a11c2befe8f8be804ded5dc2e--

From hannes.tschofenig@gmx.net  Tue Jun 11 03:47:43 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 51EB221F949D for <dime@ietfa.amsl.com>; Tue, 11 Jun 2013 03:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.561
X-Spam-Level: 
X-Spam-Status: No, score=-101.561 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 nUXAgD18nzCG for <dime@ietfa.amsl.com>; Tue, 11 Jun 2013 03:47:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39E21F8F29 for <dime@ietf.org>; Tue, 11 Jun 2013 03:47:38 -0700 (PDT)
Received: from 3capp-gmx-bs61.server.lan ([172.19.170.145]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LbfGf-1U5uxX2hXH-00lAMZ; Tue, 11 Jun 2013 12:47:36 +0200
Received: from [194.251.119.199] by 3capp-gmx-bs61.server.lan with HTTP; Tue Jun 11 12:47:36 CEST 2013
MIME-Version: 1.0
Message-ID: <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61>
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: lionel.morand@orange.com
Content-Type: text/html; charset=UTF-8
Date: Tue, 11 Jun 2013 12:47:36 +0200 (CEST)
Importance: normal
Sensitivity: Normal
In-Reply-To: <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>, <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K0:HX95ovyfFORasgSIrbqHALagG9MLYJlk5Bia5JFkwEE lbsIOZ/jGIPkFlNHk6DjB1QFtXoyniqMO5d8wY78/Ole6DTS5O K/0NsUmZbnRDz3ygE83YI99sWwwv95VjZyv/HZLVnf9zppi32z sBg0rT8OnwB+zJ4L48Oz7kTZNp+ViO4WAHzuOBuEWgxiVaN/AW 1OnzJ3caQfZaNashlM6T8tyXuQo2xKwxQTPdPECFtC6sCjZES/ X+U2Xi8bqwdr5hWE+LYkhVv+rgzDbQxgKkCS5A8hiPAV5+pH8C h3kiPI=
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 10:47:43 -0000

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Lionel,&nbsp;</div>

<div>&nbsp;</div>

<div>thanks for the response.</div>

<div>&nbsp;</div>

<div>
<div name="quoted-content" style="font-family: Verdana; font-size: 12px; line-height: 19.1875px;">Switching back to&nbsp;&quot;the Diameter base protocol&quot; is good for me.&nbsp;We should try to avoid creating additional work for the RFC Editor. I will change it.&nbsp;</div>

<div>&nbsp;</div>

<div>Version -18 is good for me. I was onlywondering whether it would make sense to add a short section about what steps to take when defining new extensions (in terms of interacting with IANA, for example).&nbsp;</div>
</div>

<div>&nbsp;</div>

<div>Ciao<br/>
Hannes</div>

<div>&nbsp;</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Donnerstag, 06. Juni 2013 um 21:09 Uhr<br/>
<b>Von:</b>&nbsp;lionel.morand@orange.com<br/>
<b>An:</b>&nbsp;&quot;internet-drafts@ietf.org&quot; &lt;internet-drafts@ietf.org&gt;, &quot;i-d-announce@ietf.org&quot; &lt;i-d-announce@ietf.org&gt;<br/>
<b>Cc:</b>&nbsp;&quot;dime@ietf.org&quot; &lt;dime@ietf.org&gt;<br/>
<b>Betreff:</b>&nbsp;Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt</div>

<div name="quoted-content">Hi,<br/>
<br/>
The version covers the changes proposed by the detailed review done by Hannes (thank you!).<br/>
Most of them are OK and taken into account in this new version... except one:<br/>
<br/>
In the RFC 6733, the correct wording used is &quot;the Diameter base protocol&quot; and not &quot;Diameter Base Protocol&quot;. I have received the same comment in the recent past! :)</div>

<div name="quoted-content">&nbsp;</div>

<div name="quoted-content">&nbsp;</div>

<div name="quoted-content"><br/>
Hannes, please confirm that this version is OK. If it is, the WGLC on this document is finished and we can move forward.</div>

<div name="quoted-content">&nbsp;</div>

<div name="quoted-content">&nbsp;</div>

<div name="quoted-content">Ciao<br/>
Hannes</div>

<div name="quoted-content"><br/>
<br/>
Regards,<br/>
<br/>
Lionel<br/>
<br/>
-----Message d&#39;origine-----<br/>
De&nbsp;: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de internet-drafts@ietf.org<br/>
Envoy&eacute;&nbsp;: jeudi 6 juin 2013 21:03<br/>
&Agrave;&nbsp;: i-d-announce@ietf.org<br/>
Cc&nbsp;: dime@ietf.org<br/>
Objet&nbsp;: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt<br/>
<br/>
<br/>
A New Internet-Draft is available from the on-line Internet-Drafts directories.<br/>
This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.<br/>
<br/>
Title : Diameter Applications Design Guidelines<br/>
Author(s) : Lionel Morand<br/>
Victor Fajardo<br/>
Hannes Tschofenig<br/>
Filename : draft-ietf-dime-app-design-guide-18.txt<br/>
Pages : 21<br/>
Date : 2013-06-06<br/>
<br/>
Abstract:<br/>
The Diameter base protocol provides facilities for protocol<br/>
extensibility enabling to define new Diameter applications or modify<br/>
existing applications. This document is a companion document to the<br/>
Diameter Base protocol that further explains and clarifies the rules<br/>
to extend Diameter. It is meant as a guidelines document and<br/>
therefore as informative in nature.<br/>
<br/>
<br/>
The IETF datatracker status page for this draft is:<br/>
<a href="https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide</a><br/>
<br/>
There&#39;s also a htmlized version available at:<br/>
<a href="http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18" target="_blank">http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18</a><br/>
<br/>
A diff from the previous version is available at:<br/>
<a href="http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-18" target="_blank">http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-18</a><br/>
<br/>
<br/>
Internet-Drafts are also available by anonymous FTP at:<br/>
ftp://ftp.ietf.org/internet-drafts/<br/>
<br/>
_______________________________________________<br/>
DiME mailing list<br/>
DiME@ietf.org<br/>
<a href="https://www.ietf.org/mailman/listinfo/dime" target="_blank">https://www.ietf.org/mailman/listinfo/dime</a><br/>
<br/>
_________________________________________________________________________________________________________________________<br/>
<br/>
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc<br/>
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler<br/>
a l&#39;expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d&#39;alteration,<br/>
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.<br/>
<br/>
This message and its attachments may contain confidential or privileged information that may be protected by law;<br/>
they should not be distributed, used or copied without authorisation.<br/>
If you have received this email in error, please notify the sender and delete this message and its attachments.<br/>
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.<br/>
Thank you.<br/>
<br/>
_______________________________________________<br/>
DiME mailing list<br/>
DiME@ietf.org<br/>
<a href="https://www.ietf.org/mailman/listinfo/dime" target="_blank">https://www.ietf.org/mailman/listinfo/dime</a></div>
</div>
</div>
</div></div></body></html>

From lionel.morand@orange.com  Tue Jun 11 03:52:35 2013
Return-Path: <lionel.morand@orange.com>
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 4C5FC21F9476 for <dime@ietfa.amsl.com>; Tue, 11 Jun 2013 03:52:35 -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 iniJ+o+lXNUF for <dime@ietfa.amsl.com>; Tue, 11 Jun 2013 03:52:31 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBA721F90CD for <dime@ietf.org>; Tue, 11 Jun 2013 03:52:30 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0A7FD18C75D; Tue, 11 Jun 2013 12:52:29 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D5C7627C08A; Tue, 11 Jun 2013 12:52:28 +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; Tue, 11 Jun 2013 12:52:28 +0200
From: <lionel.morand@orange.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Thread-Topic: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
Thread-Index: AQHOZpEYtdNQzlQv2kKaM58z0FF03pkwVdDg
Date: Tue, 11 Jun 2013 10:52:28 +0000
Message-ID: <387_1370947948_51B7016C_387_4637_1_6B7134B31289DC4FAF731D844122B36E1FF9B3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>, <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup> <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61>
In-Reply-To: <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61>
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_6B7134B31289DC4FAF731D844122B36E1FF9B3PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.11.85117
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 10:52:35 -0000

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

SGkgSGFubmVzLA0KDQpPSyBpbiB0aGUgcHJpbmNpcGxlLiBDb3VsZCB5b3UgcHJvdmlkZSBhIHNo
b3J0IHRleHQgdGhhdCBJIGNvdWxkIGluc2VydCBpbiB0aGUgZHJhZnQ/IEl0IHNob3VsZCBub3Qg
YmUgdG9vIGxvbmcuDQoNCkxpb25lbA0KDQpEZSA6IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86
SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldF0NCkVudm95w6kgOiBtYXJkaSAxMSBqdWluIDIwMTMg
MTI6NDgNCsOAIDogTU9SQU5EIExpb25lbCBPTE5DL09MTg0KQ2MgOiBkaW1lQGlldGYub3JnDQpP
YmpldCA6IEF3OiBSZTogW0RpbWVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGltZS1hcHAtZGVz
aWduLWd1aWRlLTE4LnR4dA0KDQpIaSBMaW9uZWwsDQoNCnRoYW5rcyBmb3IgdGhlIHJlc3BvbnNl
Lg0KDQpTd2l0Y2hpbmcgYmFjayB0byAidGhlIERpYW1ldGVyIGJhc2UgcHJvdG9jb2wiIGlzIGdv
b2QgZm9yIG1lLiBXZSBzaG91bGQgdHJ5IHRvIGF2b2lkIGNyZWF0aW5nIGFkZGl0aW9uYWwgd29y
ayBmb3IgdGhlIFJGQyBFZGl0b3IuIEkgd2lsbCBjaGFuZ2UgaXQuDQoNClZlcnNpb24gLTE4IGlz
IGdvb2QgZm9yIG1lLiBJIHdhcyBvbmx5d29uZGVyaW5nIHdoZXRoZXIgaXQgd291bGQgbWFrZSBz
ZW5zZSB0byBhZGQgYSBzaG9ydCBzZWN0aW9uIGFib3V0IHdoYXQgc3RlcHMgdG8gdGFrZSB3aGVu
IGRlZmluaW5nIG5ldyBleHRlbnNpb25zIChpbiB0ZXJtcyBvZiBpbnRlcmFjdGluZyB3aXRoIElB
TkEsIGZvciBleGFtcGxlKS4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KR2VzZW5kZXQ6IERvbm5lcnN0
YWcsIDA2LiBKdW5pIDIwMTMgdW0gMjE6MDkgVWhyDQpWb246IGxpb25lbC5tb3JhbmRAb3Jhbmdl
LmNvbQ0KQW46ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmc+LCAiaS1kLWFubm91bmNlQGlldGYub3JnIiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0K
Q2M6ICJkaW1lQGlldGYub3JnIiA8ZGltZUBpZXRmLm9yZz4NCkJldHJlZmY6IFJlOiBbRGltZV0g
SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaW1lLWFwcC1kZXNpZ24tZ3VpZGUtMTgudHh0DQpIaSwN
Cg0KVGhlIHZlcnNpb24gY292ZXJzIHRoZSBjaGFuZ2VzIHByb3Bvc2VkIGJ5IHRoZSBkZXRhaWxl
ZCByZXZpZXcgZG9uZSBieSBIYW5uZXMgKHRoYW5rIHlvdSEpLg0KTW9zdCBvZiB0aGVtIGFyZSBP
SyBhbmQgdGFrZW4gaW50byBhY2NvdW50IGluIHRoaXMgbmV3IHZlcnNpb24uLi4gZXhjZXB0IG9u
ZToNCg0KSW4gdGhlIFJGQyA2NzMzLCB0aGUgY29ycmVjdCB3b3JkaW5nIHVzZWQgaXMgInRoZSBE
aWFtZXRlciBiYXNlIHByb3RvY29sIiBhbmQgbm90ICJEaWFtZXRlciBCYXNlIFByb3RvY29sIi4g
SSBoYXZlIHJlY2VpdmVkIHRoZSBzYW1lIGNvbW1lbnQgaW4gdGhlIHJlY2VudCBwYXN0ISA6KQ0K
DQoNCg0KSGFubmVzLCBwbGVhc2UgY29uZmlybSB0aGF0IHRoaXMgdmVyc2lvbiBpcyBPSy4gSWYg
aXQgaXMsIHRoZSBXR0xDIG9uIHRoaXMgZG9jdW1lbnQgaXMgZmluaXNoZWQgYW5kIHdlIGNhbiBt
b3ZlIGZvcndhcmQuDQoNCg0KQ2lhbw0KSGFubmVzDQoNCg0KUmVnYXJkcywNCg0KTGlvbmVsDQoN
Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGUgOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcg
W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgaW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnDQpFbnZvecOpIDogamV1ZGkgNiBqdWluIDIwMTMgMjE6MDMNCsOAIDogaS1k
LWFubm91bmNlQGlldGYub3JnDQpDYyA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogW0RpbWVdIEkt
RCBBY3Rpb246IGRyYWZ0LWlldGYtZGltZS1hcHAtZGVzaWduLWd1aWRlLTE4LnR4dA0KDQoNCkEg
TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0
LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIERp
YW1ldGVyIE1haW50ZW5hbmNlIGFuZCBFeHRlbnNpb25zIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElF
VEYuDQoNClRpdGxlIDogRGlhbWV0ZXIgQXBwbGljYXRpb25zIERlc2lnbiBHdWlkZWxpbmVzDQpB
dXRob3IocykgOiBMaW9uZWwgTW9yYW5kDQpWaWN0b3IgRmFqYXJkbw0KSGFubmVzIFRzY2hvZmVu
aWcNCkZpbGVuYW1lIDogZHJhZnQtaWV0Zi1kaW1lLWFwcC1kZXNpZ24tZ3VpZGUtMTgudHh0DQpQ
YWdlcyA6IDIxDQpEYXRlIDogMjAxMy0wNi0wNg0KDQpBYnN0cmFjdDoNClRoZSBEaWFtZXRlciBi
YXNlIHByb3RvY29sIHByb3ZpZGVzIGZhY2lsaXRpZXMgZm9yIHByb3RvY29sDQpleHRlbnNpYmls
aXR5IGVuYWJsaW5nIHRvIGRlZmluZSBuZXcgRGlhbWV0ZXIgYXBwbGljYXRpb25zIG9yIG1vZGlm
eQ0KZXhpc3RpbmcgYXBwbGljYXRpb25zLiBUaGlzIGRvY3VtZW50IGlzIGEgY29tcGFuaW9uIGRv
Y3VtZW50IHRvIHRoZQ0KRGlhbWV0ZXIgQmFzZSBwcm90b2NvbCB0aGF0IGZ1cnRoZXIgZXhwbGFp
bnMgYW5kIGNsYXJpZmllcyB0aGUgcnVsZXMNCnRvIGV4dGVuZCBEaWFtZXRlci4gSXQgaXMgbWVh
bnQgYXMgYSBndWlkZWxpbmVzIGRvY3VtZW50IGFuZA0KdGhlcmVmb3JlIGFzIGluZm9ybWF0aXZl
IGluIG5hdHVyZS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp
cyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt
ZGltZS1hcHAtZGVzaWduLWd1aWRlDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g
YXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaW1l
LWFwcC1kZXNpZ24tZ3VpZGUtMTgNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g
aXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt
aWV0Zi1kaW1lLWFwcC1kZXNpZ24tZ3VpZGUtMTgNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFs
c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQg
c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m
aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUg
ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg
YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEg
bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu
IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp
b24sDQpGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl
IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4N
Cg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50
aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh
dzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp
dHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29t
IC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm
aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1F
QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly
IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk
b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh
dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1
aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl
IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz
Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0
b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv
dSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg
Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi
ZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg
b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp
cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp
cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg
RnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo
YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg
MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x
OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFu
YTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyog
U3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp
bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi
bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0
IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4N
Cjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAg
djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhpIEhhbm5lcyw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ow0KY29sb3I6IzFGNDk3RCI+T0sgaW4gdGhlIHByaW5jaXBsZS4gQ291bGQgeW91IHByb3Zp
ZGUgYSBzaG9ydCB0ZXh0IHRoYXQgSSBjb3VsZCBpbnNlcnQgaW4gdGhlIGRyYWZ0PyBJdCBzaG91
bGQgbm90IGJlIHRvbyBsb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3
RCI+TGlvbmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEhhbm5lcyBU
c2Nob2ZlbmlnIFttYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldF0NCjxicj4NCjxiPkVu
dm95w6kmbmJzcDs6PC9iPiBtYXJkaSAxMSBqdWluIDIwMTMgMTI6NDg8YnI+DQo8Yj7DgCZuYnNw
Ozo8L2I+IE1PUkFORCBMaW9uZWwgT0xOQy9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IGRpbWVA
aWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IEF3OiBSZTogW0RpbWVdIEktRCBBY3Rp
b246IGRyYWZ0LWlldGYtZGltZS1hcHAtZGVzaWduLWd1aWRlLTE4LnR4dDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBMaW9uZWwsJm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50aGFu
a3MgZm9yIHRoZSByZXNwb25zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBuYW1lPSJxdW90ZWQt
Y29udGVudCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Td2l0Y2hpbmcgYmFjayB0byZuYnNwOyZx
dW90O3RoZSBEaWFtZXRlciBiYXNlIHByb3RvY29sJnF1b3Q7IGlzIGdvb2QgZm9yIG1lLiZuYnNw
O1dlIHNob3VsZCB0cnkgdG8gYXZvaWQgY3JlYXRpbmcgYWRkaXRpb25hbCB3b3JrIGZvciB0aGUg
UkZDIEVkaXRvci4gSSB3aWxsIGNoYW5nZQ0KIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VmVyc2lvbiAt
MTggaXMgZ29vZCBmb3IgbWUuIEkgd2FzIG9ubHl3b25kZXJpbmcgd2hldGhlciBpdCB3b3VsZCBt
YWtlIHNlbnNlIHRvIGFkZCBhIHNob3J0IHNlY3Rpb24gYWJvdXQgd2hhdCBzdGVwcyB0byB0YWtl
IHdoZW4gZGVmaW5pbmcgbmV3IGV4dGVuc2lvbnMgKGluIHRlcm1zIG9mIGludGVyYWN0aW5nDQog
d2l0aCBJQU5BLCBmb3IgZXhhbXBsZSkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNpYW88YnI+
DQpIYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0MzRDlFNSAxLjVwdDtwYWRkaW5n
OjBjbSAwY20gMGNtIDguMHB0Ow0KbWFyZ2luLWxlZnQ6Ny41cHQ7bWFyZ2luLXRvcDo3LjVwdDtt
YXJnaW4tcmlnaHQ6My43NXB0O21hcmdpbi1ib3R0b206My43NXB0Ow0Kd29yZC13cmFwOiBicmVh
ay13b3JkOy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy
LXdoaXRlLXNwYWNlIiBuYW1lPSJxdW90ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu
NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5HZXNlbmRldDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtE
b25uZXJzdGFnLCAwNi4gSnVuaSAyMDEzIHVtIDIxOjA5IFVocjxicj4NCjxiPlZvbjo8L2I+Jm5i
c3A7bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPGJyPg0KPGI+QW46PC9iPiZuYnNwOyZxdW90O2lu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZxdW90OyAmbHQ7aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
Jmd0OywgJnF1b3Q7aS1kLWFubm91bmNlQGlldGYub3JnJnF1b3Q7ICZsdDtpLWQtYW5ub3VuY2VA
aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiZuYnNwOyZxdW90O2RpbWVAaWV0Zi5vcmcmcXVv
dDsgJmx0O2RpbWVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+QmV0cmVmZjo8L2I+Jm5ic3A7UmU6IFtE
aW1lXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRpbWUtYXBwLWRlc2lnbi1ndWlkZS0xOC50eHQ8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgbmFtZT0icXVvdGVkLWNvbnRlbnQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpLDxi
cj4NCjxicj4NClRoZSB2ZXJzaW9uIGNvdmVycyB0aGUgY2hhbmdlcyBwcm9wb3NlZCBieSB0aGUg
ZGV0YWlsZWQgcmV2aWV3IGRvbmUgYnkgSGFubmVzICh0aGFuayB5b3UhKS48YnI+DQpNb3N0IG9m
IHRoZW0gYXJlIE9LIGFuZCB0YWtlbiBpbnRvIGFjY291bnQgaW4gdGhpcyBuZXcgdmVyc2lvbi4u
LiBleGNlcHQgb25lOjxicj4NCjxicj4NCkluIHRoZSBSRkMgNjczMywgdGhlIGNvcnJlY3Qgd29y
ZGluZyB1c2VkIGlzICZxdW90O3RoZSBEaWFtZXRlciBiYXNlIHByb3RvY29sJnF1b3Q7IGFuZCBu
b3QgJnF1b3Q7RGlhbWV0ZXIgQmFzZSBQcm90b2NvbCZxdW90Oy4gSSBoYXZlIHJlY2VpdmVkIHRo
ZSBzYW1lIGNvbW1lbnQgaW4gdGhlIHJlY2VudCBwYXN0ISA6KTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBuYW1lPSJxdW90ZWQtY29udGVudCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh
bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2IG5hbWU9InF1b3RlZC1jb250ZW50Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy
ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXYgbmFtZT0icXVvdGVkLWNvbnRlbnQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtW
ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkhhbm5lcywgcGxlYXNl
IGNvbmZpcm0gdGhhdCB0aGlzIHZlcnNpb24gaXMgT0suIElmIGl0IGlzLCB0aGUgV0dMQyBvbiB0
aGlzIGRvY3VtZW50IGlzIGZpbmlzaGVkIGFuZCB3ZSBjYW4gbW92ZSBmb3J3YXJkLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBuYW1lPSJxdW90ZWQtY29udGVudCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IG5hbWU9InF1b3RlZC1jb250ZW50Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgbmFtZT0icXVvdGVkLWNvbnRlbnQiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNpYW88YnI+
DQpIYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgbmFtZT0icXVvdGVk
LWNvbnRlbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KTGlvbmVsPGJyPg0KPGJyPg0KLS0t
LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KRGUmbmJzcDs6IGRpbWUtYm91bmNlc0BpZXRm
Lm9yZyBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBpbnRlcm5l
dC1kcmFmdHNAaWV0Zi5vcmc8YnI+DQpFbnZvecOpJm5ic3A7OiBqZXVkaSA2IGp1aW4gMjAxMyAy
MTowMzxicj4NCsOAJm5ic3A7OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQpDYyZuYnNwOzog
ZGltZUBpZXRmLm9yZzxicj4NCk9iamV0Jm5ic3A7OiBbRGltZV0gSS1EIEFjdGlvbjogZHJhZnQt
aWV0Zi1kaW1lLWFwcC1kZXNpZ24tZ3VpZGUtMTgudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBOZXcg
SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh
ZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIERp
YW1ldGVyIE1haW50ZW5hbmNlIGFuZCBFeHRlbnNpb25zIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElF
VEYuPGJyPg0KPGJyPg0KVGl0bGUgOiBEaWFtZXRlciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRl
bGluZXM8YnI+DQpBdXRob3IocykgOiBMaW9uZWwgTW9yYW5kPGJyPg0KVmljdG9yIEZhamFyZG88
YnI+DQpIYW5uZXMgVHNjaG9mZW5pZzxicj4NCkZpbGVuYW1lIDogZHJhZnQtaWV0Zi1kaW1lLWFw
cC1kZXNpZ24tZ3VpZGUtMTgudHh0PGJyPg0KUGFnZXMgOiAyMTxicj4NCkRhdGUgOiAyMDEzLTA2
LTA2PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KVGhlIERpYW1ldGVyIGJhc2UgcHJvdG9jb2wg
cHJvdmlkZXMgZmFjaWxpdGllcyBmb3IgcHJvdG9jb2w8YnI+DQpleHRlbnNpYmlsaXR5IGVuYWJs
aW5nIHRvIGRlZmluZSBuZXcgRGlhbWV0ZXIgYXBwbGljYXRpb25zIG9yIG1vZGlmeTxicj4NCmV4
aXN0aW5nIGFwcGxpY2F0aW9ucy4gVGhpcyBkb2N1bWVudCBpcyBhIGNvbXBhbmlvbiBkb2N1bWVu
dCB0byB0aGU8YnI+DQpEaWFtZXRlciBCYXNlIHByb3RvY29sIHRoYXQgZnVydGhlciBleHBsYWlu
cyBhbmQgY2xhcmlmaWVzIHRoZSBydWxlczxicj4NCnRvIGV4dGVuZCBEaWFtZXRlci4gSXQgaXMg
bWVhbnQgYXMgYSBndWlkZWxpbmVzIGRvY3VtZW50IGFuZDxicj4NCnRoZXJlZm9yZSBhcyBpbmZv
cm1hdGl2ZSBpbiBuYXR1cmUuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIg
c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLWFwcC1kZXNpZ24tZ3VpZGUiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm
LWRpbWUtYXBwLWRlc2lnbi1ndWlkZTwvYT48YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28gYSBodG1s
aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRpbWUtYXBwLWRlc2lnbi1ndWlkZS0xOCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGltZS1hcHAtZGVz
aWduLWd1aWRlLTE4PC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz
aW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Jm
Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRpbWUtYXBwLWRlc2lnbi1ndWlkZS0xOCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGltZS1h
cHAtZGVzaWduLWd1aWRlLTE4PC9hPjxicj4NCjxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBh
cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQpmdHA6Ly9mdHAuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQpEaU1F
QGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9kaW1lIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kaW1lPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNzYWdl
IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg
Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8YnI+DQpw
YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g
U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu
YWxlcjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll
Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl
cyBkJ2FsdGVyYXRpb24sPGJyPg0KRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0
ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm
YWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp
YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQpJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+DQpBcyBl
bWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFi
bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp
ZmllZC48YnI+DQpUaGFuayB5b3UuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCkRpTUVA
aWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RpbWUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2RpbWU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0
IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u
ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUg
ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg
YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBs
J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g
TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv
biwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz
aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg
b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0
aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0
aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFu
Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo
YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6B7134B31289DC4FAF731D844122B36E1FF9B3PEXCVZYM13corpora_--

From hannes.tschofenig@gmx.net  Tue Jun 11 04:48:34 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 E634D21F93B9 for <dime@ietfa.amsl.com>; Tue, 11 Jun 2013 04:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.77
X-Spam-Level: 
X-Spam-Status: No, score=-101.77 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 l2Szg0jM8SCt for <dime@ietfa.amsl.com>; Tue, 11 Jun 2013 04:48:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C621F9399 for <dime@ietf.org>; Tue, 11 Jun 2013 04:48:30 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MP3Jh-1Ug3fm25Ch-006LvG for <dime@ietf.org>; Tue, 11 Jun 2013 13:48:29 +0200
Received: (qmail invoked by alias); 11 Jun 2013 11:48:29 -0000
Received: from unknown (EHLO [10.255.130.153]) [194.251.119.201] by mail.gmx.net (mp020) with SMTP; 11 Jun 2013 13:48:29 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/5rud2kP35dsEPHyZADAraPIwBDD+37fCimNmMhq NHU+xjUVD8pra5
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <387_1370947948_51B7016C_387_4637_1_6B7134B31289DC4FAF731D844122B36E1FF9B3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Tue, 11 Jun 2013 14:48:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9126B39B-A83D-44E1-912D-A35380E8EDA2@gmx.net>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>, <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup> <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61> <387_1370947948_51B7016C_387_4637_1_6B7134B31289DC4FAF731D844122B36E1FF9B3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: <lionel.morand@orange.com>
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 11:48:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes, I can give it a try to see whether the group thinks it is =
worthwhile to add this additional piece of information.=20

On a high level this is what I plan to say:

- --------

There are four main ways to extend Diameter and the process for defining =
new functionality slightly varies based on the different extensions:=20
=20
   1.  Defining new AVP values: The specifications that define the AVP =
and the AVP values provide guidance for defining new values and also =
provide the policy for adding these values. For example, RFC 5777 =
defines AVPs for traffic classification and QoS. Among the AVP it =
defines the Treatment-Action AVP, which contains a list of actions =
(drop, shape, mark, permit). New values can be defined by following the =
policy outlined in Section 10.3 of RFC 5777. As a second example, the =
Diameter base specification defines a number of AVPs. The Result-Code =
AVP is one of them and, according to Section 11.3.2 of RFC 6733, new =
values are available for assignment via IETF Review.

   2.  Creating new AVPs: New AVPs can be defined in one of two ways: =
(a) as vendor-specific AVPs and (b) within the IETF AVP codespace. In =
case (a) a vendor needs to obtain an enterprise number (which is then =
carried inside the Vendor-ID field of the AVP) through IANA. When a =
vendor-specific AVP is used then the vendor has to manage it's AVP code =
space internally. The absence of a Vendor-ID or a Vendor-ID value of =
zero (0) identifies the IETF AVP Codes namespace, which is under IANA =
control. The policy for registering AVPs under the IANA controlled =
namespace is described in Section 11.1.1 of RFC 6733.=20

Associated with AVPs are AVP flags, which requires Standards Action for =
extensions [RFC5226].=20

   3.  Creating new commands: Unlike the AVP code space the command code =
space is flat but the number range is divided into different chunks for =
different purposes and with different registration policies. There are =
three number ranges, namely a range for command codes allocated via IETF =
review, a number range for vendor-specific command codes with a =
First-Come, First-Serve policy, and a number range reserved for =
experimental and testing purposes.=20

Associated with commands is the Command Flags field, which requires =
Standards Action for extensions.=20

   4.  Creating new applications: Similarly to the command code space =
the application id space is flat but divided into two number ranges, =
namely one for for vendor
   specific applications, on a First-Come, First-Serve basis, and =
another one space with a Specification Required policy.=20

The IANA AAA parameters page can be found at =
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml and =
the enterprise number IANA page is available at =
http://www.iana.org/assignments/enterprise-numbers

Note: Register your extensions to avoid interoperability problems which =
can occur when two implementations using the same code point but with =
different semantic are run in the same network. The registration policy =
has been simplified with the publication of RFC 6733 and the number =
space is large enough to avoid exhaustion.=20

- --------

Ciao
Hannes

On Jun 11, 2013, at 1:52 PM, <lionel.morand@orange.com> wrote:

> Hi Hannes,
> =20
> OK in the principle. Could you provide a short text that I could =
insert in the draft? It should not be too long.
> =20
> Lionel
> =20
> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Envoy=E9 : mardi 11 juin 2013 12:48
> =C0 : MORAND Lionel OLNC/OLN
> Cc : dime@ietf.org
> Objet : Aw: Re: [Dime] I-D Action: =
draft-ietf-dime-app-design-guide-18.txt
> =20
> Hi Lionel,=20
> =20
> thanks for the response.
> =20
> Switching back to "the Diameter base protocol" is good for me. We =
should try to avoid creating additional work for the RFC Editor. I will =
change it.=20
> =20
> Version -18 is good for me. I was onlywondering whether it would make =
sense to add a short section about what steps to take when defining new =
extensions (in terms of interacting with IANA, for example).=20
> =20
> Ciao
> Hannes
> =20
> =20
> Gesendet: Donnerstag, 06. Juni 2013 um 21:09 Uhr
> Von: lionel.morand@orange.com
> An: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, =
"i-d-announce@ietf.org" <i-d-announce@ietf.org>
> Cc: "dime@ietf.org" <dime@ietf.org>
> Betreff: Re: [Dime] I-D Action: =
draft-ietf-dime-app-design-guide-18.txt
> Hi,
>=20
> The version covers the changes proposed by the detailed review done by =
Hannes (thank you!).
> Most of them are OK and taken into account in this new version... =
except one:
>=20
> In the RFC 6733, the correct wording used is "the Diameter base =
protocol" and not "Diameter Base Protocol". I have received the same =
comment in the recent past! :)
> =20
> =20
>=20
> Hannes, please confirm that this version is OK. If it is, the WGLC on =
this document is finished and we can move forward.
> =20
> =20
> Ciao
> Hannes
>=20
>=20
> Regards,
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de internet-drafts@ietf.org
> Envoy=E9 : jeudi 6 juin 2013 21:03
> =C0 : i-d-announce@ietf.org
> Cc : dime@ietf.org
> Objet : [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>=20
>=20
> 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.
>=20
> Title : Diameter Applications Design Guidelines
> Author(s) : Lionel Morand
> Victor Fajardo
> Hannes Tschofenig
> Filename : draft-ietf-dime-app-design-guide-18.txt
> Pages : 21
> Date : 2013-06-06
>=20
> 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.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-18
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.
> Thank you.
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJRtw6LAAoJEGhJURNOOiAteI8H/33XsWes4eZKapGZVNOpW+p2
5PJDwJr3rcshajT4HzCRraD2Z07zn2JRAhG3rMdpwOpGjt9eOxsIgLcBPjS2N9rm
vIH1QSssekt3O9z4pO++GdFeczclnlzYkQE68R2Jhvo9lOVFv3MuW+N3ryoUGBmn
NLk5bvP5IHdrxM8TNeT0xK1bLtB7tFkthyrfIIlfN2GeD0eKDqGbp4QY1x3Q4zCY
u12b9AwVOOT09lJ/jS4EueT9yaiaUkB4siqpQdlmWUVZU1Dhn2j0D1xBsiq7OMJR
1TkaU+4DgiT9xe0vQDwUckoahW643wrkgY6jeP5oYhloMfzPr5m3/HXWkUWlgd4=3D
=3DDCtz
-----END PGP SIGNATURE-----

From nh.jones01@gmail.com  Fri Jun 14 05:37:06 2013
Return-Path: <nh.jones01@gmail.com>
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 07C1021F9C88 for <dime@ietfa.amsl.com>; Fri, 14 Jun 2013 05:37:06 -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 gaF5fhxKoPrM for <dime@ietfa.amsl.com>; Fri, 14 Jun 2013 05:37:05 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A5EBA21F9AEE for <dime@ietf.org>; Fri, 14 Jun 2013 05:37:05 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz11so615789pad.30 for <dime@ietf.org>; Fri, 14 Jun 2013 05:37:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:to:from:reply-to:subject:message-id:x-priority:x-mailer :mime-version:content-transfer-encoding:content-type; bh=u3ZUA+THAG4OZev9HJ9UNMV0PWx/9SIMJ8q8Bo3zvU4=; b=RJShFkQBVqjfR/TD/CEEsLFP5NtHEaqkn4L0LtRkyCkCvl/luWXnw0a1uPaS2unrjQ zsp/KXURNntZe6EbrjtzmO7cblXmDYL2jtKCdeE9ePPqyQz0x6FClXXqxvJz8TMwWgnR 6Skg/o56mxMaLAsvjLvNaivTIYX821aVLQtKzUIKEQiPMIaWu2kw4DCkIcPHGzdoFKWY TGF4MzE0MxPirRHW+VSq7Tofa2bhsdjiJQRPVnTR+iG6b7mvTt9LHUKrtxCNKnbH0s9w AZN1FZ2exa9wYUAQMayOatfyjSO4IrQHiFG12mU+R+14QrO7vxfgOJDUFtvdvh4c0WJt HTmw==
X-Received: by 10.68.162.1 with SMTP id xw1mr2332457pbb.199.1371213425414; Fri, 14 Jun 2013 05:37:05 -0700 (PDT)
Received: from www.queryhome.com (ec2-54-245-79-134.us-west-2.compute.amazonaws.com. [54.245.79.134]) by mx.google.com with ESMTPSA id at1sm2192409pbc.10.2013.06.14.05.37.04 for <dime@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Jun 2013 05:37:04 -0700 (PDT)
Date: Fri, 14 Jun 2013 12:37:03 +0000
To: dime@ietf.org
From: Norah Jones <nh.jones01@gmail.com>
Message-ID: <abcd1234abc123ab12a0000003806000020000005101@gmail.com>
X-Priority: 3
X-Mailer: CatPHPMailer 5.1 (phpmailer.sourceforge.net)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
Subject: [Dime] Any Opensouce Java Diameter stack?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Norah Jones <nh.jones01@gmail.com>
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 12:37:06 -0000

Hi, 

I am looking for an Open source Diameter stack with Java interface.  Is there one available? 

Thanks,
Norah Jones



From brainslog@gmail.com  Fri Jun 14 06:18:28 2013
Return-Path: <brainslog@gmail.com>
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 DFCEB21F9CA7 for <dime@ietfa.amsl.com>; Fri, 14 Jun 2013 06:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.415
X-Spam-Level: 
X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 AXuajCtIrPQE for <dime@ietfa.amsl.com>; Fri, 14 Jun 2013 06:18:28 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1061521F9C8C for <dime@ietf.org>; Fri, 14 Jun 2013 06:18:27 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id z11so1652563wgg.5 for <dime@ietf.org>; Fri, 14 Jun 2013 06:18:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7o9ufnXJojW59vT+G+xiZJVUBxswc/mtsz1m8Mi0I9Y=; b=gVr6TbgtYI1EoDRX7FCbEdVMlMyjBpJxh51usEpQ7+XzBkvt5Mx6C6aJvqMr7sz9JX 55mENX2Sk5Y08nI6lOr7FyLVnaMZRO4bQXpiLis6H9zOpQ3vRTKfCRHHz76vZ6yLHLh/ AcKQ2XxnsdcgnjbnddnFl3yjzCw2VaMi2uezjgiPeAZYF2Rrt8wxKJrL7I+bjEPfpipP qCswLbje7IhEQdAcyY3M0dwmkCBj3+esuLwx30aRCD+B/m2vcxTQ7NJVBXfF85B5HsJT qwnBk/DTtaU64+sDzXAXM1SOfApIyvdqy9uLCs7WQEJAatr6z2N2Onc9KCs4pY12JSOO Qmew==
X-Received: by 10.194.242.229 with SMTP id wt5mr1390347wjc.36.1371215906741; Fri, 14 Jun 2013 06:18:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.37.7 with HTTP; Fri, 14 Jun 2013 06:17:43 -0700 (PDT)
In-Reply-To: <abcd1234abc123ab12a0000003806000020000005101@gmail.com>
References: <abcd1234abc123ab12a0000003806000020000005101@gmail.com>
From: =?ISO-8859-1?Q?Alexandre_Mendon=E7a?= <brainslog@gmail.com>
Date: Fri, 14 Jun 2013 14:17:43 +0100
Message-ID: <CAEP1nLGRMqDmuyF=iApRR3TRLGvnaj1m36qtnQ2qW6K7cu8CiA@mail.gmail.com>
To: Norah Jones <nh.jones01@gmail.com>
Content-Type: multipart/alternative; boundary=089e013d1c5e08218404df1d152b
Cc: dime@ietf.org
Subject: Re: [Dime] Any Opensouce Java Diameter stack?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 13:18:29 -0000

--089e013d1c5e08218404df1d152b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Norah,

You can have a look at Mobicents Diameter Stack @
https://code.google.com/p/jdiameter/

Best Regards,

*Alexandre Mendon=E7a*
http://ammendonca.blogspot.com/


On Fri, Jun 14, 2013 at 1:37 PM, Norah Jones <nh.jones01@gmail.com> wrote:

> Hi,
>
> I am looking for an Open source Diameter stack with Java interface.  Is
> there one available?
>
> Thanks,
> Norah Jones
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

--089e013d1c5e08218404df1d152b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:&#39;tre=
buchet ms&#39;,sans-serif;color:rgb(11,83,148)">Hi Norah,</div><div class=
=3D"gmail_default" style=3D"font-family:&#39;trebuchet ms&#39;,sans-serif;c=
olor:rgb(11,83,148)">

<br></div><div class=3D"gmail_default" style=3D"font-family:&#39;trebuchet =
ms&#39;,sans-serif;color:rgb(11,83,148)">You can have a look at Mobicents D=
iameter Stack @ <a href=3D"https://code.google.com/p/jdiameter/">https://co=
de.google.com/p/jdiameter/</a></div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_default" style=3D"font-family:&#39;trebuchet ms&#39;,sans-serif;c=
olor:rgb(11,83,148)">Best Regards,</div><div><div dir=3D"ltr"><font face=3D=
"&#39;trebuchet ms&#39;, sans-serif"><div style=3D"color:rgb(0,0,102)">

<br></div><span style=3D"font-size:12px;border-collapse:collapse"><font col=
or=3D"#0b5394"><b>Alexandre Mendon=E7a</b><br><a href=3D"http://ammendonca.=
blogspot.com/" target=3D"_blank">http://ammendonca.blogspot.com/</a></font>=
</span></font></div>

</div>
<br><br><div class=3D"gmail_quote">On Fri, Jun 14, 2013 at 1:37 PM, Norah J=
ones <span dir=3D"ltr">&lt;<a href=3D"mailto:nh.jones01@gmail.com" target=
=3D"_blank">nh.jones01@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

Hi,<br>
<br>
I am looking for an Open source Diameter stack with Java interface. =A0Is t=
here one available?<br>
<br>
Thanks,<br>
Norah Jones<br>
<br>
<br>
_______________________________________________<br>
DiME mailing list<br>
<a href=3D"mailto:DiME@ietf.org">DiME@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dime" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dime</a><br>
</blockquote></div><br></div></div>

--089e013d1c5e08218404df1d152b--

From jouni.nospam@gmail.com  Tue Jun 18 00:43:56 2013
Return-Path: <jouni.nospam@gmail.com>
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 639AE21F9C50 for <dime@ietfa.amsl.com>; Tue, 18 Jun 2013 00:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.228
X-Spam-Level: 
X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 8MfWNjHN8BoY for <dime@ietfa.amsl.com>; Tue, 18 Jun 2013 00:43:50 -0700 (PDT)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8893721F9C57 for <dime@ietf.org>; Tue, 18 Jun 2013 00:43:49 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id 13so3359617lba.30 for <dime@ietf.org>; Tue, 18 Jun 2013 00:43:48 -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:x-mailer; bh=CmfO3HTNFao0s0R0F1BrvaqVABCsk+6KCxDFObhON3k=; b=N5FgrJq/8oC2IXPRa15z3mi5AHwSMSjww/OHBBoT795O9lY5lX1d1unYBpT+xol3i7 3MLFQm9kDGpMZf9D7WgpcKWpnktNklhj2cmfCrr6Vli6/6oxrINtS0z78ed6/QGTor+N Nrr0HKOKRDkSzSW4773j07/10K4y2tZqZQ66a88pUJgjJ4W/woQK2K4JFp/4O5MKSZOq Suaq977dXNcAwpk4B9Q+VizbiRE2Tk/6hTHwTqOzYCphx7HBUg9YxvnNRnOWB2d7phjs IZSudrhwtMq/kdsJehE1tTFPOVfAIwkkLDr0LavEYUy3TZ5uronXicPAFZ1nKr6k3FMT 5xdA==
X-Received: by 10.112.17.74 with SMTP id m10mr516348lbd.18.1371541428403; Tue, 18 Jun 2013 00:43:48 -0700 (PDT)
Received: from [192.168.250.166] ([194.100.71.98]) by mx.google.com with ESMTPSA id n7sm6679297lbd.12.2013.06.18.00.43.44 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 00:43:45 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <9A4AC6D9-BDB5-414E-8DF1-7BC42594250A@gmail.com>
Date: Tue, 18 Jun 2013 10:43:42 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <6C04FADA-FC2F-4B60-9F0C-1CB04AD356AC@gmail.com>
References: <9A4AC6D9-BDB5-414E-8DF1-7BC42594250A@gmail.com>
To: "DiME@ietf.org" <dime@ietf.org>
X-Mailer: Apple Mail (2.1508)
Cc: dime-chairs@tools.ietf.org
Subject: Re: [Dime] Call for agenda items for IETF#87 Berlin meeting
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 07:43:56 -0000

Just a reminder.

- Jouni & Lionel


On May 26, 2013, at 6:35 PM, Jouni <jouni.nospam@gmail.com> wrote:

> Folks,
> 
> We have requested for two hour meeting slot. If you feel like
> presenting your work (be that in the current charter or not),
> send a request to the co-chairs. Obviously, chartered items
> will be prioritized over other topics.
> 
> - Jouni & Lionel
> 


From jouni.nospam@gmail.com  Wed Jun 19 04:17:43 2013
Return-Path: <jouni.nospam@gmail.com>
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 79A6121F99FB for <dime@ietfa.amsl.com>; Wed, 19 Jun 2013 04:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.838
X-Spam-Level: 
X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 26biLJPSpxFH for <dime@ietfa.amsl.com>; Wed, 19 Jun 2013 04:17:42 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2121F99EB for <dime@ietf.org>; Wed, 19 Jun 2013 04:17:42 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ea20so4412054lab.8 for <dime@ietf.org>; Wed, 19 Jun 2013 04:17:37 -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:x-mailer; bh=bemvN5QpXBeKwmoFvwXpQArRXeHVHazstV5YsSiJNt0=; b=G5HbLDyg+aVQbsrfID9x51cGgW+7TU9uj7i0rqhqVt1nwFS9IU5IzvupDHDnLr16UI WlbWMiNPsJufo8FrZxB9u3j06jnhDSNtYRsj0SHqiJKpccy2+OW7ijXbQIDIDrfCYxjT qK79BYSAcOJ3POZyq2fhAqUVv5XYS2iwE99jaRkptJuBIVh2zDBukPvJ2rZzssmn2fN9 sbSm/UwFlUVfuR99FQFCmD6jZeXsRh1wE4rYOxSr2v85YWarnL7V9Geyvx8crswIFjxE Kp2m8ZUfPNQkRU6c0v1WzG8TVUScWtemQ/K64JIOnuHUDRi4z4RY05H0/NBQJOrI7DEE sDRA==
X-Received: by 10.152.9.102 with SMTP id y6mr1161308laa.17.1371640657088; Wed, 19 Jun 2013 04:17:37 -0700 (PDT)
Received: from [192.168.250.158] ([194.100.71.98]) by mx.google.com with ESMTPSA id 8sm8740162lbq.4.2013.06.19.04.17.36 for <dime@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 04:17:36 -0700 (PDT)
From: Jouni Korhonen <jouni.nospam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <92540551-9180-4F05-85D3-0D6482A3ECAE@gmail.com>
Date: Wed, 19 Jun 2013 14:17:35 +0300
To: "DiME@ietf.org" <dime@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [Dime] Progressing draft-ietf-dime-group-signaling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 11:17:43 -0000

Folks,

As you remember we surfaced the draft-ietf-dime-group-signaling I-D =
during overload requirements discussion, see =
http://www.ietf.org/mail-archive/web/dime/current/msg05582.html

In order to resurrect draft-ietf-dime-group-signaling we need to know =
what the WG prefers as the final technical solution. Originally there =
were two approaches: dedicated Group Commands or a single Bulk =
Operations command. Recently (pun intended) a third alternative showed =
up: additional AVPs to turn any existing Diameter command into a group =
command. The late comer also got some backup, at least from French =
speaking part of Europe ;)

So, unless no one has anything against it, we could go for the third =
option. I does seem to fit better e.g. into the overload control needs =
than new commands. If you have concerns on the third (AVP) approach and =
want it to be rejected, then express you voice on the list by 26th June =
EOB (EEST).

- Jouni & Lionel=

From lionel.morand@orange.com  Wed Jun 19 04:27:22 2013
Return-Path: <lionel.morand@orange.com>
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 65BE121F9B10 for <dime@ietfa.amsl.com>; Wed, 19 Jun 2013 04:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 drIYnNvaIdcT for <dime@ietfa.amsl.com>; Wed, 19 Jun 2013 04:27:17 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AE08E21F9B0E for <dime@ietf.org>; Wed, 19 Jun 2013 04:27:16 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4BDE0325559; Wed, 19 Jun 2013 13:27:15 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2C3F523807F; Wed, 19 Jun 2013 13:27: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.0328.009; Wed, 19 Jun 2013 13:27:14 +0200
From: <lionel.morand@orange.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
Thread-Index: AQHOZpmYcYlYnLUCAE6rWjr4yeMOIZk87p/A
Date: Wed, 19 Jun 2013 11:27:14 +0000
Message-ID: <11669_1371641235_51C19593_11669_1841_1_6B7134B31289DC4FAF731D844122B36E205984@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>, <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup> <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61> <387_1370947948_51B7016C_387_4637_1_6B7134B31289DC4FAF731D844122B36E1FF9B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <9126B39B-A83D-44E1-912D-A35380E8EDA2@gmx.net>
In-Reply-To: <9126B39B-A83D-44E1-912D-A35380E8EDA2@gmx.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 11:27:22 -0000

Hi Hannes,

Based on your input, I propose to add a specific section with the content g=
iven below. It may be a little bit redundant with some information already =
given in RFC6733 but I agree that it is worth to repeat the guidelines.
Please comment.

Best Regards,

Lionel

************************
7.  Guidelines for Registrations of Diameter Values

   As summarized in the Section 3 of this document and further described
   in the Section 1.3 of [RFC6733], there are four main ways to extend
   Diameter.  The process for defining new functionality slightly varies
   based on the different extensions.  This section provides protocol
   designers with some guidance regarding the definition and
   registration of values for possible Diameter extensions.

   a. Defining new AVP values

      The specifications defining AVPs and AVP values provide guidance
      for defining new values and the corresponding policy for adding
      these values.  For example, the [RFC5777] defines the Treatment-
      Action AVP which contains a list of valid values corresponding to
      pre-defined actions (drop, shape, mark, permit).  This set of
      values can be extended following the Specification Required policy
      defined in [RFC5226].  As a second example, the Diameter base
      specification [RFC6733] defines the Result-Code AVP that contains
      a 32-bit address space used to identity possible errors.
      According to the Section 11.3.2 of [RFC6733], new values can be
      assigned by IANA via an IETF Review process [RFC5226].

   b. Creating new AVPs

      Two different types of AVP Codes namespaces can be used to create
      a new AVPs:

      *  IETF AVP Codes namespace;

      *  Vendor-specific AVP Codes namespace.

      In the latter case, a vendor needs to be first assigned by IANA
      with a private enterprise number, which can be used within the
      Vendor-Id field of the vendor-specific AVP.  This enterprise
      number delimits a private namespace in which the vendor is
      responsible for vendor-specific AVP code value assignment.  The
      absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP
      header identifies standard AVPs from the IETF AVP Codes namespace
      managed by IANA.  The allocation of code values from the IANA-
      managed namespace is conditioned by an Expert Review of the
      specification defining the AVPs or an IETF review if a block of
      AVPs needs to be assigned.  Moreover, the remaining bits of the
      AVP Flags field of the AVP header can be also assigned via
      Standard Action if the creation of new AVP Flags is desired.

   c. Creating new commands

      Unlike the AVP Code namespace, the Command Code namespace is flat
      but the range of values is subdivided into three chunks with
      distinct IANA registration policies:

      *  A range of standard Command Code values that can be allocated
         via IETF review;

      *  A range of vendor-specific Command Code values that can be
         allocated on a First-Come/First-Served basis;

      *  A range of 2 values reserved only for experimental and testing
         purposes.

      As for AVP Flags, the remaining bits of the Command Flags field of
      the Diameter header can also be assigned via a Standards Action to
      create new Command Flags if required.

   d. Creating new applications

      Similarly to the Command Code namespace, the Application-Id
      namespace is flat but divided into two distinct ranges:

      *  A range of values reserved for standard Application-Ids
         allocated after Expert Review of the specification defining the
         standard application;

      *  A range for values for vendor specific applications, allocated
         by IANA on a First-Come/First-Serve basis.

   The IANA AAA parameters page can be found at http://www.iana.org/
   assignments/aaa-parameters/aaa-parameters.xml and the enterprise
   number IANA page is available at http://www.iana.org/assignments/
   enterprise-numbers.  More details on the policies followed by IANA
   for namespace management (e.g. First-Come/First-Served, Expert
   Review, IETF Review, etc.) can be found in [RFC5226].

   NOTE:
      When the same functionality/extension is used by more than one
      vendor, it is recommended to define a standard extension.
      Moreover, the registration of vendor-specific extension is
      encouraged to avoid interoperability issues in the same network.
      With this aim, the registration policy of vendor-specific
      extension has been simplified with the publication of [RFC6733]
      and the namespace reserved for vendor-specific extensions is large
      enough to avoid exhaustion.

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

-----Message d'origine-----
De=A0: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
Envoy=E9=A0: mardi 11 juin 2013 13:48
=C0=A0: MORAND Lionel OLNC/OLN
Cc=A0: Hannes Tschofenig; dime@ietf.org
Objet=A0: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes, I can give it a try to see whether the group thinks it is worthwhile t=
o add this additional piece of information.=20

On a high level this is what I plan to say:

- --------

There are four main ways to extend Diameter and the process for defining ne=
w functionality slightly varies based on the different extensions:=20
=20
   1.  Defining new AVP values: The specifications that define the AVP and =
the AVP values provide guidance for defining new values and also provide th=
e policy for adding these values. For example, RFC 5777 defines AVPs for tr=
affic classification and QoS. Among the AVP it defines the Treatment-Action=
 AVP, which contains a list of actions (drop, shape, mark, permit). New val=
ues can be defined by following the policy outlined in Section 10.3 of RFC =
5777. As a second example, the Diameter base specification defines a number=
 of AVPs. The Result-Code AVP is one of them and, according to Section 11.3=
.2 of RFC 6733, new values are available for assignment via IETF Review.

   2.  Creating new AVPs: New AVPs can be defined in one of two ways: (a) a=
s vendor-specific AVPs and (b) within the IETF AVP codespace. In case (a) a=
 vendor needs to obtain an enterprise number (which is then carried inside =
the Vendor-ID field of the AVP) through IANA. When a vendor-specific AVP is=
 used then the vendor has to manage it's AVP code space internally. The abs=
ence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF AV=
P Codes namespace, which is under IANA control. The policy for registering =
AVPs under the IANA controlled namespace is described in Section 11.1.1 of =
RFC 6733.=20

Associated with AVPs are AVP flags, which requires Standards Action for ext=
ensions [RFC5226].=20

   3.  Creating new commands: Unlike the AVP code space the command code sp=
ace is flat but the number range is divided into different chunks for diffe=
rent purposes and with different registration policies. There are three num=
ber ranges, namely a range for command codes allocated via IETF review, a n=
umber range for vendor-specific command codes with a First-Come, First-Serv=
e policy, and a number range reserved for experimental and testing purposes=
.=20

Associated with commands is the Command Flags field, which requires Standar=
ds Action for extensions.=20

   4.  Creating new applications: Similarly to the command code space the a=
pplication id space is flat but divided into two number ranges, namely one =
for for vendor
   specific applications, on a First-Come, First-Serve basis, and another o=
ne space with a Specification Required policy.=20

The IANA AAA parameters page can be found at http://www.iana.org/assignment=
s/aaa-parameters/aaa-parameters.xml and the enterprise number IANA page is =
available at http://www.iana.org/assignments/enterprise-numbers

Note: Register your extensions to avoid interoperability problems which can=
 occur when two implementations using the same code point but with differen=
t semantic are run in the same network. The registration policy has been si=
mplified with the publication of RFC 6733 and the number space is large eno=
ugh to avoid exhaustion.=20

- --------

Ciao
Hannes

On Jun 11, 2013, at 1:52 PM, <lionel.morand@orange.com> wrote:

> Hi Hannes,
>=20=20
> OK in the principle. Could you provide a short text that I could insert i=
n the draft? It should not be too long.
>=20=20
> Lionel
>=20=20
> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Envoy=E9 : mardi 11 juin 2013 12:48
> =C0 : MORAND Lionel OLNC/OLN
> Cc : dime@ietf.org
> Objet : Aw: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>=20=20
> Hi Lionel,=20
>=20=20
> thanks for the response.
>=20=20
> Switching back to "the Diameter base protocol" is good for me. We should =
try to avoid creating additional work for the RFC Editor. I will change it.=
=20
>=20=20
> Version -18 is good for me. I was onlywondering whether it would make sen=
se to add a short section about what steps to take when defining new extens=
ions (in terms of interacting with IANA, for example).=20
>=20=20
> Ciao
> Hannes
>=20=20
>=20=20
> Gesendet: Donnerstag, 06. Juni 2013 um 21:09 Uhr
> Von: lionel.morand@orange.com
> An: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@=
ietf.org" <i-d-announce@ietf.org>
> Cc: "dime@ietf.org" <dime@ietf.org>
> Betreff: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
> Hi,
>=20
> The version covers the changes proposed by the detailed review done by Ha=
nnes (thank you!).
> Most of them are OK and taken into account in this new version... except =
one:
>=20
> In the RFC 6733, the correct wording used is "the Diameter base protocol"=
 and not "Diameter Base Protocol". I have received the same comment in the =
recent past! :)
>=20=20
>=20=20
>=20
> Hannes, please confirm that this version is OK. If it is, the WGLC on thi=
s document is finished and we can move forward.
>=20=20
>=20=20
> Ciao
> Hannes
>=20
>=20
> Regards,
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de i=
nternet-drafts@ietf.org
> Envoy=E9 : jeudi 6 juin 2013 21:03
> =C0 : i-d-announce@ietf.org
> Cc : dime@ietf.org
> Objet : [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Diameter Maintenance and Extensions Work=
ing Group of the IETF.
>=20
> Title : Diameter Applications Design Guidelines
> Author(s) : Lionel Morand
> Victor Fajardo
> Hannes Tschofenig
> Filename : draft-ietf-dime-app-design-guide-18.txt
> Pages : 21
> Date : 2013-06-06
>=20
> 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.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-18
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messa=
ges that have been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messa=
ges that have been modified, changed or falsified.
> Thank you.
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJRtw6LAAoJEGhJURNOOiAteI8H/33XsWes4eZKapGZVNOpW+p2
5PJDwJr3rcshajT4HzCRraD2Z07zn2JRAhG3rMdpwOpGjt9eOxsIgLcBPjS2N9rm
vIH1QSssekt3O9z4pO++GdFeczclnlzYkQE68R2Jhvo9lOVFv3MuW+N3ryoUGBmn
NLk5bvP5IHdrxM8TNeT0xK1bLtB7tFkthyrfIIlfN2GeD0eKDqGbp4QY1x3Q4zCY
u12b9AwVOOT09lJ/jS4EueT9yaiaUkB4siqpQdlmWUVZU1Dhn2j0D1xBsiq7OMJR
1TkaU+4DgiT9xe0vQDwUckoahW643wrkgY6jeP5oYhloMfzPr5m3/HXWkUWlgd4=3D
=3DDCtz
-----END PGP SIGNATURE-----

___________________________________________________________________________=
______________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From ben@nostrum.com  Wed Jun 19 14:00:48 2013
Return-Path: <ben@nostrum.com>
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 B3F2221F9A30 for <dime@ietfa.amsl.com>; Wed, 19 Jun 2013 14:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 MYDemGJR5MfQ for <dime@ietfa.amsl.com>; Wed, 19 Jun 2013 14:00:46 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1695C21F9F22 for <dime@ietf.org>; Wed, 19 Jun 2013 14:00:36 -0700 (PDT)
Received: from [172.20.10.7] (mobile-166-147-071-130.mycingular.net [166.147.71.130]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5JL0Y9x038246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dime@ietf.org>; Wed, 19 Jun 2013 16:00:35 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <12139FBB-2A3C-483A-90B3-4E795CBBB922@nostrum.com>
Date: Wed, 19 Jun 2013 16:00:29 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4688236-F70C-4640-BE33-F41C018D1456@nostrum.com>
References: <20130606214928.23822.22145.idtracker@ietfa.amsl.com> <12139FBB-2A3C-483A-90B3-4E795CBBB922@nostrum.com>
To: "dime@ietf.org" <dime@ietf.org>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass (shaman.nostrum.com: 166.147.71.130 is authenticated by a trusted mechanism)
Subject: Re: [Dime] New Version Notification for draft-campbell-dime-overload-issues-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 21:00:48 -0000

Hi everyone,

Just a reminder--we would welcome feedback and discussion on the points =
in this draft. It describes what I believe to be some significant issues =
in handling non-adjacent overload reports. We will need to have a good =
handle on these in order to define the actual mechanism(s).

Thanks!

Ben.

On Jun 6, 2013, at 4:58 PM, Ben Campbell <ben@nostrum.com> wrote:

> Hi everyone,
>=20
> I just submitted an individual submission draft related to the =
Diameter overload control work. It discusses some issues concerning =
ability to send non-adjacent overload reports  (i.e. reports across =
non-supporting intermediaries--Req 34 in the requirements draft.). It =
also goes into some detail on overload scopes, since that's helpful =
background for some of the non-adjacent issues.  =20
>=20
> I hope this will help spark some discussion, so that we can make =
progress towards the overload control solution or solutions.
>=20
> Thanks!
>=20
> Ben.
>=20
> On Jun 6, 2013, at 4:49 PM, internet-drafts@ietf.org wrote:
>=20
>>=20
>> A new version of I-D, draft-campbell-dime-overload-issues-00.txt
>> has been successfully submitted by Ben Campbell and posted to the
>> IETF repository.
>>=20
>> Filename:	 draft-campbell-dime-overload-issues
>> Revision:	 00
>> Title:		 Diameter Overload Control Solution Issues
>> Creation date:	 2013-06-06
>> Group:		 Individual Submission
>> Number of pages: 16
>> URL:             =
http://www.ietf.org/internet-drafts/draft-campbell-dime-overload-issues-00=
.txt
>> Status:          =
http://datatracker.ietf.org/doc/draft-campbell-dime-overload-issues
>> Htmlized:        =
http://tools.ietf.org/html/draft-campbell-dime-overload-issues-00
>>=20
>>=20
>> Abstract:
>>  The Diameter Maintenance and Extensions (DIME) working group has
>>  undertaken an "overload control" work item, with the goal of
>>  standardizing a mechanism to allow Diameter nodes to report overload
>>  information among themselves.  Requirements currently include, among
>>  others, the need to accurately report the scope of overload
>>  conditions, and the ability to report overload information between
>>  nodes that are not directly connected at the transport layer.  These
>>  requirements introduce complex issues.  This document describes =
those
>>  issues, in the hope that it will assist the working group's decision
>>  process.
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From internet-drafts@ietf.org  Thu Jun 20 05:48:36 2013
Return-Path: <internet-drafts@ietf.org>
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 C981F21F9BF7; Thu, 20 Jun 2013 05:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.512
X-Spam-Level: 
X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, 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 v7ha1U1N1OAA; Thu, 20 Jun 2013 05:48:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0928721F99D0; Thu, 20 Jun 2013 05:48:11 -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.51.p2
Message-ID: <20130620124810.32582.93758.idtracker@ietfa.amsl.com>
Date: Thu, 20 Jun 2013 05:48:10 -0700
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-09.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 12:48:37 -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-09.txt
	Pages           : 8
	Date            : 2013-06-20

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


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-09


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


From lionel.morand@orange.com  Thu Jun 20 10:13:21 2013
Return-Path: <lionel.morand@orange.com>
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 4B4E321F9D77 for <dime@ietfa.amsl.com>; Thu, 20 Jun 2013 10:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, 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 KBNdtKhpdQay for <dime@ietfa.amsl.com>; Thu, 20 Jun 2013 10:13:17 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DA4E721F9D08 for <dime@ietf.org>; Thu, 20 Jun 2013 10:13:16 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A1ACF18CF71 for <dime@ietf.org>; Thu, 20 Jun 2013 19:13:15 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8AD9E238059 for <dime@ietf.org>; Thu, 20 Jun 2013 19:13: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.0328.009; Thu, 20 Jun 2013 19:13:15 +0200
From: <lionel.morand@orange.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-09.txt
Thread-Index: AQHObbSXGeqls3/m3UOQ7ar4wvpp95k+lSSw
Date: Thu, 20 Jun 2013 17:13:14 +0000
Message-ID: <1069_1371748395_51C3382B_1069_5935_1_6B7134B31289DC4FAF731D844122B36E206E1B@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20130620124810.32582.93758.idtracker@ietfa.amsl.com>
In-Reply-To: <20130620124810.32582.93758.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.20.150322
Subject: Re: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-09.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 17:13:21 -0000

Hi,

This new version was needed after the final review of the document performe=
d for the doc shepherd's proto write up.
It covers mainly editorial changes and clarifications in the text. No funda=
mental change.
It will be sent to IESG for publication.

Best regards,

Lionel

-----Message d'origine-----
De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de i=
nternet-drafts@ietf.org
Envoy=E9=A0: jeudi 20 juin 2013 14:48
=C0=A0: i-d-announce@ietf.org
Cc=A0: dime@ietf.org
Objet=A0: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Diameter Maintenance and Extensions 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-09.txt
	Pages           : 8
	Date            : 2013-06-20

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


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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-09


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

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

___________________________________________________________________________=
______________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From hannes.tschofenig@gmx.net  Wed Jun 26 00:27:03 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 067EA21E811C for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 00:27:03 -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 gV88HImBCXwh for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 00:26:58 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 43FEB21E80D7 for <dime@ietf.org>; Wed, 26 Jun 2013 00:26:58 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MOmCW-1UwfY70wbu-0064pJ for <dime@ietf.org>; Wed, 26 Jun 2013 09:26:57 +0200
Received: (qmail invoked by alias); 26 Jun 2013 07:26:56 -0000
Received: from host-94-101-1-228.igua.fi (EHLO [192.168.4.115]) [94.101.1.228] by mail.gmx.net (mp029) with SMTP; 26 Jun 2013 09:26:56 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19y9/o/n3JyWwRX2ml3Bt17PcecNgibN9tA54tGI8 TV9onMohtQajOP
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <11669_1371641235_51C19593_11669_1841_1_6B7134B31289DC4FAF731D844122B36E205984@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Wed, 26 Jun 2013 10:26:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <27B72DDD-842E-4A28-AA70-CA3D6DF45160@gmx.net>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>, <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup> <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61> <387_1370947948_51B7016C_387_4637_1_6B7134B31289DC4FAF731D844122B36E1FF9B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <9126B39B-A83D-44E1-912D-A35380E8EDA2@gmx.net> <11669_1371641235_51C19593_11669_1841_1_6B7134B31289DC4FAF731D844122B36E205984@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: <lionel.morand@orange.com>
X-Pgp-Agent: GPGMail 1.4.1
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 07:27:03 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Lionel,=20

this looks like a good writeup.=20

A few minor remarks below:=20

On Jun 19, 2013, at 2:27 PM, <lionel.morand@orange.com> wrote:

> Hi Hannes,
>=20
> Based on your input, I propose to add a specific section with the =
content given below. It may be a little bit redundant with some =
information already given in RFC6733 but I agree that it is worth to =
repeat the guidelines.
> Please comment.
>=20
> Best Regards,
>=20
> Lionel
>=20
> ************************
> 7.  Guidelines for Registrations of Diameter Values
>=20
>   As summarized in the Section 3 of this document and further =
described
>   in the Section 1.3 of [RFC6733], there are four main ways to extend
>   Diameter.  The process for defining new functionality slightly =
varies
>   based on the different extensions.  This section provides protocol
>   designers with some guidance regarding the definition and
>   registration of values for possible Diameter extensions.
>=20

maybe add "... and the necessary interaction with IANA to register the =
new functionality.".=20

>   a. Defining new AVP values
>=20
>      The specifications defining AVPs and AVP values provide guidance
>      for defining new values and the corresponding policy for adding
>      these values.  For example, the [RFC5777] defines the Treatment-
>      Action AVP which contains a list of valid values corresponding to
>      pre-defined actions (drop, shape, mark, permit).

Minor bug: "For example, RFC 5777 [RFC5777]  defines ...=20

>  This set of
>      values can be extended following the Specification Required =
policy
>      defined in [RFC5226].  As a second example, the Diameter base
>      specification [RFC6733] defines the Result-Code AVP that contains
>      a 32-bit address space used to identity possible errors.
>      According to the Section 11.3.2 of [RFC6733], new values can be
>      assigned by IANA via an IETF Review process [RFC5226].
>=20
>   b. Creating new AVPs
>=20
>      Two different types of AVP Codes namespaces can be used to create
>      a new AVPs:
>=20
>      *  IETF AVP Codes namespace;
>=20
>      *  Vendor-specific AVP Codes namespace.
>=20
>      In the latter case, a vendor needs to be first assigned by IANA
>      with a private enterprise number, which can be used within the
>      Vendor-Id field of the vendor-specific AVP.  This enterprise
>      number delimits a private namespace in which the vendor is
>      responsible for vendor-specific AVP code value assignment.  The
>      absence of a Vendor-Id or a Vendor-Id value of zero (0) in the =
AVP
>      header identifies standard AVPs from the IETF AVP Codes namespace
>      managed by IANA.  The allocation of code values from the IANA-
>      managed namespace is conditioned by an Expert Review of the
>      specification defining the AVPs or an IETF review if a block of
>      AVPs needs to be assigned.  Moreover, the remaining bits of the
>      AVP Flags field of the AVP header can be also assigned via
>      Standard Action if the creation of new AVP Flags is desired.
>=20
>   c. Creating new commands
>=20
>      Unlike the AVP Code namespace, the Command Code namespace is flat
>      but the range of values is subdivided into three chunks with
>      distinct IANA registration policies:
>=20
>      *  A range of standard Command Code values that can be allocated
>         via IETF review;
>=20
>      *  A range of vendor-specific Command Code values that can be
>         allocated on a First-Come/First-Served basis;
>=20
>      *  A range of 2 values reserved only for experimental and testing
>         purposes.

This should rather say " A range of values reserved only for =
experimental and testing purposes."

>=20
>      As for AVP Flags, the remaining bits of the Command Flags field =
of
>      the Diameter header can also be assigned via a Standards Action =
to
>      create new Command Flags if required.
>=20
>   d. Creating new applications
>=20
>      Similarly to the Command Code namespace, the Application-Id
>      namespace is flat but divided into two distinct ranges:
>=20
>      *  A range of values reserved for standard Application-Ids
>         allocated after Expert Review of the specification defining =
the
>         standard application;
>=20
>      *  A range for values for vendor specific applications, allocated
>         by IANA on a First-Come/First-Serve basis.
>=20
>   The IANA AAA parameters page can be found at http://www.iana.org/
>   assignments/aaa-parameters/aaa-parameters.xml and the enterprise
>   number IANA page is available at http://www.iana.org/assignments/
>   enterprise-numbers.  More details on the policies followed by IANA
>   for namespace management (e.g. First-Come/First-Served, Expert
>   Review, IETF Review, etc.) can be found in [RFC5226].
>=20
>   NOTE:
>      When the same functionality/extension is used by more than one
>      vendor, it is recommended to define a standard extension.
>      Moreover, the registration of vendor-specific extension is
>      encouraged to avoid interoperability issues in the same network.
>      With this aim, the registration policy of vendor-specific
>      extension has been simplified with the publication of [RFC6733]
>      and the namespace reserved for vendor-specific extensions is =
large
>      enough to avoid exhaustion.
>=20
> ************************
>=20

Ciao
Hannes

> -----Message d'origine-----
> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Envoy=E9 : mardi 11 juin 2013 13:48
> =C0 : MORAND Lionel OLNC/OLN
> Cc : Hannes Tschofenig; dime@ietf.org
> Objet : Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> Yes, I can give it a try to see whether the group thinks it is =
worthwhile to add this additional piece of information.=20
>=20
> On a high level this is what I plan to say:
>=20
> - --------
>=20
> There are four main ways to extend Diameter and the process for =
defining new functionality slightly varies based on the different =
extensions:=20
>=20
>   1.  Defining new AVP values: The specifications that define the AVP =
and the AVP values provide guidance for defining new values and also =
provide the policy for adding these values. For example, RFC 5777 =
defines AVPs for traffic classification and QoS. Among the AVP it =
defines the Treatment-Action AVP, which contains a list of actions =
(drop, shape, mark, permit). New values can be defined by following the =
policy outlined in Section 10.3 of RFC 5777. As a second example, the =
Diameter base specification defines a number of AVPs. The Result-Code =
AVP is one of them and, according to Section 11.3.2 of RFC 6733, new =
values are available for assignment via IETF Review.
>=20
>   2.  Creating new AVPs: New AVPs can be defined in one of two ways: =
(a) as vendor-specific AVPs and (b) within the IETF AVP codespace. In =
case (a) a vendor needs to obtain an enterprise number (which is then =
carried inside the Vendor-ID field of the AVP) through IANA. When a =
vendor-specific AVP is used then the vendor has to manage it's AVP code =
space internally. The absence of a Vendor-ID or a Vendor-ID value of =
zero (0) identifies the IETF AVP Codes namespace, which is under IANA =
control. The policy for registering AVPs under the IANA controlled =
namespace is described in Section 11.1.1 of RFC 6733.=20
>=20
> Associated with AVPs are AVP flags, which requires Standards Action =
for extensions [RFC5226].=20
>=20
>   3.  Creating new commands: Unlike the AVP code space the command =
code space is flat but the number range is divided into different chunks =
for different purposes and with different registration policies. There =
are three number ranges, namely a range for command codes allocated via =
IETF review, a number range for vendor-specific command codes with a =
First-Come, First-Serve policy, and a number range reserved for =
experimental and testing purposes.=20
>=20
> Associated with commands is the Command Flags field, which requires =
Standards Action for extensions.=20
>=20
>   4.  Creating new applications: Similarly to the command code space =
the application id space is flat but divided into two number ranges, =
namely one for for vendor
>   specific applications, on a First-Come, First-Serve basis, and =
another one space with a Specification Required policy.=20
>=20
> The IANA AAA parameters page can be found at =
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml and =
the enterprise number IANA page is available at =
http://www.iana.org/assignments/enterprise-numbers
>=20
> Note: Register your extensions to avoid interoperability problems =
which can occur when two implementations using the same code point but =
with different semantic are run in the same network. The registration =
policy has been simplified with the publication of RFC 6733 and the =
number space is large enough to avoid exhaustion.=20
>=20
> - --------
>=20
> Ciao
> Hannes
>=20
> On Jun 11, 2013, at 1:52 PM, <lionel.morand@orange.com> wrote:
>=20
>> Hi Hannes,
>>=20
>> OK in the principle. Could you provide a short text that I could =
insert in the draft? It should not be too long.
>>=20
>> Lionel
>>=20
>> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
>> Envoy=E9 : mardi 11 juin 2013 12:48
>> =C0 : MORAND Lionel OLNC/OLN
>> Cc : dime@ietf.org
>> Objet : Aw: Re: [Dime] I-D Action: =
draft-ietf-dime-app-design-guide-18.txt
>>=20
>> Hi Lionel,=20
>>=20
>> thanks for the response.
>>=20
>> Switching back to "the Diameter base protocol" is good for me. We =
should try to avoid creating additional work for the RFC Editor. I will =
change it.=20
>>=20
>> Version -18 is good for me. I was onlywondering whether it would make =
sense to add a short section about what steps to take when defining new =
extensions (in terms of interacting with IANA, for example).=20
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>> Gesendet: Donnerstag, 06. Juni 2013 um 21:09 Uhr
>> Von: lionel.morand@orange.com
>> An: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, =
"i-d-announce@ietf.org" <i-d-announce@ietf.org>
>> Cc: "dime@ietf.org" <dime@ietf.org>
>> Betreff: Re: [Dime] I-D Action: =
draft-ietf-dime-app-design-guide-18.txt
>> Hi,
>>=20
>> The version covers the changes proposed by the detailed review done =
by Hannes (thank you!).
>> Most of them are OK and taken into account in this new version... =
except one:
>>=20
>> In the RFC 6733, the correct wording used is "the Diameter base =
protocol" and not "Diameter Base Protocol". I have received the same =
comment in the recent past! :)
>>=20
>>=20
>>=20
>> Hannes, please confirm that this version is OK. If it is, the WGLC on =
this document is finished and we can move forward.
>>=20
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part =
de internet-drafts@ietf.org
>> Envoy=E9 : jeudi 6 juin 2013 21:03
>> =C0 : i-d-announce@ietf.org
>> Cc : dime@ietf.org
>> Objet : [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>>=20
>>=20
>> 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.
>>=20
>> Title : Diameter Applications Design Guidelines
>> Author(s) : Lionel Morand
>> Victor Fajardo
>> Hannes Tschofenig
>> Filename : draft-ietf-dime-app-design-guide-18.txt
>> Pages : 21
>> Date : 2013-06-06
>>=20
>> 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.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-18
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous =
avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender =
and delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.
>> Thank you.
>>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>=20
> iQEcBAEBCgAGBQJRtw6LAAoJEGhJURNOOiAteI8H/33XsWes4eZKapGZVNOpW+p2
> 5PJDwJr3rcshajT4HzCRraD2Z07zn2JRAhG3rMdpwOpGjt9eOxsIgLcBPjS2N9rm
> vIH1QSssekt3O9z4pO++GdFeczclnlzYkQE68R2Jhvo9lOVFv3MuW+N3ryoUGBmn
> NLk5bvP5IHdrxM8TNeT0xK1bLtB7tFkthyrfIIlfN2GeD0eKDqGbp4QY1x3Q4zCY
> u12b9AwVOOT09lJ/jS4EueT9yaiaUkB4siqpQdlmWUVZU1Dhn2j0D1xBsiq7OMJR
> 1TkaU+4DgiT9xe0vQDwUckoahW643wrkgY6jeP5oYhloMfzPr5m3/HXWkUWlgd4=3D
> =3DDCtz
> -----END PGP SIGNATURE-----
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or =
privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and =
delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for =
messages that have been modified, changed or falsified.
> Thank you.
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJRype/AAoJEGhJURNOOiAthTMH/3WayLZ2+6O8emrPRmcfuTIX
C5ObqhhUJ3Af4mM6pil7ApFrVy4wGya/AG6iofeLJb2wDd0eeuR1kBKshOhJHuiu
got8AkT4UvoOjI1d/U6nl0a1ZpXbeeal8Bf9oACMFwviSlu9AdjT+d+zF1moW5YI
v8/ujDgcTzi2TNY9z+1EhF5BB2gtHqNkAM8HYHf4uCluyTjdQyl51HCgQBk2DBaq
FMb9bf/IT5oQLof9AP4AFxojODRi6Cu/wUe3e0e/OpSY4QxHnXOKcetaN6ElE9To
7XfYj1zfUOqcAjwhdTJKOyj1aml08P9yQlC0vckEVemBCyOzsj2HjlHjdml6M8s=3D
=3DGk0N
-----END PGP SIGNATURE-----

From lionel.morand@orange.com  Wed Jun 26 07:35:54 2013
Return-Path: <lionel.morand@orange.com>
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 567A021E8090 for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 07:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 u4r0pV5PvMNK for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 07:35:50 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 993C921E8088 for <dime@ietf.org>; Wed, 26 Jun 2013 07:35:49 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DFC2F32421D; Wed, 26 Jun 2013 16:35:47 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C4D714C06F; Wed, 26 Jun 2013 16:35:47 +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; Wed, 26 Jun 2013 16:35:47 +0200
From: <lionel.morand@orange.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Thread-Topic: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
Thread-Index: AQHOcj6LCypyxRiuNUOt4n7h3LlUM5lIEApg
Date: Wed, 26 Jun 2013 14:35:46 +0000
Message-ID: <30008_1372257347_51CAFC43_30008_7675_1_6B7134B31289DC4FAF731D844122B36E216FE3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20130606190254.12067.1236.idtracker@ietfa.amsl.com>, <28619_1370546027_51B0DF6A_28619_1558_1_6B7134B31289DC4FAF731D844122B36E1FD598@PEXCVZYM13.corporate.adroot.infra.ftgroup> <trinity-744015f0-95dd-46bc-b542-c434057fef75-1370947656492@3capp-gmx-bs61> <387_1370947948_51B7016C_387_4637_1_6B7134B31289DC4FAF731D844122B36E1FF9B3@PEXCVZYM13.corporate.adroot.infra.ftgroup> <9126B39B-A83D-44E1-912D-A35380E8EDA2@gmx.net> <11669_1371641235_51C19593_11669_1841_1_6B7134B31289DC4FAF731D844122B36E205984@PEXCVZYM13.corporate.adroot.infra.ftgroup> <27B72DDD-842E-4A28-AA70-CA3D6DF45160@gmx.net>
In-Reply-To: <27B72DDD-842E-4A28-AA70-CA3D6DF45160@gmx.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.26.131226
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 14:35:54 -0000

Thank you!

I will incorporate the proposed text in a new version of the draft, includi=
ng your minor comments.

Regards,

Lionel

-----Message d'origine-----
De=A0: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
Envoy=E9=A0: mercredi 26 juin 2013 09:27
=C0=A0: MORAND Lionel OLNC/OLN
Cc=A0: Hannes Tschofenig; dime@ietf.org
Objet=A0: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Lionel,=20

this looks like a good writeup.=20

A few minor remarks below:=20

On Jun 19, 2013, at 2:27 PM, <lionel.morand@orange.com> wrote:

> Hi Hannes,
>=20
> Based on your input, I propose to add a specific section with the content=
 given below. It may be a little bit redundant with some information alread=
y given in RFC6733 but I agree that it is worth to repeat the guidelines.
> Please comment.
>=20
> Best Regards,
>=20
> Lionel
>=20
> ************************
> 7.  Guidelines for Registrations of Diameter Values
>=20
>   As summarized in the Section 3 of this document and further described
>   in the Section 1.3 of [RFC6733], there are four main ways to extend
>   Diameter.  The process for defining new functionality slightly varies
>   based on the different extensions.  This section provides protocol
>   designers with some guidance regarding the definition and
>   registration of values for possible Diameter extensions.
>=20

maybe add "... and the necessary interaction with IANA to register the new =
functionality.".=20

>   a. Defining new AVP values
>=20
>      The specifications defining AVPs and AVP values provide guidance
>      for defining new values and the corresponding policy for adding
>      these values.  For example, the [RFC5777] defines the Treatment-
>      Action AVP which contains a list of valid values corresponding to
>      pre-defined actions (drop, shape, mark, permit).

Minor bug: "For example, RFC 5777 [RFC5777]  defines ...=20

>  This set of
>      values can be extended following the Specification Required policy
>      defined in [RFC5226].  As a second example, the Diameter base
>      specification [RFC6733] defines the Result-Code AVP that contains
>      a 32-bit address space used to identity possible errors.
>      According to the Section 11.3.2 of [RFC6733], new values can be
>      assigned by IANA via an IETF Review process [RFC5226].
>=20
>   b. Creating new AVPs
>=20
>      Two different types of AVP Codes namespaces can be used to create
>      a new AVPs:
>=20
>      *  IETF AVP Codes namespace;
>=20
>      *  Vendor-specific AVP Codes namespace.
>=20
>      In the latter case, a vendor needs to be first assigned by IANA
>      with a private enterprise number, which can be used within the
>      Vendor-Id field of the vendor-specific AVP.  This enterprise
>      number delimits a private namespace in which the vendor is
>      responsible for vendor-specific AVP code value assignment.  The
>      absence of a Vendor-Id or a Vendor-Id value of zero (0) in the AVP
>      header identifies standard AVPs from the IETF AVP Codes namespace
>      managed by IANA.  The allocation of code values from the IANA-
>      managed namespace is conditioned by an Expert Review of the
>      specification defining the AVPs or an IETF review if a block of
>      AVPs needs to be assigned.  Moreover, the remaining bits of the
>      AVP Flags field of the AVP header can be also assigned via
>      Standard Action if the creation of new AVP Flags is desired.
>=20
>   c. Creating new commands
>=20
>      Unlike the AVP Code namespace, the Command Code namespace is flat
>      but the range of values is subdivided into three chunks with
>      distinct IANA registration policies:
>=20
>      *  A range of standard Command Code values that can be allocated
>         via IETF review;
>=20
>      *  A range of vendor-specific Command Code values that can be
>         allocated on a First-Come/First-Served basis;
>=20
>      *  A range of 2 values reserved only for experimental and testing
>         purposes.

This should rather say " A range of values reserved only for experimental a=
nd testing purposes."

>=20
>      As for AVP Flags, the remaining bits of the Command Flags field of
>      the Diameter header can also be assigned via a Standards Action to
>      create new Command Flags if required.
>=20
>   d. Creating new applications
>=20
>      Similarly to the Command Code namespace, the Application-Id
>      namespace is flat but divided into two distinct ranges:
>=20
>      *  A range of values reserved for standard Application-Ids
>         allocated after Expert Review of the specification defining the
>         standard application;
>=20
>      *  A range for values for vendor specific applications, allocated
>         by IANA on a First-Come/First-Serve basis.
>=20
>   The IANA AAA parameters page can be found at http://www.iana.org/
>   assignments/aaa-parameters/aaa-parameters.xml and the enterprise
>   number IANA page is available at http://www.iana.org/assignments/
>   enterprise-numbers.  More details on the policies followed by IANA
>   for namespace management (e.g. First-Come/First-Served, Expert
>   Review, IETF Review, etc.) can be found in [RFC5226].
>=20
>   NOTE:
>      When the same functionality/extension is used by more than one
>      vendor, it is recommended to define a standard extension.
>      Moreover, the registration of vendor-specific extension is
>      encouraged to avoid interoperability issues in the same network.
>      With this aim, the registration policy of vendor-specific
>      extension has been simplified with the publication of [RFC6733]
>      and the namespace reserved for vendor-specific extensions is large
>      enough to avoid exhaustion.
>=20
> ************************
>=20

Ciao
Hannes

> -----Message d'origine-----
> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Envoy=E9 : mardi 11 juin 2013 13:48
> =C0 : MORAND Lionel OLNC/OLN
> Cc : Hannes Tschofenig; dime@ietf.org
> Objet : Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> Yes, I can give it a try to see whether the group thinks it is worthwhile=
 to add this additional piece of information.=20
>=20
> On a high level this is what I plan to say:
>=20
> - --------
>=20
> There are four main ways to extend Diameter and the process for defining =
new functionality slightly varies based on the different extensions:=20
>=20
>   1.  Defining new AVP values: The specifications that define the AVP and=
 the AVP values provide guidance for defining new values and also provide t=
he policy for adding these values. For example, RFC 5777 defines AVPs for t=
raffic classification and QoS. Among the AVP it defines the Treatment-Actio=
n AVP, which contains a list of actions (drop, shape, mark, permit). New va=
lues can be defined by following the policy outlined in Section 10.3 of RFC=
 5777. As a second example, the Diameter base specification defines a numbe=
r of AVPs. The Result-Code AVP is one of them and, according to Section 11.=
3.2 of RFC 6733, new values are available for assignment via IETF Review.
>=20
>   2.  Creating new AVPs: New AVPs can be defined in one of two ways: (a) =
as vendor-specific AVPs and (b) within the IETF AVP codespace. In case (a) =
a vendor needs to obtain an enterprise number (which is then carried inside=
 the Vendor-ID field of the AVP) through IANA. When a vendor-specific AVP i=
s used then the vendor has to manage it's AVP code space internally. The ab=
sence of a Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF A=
VP Codes namespace, which is under IANA control. The policy for registering=
 AVPs under the IANA controlled namespace is described in Section 11.1.1 of=
 RFC 6733.=20
>=20
> Associated with AVPs are AVP flags, which requires Standards Action for e=
xtensions [RFC5226].=20
>=20
>   3.  Creating new commands: Unlike the AVP code space the command code s=
pace is flat but the number range is divided into different chunks for diff=
erent purposes and with different registration policies. There are three nu=
mber ranges, namely a range for command codes allocated via IETF review, a =
number range for vendor-specific command codes with a First-Come, First-Ser=
ve policy, and a number range reserved for experimental and testing purpose=
s.=20
>=20
> Associated with commands is the Command Flags field, which requires Stand=
ards Action for extensions.=20
>=20
>   4.  Creating new applications: Similarly to the command code space the =
application id space is flat but divided into two number ranges, namely one=
 for for vendor
>   specific applications, on a First-Come, First-Serve basis, and another =
one space with a Specification Required policy.=20
>=20
> The IANA AAA parameters page can be found at http://www.iana.org/assignme=
nts/aaa-parameters/aaa-parameters.xml and the enterprise number IANA page i=
s available at http://www.iana.org/assignments/enterprise-numbers
>=20
> Note: Register your extensions to avoid interoperability problems which c=
an occur when two implementations using the same code point but with differ=
ent semantic are run in the same network. The registration policy has been =
simplified with the publication of RFC 6733 and the number space is large e=
nough to avoid exhaustion.=20
>=20
> - --------
>=20
> Ciao
> Hannes
>=20
> On Jun 11, 2013, at 1:52 PM, <lionel.morand@orange.com> wrote:
>=20
>> Hi Hannes,
>>=20
>> OK in the principle. Could you provide a short text that I could insert =
in the draft? It should not be too long.
>>=20
>> Lionel
>>=20
>> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
>> Envoy=E9 : mardi 11 juin 2013 12:48
>> =C0 : MORAND Lionel OLNC/OLN
>> Cc : dime@ietf.org
>> Objet : Aw: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.t=
xt
>>=20
>> Hi Lionel,=20
>>=20
>> thanks for the response.
>>=20
>> Switching back to "the Diameter base protocol" is good for me. We should=
 try to avoid creating additional work for the RFC Editor. I will change it=
.=20
>>=20
>> Version -18 is good for me. I was onlywondering whether it would make se=
nse to add a short section about what steps to take when defining new exten=
sions (in terms of interacting with IANA, for example).=20
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>> Gesendet: Donnerstag, 06. Juni 2013 um 21:09 Uhr
>> Von: lionel.morand@orange.com
>> An: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce=
@ietf.org" <i-d-announce@ietf.org>
>> Cc: "dime@ietf.org" <dime@ietf.org>
>> Betreff: Re: [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>> Hi,
>>=20
>> The version covers the changes proposed by the detailed review done by H=
annes (thank you!).
>> Most of them are OK and taken into account in this new version... except=
 one:
>>=20
>> In the RFC 6733, the correct wording used is "the Diameter base protocol=
" and not "Diameter Base Protocol". I have received the same comment in the=
 recent past! :)
>>=20
>>=20
>>=20
>> Hannes, please confirm that this version is OK. If it is, the WGLC on th=
is document is finished and we can move forward.
>>=20
>>=20
>> Ciao
>> Hannes
>>=20
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de =
internet-drafts@ietf.org
>> Envoy=E9 : jeudi 6 juin 2013 21:03
>> =C0 : i-d-announce@ietf.org
>> Cc : dime@ietf.org
>> Objet : [Dime] I-D Action: draft-ietf-dime-app-design-guide-18.txt
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>> This draft is a work item of the Diameter Maintenance and Extensions Wor=
king Group of the IETF.
>>=20
>> Title : Diameter Applications Design Guidelines
>> Author(s) : Lionel Morand
>> Victor Fajardo
>> Hannes Tschofenig
>> Filename : draft-ietf-dime-app-design-guide-18.txt
>> Pages : 21
>> Date : 2013-06-06
>>=20
>> 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.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-18
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-18
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> ________________________________________________________________________=
_________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liable for mess=
ages that have been modified, changed or falsified.
>> Thank you.
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>> ________________________________________________________________________=
_________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations confi=
dentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r=
ecu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages=
 electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce message a ete=
 altere, deforme ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liable for mess=
ages that have been modified, changed or falsified.
>> Thank you.
>>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>=20
> iQEcBAEBCgAGBQJRtw6LAAoJEGhJURNOOiAteI8H/33XsWes4eZKapGZVNOpW+p2
> 5PJDwJr3rcshajT4HzCRraD2Z07zn2JRAhG3rMdpwOpGjt9eOxsIgLcBPjS2N9rm
> vIH1QSssekt3O9z4pO++GdFeczclnlzYkQE68R2Jhvo9lOVFv3MuW+N3ryoUGBmn
> NLk5bvP5IHdrxM8TNeT0xK1bLtB7tFkthyrfIIlfN2GeD0eKDqGbp4QY1x3Q4zCY
> u12b9AwVOOT09lJ/jS4EueT9yaiaUkB4siqpQdlmWUVZU1Dhn2j0D1xBsiq7OMJR
> 1TkaU+4DgiT9xe0vQDwUckoahW643wrkgY6jeP5oYhloMfzPr5m3/HXWkUWlgd4=3D
> =3DDCtz
> -----END PGP SIGNATURE-----
>=20
> _________________________________________________________________________=
________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messa=
ges that have been modified, changed or falsified.
> Thank you.
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJRype/AAoJEGhJURNOOiAthTMH/3WayLZ2+6O8emrPRmcfuTIX
C5ObqhhUJ3Af4mM6pil7ApFrVy4wGya/AG6iofeLJb2wDd0eeuR1kBKshOhJHuiu
got8AkT4UvoOjI1d/U6nl0a1ZpXbeeal8Bf9oACMFwviSlu9AdjT+d+zF1moW5YI
v8/ujDgcTzi2TNY9z+1EhF5BB2gtHqNkAM8HYHf4uCluyTjdQyl51HCgQBk2DBaq
FMb9bf/IT5oQLof9AP4AFxojODRi6Cu/wUe3e0e/OpSY4QxHnXOKcetaN6ElE9To
7XfYj1zfUOqcAjwhdTJKOyj1aml08P9yQlC0vckEVemBCyOzsj2HjlHjdml6M8s=3D
=3DGk0N
-----END PGP SIGNATURE-----

___________________________________________________________________________=
______________________________________________

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 internet-drafts@ietf.org  Wed Jun 26 07:39:06 2013
Return-Path: <internet-drafts@ietf.org>
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 DEEE021E809A; Wed, 26 Jun 2013 07:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.489
X-Spam-Level: 
X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, 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 8jZV7rueQ--e; Wed, 26 Jun 2013 07:39:06 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 718D511E80E6; Wed, 26 Jun 2013 07:39:06 -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.51.p2
Message-ID: <20130626143906.12364.41616.idtracker@ietfa.amsl.com>
Date: Wed, 26 Jun 2013 07:39:06 -0700
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-19.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 14:39:07 -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-19.txt
	Pages           : 23
	Date            : 2013-06-26

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-app-design-guide-19


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


From ben@nostrum.com  Wed Jun 26 14:57:07 2013
Return-Path: <ben@nostrum.com>
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 B806D21F9AFD for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 14:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.373
X-Spam-Level: 
X-Spam-Status: No, score=-101.373 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, SPF_PASS=-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 IhCR4s4QG4w1 for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 14:56:59 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C913411E8132 for <dime@ietf.org>; Wed, 26 Jun 2013 14:55:56 -0700 (PDT)
Received: from [172.20.10.7] (mobile-166-147-070-136.mycingular.net [166.147.70.136]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5QLtia1091621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jun 2013 16:55:45 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Jun 2013 16:55:39 -0500
Message-Id: <458380E1-F03C-4DFB-A705-ECEA3337F5C9@nostrum.com>
To: "dime@ietf.org" <dime@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass (shaman.nostrum.com: 166.147.70.136 is authenticated by a trusted mechanism)
Cc: "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: [Dime] Overload Control Solution Progress
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 21:57:08 -0000

Hi Everyone,

The Diameter overload control requirements draft has been submitted to =
the IESG and is undergoing AD review. I think we can consider the =
requirement to be reasonably stable. That means it's time to start =
making progress on a solution. The current proposals on the table are =
draft-roach-dime-overload-ctrl-03, which piggy-backs overload reports =
onto existing Diameter messages, and draft-korhonen-dime-ovl-01, which =
defines a dedicated application for transmitting overload reports.

Now what? How can we move forward?

Eric published a requirements analysis of the Roach draft (Appendix A in =
version 03.) That analysis indicates that the draft meets all the =
requirements except Req 34 (traversing non-supporting intermediaries. I =
recently published draft-campbell-dime-overload-issues to discuss some =
issues in solving Req 34, and to hopefully start some discussion about =
whether it really makes sense to support non-adjacent overload control =
in the general case. But in either case, we think we can add some =
restricted non-adjacent support with some fairly minor changes to the =
Roach draft.=20

We would greatly appreciate feedback on whether other agree with the =
requirements analysis. We would welcome a similar analysis of Jouni's =
draft for comparison purposes.

I would personally love to come out of the Berlin meeting with a good =
idea of the path forward--maybe even a decision to adopt some draft or =
another for the overload control solution milestone. Do the chairs have =
thoughts on how to proceed?=20

Thanks!

Ben.=

From emcmurry@computer.org  Wed Jun 26 15:24:25 2013
Return-Path: <emcmurry@computer.org>
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 9BDA521F9B26 for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 15:24:25 -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 RlZmMMG6WVsz for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 15:24:19 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id BFA4721F9B1B for <dime@ietf.org>; Wed, 26 Jun 2013 15:24:19 -0700 (PDT)
Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <emcmurry@computer.org>) id 1Ury8Q-000F6w-QB for dime@ietf.org; Wed, 26 Jun 2013 22:24:19 +0000
Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id CC5285D26CC for <dime@ietf.org>; Wed, 26 Jun 2013 17:24:15 -0500 (CDT)
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 76.184.161.215
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1++nm0z+bM2j+lzp7HgdJqDhRbqSYpmWlM=
X-Virus-Scanned: amavisd-new at casamcmurry.com
Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebKd-j7s7MCN for <dime@ietf.org>; Wed, 26 Jun 2013 17:24:15 -0500 (CDT)
Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 8A8215D26C1 for <dime@ietf.org>; Wed, 26 Jun 2013 17:24:15 -0500 (CDT)
From: Eric McMurry <emcmurry@computer.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org>
Date: Wed, 26 Jun 2013 17:24:14 -0500
To: "dime@ietf.org" <dime@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [Dime] origin-host scope for draft-roach-dime-overload-ctrl
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 22:24:25 -0000

There are use cases for Diameter overload control where it would be =
useful for a server to be able to throttle traffic from a specific =
source.  When the source is adjacent to the server, this can be =
accomplished easily enough by the server just sending the overload =
control information directly to the source in question.

However, when there are intermediaries between the server and the source =
(client), the current proposed mechanism in =
draft-roach-dime-overload-ctrl does not have a way to do this.  Adding a =
scope for origin-host would solve this issue.  The way this would work =
would be for the server to construct the overload control information =
and attach the origin-host scope to it that matches the specific source =
of overload it wants to target.  The information would be ignored by any =
other recipients as they would not have an origin-host that matches that =
scope when sending messages.

I think this could be an optional scope as it wouldn't be needed for all =
applications that may use Diameter overload control.

Thoughts?



Thanks!

Eric




From ben@nostrum.com  Wed Jun 26 20:46:09 2013
Return-Path: <ben@nostrum.com>
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 25D2C11E80FC for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 20:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.373
X-Spam-Level: 
X-Spam-Status: No, score=-101.373 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, SPF_PASS=-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 FnKgFCXTFMaU for <dime@ietfa.amsl.com>; Wed, 26 Jun 2013 20:45:48 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA711E80E9 for <dime@ietf.org>; Wed, 26 Jun 2013 20:45:48 -0700 (PDT)
Received: from [10.0.1.12] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5R3jiEv029429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Jun 2013 22:45:45 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org>
Date: Wed, 26 Jun 2013 22:45:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D571A124-1BD1-4A0A-8841-5E6B4C6085BE@nostrum.com>
References: <8D4DCE31-7590-4423-8C6B-7435B3661940@computer.org>
To: Eric McMurry <emcmurry@computer.org>
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] origin-host scope for draft-roach-dime-overload-ctrl
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 03:46:09 -0000

On Jun 26, 2013, at 5:24 PM, Eric McMurry <emcmurry@computer.org> wrote:

> There are use cases for Diameter overload control where it would be =
useful for a server to be able to throttle traffic from a specific =
source.  When the source is adjacent to the server, this can be =
accomplished easily enough by the server just sending the overload =
control information directly to the source in question.
>=20
> However, when there are intermediaries between the server and the =
source (client), the current proposed mechanism in =
draft-roach-dime-overload-ctrl does not have a way to do this.  Adding a =
scope for origin-host would solve this issue.  The way this would work =
would be for the server to construct the overload control information =
and attach the origin-host scope to it that matches the specific source =
of overload it wants to target.  The information would be ignored by any =
other recipients as they would not have an origin-host that matches that =
scope when sending messages.

This could also be used by an agent to throttle traffic from a specific =
client, since it could match the actual origin-host value in a request =
to the origin-host scope value.

>=20
> I think this could be an optional scope as it wouldn't be needed for =
all applications that may use Diameter overload control.
>=20

I agree it should be optional for agents. I'm on the fence for clients, =
but optional is probably okay there. If people specify application =
specific behavior for certain applications, they could always mandate it =
there.

> Thoughts?
>=20
>=20
>=20
> Thanks!
>=20
> Eric
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From jouni.nospam@gmail.com  Thu Jun 27 00:37:30 2013
Return-Path: <jouni.nospam@gmail.com>
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 9CD1F21F9BF8 for <dime@ietfa.amsl.com>; Thu, 27 Jun 2013 00:37:30 -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 4jzDD9+fNURZ for <dime@ietfa.amsl.com>; Thu, 27 Jun 2013 00:37:30 -0700 (PDT)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D98E021F9BEF for <dime@ietf.org>; Thu, 27 Jun 2013 00:37:29 -0700 (PDT)
Received: by mail-bk0-f50.google.com with SMTP id ik8so130843bkc.9 for <dime@ietf.org>; Thu, 27 Jun 2013 00:37:29 -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:x-mailer; bh=FQa4kpx9QZL/M2LL0Bg2Ww2xdhUXkYk9vIiix8V3IRc=; b=hEofpdvR4TOnCUC9cBq/hPAtNwesq/ruTiEMZY2kjqzmEW92d7Qo1V6BO8AUaQfrGc y+2cywnOgJ6g0iAl3mnRB670nQ1nZ1ySIUwRCu5+N0TMTM8aaVrrIUIKlgEsvi8aVczc 9vD4cDqIy0ZJCN6F+xX/7Qj7aA67b4tcyXeFHmoM+5l2FztZ2EeybmWsRWOHAHM8wRW1 XmwyC6ZJDMmxR/oOfHK8OcU1zlSNCiIsA8DmCOWzS9WiLSzw1IMipKGicTzFVqX56J/X e4zdo3Lp/BM6EIcjAv7t8/bs/BbCMrH+nBH6PzLi671Y3GEe5bJ2n/oojcTSsoE1n89K 2d7Q==
X-Received: by 10.204.174.200 with SMTP id u8mr1003269bkz.175.1372318648940; Thu, 27 Jun 2013 00:37:28 -0700 (PDT)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id oe10sm404524bkb.1.2013.06.27.00.37.27 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 00:37:27 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <92540551-9180-4F05-85D3-0D6482A3ECAE@gmail.com>
Date: Thu, 27 Jun 2013 10:37:25 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4591BBC6-2AC2-4F07-9CAA-8D8926026240@gmail.com>
References: <92540551-9180-4F05-85D3-0D6482A3ECAE@gmail.com>
To: "DiME@ietf.org" <dime@ietf.org>, Marco Liebsch <marco.liebsch@neclab.eu>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [Dime] Progressing draft-ietf-dime-group-signaling
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 07:37:30 -0000

Folks,


The poll has ended and no one seemed to have hard times against the =
third option.
Thus, the editor of the I-D is free to change the document according =
what is needed
for the third alternative.


- Jouni & Lionel


On Jun 19, 2013, at 2:17 PM, Jouni Korhonen <jouni.nospam@gmail.com> =
wrote:

> Folks,
>=20
> As you remember we surfaced the draft-ietf-dime-group-signaling I-D =
during overload requirements discussion, see =
http://www.ietf.org/mail-archive/web/dime/current/msg05582.html
>=20
> In order to resurrect draft-ietf-dime-group-signaling we need to know =
what the WG prefers as the final technical solution. Originally there =
were two approaches: dedicated Group Commands or a single Bulk =
Operations command. Recently (pun intended) a third alternative showed =
up: additional AVPs to turn any existing Diameter command into a group =
command. The late comer also got some backup, at least from French =
speaking part of Europe ;)
>=20
> So, unless no one has anything against it, we could go for the third =
option. I does seem to fit better e.g. into the overload control needs =
than new commands. If you have concerns on the third (AVP) approach and =
want it to be rejected, then express you voice on the list by 26th June =
EOB (EEST).
>=20
> - Jouni & Lionel


From jouni.nospam@gmail.com  Thu Jun 27 14:06:52 2013
Return-Path: <jouni.nospam@gmail.com>
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 09D4111E80F2 for <dime@ietfa.amsl.com>; Thu, 27 Jun 2013 14:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-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 GXzZ1gJOWfbB for <dime@ietfa.amsl.com>; Thu, 27 Jun 2013 14:06:51 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD0B11E80EC for <dime@ietf.org>; Thu, 27 Jun 2013 14:06:51 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id d7so509047bkh.25 for <dime@ietf.org>; Thu, 27 Jun 2013 14:06:50 -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:x-mailer; bh=WeMKVo/a3qINXHgY3Rl4Z8RRCKVUKdJAy3VrjVulWM8=; b=k4SwH0C34EEnwq1YJ4DmIusR9yERcGVRmzd7CARm9qWfAzBax1eoYpb2PBJR7eFV/H kRFmy2hr0bKMzFXAOWIgEhyf1cunQZfcgg1RucszB6ttxK2C4kMHPyK5hN5INlS4d0eH Vs32LaJoun9fyb45kXl6y/PBx0JiojM3oakows3fPM7q4jug1s6Fble0OtnC4Gszm1NU gyOjmj2J9AwHS2zyTp7JHZ17kQnWsiWU/rbevLdOSZTCbeF/jRLK/htRrsmjOd6wAMt7 crt1BJMtjlfwrpkYGDxpmWTiqfziwHhxaNZAGtTuSezj4BnfHiUZ4balFQuIzd4TwOCu Q5ew==
X-Received: by 10.204.3.137 with SMTP id 9mr1387097bkn.147.1372367210308; Thu, 27 Jun 2013 14:06:50 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:29e3:eb80:897d:8b3e? ([2001:1bc8:101:f101:29e3:eb80:897d:8b3e]) by mx.google.com with ESMTPSA id hn4sm2338873bkc.2.2013.06.27.14.06.47 for <dime@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 14:06:47 -0700 (PDT)
From: Jouni <jouni.nospam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Jun 2013 00:06:46 +0300
References: <20130627200010.20880.67670.idtracker@ietfa.amsl.com>
To: "DiME@ietf.org" <dime@ietf.org>
Message-Id: <BA6AFB4F-6285-479B-9C49-D3BA8E1AAD8F@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Subject: [Dime] Fwd: dime - Requested session has been scheduled for IETF 87
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 21:06:52 -0000

FYI

Begin forwarded message:

> From: "\"IETF Secretariat\"" <agenda@ietf.org>
> Subject: dime - Requested session has been scheduled for IETF 87
> Date: June 27, 2013 11:00:10 PM GMT+03:00
> To: jouni.nospam@gmail.com
> Cc: dime-ads@tools.ietf.org, jouni.nospam@gmail.com, =
lionel.morand@orange.com, smccammon@amsl.com
>=20
> Dear Jouni Korhonen,
>=20
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request.=20
>=20
> dime Session 1 (2:00:00)
>    Monday, Afternoon Session I 1300-1500
>    Room Name: Schoeneberg 1/2
>    ---------------------------------------------
>=20
>=20
>=20
> Request Information:
>=20
>=20
> ---------------------------------------------------------
> Working Group Name:=20
> Area Name:=20
> Session Requester:=20
>=20
> Number of Sessions: 1
> Length of Session(s):  2 Hours
> Number of Attendees: 35
> Conflicts to Avoid:=20
> First Priority: 6man dmm abfab v6ops radext
> Second Priority: 6lowpan core behave softwire homenet netext
>=20
>=20
>=20
> Special Requests:
>=20
> ---------------------------------------------------------
>=20