From internet-drafts@ietf.org Wed Aug 1 19:51:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D4811E8109; Wed, 1 Aug 2012 19:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 7-heSh90RKDn; Wed, 1 Aug 2012 19:51:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36811E8169; Wed, 1 Aug 2012 19:51:38 -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.33 Message-ID: <20120802025138.6205.34713.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 19:51:38 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-18.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 02:51:39 -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 Support for Proxy Mobile IPv6 Localized Routing Author(s) : Glen Zorn Qin Wu Jouni Korhonen Filename : draft-ietf-dime-pmip6-lr-18.txt Pages : 12 Date : 2012-08-01 Abstract: In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-pmip6-lr-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-pmip6-lr-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From arud.selvan.sundaramurthy@ericsson.com Thu Aug 2 00:08:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6713311E8186 for ; Thu, 2 Aug 2012 00:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XejI7mw+kXSZ for ; Thu, 2 Aug 2012 00:08:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E33FE11E8152 for ; Thu, 2 Aug 2012 00:08:22 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-f6-501a2764c787 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1B.25.12641.4672A105; Thu, 2 Aug 2012 09:08:21 +0200 (CEST) Received: from ESESSCMS0357.eemea.ericsson.se ([169.254.1.39]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 2 Aug 2012 09:08:21 +0200 From: Arud Selvan Sundaramurthy To: "dime@ietf.org" Date: Thu, 2 Aug 2012 09:08:20 +0200 Thread-Topic: Regarding 'P' bit setting in Diameter Header Thread-Index: Ac1wd9EgGC6l9z6HRAi+axQWKXdYXQ== Message-ID: <044FE89B8513A3408E08F57DCD25EB1737B397E796@ESESSCMS0357.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_044FE89B8513A3408E08F57DCD25EB1737B397E796ESESSCMS0357e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrW6qulSAQdMERou5vSvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWLSS/aCi3oVU7+/Ym9gbNXsYuTgkBAwkdiyt6qLkRPIFJO4 cG89WxcjF4eQwClGiQdbvrBCOPMZJRra7jOBVLEJeEhM7HzKBtIsIqAscfqXA4jJIqAicegZ D0iFsICpxOqNP8CqRQSsJKbPvsoIYetJLF5xgB3E5hUIl9gyZxoziM0ItPf7qTVg9cwC4hK3 nsxngrhHQGLJnvPMELaoxMvH/1gh6kUl7rSvZ4Soz5e41nqWFWKmoMTJmU9YJjAKzUIyahaS sllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRuHcxMyc9HJzvdSizOTi4vw8veLU TYzAWDi45bfBDsZN98UOMUpzsCiJ8+qp7vcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhf fE9APcNOz3FFuDZv0TXhmF/pel3HY7grM8/0vgt52XPBOS/e+DVHwv9K/TvBqcJ/YgMbtO4o bT3J/vCEp7rx4W25Wcdr1fjefc58FXS6d//yX++nm4VqCfW5ci3tMtx8JPDvc7F+e8evy1Yr Pt53sOzHQSYW3ZvfJ3DuEZOJ4/7/ROPQcSWW4oxEQy3mouJEANFSNbJTAgAA Subject: [Dime] Regarding 'P' bit setting in Diameter Header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:08:24 -0000 --_000_044FE89B8513A3408E08F57DCD25EB1737B397E796ESESSCMS0357e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt in diameter proxy behaviour when routing a request. When diameter proxy receives a request with 'P' bit **NOT SET ** in header = , and having valid routing entry to route the request to next hop, will i= t route the request to next hop by setting the 'P' bit or will it reply wil= l "DIAMETER_UNABLE_TO_DELIVER" as the 'P' bit is not set. Will the proxy i= s allowed to modify the header in this case? As per bis draft-ietf-dime-rfc3588bis-34.txt in section 6.1.9 , it states "Relay and proxy agents are not required to perform full inspection of incoming messages. At a minimum, validation of the message header and relevant routing AVPs has to be done when relaying messages.". Does the "minimum header validation" includes checking the 'P' in header by= Proxy agent also? Kindly provide your suggestion on this. Thanks, Arud selvan.S. --_000_044FE89B8513A3408E08F57DCD25EB1737B397E796ESESSCMS0357e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I  have a doubt in diameter proxy behaviour whe= n routing  a request.

 

When diameter proxy receives a request with &#= 8216;P’ bit **NOT SET ** in header   , and having valid rou= ting entry to route the request to next hop, will it route the request to n= ext hop by setting the ‘P’ bit or will it reply will “DIA= METER_UNABLE_TO_DELIVER” as the ‘P’ bit is not set.  = ;Will the proxy is allowed to modify the header in this case?

 

 =

As per bis draft-iet= f-dime-rfc3588bis-34.txt in section 6.1.9 , it states
“Relay and proxy agents are not required to perform full ins=
pection of
<=
span lang=3DEN style=3D'font-size:10.0pt'>   incoming messages.&n=
bsp; At a minimum, validation of the message header
= 
   and relevant routing AVPs has to be done when relaying=
 messages.”.

Does the “minimum header validation” includes che= cking the ‘P’ in header by Proxy agent also?<= /h1>

Kindly provide your suggestion on this.

=  

Thanks,

Arud selvan.S.

 <= /o:p>

= --_000_044FE89B8513A3408E08F57DCD25EB1737B397E796ESESSCMS0357e_-- From glenzorn@gmail.com Thu Aug 2 10:45:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8D211E80D3 for ; Thu, 2 Aug 2012 10:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, 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 tFqssFj2jRA4 for ; Thu, 2 Aug 2012 10:45:07 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25A3721F85DD for ; Thu, 2 Aug 2012 10:45:07 -0700 (PDT) Received: by qadz3 with SMTP id z3so3543736qad.10 for ; Thu, 02 Aug 2012 10:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:organization :date:message-id:mime-version:x-mailer; bh=f/XJKPH2oDvH3cTEdSSYyOrh0ij/Ljx44d/wSGjDVX0=; b=aZY2ZQskY0uT+rTfO6B9/RIKPzm0oOwLZGmq+ld3mlQu1YMl14Kiu/oxkaRhUwdKAx vGuxo9XaWJPvJbv7eCqSzfL+pFCsXwdcoRay4rQEFg9blx3gt9xgVQTFtXFVbIK2DLRS azBTw8xPh2BeKOyb8/pKfYN7S1OSld/HNqIgvDWd3Ij0WKatqZfZYijxD8o8h7nHFr5x GTT9fIaJU9y6GTYp7s7hlDn47Rt76tkqUOCsL4vBj3SgRf1Fx7/h6r81bG0+y6V6nZMo WgJiTYIacyr/8Oen0Z+0+9dA5CT4DaZe3tWdgpkJOrAfuxTklqiUlCFQ9HilTZ4t4Fl+ a0XQ== Received: by 10.60.13.201 with SMTP id j9mr38346244oec.51.1343929506566; Thu, 02 Aug 2012 10:45:06 -0700 (PDT) Received: from [10.0.1.195] (216-19-185-109.dyn.novuscom.net. [216.19.185.109]) by mx.google.com with ESMTPS id n7sm5069958oec.2.2012.08.02.10.45.04 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 10:45:06 -0700 (PDT) From: Glen Zorn To: dime@ietf.org In-Reply-To: <044FE89B8513A3408E08F57DCD25EB1737B397E796@ESESSCMS0357.eemea.ericsson.se> References: <044FE89B8513A3408E08F57DCD25EB1737B397E796@ESESSCMS0357.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="=-fUNBjhf+ItMYib2H9p4S" Organization: Network Zen Date: Thu, 02 Aug 2012 10:45:03 -0700 Message-ID: <1343929503.17758.16.camel@gwz-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Subject: Re: [Dime] Regarding 'P' bit setting in Diameter Header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:45:09 -0000 --=-fUNBjhf+ItMYib2H9p4S Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 2012-08-02 at 09:08 +0200, Arud Selvan Sundaramurthy wrote: > Hi, > > I have a doubt in diameter proxy behaviour when routing a request. > > > > When diameter proxy receives a request with ‘P’ bit **NOT SET ** in > header , and having valid routing entry to route the request to next > hop, will it route the request to next hop by setting the ‘P’ bit or > will it reply will “DIAMETER_UNABLE_TO_DELIVER” as the ‘P’ bit is not > set. Will the proxy is allowed to modify the header in this case? No; the value of the 'P' bit is part of the command definition and isn't modifiable at run time. > > > > > > > > As per bis draft-ietf-dime-rfc3588bis-34.txt in section 6.1.9 , it > states > > “Relay and proxy agents are not required to perform full inspection of > incoming messages. At a minimum, validation of the message header > and relevant routing AVPs has to be done when relaying messages.”. > > Does the “minimum header validation” includes checking the ‘P’ in > header by Proxy agent also? It actually says "At a minimum," which means 'At the very least'. > Kindly provide your suggestion on this. > > > > Thanks, > > Arud selvan.S. > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=-fUNBjhf+ItMYib2H9p4S Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-08-02 at 09:08 +0200, Arud Selvan Sundaramurthy wrote:
Hi,

I  have a doubt in diameter proxy behaviour when routing  a request.

 

When diameter proxy receives a request with ‘P’ bit **NOT SET ** in header   , and having valid routing entry to route the request to next hop, will it route the request to next hop by setting the ‘P’ bit or will it reply will “DIAMETER_UNABLE_TO_DELIVER” as the ‘P’ bit is not set.  Will the proxy is allowed to modify the header in this case?

No; the value of the 'P' bit is part of the command definition and isn't modifiable at run time.


 

 


As per bis draft-ietf-dime-rfc3588bis-34.txt in section 6.1.9 , it states 

“Relay and proxy agents are not required to perform full inspection of
   incoming messages.  At a minimum, validation of the message header
   and relevant routing AVPs has to be done when relaying messages.”.

Does the “minimum header validation” includes checking the ‘P’ in header by Proxy agent also?


It actually says "At a minimum," which means 'At the very least'.

Kindly provide your suggestion on this.

 

Thanks,

Arud selvan.S.

 

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

--=-fUNBjhf+ItMYib2H9p4S-- From iesg-secretary@ietf.org Fri Aug 10 10:10:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F063021F87E4; Fri, 10 Aug 2012 10:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 y-aotro9DeLy; Fri, 10 Aug 2012 10:10:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F0121F8832; Fri, 10 Aug 2012 10:10:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120810171048.5660.26563.idtracker@ietfa.amsl.com> Date: Fri, 10 Aug 2012 10:10:48 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to Proposed Standard (draft-ietf-dime-pmip6-lr-18.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:10:50 -0000 The IESG has approved the following document: - 'Diameter Support for Proxy Mobile IPv6 Localized Routing' (draft-ietf-dime-pmip6-lr-18.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/ Technical Summary Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of localized routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol. Working Group Summary There is Dime WG consensus behind the document. Document Quality The document is complete, straightforward, simple and well-written. Personnel Lionel Morand is the Document Shepherd for this document Dan Romascanu was the first responsible Area Director. Benoit Claise is the current responsible Area Director. From jouni.korhonen@iki.fi Sat Aug 11 03:43:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DDC21F8535 for ; Sat, 11 Aug 2012 03:43: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 P7N-jhseHpQP for ; Sat, 11 Aug 2012 03:43:05 -0700 (PDT) Received: from vs18.mail.saunalahti.fi (vs18.mail.saunalahti.fi [62.142.117.199]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5F21F853B for ; Sat, 11 Aug 2012 03:43:04 -0700 (PDT) Received: from vams (localhost [127.0.0.1]) by vs18.mail.saunalahti.fi (Postfix) with SMTP id E8C31180043; Sat, 11 Aug 2012 13:43:02 +0300 (EEST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs18.mail.saunalahti.fi (Postfix) with ESMTP id CD35C180043; Sat, 11 Aug 2012 13:43:02 +0300 (EEST) Received: from [188.117.15.109] (unknown [188.117.15.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 94438216CD9; Sat, 11 Aug 2012 13:42:58 +0300 (EEST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Aug 2012 13:42:57 +0300 Message-Id: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 11 Aug 2012 03:44:39 -0700 Cc: dime-chairs@tools.ietf.org Subject: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 10:43:06 -0000 Folks, Like discussed briefly during the Vancouver meeting there is a small charter & milestone update required for the overload work. The topic has already been brought up in IESG.. Here is the proposed charter update text: - Diameter overload control. The aim of this work is to identify the limitations of the Diameter protocol level overload control provided by the current Diameter Base protocol. A set of requirements will be provided to define a new Diameter level overload control mechanisms. .. Sep 2012 - Submit I-D ' Diameter Overload Control Requirements' as a working group document. To be Informational RFC. Nov 2012 - Submit I-D ' Diameter Overload Control' as a working group = document. To be Standards Track RFC. Dec 2012 - Submit I-D ' Diameter Overload Control Requirements' to the = IESG for consideration as a Informational RFC. Mar 2013 - Submit I-D ' Diameter Overload Control' to the IESG for = consideration as a Proposed Standard RFC. - Jouni & Lionel From jouni.nospam@gmail.com Sun Aug 12 13:47:36 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB321F85E3 for ; Sun, 12 Aug 2012 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 72Iw04rQxTs6 for ; Sun, 12 Aug 2012 13:47:35 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE00021F85E0 for ; Sun, 12 Aug 2012 13:47:34 -0700 (PDT) Received: by eekb45 with SMTP id b45so788888eek.31 for ; Sun, 12 Aug 2012 13:47:34 -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:message-id :to:mime-version:x-mailer; bh=ZhwdowLEmcRg5sgues2+Jg5D3XNko89Lt719PTl8W7I=; b=aCY8Iq5KMHjQu4toBiHopg0sBr9PORGfhQT3yTlCW5A6W/Z05trVjeKtVFWxShriJD CaSIOmnF9/q/g1BBduNneA1qdWKlwb98sKH8T2YmkiBthYZyf+Q9UDRXgSE8zxwt65cG BASRMTnn7qc85aXBeFuwOnh+SU7d22lINS22rgLdBbSlw4AxUIssxApzV0XBNpH5Amr4 oLcNxrtJUj6UqAnAbD/uIKbmKghW/yBHlf951nPy0IXmiBWV7XwU/LhiWix2Xz3euiOb R5mBW/XBmOeCvonJ45Yo/Sic76+gnyzq6UE2cF0GiK4UVQa+I9EqWDrbJ81SZu3qZG0X J/+Q== Received: by 10.14.215.193 with SMTP id e41mr2120883eep.44.1344804453911; Sun, 12 Aug 2012 13:47:33 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id 45sm13393111eed.17.2012.08.12.13.47.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Aug 2012 13:47:33 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Aug 2012 23:47:32 +0300 Message-Id: <56E8263E-D647-454F-99D8-E90E9886D420@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Draft IETF#84 meeting minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 20:47:36 -0000 Folks, Have a look at the draft minutes. There are few "???"s regarding who gave comments. It would be nice to have those filled with correct names. Thanks a bunch to Jane for taking excellent minutes. - JOuni ---------------------------- Minutes of the DIME WG meeting at IETF 84 Tuesday, July 31, 2012 1300-1500 Afternoon Session I, Georgia A Administrivia =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=20 Presenters: Jouni Korhonen, Lionel Morand - Note well presented - Note taker: Jean Mahoney - Jabber scribe: Tom Taylor =3D=3D Working Group Status Update =3D=3D Presenters: Jouni Korhonen, Lionel Morand WG Documents: - draft-ietf-dime-erp=20 - proto writeup =20 - another draft - draft-ietf-dime-app-design-guide=20 - if wg agrees, move to wglc - draft-ietf-dime-realm-based-redirect=20 - discuss here - reissue for wglc - draft-ietf-dime-group-signaling - at an early stage A list of documents that have dependencies on draft-ietf-dime-rfc3588bis = was=20 presented.=20 Benoit Claise, OPS area director: A new version of = draft-ietf-dime-pmip6-lr has=20 been posted. One author has removed himself from the author list. = However,=20 there's a copyright issue and the author needs to be acknowledged. = Marco, what=20 do you want? Marco Liebsch: If someone should be acknowledged, then add them to the=20= Acknowledgement section. My name isn't in the latest, keep as-is. Benoit: If the text that Marco contributed is gone, then we don't have = an issue. Marco: It has been removed. Benoit: No issue then. It is to the main author (Glen Zorn) to = acknowledge or=20 not.=20 =3D=3D Charter update =3D=3D - Removed mib docs due to lack of interest. Realm based redirect=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D draft-ietf-dime-realm-based-redirect Presenter: Tom Taylor =3D=3D Issue: Redirect Agent versus Server =3D=3D Redirect agents don't have application-specific behavior. Redirection = must be=20 performed by the application at a server, and only a proxy or client can = reroute=20 based on the response. Does anyone have issues with changing from redirect agent to server? Lionel: Clarify what a proxy can do. Clarify new requests versus = redirect. This=20 is on the right path, but more information needs to be added. =3D=3D Issue: handling of request with Destination-Host AVP =3D=3D Destination-Host AVP is normally added to requests only subsequent to = the=20 initial request of the session. The Destination-Host AVP is incompatable = with=20 realm-based redirection. However, the Destination-Host will be there = because you=20 are in the middle of the session rather than at the beginning.=20 The application can specify that it only applies to initial requests, so = it's=20 not disruptive to current requests. =20 Lionel: Is there a use case where you would redirect midsession? If not, = just=20 remove info on the Destination-Host AVP. It's a blocking point. =20 ACTION to working group: Please comment on the mailing list on whether = we need=20 to support mid-session realm-based redirection. Tom Taylor took an action on himself to clean up the text about the = proxy=20 behavior. Next version of the document will be out this week or next.=20 Design Guidelines =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D draft-ietf-dime-app-design-guide Presenter: Lionel Morand Lionel presented changes to the document since version -14. Lionel feels that the document is finished, and is planning a WGLC in = August. ACTION to the working group: Please provide feedback. Ben Campbell: RFC3588bis recommends TLS and DTLS, does providing IPsec=20= recommendations violate that part of RFC3588bis?=20 Lionel: The IPsec text was originally in RFC3588. It has been removed = from=20 RFC3588bis and added to the design guide.=20 Ben: But isn't using IPsec a deployment decision? Lionel: It's a design decision, you can specify the transport when you = design=20 the application.=20 Group signaling =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D draft-ietf-dime-group-signaling Presenter: Marco Liebsch Marco presented two different approaches to manipulating groups of = sessions:=20 - Dedicated group commands - do not contain the same AVPs as their non-group equivalents - new commands are defined for each group operation - new Application-Id - pros: straightforward, low-level of ambiguity - cons: new commands and formats needed for all bulk-enabled commands; proxy needs to be aware of=20 the new application - Bulk operation command - a single Diameter command for bulk operations - applies to existing Diameter commands that handle single sessions - pros: no new formats or codes needed - cons: Session-Id AVP needs to be ignored or used=20 to carry group ID; proxy needs to be aware of=20 the new application; potential issue with mandatory attributes in the body when they apply to a single=20 session Lionel: There's no way to know that dedicated group commands are for a = group Marco: There is a new application in the header, a new command code, and = the=20 Session-Group-Id AVP. Lionel: For example, only thing that GRAR has in common with RAR is the=20= Re-Auth-Request-Type. Except the name, there's nothing in common with = the=20 original command. There is nothing here that says you have to do = something=20 else here.=20 Lionel: For the bulk operation command, the RAR command code is reused, = you can=20 rely on this to know what to do. Marco: =46rom an implementation perspective, it's not hard to link a new = GRAR to=20 the RAR state machine. Lionel: Different state machines? Marco: Yes, it varies. Lionel: You'll have same command code but with different state machines = and=20 ABNF. Marco: The mandatory fields differ. Jouni: We're modifying current ABNF. Something is not clear and is = against=20 existing RFCs.=20 Next steps: Soliciting input on formatting, design update draft in August Lionel: For a minimal impact on existing applications, just add group = AVPs. The=20 only new information is the two new AVPs (Session-Group-id,=20 Session-Group-Action). What if we added these AVPs and created a new=20= application? Can reuse for any command.=20 Jouni: An optional AVP, but there's another issue - you don't know if = the other=20 end is supporting it. Need to negotiate capabilities.=20 Lionel: Create a new application, have capabilities exchange. Or use = optional=20 AVP and advertise support.=20 Adam: Capabilities exchange only works between adjacent nodes. Each node = in path=20 will have to support it. I would prefer not to define new = applications. Work=20 here can be reused for overload.=20 Lionel: The only way to avoid new applications is to use optional AVPs. Adam: Yes, I would prefer that.=20 Glen: Capabilities are pair-wise, they don't go forward. It's just an=20 advertisement, it's not negotiated.=20 Adam: We're not creating groups and then adding sessions to them. We're = adding=20 existing sessions to groups. Right? Marco: Individual Session-Id is carried but ignored.=20 ???: This could be a new session. Unless there's a reason to limit to = existing=20 sessions, it should apply to both.=20 Mark Jones: (from the chat room) About end-end negotiation, groups are = always=20 assigned at session creation.=20 ACTION to working group: discuss on the mailing list. Diameter Overload Control =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Overload control justification and use cases Presenter: Martin Dolly Martin Dolly presented reasons for Diameter overload control. Glen Zorn asked for clarification of 3GPP terms since it shouldn't be = assumed=20 that participants are familiar with them.=20 Benoit: What are you asking for with this presentation? Martin: AT&T and other operators see a need to support a diameter = overlaod=20 mechanism to alleviate problems identified here. Glen: I want to be convinced why this is the IETF's problem. Inadequate = capacity=20 or poor network planning is not our problem.=20 Ben: The next presentation will say how this is a IETF problem. Peak = loads are=20 many orders of magnetude above regular load. If you provision for = that,=20 everyone pays more. Adam: It's like saying that TCP congestion isn't a problem. It's bursty, = it can=20 pile up, the network will exceed capacity. Need to make sure it = doesn't melt=20 down.=20 Martin: We need a resilient network. This is like SIP overload. AT&T = initiated=20 the SIP overload work. We want a generic solution across the diameter=20= interfaces.=20 ??: My company thinks the IETF has the expertise and wants the IETF to = do this=20 work. Tom Taylor: Bursts happen. Something has to be done.=20 Jouni: The operators have been kind enough to ask us to work on it. Jin Rong, ATT: The problem is in the base protocol. Handling it in the = protocol=20 is the most efficient way to handle it. Otherwise we don't have a tool = to=20 solve this problem. draft-mcmurry-dime-overload-reqs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Presenter: Eric McMurry Eric's presentation on Diameter overload control requirements was cut = short due=20 to running out of time. Eric: The point of the presentation is to get people interested, and it = should=20 be handled in the base protocol. There's a draft out there of = requirements. We=20 want to get agreement on that before working on a mechanism. Next = steps: is=20 the problem real and worth working on? Does the work belong in dime? Ben: We don't expect the doc to be perfect, don't know if the = requirements are=20 all there. Is the dime working group the right place? Mark Jones: Yes, it's real, and worth working on. It fits the charter. Martin: ATT supports this and would love to see this in the wg.=20 Geller (??): We support this. John Kaippallimalil from Huawei CRO (3gpp core network overload): We = support=20 this, too. Tom Taylor: I support it.=20 Lionel (as an individual): We see this problem in multiple protocols. We = need to=20 identify problems with the existing specification. What's missing, = unclear?=20 Have requirements to fill the gap. Extend the base protocol? Or create = a new=20 application? Jouni (as an individual): This is a real problem, need to work on it = (commented=20 already few points on email earlier), need a solution. Ben: We agree that requirements come first. It's been controversial for = every=20 working group that faces it.=20 Benoit (as AD): I'm pleased that operators come here. I believe there's = support.=20 You might ask who opposes. Who will work on it? Jouni: anyone against? Who will work on it: Benoit: There's support. Create a problem statement and then = requirements? Jouni (ind): Problem statements are waste of time. Add a paragraph in = the=20 requirements doc.=20 Lionel: More than one paragraph. Have one document that explains what's = missing=20 in Diameter and provides a set of requirements.=20 Jouni: Anyone aganist adoption?=20 ACTION for Jouni: To ask the working group about adoption.=20 Ben: If the wg adopts, we'll adjust for consensus.=20 Benoit: Don't have to hurry on deciding that it fits the charter.=20 Lionel: We need to first agree that we will work on it.=20 Martin: You need to hurry on deciding to work on it, otherwise = ATT/VZW/TMO - 40%=20 of LTE deployment - will ask our vendors to work on non-standard = solutions.=20 Lionel: This document is not blocked on whether it fits the charter.=20 From ben@nostrum.com Mon Aug 13 12:01:13 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB0D21F8437 for ; Mon, 13 Aug 2012 12:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.787 X-Spam-Level: X-Spam-Status: No, score=-101.787 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 EM31yNi8P0pv for ; Mon, 13 Aug 2012 12:01:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB61421F84DA for ; Mon, 13 Aug 2012 12:01:08 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7DJ0xQj042363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 14:01:02 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <56E8263E-D647-454F-99D8-E90E9886D420@gmail.com> Date: Mon, 13 Aug 2012 14:00:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3967A5C5-6CB9-420E-8F75-B9B0D3B5D036@nostrum.com> References: <56E8263E-D647-454F-99D8-E90E9886D420@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1485) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] Draft IETF#84 meeting minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 19:01:14 -0000 The minutes look good to me.=20 I can't help with the missing names, except to point out that the minute = taker was "Jean" rather than "Jane" :-) Thanks! Ben. On Aug 12, 2012, at 3:47 PM, jouni korhonen = wrote: > Folks, >=20 > Have a look at the draft minutes. There are few "???"s regarding who > gave comments. It would be nice to have those filled with correct = names. >=20 > Thanks a bunch to Jane for taking excellent minutes. >=20 > - JOuni >=20 > ---------------------------- >=20 > Minutes of the DIME WG meeting at IETF 84 > Tuesday, July 31, 2012 > 1300-1500 Afternoon Session I, Georgia A >=20 > Administrivia =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=20 > Presenters: Jouni Korhonen, Lionel Morand >=20 > - Note well presented > - Note taker: Jean Mahoney > - Jabber scribe: Tom Taylor >=20 >=20 > =3D=3D Working Group Status Update =3D=3D > Presenters: Jouni Korhonen, Lionel Morand >=20 > WG Documents: > - draft-ietf-dime-erp=20 > - proto writeup =20 > - another draft > - draft-ietf-dime-app-design-guide=20 > - if wg agrees, move to wglc > - draft-ietf-dime-realm-based-redirect=20 > - discuss here > - reissue for wglc > - draft-ietf-dime-group-signaling > - at an early stage >=20 > A list of documents that have dependencies on = draft-ietf-dime-rfc3588bis was=20 > presented.=20 >=20 > Benoit Claise, OPS area director: A new version of = draft-ietf-dime-pmip6-lr has=20 > been posted. One author has removed himself from the author list. = However,=20 > there's a copyright issue and the author needs to be acknowledged. = Marco, what=20 > do you want? >=20 > Marco Liebsch: If someone should be acknowledged, then add them to the=20= > Acknowledgement section. My name isn't in the latest, keep as-is. >=20 > Benoit: If the text that Marco contributed is gone, then we don't have = an issue. >=20 > Marco: It has been removed. >=20 > Benoit: No issue then. It is to the main author (Glen Zorn) to = acknowledge or=20 > not.=20 >=20 >=20 > =3D=3D Charter update =3D=3D >=20 > - Removed mib docs due to lack of interest. >=20 >=20 > Realm based redirect=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > draft-ietf-dime-realm-based-redirect > Presenter: Tom Taylor >=20 > =3D=3D Issue: Redirect Agent versus Server =3D=3D >=20 > Redirect agents don't have application-specific behavior. Redirection = must be=20 > performed by the application at a server, and only a proxy or client = can reroute=20 > based on the response. >=20 > Does anyone have issues with changing from redirect agent to server? >=20 > Lionel: Clarify what a proxy can do. Clarify new requests versus = redirect. This=20 > is on the right path, but more information needs to be added. >=20 > =3D=3D Issue: handling of request with Destination-Host AVP =3D=3D >=20 > Destination-Host AVP is normally added to requests only subsequent to = the=20 > initial request of the session. The Destination-Host AVP is = incompatable with=20 > realm-based redirection. However, the Destination-Host will be there = because you=20 > are in the middle of the session rather than at the beginning.=20 >=20 > The application can specify that it only applies to initial requests, = so it's=20 > not disruptive to current requests. =20 >=20 > Lionel: Is there a use case where you would redirect midsession? If = not, just=20 > remove info on the Destination-Host AVP. It's a blocking point. >=20 > =20 >=20 > ACTION to working group: Please comment on the mailing list on whether = we need=20 > to support mid-session realm-based redirection. >=20 > Tom Taylor took an action on himself to clean up the text about the = proxy=20 > behavior. >=20 > Next version of the document will be out this week or next.=20 >=20 >=20 >=20 > Design Guidelines =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > draft-ietf-dime-app-design-guide > Presenter: Lionel Morand >=20 > Lionel presented changes to the document since version -14. >=20 > Lionel feels that the document is finished, and is planning a WGLC in = August. >=20 > ACTION to the working group: Please provide feedback. >=20 > Ben Campbell: RFC3588bis recommends TLS and DTLS, does providing IPsec=20= > recommendations violate that part of RFC3588bis?=20 >=20 > Lionel: The IPsec text was originally in RFC3588. It has been removed = from=20 > RFC3588bis and added to the design guide.=20 >=20 > Ben: But isn't using IPsec a deployment decision? >=20 > Lionel: It's a design decision, you can specify the transport when you = design=20 > the application.=20 >=20 >=20 >=20 > Group signaling =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > draft-ietf-dime-group-signaling > Presenter: Marco Liebsch >=20 > Marco presented two different approaches to manipulating groups of = sessions:=20 > - Dedicated group commands > - do not contain the same AVPs as their non-group > equivalents > - new commands are defined for each group operation > - new Application-Id > - pros: straightforward, low-level of ambiguity > - cons: new commands and formats needed for all > bulk-enabled commands; proxy needs to be aware of=20 > the new application > - Bulk operation command > - a single Diameter command for bulk operations > - applies to existing Diameter commands that handle > single sessions > - pros: no new formats or codes needed > - cons: Session-Id AVP needs to be ignored or used=20 > to carry group ID; proxy needs to be aware of=20 > the new application; potential issue with mandatory > attributes in the body when they apply to a single=20 > session >=20 > Lionel: There's no way to know that dedicated group commands are for a = group >=20 > Marco: There is a new application in the header, a new command code, = and the=20 > Session-Group-Id AVP. >=20 > Lionel: For example, only thing that GRAR has in common with RAR is = the=20 > Re-Auth-Request-Type. Except the name, there's nothing in common with = the=20 > original command. There is nothing here that says you have to do = something=20 > else here.=20 >=20 > Lionel: For the bulk operation command, the RAR command code is = reused, you can=20 > rely on this to know what to do. >=20 > Marco: =46rom an implementation perspective, it's not hard to link a = new GRAR to=20 > the RAR state machine. >=20 > Lionel: Different state machines? >=20 > Marco: Yes, it varies. >=20 > Lionel: You'll have same command code but with different state = machines and=20 > ABNF. >=20 > Marco: The mandatory fields differ. >=20 > Jouni: We're modifying current ABNF. Something is not clear and is = against=20 > existing RFCs.=20 >=20 > Next steps: > Soliciting input on formatting, design update draft in August >=20 > Lionel: For a minimal impact on existing applications, just add group = AVPs. The=20 > only new information is the two new AVPs (Session-Group-id,=20 > Session-Group-Action). What if we added these AVPs and created a new=20= > application? Can reuse for any command.=20 >=20 > Jouni: An optional AVP, but there's another issue - you don't know if = the other=20 > end is supporting it. Need to negotiate capabilities.=20 >=20 > Lionel: Create a new application, have capabilities exchange. Or use = optional=20 > AVP and advertise support.=20 >=20 > Adam: Capabilities exchange only works between adjacent nodes. Each = node in path=20 > will have to support it. I would prefer not to define new = applications. Work=20 > here can be reused for overload.=20 >=20 > Lionel: The only way to avoid new applications is to use optional = AVPs. >=20 > Adam: Yes, I would prefer that.=20 >=20 > Glen: Capabilities are pair-wise, they don't go forward. It's just an=20= > advertisement, it's not negotiated.=20 >=20 > Adam: We're not creating groups and then adding sessions to them. = We're adding=20 > existing sessions to groups. Right? >=20 > >=20 > Marco: Individual Session-Id is carried but ignored.=20 >=20 > ???: This could be a new session. Unless there's a reason to limit to = existing=20 > sessions, it should apply to both.=20 >=20 > Mark Jones: (from the chat room) About end-end negotiation, groups are = always=20 > assigned at session creation.=20 >=20 > ACTION to working group: discuss on the mailing list. >=20 >=20 > Diameter Overload Control =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Overload control justification and use cases > Presenter: Martin Dolly >=20 > Martin Dolly presented reasons for Diameter overload control. >=20 > Glen Zorn asked for clarification of 3GPP terms since it shouldn't be = assumed=20 > that participants are familiar with them.=20 >=20 > Benoit: What are you asking for with this presentation? >=20 > Martin: AT&T and other operators see a need to support a diameter = overlaod=20 > mechanism to alleviate problems identified here. >=20 > Glen: I want to be convinced why this is the IETF's problem. = Inadequate capacity=20 > or poor network planning is not our problem.=20 >=20 > Ben: The next presentation will say how this is a IETF problem. Peak = loads are=20 > many orders of magnetude above regular load. If you provision for = that,=20 > everyone pays more. >=20 > Adam: It's like saying that TCP congestion isn't a problem. It's = bursty, it can=20 > pile up, the network will exceed capacity. Need to make sure it = doesn't melt=20 > down.=20 >=20 > Martin: We need a resilient network. This is like SIP overload. AT&T = initiated=20 > the SIP overload work. We want a generic solution across the diameter=20= > interfaces.=20 >=20 > ??: My company thinks the IETF has the expertise and wants the IETF to = do this=20 > work. >=20 > Tom Taylor: Bursts happen. Something has to be done.=20 >=20 > Jouni: The operators have been kind enough to ask us to work on it. >=20 > Jin Rong, ATT: The problem is in the base protocol. Handling it in the = protocol=20 > is the most efficient way to handle it. Otherwise we don't have a = tool to=20 > solve this problem. >=20 >=20 >=20 > draft-mcmurry-dime-overload-reqs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Presenter: Eric McMurry >=20 > Eric's presentation on Diameter overload control requirements was cut = short due=20 > to running out of time. >=20 > Eric: The point of the presentation is to get people interested, and = it should=20 > be handled in the base protocol. There's a draft out there of = requirements. We=20 > want to get agreement on that before working on a mechanism. Next = steps: is=20 > the problem real and worth working on? Does the work belong in dime? >=20 > Ben: We don't expect the doc to be perfect, don't know if the = requirements are=20 > all there. Is the dime working group the right place? >=20 > Mark Jones: Yes, it's real, and worth working on. It fits the charter. >=20 > Martin: ATT supports this and would love to see this in the wg.=20 >=20 > Geller (??): We support this. >=20 > John Kaippallimalil from Huawei CRO (3gpp core network overload): We = support=20 > this, too. >=20 > Tom Taylor: I support it.=20 >=20 > Lionel (as an individual): We see this problem in multiple protocols. = We need to=20 > identify problems with the existing specification. What's missing, = unclear?=20 > Have requirements to fill the gap. Extend the base protocol? Or = create a new=20 > application? >=20 > Jouni (as an individual): This is a real problem, need to work on it = (commented=20 > already few points on email earlier), need a solution. >=20 > Ben: We agree that requirements come first. It's been controversial = for every=20 > working group that faces it.=20 >=20 > Benoit (as AD): I'm pleased that operators come here. I believe = there's support.=20 > You might ask who opposes. Who will work on it? >=20 > Jouni: anyone against? >=20 > >=20 > Who will work on it: >=20 > Benoit: There's support. Create a problem statement and then = requirements? >=20 > Jouni (ind): Problem statements are waste of time. Add a paragraph in = the=20 > requirements doc.=20 >=20 > Lionel: More than one paragraph. Have one document that explains = what's missing=20 > in Diameter and provides a set of requirements.=20 >=20 > Jouni: Anyone aganist adoption?=20 >=20 > >=20 > ACTION for Jouni: To ask the working group about adoption.=20 >=20 > Ben: If the wg adopts, we'll adjust for consensus.=20 >=20 > Benoit: Don't have to hurry on deciding that it fits the charter.=20 >=20 > Lionel: We need to first agree that we will work on it.=20 >=20 > Martin: You need to hurry on deciding to work on it, otherwise = ATT/VZW/TMO - 40%=20 > of LTE deployment - will ask our vendors to work on non-standard = solutions.=20 >=20 > Lionel: This document is not blocked on whether it fits the charter.=20= >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Mon Aug 13 14:45:57 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252FA21F856D for ; Mon, 13 Aug 2012 14:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, 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 hhT9KM+Rh-Dx for ; Mon, 13 Aug 2012 14:45:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4D21F84F5 for ; Mon, 13 Aug 2012 14:45:56 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7DLjoa2058229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 16:45:53 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> Date: Mon, 13 Aug 2012 16:45:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <196921E1-E38D-4342-AC06-57D0FB746394@nostrum.com> References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> To: jouni korhonen X-Mailer: Apple Mail (2.1485) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 21:45:57 -0000 Hi, Comments inline: On Aug 11, 2012, at 5:42 AM, jouni korhonen = wrote: > Folks, >=20 > Like discussed briefly during the Vancouver meeting there is a small > charter & milestone update required for the overload work. The topic > has already been brought up in IESG.. >=20 > Here is the proposed charter update text: >=20 > - Diameter overload control. The aim of this work is to identify the > limitations of the Diameter protocol level overload control provided > by the current Diameter Base protocol. A set of requirements will be > provided to define a new Diameter level overload control mechanisms. Is this language intended to cover work on the mechanism as well as work = on requirements? As written, it seems to cover identification of the = limitations and the the set of requirements for a mechanism, but not the = mechanism itself. =46rom the Vancouver meeting, I can see that being a = possible approach, but you did include milestones below that I assume to = be for the mechanism. That being said, I wonder why we need new charter text (as opposed to = milestones) for this? The current charter contains the following text: > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as = enhanced > features or bug fixes. It seems to me that the proposed work falls squarely into the "enhanced = features or bug fixes" language. Don't get me wrong; I don't object to adding more specific charter = language per se. My concern is that, if doing so delays having this work = show up as a milestone, that may encourage other SDOs (e.g 3GPP) to = pursue application-specific point solutions. Normally, I'm the first to = say that doing something correctly should take priority over meeting an = external deadline--but in this case I have trouble seeing why adding the = milestone under the existing charter text wouldn't be equally correct. >=20 > .. >=20 > Sep 2012 - Submit I-D ' Diameter Overload Control Requirements' as a > working group document. To be Informational RFC. >=20 > Nov 2012 - Submit I-D ' Diameter Overload Control' as a working group = document. > To be Standards Track RFC. >=20 > Dec 2012 - Submit I-D ' Diameter Overload Control Requirements' to the = IESG for > consideration as a Informational RFC. >=20 > Mar 2013 - Submit I-D ' Diameter Overload Control' to the IESG for = consideration > as a Proposed Standard RFC. I think the milestones look good in general, but I really hope it = doesn't take us until November to be able to progress the requirements = document. I guess that depends on whether we get any significant = controversy on it as more people read it. Thanks! Ben.= From glenzorn@gmail.com Tue Aug 14 05:17:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D7121F8692 for ; Tue, 14 Aug 2012 05:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ePJyWTw08Lk4 for ; Tue, 14 Aug 2012 05:17:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59CB621F85D0 for ; Tue, 14 Aug 2012 05:17:37 -0700 (PDT) Received: by yenm5 with SMTP id m5so403565yen.31 for ; Tue, 14 Aug 2012 05:17:37 -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 :references:in-reply-to:content-type; bh=hfBpLzepNpXAnJrFm5IOW60NaogG/uar1VByK9i2v/8=; b=XPncJrsd2w5QA4BAV99AwbVQi7nsjijwSDe2r5IdCsXejbHnuic2EbZBhf9JqXU1GJ pnOfY4lbW7fuHDCcuFAbUdwWl0DCjYVNRKLS8dNehlMY8eNKdcUDY9Yr17ObmT9wNfZp mizvkXQZug3ll3u1EtbNbGgdq84TxHCjA2EKEuKGfQIQXrybdsOz3b8H7na3TN2d8VAF HavmT8iVoB+3yKfMVafsj0hkzpQV7tC0Dquf8UxY8Bb9pqnr+jrqOc7ZusPm5CNOS7Yw 0KYkY8yg89wnmYXsUiQhR+dNOdV2DrsCO3cv1QYab3wzyte2RMrCh5YHbqwNHDzblXKY J3Qw== Received: by 10.50.220.194 with SMTP id py2mr11445669igc.15.1344946656444; Tue, 14 Aug 2012 05:17:36 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-122-129-252.revip2.asianet.co.th. [124.122.129.252]) by mx.google.com with ESMTPS id ut5sm21005269igc.13.2012.08.14.05.17.33 (version=SSLv3 cipher=OTHER); Tue, 14 Aug 2012 05:17:35 -0700 (PDT) Message-ID: <502A41DB.1020609@gmail.com> Date: Tue, 14 Aug 2012 19:17:31 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120721 Thunderbird/14.0 MIME-Version: 1.0 To: Glen Zorn References: <20120715054226.4612.98302.idtracker@ietfa.amsl.com> <500F08AF.4010102@cisco.com> <1343202545.7688.181.camel@gwz-laptop> In-Reply-To: <1343202545.7688.181.camel@gwz-laptop> Content-Type: multipart/alternative; boundary="------------050008010005020604050106" Cc: dime mailing list Subject: Re: [Dime] Fwd: New Version Notification - draft-ietf-dime-rfc4005bis-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 12:17:38 -0000 This is a multi-part message in MIME format. --------------050008010005020604050106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/25/2012 02:49 PM, Glen Zorn wrote: Hi. Has this gone to IETF LC already? I didn't see the announcement... > On Tue, 2012-07-24 at 13:42 -0700, Benoit Claise wrote: >> Hi Glen, >> >> Thanks for this new version. >> Two points that need to be addressed. >> >> >> 1. It seems that you have forgotten what we agreed upon on the >> mailing list. >> >> How about this? >> >> OLD: >> 3. Diameter NAS Application Messages >> >> This section defines the Diameter message Command-Code >> [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all >> Diameter implementations conforming to this specification. The >> Command Codes are as follows: >> >> +-----------------------------------+---------+------+--------------+ >> | Command Name | Abbrev. | Code | >> Reference | >> +-----------------------------------+---------+------+--------------+ >> | AA-Request | AAR | 265 | Section >> 3.1 | >> | AA-Answer | AAA | 265 | Section >> 3.2 | >> | Re-Auth-Request | RAR | 258 | Section >> 3.3 | >> | Re-Auth-Answer | RAA | 258 | Section >> 3.4 | >> | Session-Termination-Request | STR | 275 | Section >> 3.5 | >> | Session-Termination-Answer | STA | 275 | Section >> 3.6 | >> | Abort-Session-Request | ASR | 274 | Section >> 3.7 | >> | Abort-Session-Answer | ASA | 274 | Section >> 3.8 | >> | Accounting-Request | ACR | 271 | Section >> 3.9 | >> | Accounting-Answer | ACA | 271 | Section >> 3.10 | >> +-----------------------------------+---------+------+--------------+ >> >> NEW: >> 3. Diameter NAS Application Messages >> >> This section defines the Diameter message Command-Code >> [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all >> Diameter implementations conforming to this specification. The >> Command Codes are as follows: >> >> +-----------------------------------+---------+------+--------------+ >> | Command Name | Abbrev. | Code | >> Reference | >> +-----------------------------------+---------+------+--------------+ >> | AA-Request | AAR | 265 | Section >> 3.1 | >> | AA-Answer | AAA | 265 | Section >> 3.2 | >> | Re-Auth-Request | RAR | 258 | Section >> 3.3 | >> | Re-Auth-Answer | RAA | 258 | Section >> 3.4 | >> | Session-Termination-Request | STR | 275 | Section >> 3.5 | >> | Session-Termination-Answer | STA | 275 | Section >> 3.6 | >> | Abort-Session-Request | ASR | 274 | Section >> 3.7 | >> | Abort-Session-Answer | ASA | 274 | Section >> 3.8 | >> | Accounting-Request | ACR | 271 | Section >> 3.9 | >> | Accounting-Answer | ACA | 271 | Section >> 3.10 | >> +-----------------------------------+---------+------+--------------+ >> >> Note that the message formats in the following sub-sections use >> the standard Diameter Command Code Format >> ([I-D.ietf-dime-rfc3588bis], Section 3.2). >> >> >> >> 2. To be complete, and to let the DIME WG know, let me include what >> we have exchanged in a private email regarding the IANA pointer for >> the application id 1. >> >> You asked for a statement and some consistency from the IESG. >> - statement: The reference should be where the item in question is >> documented, not what registered it. >> - consistency: right, we need to make this clear and not change it. >> Michelle Coton and Barry Leiba are working on an update to BCP 26 >> that will, in part, do just that, and you are welcome to comment on >> it when it's posted (during or shortly after IETF 84). >> >> I propose that you add an "IANA note" in the IANA security section of >> draft-ietf-dime-rfc4005bis-09.txt expressing something such as: as >> discussed with the IESG, application id 1 should point to >> >> >> >> Please include those two points in the next revision of the draft, >> and I'll progress the draft to IETF LC. > > I'll submit it Monday evening. > > ... --------------050008010005020604050106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/25/2012 02:49 PM, Glen Zorn wrote:

Hi.  Has this gone to IETF LC already?  I didn't see the announcement...

On Tue, 2012-07-24 at 13:42 -0700, Benoit Claise wrote:
Hi Glen,

Thanks for this new version.
Two points that need to be addressed.


1. It seems that you have forgotten what we agreed upon on the mailing list.

How about this?

OLD:
3.  Diameter NAS Application Messages

   This section defines the Diameter message Command-Code
   [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all
   Diameter implementations conforming to this specification.  The
   Command Codes are as follows:

   +-----------------------------------+---------+------+--------------+
   | Command Name                      | Abbrev. | Code | Reference    |
   +-----------------------------------+---------+------+--------------+
   | AA-Request                        |   AAR   |  265 | Section 3.1  |
   | AA-Answer                         |   AAA   |  265 | Section 3.2  |
   | Re-Auth-Request                   |   RAR   |  258 | Section 3.3  |
   | Re-Auth-Answer                    |   RAA   |  258 | Section 3.4  |
   | Session-Termination-Request       |   STR   |  275 | Section 3.5  |
   | Session-Termination-Answer        |   STA   |  275 | Section 3.6  |
   | Abort-Session-Request             |   ASR   |  274 | Section 3.7  |
   | Abort-Session-Answer              |   ASA   |  274 | Section 3.8  |
   | Accounting-Request                |   ACR   |  271 | Section 3.9  |
   | Accounting-Answer                 |   ACA   |  271 | Section 3.10 |
   +-----------------------------------+---------+------+--------------+

NEW:
3.  Diameter NAS Application Messages

   This section defines the Diameter message Command-Code
   [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all
   Diameter implementations conforming to this specification.  The
   Command Codes are as follows:

   +-----------------------------------+---------+------+--------------+
   | Command Name                      | Abbrev. | Code | Reference    |
   +-----------------------------------+---------+------+--------------+
   | AA-Request                        |   AAR   |  265 | Section 3.1  |
   | AA-Answer                         |   AAA   |  265 | Section 3.2  |
   | Re-Auth-Request                   |   RAR   |  258 | Section 3.3  |
   | Re-Auth-Answer                    |   RAA   |  258 | Section 3.4  |
   | Session-Termination-Request       |   STR   |  275 | Section 3.5  |
   | Session-Termination-Answer        |   STA   |  275 | Section 3.6  |
   | Abort-Session-Request             |   ASR   |  274 | Section 3.7  |
   | Abort-Session-Answer              |   ASA   |  274 | Section 3.8  |
   | Accounting-Request                |   ACR   |  271 | Section 3.9  |
   | Accounting-Answer                 |   ACA   |  271 | Section 3.10 |
   +-----------------------------------+---------+------+--------------+

Note that the message formats in the following sub-sections use the standard Diameter Command Code Format ([I-D.ietf-dime-rfc3588bis], Section 3.2).


2. To be complete, and to let the DIME WG know, let me include what we have exchanged in a private email regarding the IANA pointer for the application id 1.

You asked for a statement and some consistency from the IESG.
- statement: The reference should be where the item in question is documented, not what registered it.
- consistency: right, we need to make this clear and not change it. Michelle Coton and Barry Leiba are working on an update to BCP 26 that will, in part, do just that, and you are welcome to comment on it when it's posted (during or shortly after IETF 84).

I propose that you add an "IANA note" in the IANA security section of draft-ietf-dime-rfc4005bis-09.txt expressing something such as: as discussed with the IESG, application id 1 should point to <RFC4005bis.>



Please include those two points in the next revision of the draft, and I'll progress the draft to IETF LC.

I'll submit it Monday evening.

...

--------------050008010005020604050106-- From jouni.nospam@gmail.com Tue Aug 14 05:56:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF23E21F853E for ; Tue, 14 Aug 2012 05:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 AWx0L9x36SBU for ; Tue, 14 Aug 2012 05:56:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7821F853D for ; Tue, 14 Aug 2012 05:56:39 -0700 (PDT) Received: by eaai11 with SMTP id i11so146044eaa.31 for ; Tue, 14 Aug 2012 05:56:38 -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:message-id :cc:to:mime-version:x-mailer; bh=4WVDc3Y2pNkFH34H9dJs3zdH5AMOrgEWldLdoT1kNQk=; b=rK20ojDp3pKgvng5JWpGFHCWi0tSdzoJIH+VRiMLAIk8pPNfQaLvHK54fnpkHTvzb2 Of/9+WtmVEhWG0AHwVhSB6ciCi9KnmIRfahJEon/+pVcP3l5bDM7U1F/B5sjgoqY3a1N BH49wIzcpSlHIJXvkrBPFBDm8ceK1QUSKlnu0Nu6a7K+zy36g8cvl0zBARtX2D820jdX hH2FTru5NeeyfA5nQlwZjGx4X68is+YIjglEXH+sNiBgNzDjz2QKXm/b7d+aZINndYAI b+7T7gPmLVGE8sqxpVLTWGL/Nizj89g/8TfgelAk8/DVBcrEHXEMlNqH4y7FN2hgdHhn rDsQ== Received: by 10.14.172.193 with SMTP id t41mr621643eel.25.1344948998457; Tue, 14 Aug 2012 05:56:38 -0700 (PDT) Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id u8sm6668261eel.11.2012.08.14.05.56.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 05:56:36 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Aug 2012 15:56:34 +0300 Message-Id: <16CA68BC-108C-4561-956D-FCB9463AD132@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC for draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 12:56:40 -0000 Folks, This email starts a two week WGLC for "Diameter Applications Design = Guidelines" I-D (draft-ietf-dime-app-design-guide-15). The WGLC ends 28-Aug-2012. = Send your comments to the mailer and please also use the Issue Tracker. - Jouni= From jouni.korhonen@iki.fi Tue Aug 14 12:47:55 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB34821E8086 for ; Tue, 14 Aug 2012 12:47:55 -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 jItSxLOirkml for ; Tue, 14 Aug 2012 12:47:54 -0700 (PDT) Received: from vs18.mail.saunalahti.fi (vs18.mail.saunalahti.fi [62.142.117.199]) by ietfa.amsl.com (Postfix) with ESMTP id 905DC21E8063 for ; Tue, 14 Aug 2012 12:47:54 -0700 (PDT) Received: from vams (localhost [127.0.0.1]) by vs18.mail.saunalahti.fi (Postfix) with SMTP id 57F9A180049; Tue, 14 Aug 2012 22:47:52 +0300 (EEST) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs18.mail.saunalahti.fi (Postfix) with ESMTP id 30905180049; Tue, 14 Aug 2012 22:47:52 +0300 (EEST) Received: from [188.117.15.109] (unknown [188.117.15.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 04DA5151873; Tue, 14 Aug 2012 22:47:46 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <196921E1-E38D-4342-AC06-57D0FB746394@nostrum.com> Date: Tue, 14 Aug 2012 22:47:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <78E86CCF-4D11-40BF-A02B-1F5364AECD65@iki.fi> References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> <196921E1-E38D-4342-AC06-57D0FB746394@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:47:55 -0000 Ben, On Aug 14, 2012, at 12:45 AM, Ben Campbell wrote: > Hi, Comments inline: >=20 > On Aug 11, 2012, at 5:42 AM, jouni korhonen = wrote: >=20 >> Folks, >>=20 >> Like discussed briefly during the Vancouver meeting there is a small >> charter & milestone update required for the overload work. The topic >> has already been brought up in IESG.. >>=20 >> Here is the proposed charter update text: >>=20 >> - Diameter overload control. The aim of this work is to identify the >> limitations of the Diameter protocol level overload control provided >> by the current Diameter Base protocol. A set of requirements will be >> provided to define a new Diameter level overload control mechanisms. >=20 > Is this language intended to cover work on the mechanism as well as = work on requirements? As written, it=20 Yes. Sloppy wording. Lets try tweaking the wording a bit: - Diameter overload control. The aim of this work is to identify the limitations of the current Diameter base protocol overload control mechanisms and based on the identified limitations define a set of requirements for an overall Diameter overload control solution. The solution would need to fulfill the requirements. > seems to cover identification of the limitations and the the set of = requirements for a mechanism, but not the mechanism itself. =46rom the = Vancouver meeting, I can see that being a possible approach, but you did = include milestones below that I assume to be for the mechanism. >=20 > That being said, I wonder why we need new charter text (as opposed to = milestones) for this? The current charter contains the following text: Just adding new milestones was the original intention. However, this got changed in "upper layers" and thus the charter text modification as = well. >> - Maintaining and/or progressing, along the standards track, the >> Diameter Base protocol and Diameter Applications. This includes >> extensions to Diameter Base protocol that can be considered as = enhanced >> features or bug fixes. >=20 >=20 > It seems to me that the proposed work falls squarely into the = "enhanced features or bug fixes" language. >=20 > Don't get me wrong; I don't object to adding more specific charter = language per se. My concern is that, if doing so delays having this work = show up as a milestone, that may encourage other SDOs (e.g 3GPP) to = pursue application-specific point solutions. Normally, I'm the first to = say that doing something correctly should take priority over meeting an = external deadline--but in this case I have trouble seeing why adding the = milestone under the existing charter text wouldn't be equally correct. >=20 >=20 >>=20 >> .. >>=20 >> Sep 2012 - Submit I-D ' Diameter Overload Control Requirements' as a >> working group document. To be Informational RFC. >>=20 >> Nov 2012 - Submit I-D ' Diameter Overload Control' as a working group = document. >> To be Standards Track RFC. >>=20 >> Dec 2012 - Submit I-D ' Diameter Overload Control Requirements' to = the IESG for >> consideration as a Informational RFC. >>=20 >> Mar 2013 - Submit I-D ' Diameter Overload Control' to the IESG for = consideration >> as a Proposed Standard RFC. >=20 > I think the milestones look good in general, but I really hope it = doesn't take us until November to be able to progress the requirements = document. I guess that depends on whether we get any significant = controversy on it as more people read it. There is no reason to wait till the milestone timeline is met if a = document is ready. That said, the document can be advanced as soon as it is ready = for it. - Jouni >=20 >=20 > Thanks! >=20 > Ben. From sm@elandsys.com Thu Aug 16 09:16:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9437021F85CD; Thu, 16 Aug 2012 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR2y9EKINjE2; Thu, 16 Aug 2012 09:16:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7CE21F85B8; Thu, 16 Aug 2012 09:16:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.144]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7GGGFPd016947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 09:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345133788; bh=1CVDZs2mT3J+cQNFNCagB9II2o1mqQ80GmxQKDB+ugk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LA2QkarofnMq37poogMYUeDjmQOvfuW4ePHC/3HPn+a+2NGbV4YANtZoFv4CfWRey mIuLtsLoNkFkmxCikvFLn2QR2JkfusXi4fBsxUXuNvCtVdNPFktaHptMCFneFO9ToV UidZIT/moHRiu2V0G4YHc4ZAx7083lTc8/2Nyz+E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1345133788; i=@elandsys.com; bh=1CVDZs2mT3J+cQNFNCagB9II2o1mqQ80GmxQKDB+ugk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XAbNq6FofGm1OVenuh6djhaEJLKQmA7oIv8VCM9Q3iRfDbTaHw7GI12PoMKfmOvmH cI6Lv6mANR7JFOpsKsjhpOd0i8dqd+9NGsorB2jOUQAy5UulIgoJt0Kb9ymmCIZiDS uRlYJRG3JMbO6hBuD5v/3vJ7diVOhICJhMYMmBfg= Message-Id: <6.2.5.6.2.20120816075352.0a770008@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Aug 2012 09:09:36 -0700 To: dime@ietf.org From: S Moonesamy In-Reply-To: <50161436.8080900@bbiw.net> References: <50161436.8080900@bbiw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 16 Aug 2012 11:16:52 -0700 Cc: apps-discuss@ietf.org Subject: Re: [Dime] [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:16:31 -0000 Hello, I received a comment about the Applications Area Directorate (APPSDIR) review of draft-ietf-dime-rfc4005bis-09 ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06768.html ). There is some background information about the Applications Directorate at http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate Some information for document authors is available at http://trac.tools.ietf.org/area/app/trac/wiki/template I'll highlight the following: "In plain English, this means that the comments in the Applications Area Directorate review does not bear more weight than a comment submitted by an individual during a Last Call." There was a Publication Request on May 23 for draft-ietf-dime-rfc4005bis. I assume that the draft is ready for review. APPSDIR tries to perform early reviews, i.e., catch issues early so the document authors have more time to address the issues. It is up to the authors, or working group, to decide about whether the issues should be resolved and how to do so. If you have any questions about APPSDIR you can contact the undersigned or post a message to the apps-discuss@ietf.org mailing list. Regards, S. Moonesamy From glenzorn@gmail.com Thu Aug 16 18:23:42 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E066811E8098 for ; Thu, 16 Aug 2012 18:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wJWYUz++o4T for ; Thu, 16 Aug 2012 18:23:40 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5AD11E8091 for ; Thu, 16 Aug 2012 18:23:40 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3917400ghb.31 for ; Thu, 16 Aug 2012 18:23:39 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=WREStcdjV8hXZma20nn+7s49oTkNjcSZ5KagRpSdRbE=; b=ZEngkBY5PJwHPdM7xDDv2l1unIYO0P4Ybl4cr38TsytL+qISAuppRLuNFfjuWncSoT UUbRKPam34SrIiNMWr6UxhyXpxi9cg1DV+51bbjVQ3ZSFEPdxM0RKYePElVJIO66Uad+ jXh82OZxpGQylyAg2yvxwnS3bfVGRuZwDdinoVBxFnSNKJ+YOlFMjRNh8ABcupJpgy5n Ag3u+W7JVOXAsda9pCifu6axu9RpGCTOg9ffGOcGx1+ZtWm32IWniz8H8jPCnYCELdEE CNT089L/iC+CfHEMuzuhuGhopi+c8SGCOPSg2csXkdIxpxK2wnMJqqVnBiVvfmloWJR/ zdzw== Received: by 10.50.179.99 with SMTP id df3mr95645igc.73.1345166619335; Thu, 16 Aug 2012 18:23:39 -0700 (PDT) Received: from [192.168.0.102] (ppp-124-121-209-4.revip2.asianet.co.th. [124.121.209.4]) by mx.google.com with ESMTPS id i17sm3345421igd.5.2012.08.16.18.23.36 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 18:23:38 -0700 (PDT) Message-ID: <502D9D16.4040107@gmail.com> Date: Fri, 17 Aug 2012 08:23:34 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120721 Thunderbird/14.0 MIME-Version: 1.0 To: jouni korhonen References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> In-Reply-To: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 01:23:43 -0000 On 08/11/2012 05:42 PM, jouni korhonen wrote: Since we're at this & given the fairly immanent publication of RFC 4005bis, how about we add http://datatracker.ietf.org/doc/draft-zorn-dime-radia-gate/ to the charter? > Folks, > > Like discussed briefly during the Vancouver meeting there is a small > charter & milestone update required for the overload work. The topic > has already been brought up in IESG.. > > Here is the proposed charter update text: > > - Diameter overload control. The aim of this work is to identify the > limitations of the Diameter protocol level overload control provided > by the current Diameter Base protocol. A set of requirements will be > provided to define a new Diameter level overload control mechanisms. > > .. > > Sep 2012 - Submit I-D ' Diameter Overload Control Requirements' as a > working group document. To be Informational RFC. > > Nov 2012 - Submit I-D ' Diameter Overload Control' as a working group document. > To be Standards Track RFC. > > Dec 2012 - Submit I-D ' Diameter Overload Control Requirements' to the IESG for > consideration as a Informational RFC. > > Mar 2013 - Submit I-D ' Diameter Overload Control' to the IESG for consideration > as a Proposed Standard RFC. > > > > - Jouni & Lionel > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Thu Aug 16 21:56:02 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B5E21F8522 for ; Thu, 16 Aug 2012 21:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqaplTNhKl5M for ; Thu, 16 Aug 2012 21:56:01 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1D21F8467 for ; Thu, 16 Aug 2012 21:56:01 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7H4txCO020782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Aug 2012 23:55:59 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <78E86CCF-4D11-40BF-A02B-1F5364AECD65@iki.fi> Date: Thu, 16 Aug 2012 23:56:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <651528FD-F859-44B4-8978-460039563FC6@nostrum.com> References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> <196921E1-E38D-4342-AC06-57D0FB746394@nostrum.com> <78E86CCF-4D11-40BF-A02B-1F5364AECD65@iki.fi> To: jouni korhonen X-Mailer: Apple Mail (2.1485) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 04:56:02 -0000 On Aug 14, 2012, at 2:47 PM, jouni korhonen = wrote: >> Is this language intended to cover work on the mechanism as well as = work on requirements? As written, it=20 >=20 > Yes. Sloppy wording. Lets try tweaking the wording a bit: >=20 > - Diameter overload control. The aim of this work is to identify the > limitations of the current Diameter base protocol overload control > mechanisms and based on the identified limitations define a set of > requirements for an overall Diameter overload control solution. The > solution would need to fulfill the requirements. I may be being overly pedantic, but I still don't see that language as = saying to actually define the solution. Here's a suggested further = tweak: "- Diameter overload control. The aim of this work is to identify the limitations of the current Diameter base protocol for overload control = purposes. Based on the identified limitations=20 the working group will specify a set of requirements for an overall = Diameter overload control solution and define=20 a solution that meets those requirements." Thanks! Ben.= From bill.wu@huawei.com Thu Aug 16 23:02:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE44621F8464 for ; Thu, 16 Aug 2012 23:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.334 X-Spam-Level: X-Spam-Status: No, score=-4.334 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqwGn7aHC8Cg for ; Thu, 16 Aug 2012 23:02:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F065821F8462 for ; Thu, 16 Aug 2012 23:02:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM20089; Thu, 16 Aug 2012 22:02:14 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 22:58:52 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 22:58:58 -0700 Received: from w53375 (10.138.41.149) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 17 Aug 2012 13:58:52 +0800 Message-ID: From: Qin Wu To: Glen Zorn , jouni korhonen References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> <502D9D16.4040107@gmail.com> Date: Fri, 17 Aug 2012 13:58:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 06:02:15 -0000 U3VwcG9ydC4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiR2xlbiBab3JuIiA8Z2xlbnpvcm5AZ21haWwuY29tPg0KVG86ICJqb3VuaSBrb3Jo b25lbiIgPGpvdW5pLmtvcmhvbmVuQGlraS5maT4NCkNjOiA8ZGltZUBpZXRmLm9yZz47IDxkaW1l LWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgQXVndXN0IDE3LCAyMDEyIDk6 MjMgQU0NClN1YmplY3Q6IFJlOiBbRGltZV0gQ2hhcnRlciB1cGRhdGUNCg0KDQo+IE9uIDA4LzEx LzIwMTIgMDU6NDIgUE0sIGpvdW5pIGtvcmhvbmVuIHdyb3RlOg0KPiANCj4gU2luY2Ugd2UncmUg YXQgdGhpcyAmIGdpdmVuIHRoZSBmYWlybHkgaW1tYW5lbnQgcHVibGljYXRpb24gb2YgUkZDIA0K PiA0MDA1YmlzLCBob3cgYWJvdXQgd2UgYWRkIA0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXpvcm4tZGltZS1yYWRpYS1nYXRlLyB0byB0aGUgY2hhcnRlcj8NCj4gDQo+ PiBGb2xrcywNCj4+DQo+PiBMaWtlIGRpc2N1c3NlZCBicmllZmx5IGR1cmluZyB0aGUgVmFuY291 dmVyIG1lZXRpbmcgdGhlcmUgaXMgYSBzbWFsbA0KPj4gY2hhcnRlciAmIG1pbGVzdG9uZSB1cGRh dGUgcmVxdWlyZWQgZm9yIHRoZSBvdmVybG9hZCB3b3JrLiBUaGUgdG9waWMNCj4+IGhhcyBhbHJl YWR5IGJlZW4gYnJvdWdodCB1cCBpbiBJRVNHLi4NCj4+DQo+PiBIZXJlIGlzIHRoZSBwcm9wb3Nl ZCBjaGFydGVyIHVwZGF0ZSB0ZXh0Og0KPj4NCj4+IC0gRGlhbWV0ZXIgb3ZlcmxvYWQgY29udHJv bC4gVGhlIGFpbSBvZiB0aGlzIHdvcmsgaXMgdG8gaWRlbnRpZnkgdGhlDQo+PiAgICBsaW1pdGF0 aW9ucyBvZiB0aGUgRGlhbWV0ZXIgcHJvdG9jb2wgbGV2ZWwgb3ZlcmxvYWQgY29udHJvbCBwcm92 aWRlZA0KPj4gICAgYnkgdGhlIGN1cnJlbnQgRGlhbWV0ZXIgQmFzZSBwcm90b2NvbC4gQSBzZXQg b2YgcmVxdWlyZW1lbnRzIHdpbGwgYmUNCj4+ICAgIHByb3ZpZGVkIHRvIGRlZmluZSBhIG5ldyBE aWFtZXRlciBsZXZlbCBvdmVybG9hZCBjb250cm9sIG1lY2hhbmlzbXMuDQo+Pg0KPj4gLi4NCj4+ DQo+PiBTZXAgMjAxMiAtIFN1Ym1pdCBJLUQgJyBEaWFtZXRlciBPdmVybG9hZCBDb250cm9sIFJl cXVpcmVtZW50cycgYXMgYQ0KPj4gICAgICAgICAgICAgd29ya2luZyBncm91cCBkb2N1bWVudC4g VG8gYmUgSW5mb3JtYXRpb25hbCBSRkMuDQo+Pg0KPj4gTm92IDIwMTIgLSBTdWJtaXQgSS1EICcg RGlhbWV0ZXIgT3ZlcmxvYWQgQ29udHJvbCcgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K Pj4gICAgICAgICAgICAgVG8gYmUgU3RhbmRhcmRzIFRyYWNrIFJGQy4NCj4+DQo+PiBEZWMgMjAx MiAtIFN1Ym1pdCBJLUQgJyBEaWFtZXRlciBPdmVybG9hZCBDb250cm9sIFJlcXVpcmVtZW50cycg dG8gdGhlIElFU0cgZm9yDQo+PiAgICAgICAgICAgICBjb25zaWRlcmF0aW9uIGFzIGEgSW5mb3Jt YXRpb25hbCBSRkMuDQo+Pg0KPj4gTWFyIDIwMTMgLSBTdWJtaXQgSS1EICcgRGlhbWV0ZXIgT3Zl cmxvYWQgQ29udHJvbCcgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24NCj4+ICAgICAgICAg ICAgIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDLg0KPj4NCj4+DQo+Pg0KPj4gLSBKb3VuaSAm IExpb25lbA0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBEaU1FIG1haWxpbmcgbGlzdA0KPj4gRGlNRUBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0K PiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZQ== From jouni.korhonen@iki.fi Thu Aug 16 23:39:48 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0E21F8577 for ; Thu, 16 Aug 2012 23:39:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN-2vdqzVHKR for ; Thu, 16 Aug 2012 23:39:47 -0700 (PDT) Received: from vs15.mail.saunalahti.fi (vs15.mail.saunalahti.fi [62.142.117.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25A21F8570 for ; Thu, 16 Aug 2012 23:39:46 -0700 (PDT) Received: from vams (localhost [127.0.0.1]) by vs15.mail.saunalahti.fi (Postfix) with SMTP id 00C1940080; Fri, 17 Aug 2012 09:39:38 +0300 (EEST) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs15.mail.saunalahti.fi (Postfix) with ESMTP id DD63C40080; Fri, 17 Aug 2012 09:39:37 +0300 (EEST) Received: from [10.255.128.118] (unknown [194.251.119.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 29741151650; Fri, 17 Aug 2012 09:39:33 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <651528FD-F859-44B4-8978-460039563FC6@nostrum.com> Date: Fri, 17 Aug 2012 09:39:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> <196921E1-E38D-4342-AC06-57D0FB746394@nostrum.com> <78E86CCF-4D11-40BF-A02B-1F5364AECD65@iki.fi> <651528FD-F859-44B4-8978-460039563FC6@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 06:39:48 -0000 Hi, On Aug 17, 2012, at 7:56 AM, Ben Campbell wrote: >=20 > On Aug 14, 2012, at 2:47 PM, jouni korhonen = wrote: >=20 >>> Is this language intended to cover work on the mechanism as well as = work on requirements? As written, it=20 >>=20 >> Yes. Sloppy wording. Lets try tweaking the wording a bit: >>=20 >> - Diameter overload control. The aim of this work is to identify the >> limitations of the current Diameter base protocol overload control >> mechanisms and based on the identified limitations define a set of >> requirements for an overall Diameter overload control solution. The >> solution would need to fulfill the requirements. >=20 > I may be being overly pedantic, but I still don't see that language as = saying to actually define the solution. Here's a suggested further = tweak: I would day you are overly pedantic ;) However, the text you propose is definitely better than mine! > "- Diameter overload control. The aim of this work is to identify the > limitations of the current Diameter base protocol for overload control = purposes. Based on the identified limitations=20 > the working group will specify a set of requirements for an overall = Diameter overload control solution and define=20 > a solution that meets those requirements." >=20 > Thanks! - Jouni >=20 > Ben. From md3135@att.com Fri Aug 17 03:59:23 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC821F852D for ; Fri, 17 Aug 2012 03:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIgSNeEWvt3U for ; Fri, 17 Aug 2012 03:59:23 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 746CD21F850D for ; Fri, 17 Aug 2012 03:59:22 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 9042e205.0.1045903.00-451.2849922.nbfkord-smmo08.seg.att.com (envelope-from ); Fri, 17 Aug 2012 10:59:22 +0000 (UTC) X-MXL-Hash: 502e240a3f9fa861-15469e49045a24971c3541c221a50378b7447677 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7HAxLAe022390; Fri, 17 Aug 2012 03:59:21 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7HAx86J022249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 03:59:09 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Fri, 17 Aug 2012 03:58:51 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0318.001; Fri, 17 Aug 2012 06:58:50 -0400 From: "DOLLY, MARTIN C" To: Ben Campbell , jouni korhonen Thread-Topic: [Dime] Charter update Thread-Index: AQHNfDSYPFZVqhpBF0ejNlJlpJeHd5dd1gyA Date: Fri, 17 Aug 2012 10:58:50 +0000 Message-ID: References: <2D1E666F-1BA7-4FCA-800B-D01E5E5756D1@iki.fi> <196921E1-E38D-4342-AC06-57D0FB746394@nostrum.com> <78E86CCF-4D11-40BF-A02B-1F5364AECD65@iki.fi> <651528FD-F859-44B4-8978-460039563FC6@nostrum.com> In-Reply-To: <651528FD-F859-44B4-8978-460039563FC6@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.86.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=ShlNgWpomOMA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=6VgASLwbLIkA:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=-tnswElqFK5BoL_NScoA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Charter update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 10:59:23 -0000 Support Ben's wording change. -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ben= Campbell Sent: Friday, August 17, 2012 12:56 AM To: jouni korhonen Cc: dime@ietf.org; dime-chairs@tools.ietf.org Subject: Re: [Dime] Charter update On Aug 14, 2012, at 2:47 PM, jouni korhonen wrote: >> Is this language intended to cover work on the mechanism as well as work= on requirements? As written, it=20 >=20 > Yes. Sloppy wording. Lets try tweaking the wording a bit: >=20 > - Diameter overload control. The aim of this work is to identify the > limitations of the current Diameter base protocol overload control > mechanisms and based on the identified limitations define a set of > requirements for an overall Diameter overload control solution. The > solution would need to fulfill the requirements. I may be being overly pedantic, but I still don't see that language as sayi= ng to actually define the solution. Here's a suggested further tweak: "- Diameter overload control. The aim of this work is to identify the limitations of the current Diameter base protocol for overload control purp= oses. Based on the identified limitations=20 the working group will specify a set of requirements for an overall Diamete= r overload control solution and define=20 a solution that meets those requirements." Thanks! Ben. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From iesg-secretary@ietf.org Tue Aug 21 08:42:22 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4487821F87A4; Tue, 21 Aug 2012 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtmUb9vPtsdz; Tue, 21 Aug 2012 08:42:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E8821F879C; Tue, 21 Aug 2012 08:42:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120821154217.2608.45662.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 08:42:17 -0700 Cc: dime WG Subject: [Dime] WG Action: Rechartered Diameter Maintenance and Extensions (dime) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:42:22 -0000 The Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Diameter Maintenance and Extensions (dime) ------------------------------------------------ Current Status: Active Working Group Chairs: Jouni Korhonen Lionel Morand Assigned Area Director: Benoit Claise Mailing list Address: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/ Charter of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. - Diameter overload control. The aim of this work is to identify the limitations of the Diameter protocol level overload control provided by the current Diameter Base protocol. A set of requirements will be provided to define a new Diameter level overload control mechanism. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Sep 2012 - Submit I-D 'Diameter Overload Control Requirements' as a working group document. To be Standards Track RFC. Nov 2012 - Submit I-D 'Diameter Overload Control' as a working group document. To be Standards Track RFC. Dec 2012 - Submit I-D 'Diameter Overload Control Requirements' to the IESG for consideration as a Proposed Standard Dec 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Mar 2013 - Submit I-D 'Diameter Overload Control' to the IESG for consideration as a Proposed Standard Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard From internet-drafts@ietf.org Thu Aug 23 16:24:57 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1224E21F848F; Thu, 23 Aug 2012 16:24:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUSsDU3hkHKF; Thu, 23 Aug 2012 16:24:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CA121F8491; Thu, 23 Aug 2012 16:24:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120823232456.1616.77752.idtracker@ietfa.amsl.com> Date: Thu, 23 Aug 2012 16:24:56 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:24:57 -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-06.txt Pages : 8 Date : 2012-08-23 Abstract: The Diameter protocol allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. 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 RFC3588bis 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Thu Aug 23 17:09:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167FB21F8540 for ; Thu, 23 Aug 2012 17:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBVISwXNg137 for ; Thu, 23 Aug 2012 17:09:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C57021F854D for ; Thu, 23 Aug 2012 17:09:05 -0700 (PDT) Received: by iabz21 with SMTP id z21so2468767iab.31 for ; Thu, 23 Aug 2012 17:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=1lAW0+zGuRDZogkqvoqKuDkLo/ZNB8NFMwC3YALrv90=; b=O24mceeusvA+svf29dSD9+roHVcZ/4dS4alSco0ao9gHabhN5/NOEyB7SIz8x02YBO ik44DTVt2WyiOlzW4b4lN26KqJeXfUyY5JzfGbEr+4qB8LBWPg3bhpP5i73n1/43yaPB j74ScSYpN0DWc/ihA3j9Y0VgTc91Y7Whs4jhQvXyLVPhVJP979VgSY31AIax56tdfZyH XqNTS13RYv4GBR4ZTA0Xo3mvtUnPnuq5oNr3YKX1B1pFGq6hdaI53Q9dIje8Qc/4aJ1o c++mKakVbsQRv/iLlMZ++XikHSnJM8LkzRyoc2228uGGhzp9ukue7/JWLgBmTZBr1swV TMTA== Received: by 10.50.85.129 with SMTP id h1mr242293igz.25.1345766943409; Thu, 23 Aug 2012 17:09:03 -0700 (PDT) Received: from [127.0.0.1] ([199.246.39.165]) by mx.google.com with ESMTPS id qp6sm2004857igc.0.2012.08.23.17.09.01 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 17:09:02 -0700 (PDT) Message-ID: <5036C61C.8080900@gmail.com> Date: Thu, 23 Aug 2012 20:09:00 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dime@ietf.org References: <20120823232456.1616.77752.idtracker@ietfa.amsl.com> In-Reply-To: <20120823232456.1616.77752.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120823-0, 23/08/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:09:06 -0000 The draft has been updated primarily based on comments from Jouni and Lionel. Changes: - Updates RFC3588bis - Paragraph adding to the Abstract saying the same thing, and giving more details. - Placed the statement that application designers could decide whether realm-based redirection applies to the first or to all requests of a session into Section 2, "Support of Realm-Based Redirection Within Applications". - In the introductory part of Section 3, noted the extension of behaviour with respect to the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. - Also in the introductory part, noted that the caching of new routes at a proxy or client means that the alternative routing persists for subsequent requests until the cache entry times out, with implications for use of realm-based routing on a temporary basis. - In Section 3.2.1, "Behaviour at the Redirecting Server", deleted the bullet saying that a request with a Destination-Host AVP should be rejected with UNABLE_TO_DELIVER. Added an informational note that the Destination-Host AVP would be ignored. My reasoning was that if the application specifies that realm-based redirection applies to all requests and not just the first request of a session, then that is what should happen. - In Section 3.2.2, "Proxy Behaviour", added a note that instead of attempting to reroute the request, the proxy could just forward the answer to the upstream peer. - In the same section, got rid of the bullet calling for verification of the alternate realm, given that this happens implicitly when the proxy connects with a peer in that realm. - In Section 3.2.3, "Client Behaviour", got rid of similar text about verifying the alternative realm. - Added a section specifying the new error code DIAMETER_REALM_REDIRECT_INDICATION. - Modified the wording of the Security Considerations section to just refer to Section 2.9 (corrected) of 3588bis. Tom Taylor From mahoney@nostrum.com Tue Aug 28 07:00:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E3921F8466 for ; Tue, 28 Aug 2012 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvG7w+gWKrdW for ; Tue, 28 Aug 2012 07:00:42 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B9EF621F8514 for ; Tue, 28 Aug 2012 07:00:41 -0700 (PDT) Received: from A-Jean-Mahoneys-MacBook-Pro.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7SE0eqZ098686 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 09:00:40 -0500 (CDT) (envelope-from mahoney@nostrum.com) Message-ID: <503CCF08.5070008@nostrum.com> Date: Tue, 28 Aug 2012 09:00:40 -0500 From: "A. Jean Mahoney" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dime@ietf.org, draft-ietf-dime-app-design-guide@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Subject: [Dime] WGLC review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:00:43 -0000 Hi all, I didn't find any major issues while reviewing the document. However, I did come up with a long list of nits. The first part of the review offers suggested wording changes to sentences and paragraphs. The second section covers typographical and punctuation errors. Jean 4. p1 s1 (Section 4, paragraph 1, sentence 1): Current: protocol designers are advised to try to re-use as much as possible existing Diameter applications to simplify standardization, implementation and avoid potential interoperability issues. Suggested: protocol designers are advised to reuse as much as possible existing Diameter applications in order to simplify standardization and implementation, and to avoid potential interoperability issues. 4.3 p2 s3: Current: Therefore, if it is still recommended to re-use as much as possible existing commands, protocol designers can consider more easily the definition of a new command when it is a solution more suitable than twisting existing command use and applications. Suggested: Although reuse of existing commands is still recommended, protocol designers can consider defining a new command when it provides a solution more suitable than the twisting of an existing command's use and applications. 4.3.1 p2 s5: Current: Here is a list of few common questions that application designers should wonder when trying to decide: Suggested: Application designers should consider the following questions when deciding to set the M-bit for a new AVP: 4.3.2 p1 s1: Current: When deleting an AVP from a command, the following cases need to be differentiated: Suggested: The impacts of deleting an AVP from a command depend on its command code format specification and M-bit setting: 5.4 p1 s2: Current: When a new application is being defined that cannot clearly be categorized into any of these services it is recommended that the application itself define its own session state machine. The existing session state machines defined by [I-D.ietf-dime-rfc3588bis] is not intended for general use beyond AAA services, therefore any behavior not covered by that category would not fit well. Suggested: If a new application cannot clearly be categorized into any of these services, it is recommended that the application define its own session state machine. The session state machines defined by [I-D.ietf-dime-rfc3588bis] are not intended to cover behavior outside of AAA. 5.6 p2 s2: Current: This has to be considered as a sub-optimal design as this limits the extensibility of the application: any new capability/permission would have to be supported by a new AVP or new Enumerated value of the already defined AVP that would cause in consequence backwards compatibility issues with existing implementations. Suggested: This is a sub-optimal design since it limits the extensibility of the application: any new capability/permission would have to be supported by a new AVP or new Enumerated value of the already defined AVP, causing backwards compatibility issues with existing implementations. 5.6 p3: Current: Instead of defining Enumerated AVP when the AVP simply used as a Boolean flag, protocol designers are encouraged to rely on AVP defined in the form of a bit mask with the interpretation of the setting of each bit described in the relevant Diameter application specification. Such AVPs can be reused and extended to multiplex several indications without major impact on the Diameter application. The bit-mask should be therefore long enough to leave room for future additions. Examples of AVP defined as bit mask are the Session- Binding AVP defined in [I-D.ietf-dime-rfc3588bis] and the MIP6- Feature-Vector AVP defined in [RFC5447] Suggested: Instead of using an Enumerated AVP for a Boolean flag, protocol designers are encouraged to use a bit mask AVP whose bit settings are described in the relevant Diameter application specification. Such AVPs can be reused and extended without major impact on the Diameter application. The bit mask AVP should leave room for future additions. Examples of bit mask AVPs are the Session-Binding AVP [I-D.ietf-dime-rfc3588bis] and the MIP6-Feature-Vector AVP [RFC5447]. 5.7 p3: Current: Example of such specific routing function can be found the applications defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx applications ([TS29.228] and [TS29.229]) in which the Subscriber Location Function (SLF) is defined a proxy agent (or enhanced Redirect agent) using specific application-level identities found in the request to determine the final destination of the message. Suggested: Examples of such application-specific routing functions can be found in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP Multimedia Subsystem, in which the proxy agent (Subscriber Location Function) uses application-level identities found in the request to determine the final destination of the message. 5.7 p4 s2: Current: In particular, this ensures that Diameter agents in the request routing path (Relay or Proxy agents) will be able to correctly release the transaction state associated to the request upon receipt of the answer, avoiding thus unnecessary failover triggering due to non reception of the answer corresponding to the request. Application designers are strongly recommended to not attempt to modify the answer routing principles described in [I-D.ietf-dime-rfc3588bis] when defining a new application. Suggested: In particular, this ensures that the Diameter Relay or Proxy agents in the request routing path will be able to release the transaction state upon receipt of the corresponding answer, avoiding unnecessary failovers. Application designers are strongly dissuaded from modifying the answer-routing principles described in [I-D.ietf-dime-rfc3588bis] when defining a new application. 5.8 p2: Current: In the specific case of RADIUS, it was initially foreseen that the translation function would have been straightforward to define and deploy by adopting few basic principles e.g. use of a shared range of code values for RADIUS attributes and Diameter AVPs, some guidelines on translation and management of key information (such as authentication parameter, routing/accounting or states), etc. And all this material was put in the RFC 4005 ([RFC4005]) to be used as generic guideline for implementation of RADIUS-Diameter translation agent. Suggested: In the case of RADIUS, it was initially thought that defining the translation function would be straightforward. Guidelines for implementing a RADIUS-Diameter translation agent were put into RFC 4005 ([RFC4005]). 5.8 p4 s1: Current: Therefore, when interoperability with RADIUS infrastructure is foreseen, protocol designers are advised that they cannot assume the availability of "standard" Diameter-to-RADIUS gateways agent and the required translation mechanism should be then specified along with the Diameter application. And the recommendation in the case of RADIUS-Diameter interworking applies of course for any other kind of translation (e.g. Diameter/MAP). Suggested: Therefore, protocol designers cannot assume the availability of a "standard" Diameter-to-RADIUS gateways agent when planning to interoperate with the RADIUS infrastructure. They should specify the required translation mechanism along with the Diameter application. This recommendation applies for any kind of translation (e.g. Diameter/MAP). 5.9 p2 and bullets: Current: The end-to-end capabilities AVPs can aid in the following cases: o Formalizing the way new functionality is added to existing applications by announcing support for it. o Applications that do not understand these AVP can discard it upon receipt. In such case, senders of the AVP can also safely assume the receiving end-point does not support any functionality carried by the AVP if it is not present in subsequent responses. o Useful in cases where deployment choices are offered and the generic design can be made available for a number of applications. Suggested: The end-to-end capabilities AVPs formalize the addition of new functionality to existing applications by announcing support for it. Applications that do not understand these AVPs can discard them upon receipt. Senders of the AVP can safely assume the receiving end-point does not support any functionality carried by the AVP if it is not present in subsequent responses. This is useful in cases where deployment choices are offered, and the generic design can be made available for a number of applications. 6. p2 b3 s3: Current: However, the drawback is that the timing of sending extension data will be tied to when the application would be sending a message. This has consequences if the application and the extensions have different timing requirements. Suggested: However, this ties the sending of extension data to the application's transmission of a message. This has consequences if the application and the extensions have different timing requirements. 6. p3 s1: Current: In practice, it is often the case that the generic extensions use optional AVPs because it's simple and not intrusive to the application that would carry it. Suggested: In practice, generic extensions often use optional AVPs because they are simple and nonintrusive to the application that would carry them. Nits: 3. p2 s2: "completly" -> "completely" 4.1 p1 s3: "create an new" -> "create a new" 4.1 p3 s1: "case by case" -> "case-by-base" 4.1 p3 b3 s1: "importing existing" -> "importing an existing" 4.1 p3 b3 s2: "applications" -> "application" remove the stray period at the end. 4.2 p1 s1: "to an application" -> "from an application" 4.2 p1 s2: "this" -> "This" 4.2 p2 s3: "which" -> "that" 4.3.1 heading: "ommand" -> "Command" 4.3.1 p1 b1 s2: "node receiving are" -> "node receiving them is" 4.3.1 p1 b2 s1: "receiving these AVP" -> "receiving these AVPs" 4.3.1 p2 b4 s1: "application related" -> "application-related" 4.3.1 p4 s1: "contemplating on the" -> "contemplating the" 4.3.1 p4 b2: "applications data" -> "application data" 4.3.1 p4 b3: "a mandatory AVPs" -> "a mandatory AVP" 4.4.1 p2 s1: add period after "unchanged" 5.1 p3 s1: add comma after "extensibility" 5.2 p1 s1: "Reusing" -> "reusing" 5.2 p1 s3: "pratices" -> "practices" 5.3 p1 s1 and s2: "session level" -> "session-level" 5.4 p1 s4: "server initiated" -> "server-initiated" 5.5 p3 s1: delete "really" 5.5 p3 s3: "by the application the" -> "by the application, the" 5.6 p1 s1: "provide list" -> "provide a list" 5.6 p1 s2: "perform on" -> "perform upon" 5.6 p2 s1: "as simple" -> "as a simple" 5.7 p2 s1: add comma after "suitable" 5.7 p4 s1: ", the answer" -> ", with the answer" "Hop-by-hop" -> "hop-by-hop" 5.8 p3 s2: remove "will likely" add comma after "specification" 5.10 p1 s1: "which" -> "that" 5.10 p2 s4: delete "generally" 5.10 p3 s2: delete "somehow" 5.10 p3 s3: "to be have" -> "to have" delete "uniquely" 5.10 p3 s4: add comma after "existing AVPs" "records" -> "record" 5.11 p1 s2: "However, IPsec Additional" -> "However, additional" 5.11 p2 s3: add comma after "pre-shared key" 5.11 p3 s1: "as security mechanisms" -> "as the security mechanism" 6 p2 b3 s2: "applications; However" -> "applications. However" 6 p2 b3 s5: add comma after "issue" 6 p3 s4: add comma after "set of applications" 8 p1 s1: delete "does" 8 p1 s2: "security related" -> "security-related" Throughout the document: "Diameter Base protocol" -> "Diameter base protocol" "application specific" -> application-specific" "tradeoff" -> "trade-off" From emcmurry@estacado.net Tue Aug 28 14:48:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174BF21F859F for ; Tue, 28 Aug 2012 14:48:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEQsYXRy7pzD for ; Tue, 28 Aug 2012 14:48:31 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7749D21F8598 for ; Tue, 28 Aug 2012 14:48:31 -0700 (PDT) Received: from ericlaptop.casamcmurry.com (cpe-76-184-161-215.tx.res.rr.com [76.184.161.215]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q7SLmQmT085017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Aug 2012 16:48:30 -0500 (CDT) (envelope-from emcmurry@estacado.net) From: Eric McMurry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <678A10E2-BA0E-4A6C-8303-36C67A94CD43@estacado.net> Date: Tue, 28 Aug 2012 16:48:21 -0500 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Subject: [Dime] Diameter Overload Control Requirements update 02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:48:32 -0000 An update has been submitted for the draft intended to address = requirements for overload control in Diameter: URL: = http://www.ietf.org/id/draft-mcmurry-dime-overload-reqs-02.txt Status: = http://datatracker.ietf.org/doc/draft-mcmurry-dime-overload-reqs Htmlized: = http://tools.ietf.org/html/draft-mcmurry-dime-overload-reqs-02 Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-mcmurry-dime-overload-reqs-02 This update adds front matter and a requirement to cover the scenario = with interconnect networks between diameter elements. From ben@nostrum.com Tue Aug 28 14:54:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9A21F8535 for ; Tue, 28 Aug 2012 14:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Sgq065dxUv0 for ; Tue, 28 Aug 2012 14:54:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9832321F8532 for ; Tue, 28 Aug 2012 14:54:58 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7SLstMB043115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Aug 2012 16:54:57 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 28 Aug 2012 16:54:53 -0500 To: "dime@ietf.org" , draft-ietf-dime-app-design-guide@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:54:59 -0000 Hi, The draft gives good guidance overall. I do have a few comments, though: Substantive Comments: -- section 4: The section seems to talk mainly about syntax, rather than semantics. Is = there any guidance to give about things (applications, commands, avps) = that might be syntactically similar but mean very different things? -- 4.3.2, last paragraph: Does it become an error if a peer uses the = "no-longer-used-but-not-deleted" avp? -- 5.9 Does the advice in this section open up an unmanaged extension vector? = In the extreme case, would this encourage an external group to register = a single application id for a highly extensible application, then bypass = IETF extension processes by just adding more functions to the original = application? -- 8: The security considerations say that this draft does not define nor = address security related protocols or schemes. But there was an entire = section dedicated to the use of IPSec, which certainly seems to address = a security related protocol and scheme.=20 Editorial Comments: -- section 1: I'm confused by list item 2. It seems to talk both about adding new = function to an existing application and creating a new application. I = suspect this is about the case of using two applications together to = effectively add function--if so, that could be more clear. -- section 3, Major Extension case: "... in such a way that this implies = backward compatible change to the existing application ..." Do you mean a _non_ backwards compatible change? -- section 4.1, third bullet: " Care should be taken to avoid a liberal = method of importing existing command=92s CCF syntax specification." I'm not sure I understand what you mean by a "liberal method of = importing"? "This would result in a monolithic and hard to manage applications..."=20= singular/plural disagreement -- 4.2, 2nd paragraph s/" indicates of a flawed design"/"indicates a flawed design" -- 4.3, 2nd paragraph: s/"It is worth to note that"/"It is worth noting that" [Or even = better, skip the whole clause] s/"in the [RFC3588]"/"in [RFC3588]" -- 4.3.1, title: s/ommand/command -- 4.3.1, 2nd bullet list, 3rd bullet: The second half of this bullet item seems redundant with the previous = bullet. -- 5.8 The section may have some meaning obscured by passive voice. In = particular, who foresaw that translation would be easy, who acknowledged = that it wasn't, and who might foresee the need for RADIUS interworking? = (I think those are the work group, the work group, and application = designers, respectively) -- 5.9, third bullet: "Applications that do not understand these AVP can = discard it ..." singular/plural disagreement -- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms = such as IPsec can also be deployed to secure connections between = Diameter peers." Do you mean "IPSec can also be deployed...", or "Additional security = mechanisms such as IPSec can also be deployed..."? Thanks! Ben.