From internet-drafts@ietf.org Wed Aug 3 09:53:47 2011 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 9F97821F8B71; Wed, 3 Aug 2011 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 OdBlNwgOiWgE; Wed, 3 Aug 2011 09:53:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380EE21F8AFA; Wed, 3 Aug 2011 09:53:47 -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: 3.57 Message-ID: <20110803165347.11996.7084.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2011 09:53:47 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-extended-naptr-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:53:47 -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 W= orking Group of the IETF. Title : Diameter S-NAPTR Usage Author(s) : Mark Jones Jouni Korhonen Lionel Morand Filename : draft-ietf-dime-extended-naptr-09.txt Pages : 14 Date : 2011-08-03 The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC3588 "Diameter Base Protocol" and describes an impr= ovement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-09.txt From mark@azu.ca Fri Aug 5 11:29:04 2011 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 53D0311E809B for ; Fri, 5 Aug 2011 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 x5YkfoMxKMph for ; Fri, 5 Aug 2011 11:29:03 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34811E8070 for ; Fri, 5 Aug 2011 11:29:03 -0700 (PDT) Received: by iye1 with SMTP id 1so3707538iye.27 for ; Fri, 05 Aug 2011 11:29:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.67.211 with SMTP id s19mr2029657ibi.30.1312568961427; Fri, 05 Aug 2011 11:29:21 -0700 (PDT) Received: by 10.231.199.204 with HTTP; Fri, 5 Aug 2011 11:29:21 -0700 (PDT) Date: Fri, 5 Aug 2011 14:29:21 -0400 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: multipart/alternative; boundary=00151773e622b069dc04a9c6460b Subject: [Dime] Bulk Session Signaling in Diameter 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, 05 Aug 2011 18:29:04 -0000 --00151773e622b069dc04a9c6460b Content-Type: text/plain; charset=ISO-8859-1 In the last few IETF meetings, we've discussed ways of expressing groups of sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled this. Marco Liebsch presented a good summary of this problem and current solutions in Quebec. I would like to submit an I-D that specifies a solution for this problem. I circulated an abstract (offline) and here is the resulting version: "In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges in order to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization." I understand that this work is not within the scope of the current DIME charter and so propose the charter be amended to include the following clause: " - Protocol extensions to optimize signaling when a Diameter peer needs to apply the same operation to large groups of sessions." Does the WG think this is a useful work item? Are there objections to amending the charter to include it? Thanks Mark --00151773e622b069dc04a9c6460b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the last few IETF meetings, we've discussed ways of expressing group= s of sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled= this. Marco Liebsc= h=A0presented a good summary of this problem and current solutions i= n Quebec.

I would like to submit an I-D that specifies a solution for = this problem. I circulated an abstract (offline) and here is the resulting = version:

"In large network deployments, a single Diameter peer c= an support over a million concurrent Diameter sessions. Recent use cases ha= ve revealed the need for Diameter peers to apply=A0the same operation to a = large group of Diameter sessions concurrently. The Diameter=A0base protocol= commands operate on a single session so these use cases could result in ma= ny=A0thousands of command exchanges in order to enforce the same operation = on each=A0session in the group. In order to reduce signaling, it would be d= esirable to enable=A0bulk operations on all (or part of) the sessions manag= ed by a Diameter peer using a single=A0or a few command exchanges. This doc= ument specifies the Diameter protocol extensions=A0to achieve this signalin= g optimization."

I understand that = this work is not within the scope of the current DIME charter and so propos= e the charter be amended to include the following clause:

" - Pr= otocol extensions to optimize signaling when a Diameter peer needs to=A0app= ly the same operation to large groups of sessions."

Does the WG= think this is a useful work item? Are there objections to amending the cha= rter to include it?

Thanks
Mark

<= br>
--00151773e622b069dc04a9c6460b-- From mark@azu.ca Fri Aug 5 11:29:09 2011 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 243E211E8070 for ; Fri, 5 Aug 2011 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 QpAToifTVysK for ; Fri, 5 Aug 2011 11:29:08 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 86AD211E80BE for ; Fri, 5 Aug 2011 11:29:08 -0700 (PDT) Received: by pzk33 with SMTP id 33so10706619pzk.18 for ; Fri, 05 Aug 2011 11:29:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.202.21 with SMTP id z21mr2287470wff.83.1312568966489; Fri, 05 Aug 2011 11:29:26 -0700 (PDT) Received: by 10.68.50.98 with HTTP; Fri, 5 Aug 2011 11:29:26 -0700 (PDT) Date: Fri, 5 Aug 2011 14:29:26 -0400 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: multipart/alternative; boundary=000e0cd24036fda78204a9c6460e Subject: [Dime] Bulk Session Signaling in Diameter 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, 05 Aug 2011 18:29:09 -0000 --000e0cd24036fda78204a9c6460e Content-Type: text/plain; charset=ISO-8859-1 In the last few IETF meetings, we've discussed ways of expressing groups of sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled this. Marco Liebsch presented a good summary of this problem and current solutions in Quebec. I would like to submit an I-D that specifies a solution for this problem. I circulated an abstract (offline) and here is the resulting version: "In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges in order to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization." I understand that this work is not within the scope of the current DIME charter and so propose the charter be amended to include the following clause: " - Protocol extensions to optimize signaling when a Diameter peer needs to apply the same operation to large groups of sessions." Does the WG think this is a useful work item? Are there objections to amending the charter to include it? Thanks Mark --000e0cd24036fda78204a9c6460e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the last few IETF meetings, we've discussed ways of expressing group= s of sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled= this. Marco Liebsc= h=A0presented a good summary of this problem and current solutions i= n Quebec.

I would like to submit an I-D that specifies a solution for = this problem. I circulated an abstract (offline) and here is the resulting = version:

"In large network deployments, a single Diameter peer c= an support over a million concurrent Diameter sessions. Recent use cases ha= ve revealed the need for Diameter peers to apply=A0the same operation to a = large group of Diameter sessions concurrently. The Diameter=A0base protocol= commands operate on a single session so these use cases could result in ma= ny=A0thousands of command exchanges in order to enforce the same operation = on each=A0session in the group. In order to reduce signaling, it would be d= esirable to enable=A0bulk operations on all (or part of) the sessions manag= ed by a Diameter peer using a single=A0or a few command exchanges. This doc= ument specifies the Diameter protocol extensions=A0to achieve this signalin= g optimization."

I understand that = this work is not within the scope of the current DIME charter and so propos= e the charter be amended to include the following clause:

" - Pr= otocol extensions to optimize signaling when a Diameter peer needs to=A0app= ly the same operation to large groups of sessions."

Does the WG= think this is a useful work item? Are there objections to amending the cha= rter to include it?

Thanks
Mark

<= br>
--000e0cd24036fda78204a9c6460e-- From Marco.Liebsch@neclab.eu Mon Aug 8 05:58:03 2011 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 0D24E21F89BE for ; Mon, 8 Aug 2011 05:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrxtsQWNxprM for ; Mon, 8 Aug 2011 05:58:02 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 24BD721F8753 for ; Mon, 8 Aug 2011 05:58:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AADD0280002FE; Mon, 8 Aug 2011 14:58:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV1oYLFrLW71; Mon, 8 Aug 2011 14:58:27 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 89CB028000213; Mon, 8 Aug 2011 14:58:17 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Mon, 8 Aug 2011 14:57:56 +0200 From: Marco Liebsch To: Mark Jones , "dime@ietf.org" Thread-Topic: [Dime] Bulk Session Signaling in Diameter Thread-Index: AQHMU52iX4Cu9wLmbkeP8jn766/xpJUS7UsA Date: Mon, 8 Aug 2011 12:57:56 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D1CE2F6FC@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.32] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D1CE2F6FCDAPHNISofficehd_" MIME-Version: 1.0 Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 08 Aug 2011 12:58:03 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D1CE2F6FCDAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adding the work item on bulk signaling to the DIME charter. Marco From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mar= k Jones Sent: Freitag, 5. August 2011 20:29 To: dime@ietf.org Subject: [Dime] Bulk Session Signaling in Diameter In the last few IETF meetings, we've discussed ways of expressing groups of= sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled thi= s. Marco Liebsch presented a good summary of this problem and current solut= ions in Quebec. I would like to submit an I-D that specifies a solution for this problem. I= circulated an abstract (offline) and here is the resulting version: "In large network deployments, a single Diameter peer can support over a mi= llion concurrent Diameter sessions. Recent use cases have revealed the need= for Diameter peers to apply the same operation to a large group of Diamete= r sessions concurrently. The Diameter base protocol commands operate on a s= ingle session so these use cases could result in many thousands of command = exchanges in order to enforce the same operation on each session in the gro= up. In order to reduce signaling, it would be desirable to enable bulk oper= ations on all (or part of) the sessions managed by a Diameter peer using a = single or a few command exchanges. This document specifies the Diameter pro= tocol extensions to achieve this signaling optimization." I understand that this work is not within the scope of the current DIME cha= rter and so propose the charter be amended to include the following clause: " - Protocol extensions to optimize signaling when a Diameter peer needs to= apply the same operation to large groups of sessions." Does the WG think this is a useful work item? Are there objections to amend= ing the charter to include it? Thanks Mark --_000_69756203DDDDE64E987BC4F70B71A26D1CE2F6FCDAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support = adding the work item on bulk signaling to the DIME charter.

 = ;

Marco=

 = ;

 = ;

 = ;

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mark Jones
Sent: Freitag, 5. August 2011 20:29
To: dime@ietf.org
Subject: [Dime] Bulk Session Signaling in Diameter=

 

In the last few IETF meetings, we've discussed ways = of expressing groups of sessions and reviewed how some SDOs, e.g. TISPAN, h= ave already tackled this. Marco Liebsch presented a good summary of this problem and current solutions in Quebec.=

 

I would like to submit an I-D that specifies a solut= ion for this problem. I circulated an abstract (offline) and here is the re= sulting version:

 

"In large network deployments, a single Diameter peer can sup= port over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation= to a large group of Diameter sessions concurrently. The Diameter base= protocol commands operate on a single session so these use cases could res= ult in many thousands of command exchanges in order to enforce the same operation on each session in the group. = In order to reduce signaling, it would be desirable to enable bulk ope= rations on all (or part of) the sessions managed by a Diameter peer using a= single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling = optimization."

 

I understand that this wo= rk is not within the scope of the current DIME charter and so propose the c= harter be amended to include the following clause:=

 

" - Protocol extensions to optimize signaling when a Diameter= peer needs to apply the same operation to large groups of sessions.&q= uot;

 

Does the WG think this is a useful work item? Are there objections= to amending the charter to include it?

 

Thanks

Mark

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D1CE2F6FCDAPHNISofficehd_-- From iesg-secretary@ietf.org Mon Aug 8 14:20:03 2011 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 5D51E11E809D; Mon, 8 Aug 2011 14:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGwK05flSuYM; Mon, 8 Aug 2011 14:20:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8011E80B5; Mon, 8 Aug 2011 14:20:02 -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: 3.57 Message-ID: <20110808212002.1259.76211.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2011 14:20:02 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter S-NAPTR Usage' to Proposed Standard (draft-ietf-dime-extended-naptr-09.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: Mon, 08 Aug 2011 21:20:03 -0000 The IESG has approved the following document: - 'Diameter S-NAPTR Usage' (draft-ietf-dime-extended-naptr-09.txt) as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-extended-naptr/ Technical Summary The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates [RFC3588] and describes an improvement using an extended format for the Straightforward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. Working Group Summary Since the WG consists of a few individuals, it is difficult to assess how solid is the WG consensus. However, the document was taken as WG item with a strong consensus on its usefulness, and received good contributions afterwards. Document Quality There is currently no publicly announced implementations of this mechanism, but there is known on-going implementation effort. S-NAPTR and Diameter are implemented protocols. Personnel Sebastien Decugis is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director.' From bill.wu@huawei.com Mon Aug 8 18:59:28 2011 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 EF2DF11E8086 for ; Mon, 8 Aug 2011 18:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, 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 3RrsMSW3zkDO for ; Mon, 8 Aug 2011 18:59:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4B11E8087 for ; Mon, 8 Aug 2011 18:59:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPN00FTT1JTMJ@szxga03-in.huawei.com> for dime@ietf.org; Tue, 09 Aug 2011 09:59:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPN00HT41JG04@szxga03-in.huawei.com> for dime@ietf.org; Tue, 09 Aug 2011 09:59:53 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADA17495; Tue, 09 Aug 2011 09:59:52 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 09 Aug 2011 09:59:47 +0800 Received: from w53375q (10.138.41.130) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 09 Aug 2011 09:59:49 +0800 Date: Tue, 09 Aug 2011 09:59:48 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Marco Liebsch , Mark Jones , dime@ietf.org Message-id: <5714F3165FC046D584C7D65F50B27283@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_KyoYPDsThBsdet/KZ4rZkw)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <69756203DDDDE64E987BC4F70B71A26D1CE2F6FC@DAPHNIS.office.hd> Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 09 Aug 2011 01:59:29 -0000 --Boundary_(ID_KyoYPDsThBsdet/KZ4rZkw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT +1 ----- Original Message ----- From: Marco Liebsch To: Mark Jones ; dime@ietf.org Sent: Monday, August 08, 2011 8:57 PM Subject: Re: [Dime] Bulk Session Signaling in Diameter I support adding the work item on bulk signaling to the DIME charter. Marco From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mark Jones Sent: Freitag, 5. August 2011 20:29 To: dime@ietf.org Subject: [Dime] Bulk Session Signaling in Diameter In the last few IETF meetings, we've discussed ways of expressing groups of sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled this. Marco Liebsch presented a good summary of this problem and current solutions in Quebec. I would like to submit an I-D that specifies a solution for this problem. I circulated an abstract (offline) and here is the resulting version: "In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges in order to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization." I understand that this work is not within the scope of the current DIME charter and so propose the charter be amended to include the following clause: " - Protocol extensions to optimize signaling when a Diameter peer needs to apply the same operation to large groups of sessions." Does the WG think this is a useful work item? Are there objections to amending the charter to include it? Thanks Mark ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_KyoYPDsThBsdet/KZ4rZkw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
+1
----- Original Message -----
Sent: Monday, August 08, 2011 8:57 PM
Subject: Re: [Dime] Bulk Session Signaling in Diameter

I support adding the work item on bulk signaling to the DIME charter.

 

Marco

 

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Mark Jones
Sent: Freitag, 5. August 2011 20:29
To: dime@ietf.org
Subject: [Dime] Bulk Session Signaling in Diameter

 

In the last few IETF meetings, we've discussed ways of expressing groups of sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled this. Marco Liebsch presented a good summary of this problem and current solutions in Quebec.

 

I would like to submit an I-D that specifies a solution for this problem. I circulated an abstract (offline) and here is the resulting version:

 

"In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges in order to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization."

 

I understand that this work is not within the scope of the current DIME charter and so propose the charter be amended to include the following clause:

 

" - Protocol extensions to optimize signaling when a Diameter peer needs to apply the same operation to large groups of sessions."

 

Does the WG think this is a useful work item? Are there objections to amending the charter to include it?

 

Thanks

Mark

 

 

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_KyoYPDsThBsdet/KZ4rZkw)-- From gwz@net-zen.net Tue Aug 9 01:09:29 2011 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 4ED3921F893C for ; Tue, 9 Aug 2011 01:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmysZC5uel7C for ; Tue, 9 Aug 2011 01:09:28 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by ietfa.amsl.com (Postfix) with SMTP id 63ABD21F876A for ; Tue, 9 Aug 2011 01:09:28 -0700 (PDT) Received: (qmail 15332 invoked from network); 9 Aug 2011 08:03:16 -0000 Received: from unknown (124.120.247.89) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 09 Aug 2011 08:03:15 -0000 Message-ID: <4E40E9BF.5040603@net-zen.net> Date: Tue, 09 Aug 2011 15:03:11 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Marco Liebsch References: <69756203DDDDE64E987BC4F70B71A26D1CE2F6FC@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D1CE2F6FC@DAPHNIS.office.hd> X-Enigmail-Version: 1.2 Content-Type: multipart/mixed; boundary="------------030904090409040707010507" Cc: "dime@ietf.org" Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 09 Aug 2011 08:09:29 -0000 This is a multi-part message in MIME format. --------------030904090409040707010507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/8/2011 7:57 PM, Marco Liebsch wrote: > I support adding the work item on bulk signaling to the DIME > charter. I don't think that it is as simple as just adding a work item: the charter says nothing about this kind of work, so I think that it is clear that a re-charter would be necessary (again). ... --------------030904090409040707010507 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------030904090409040707010507-- From avi@bridgewatersystems.com Tue Aug 9 06:27:07 2011 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 CB54221F8829 for ; Tue, 9 Aug 2011 06:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, 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 pRrp2uYTCOOz for ; Tue, 9 Aug 2011 06:27:07 -0700 (PDT) Received: from mail37.messagelabs.com (mail37.messagelabs.com [216.82.241.83]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B121F8757 for ; Tue, 9 Aug 2011 06:27:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-4.tower-37.messagelabs.com!1312896454!98823361!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 7427 invoked from network); 9 Aug 2011 13:27:34 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-4.tower-37.messagelabs.com with RC4-SHA encrypted SMTP; 9 Aug 2011 13:27:34 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 9 Aug 2011 09:27:32 -0400 From: Avi Lior To: Mark Jones , "dime@ietf.org" Date: Tue, 9 Aug 2011 09:27:42 -0400 Thread-Topic: [Dime] Bulk Session Signaling in Diameter Thread-Index: AcxWmBfECdBuLRvvStecqCiu6Ky63A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: multipart/alternative; boundary="_000_CA66AC8C5FBCavibridgewatersystemscom_" MIME-Version: 1.0 Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 09 Aug 2011 13:27:07 -0000 --_000_CA66AC8C5FBCavibridgewatersystemscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also support Bulk Session Signalling in Diameter. I think this is going = to be useful for example in the area of Machine to Machine. A machine to machine deployment typically consists of a group of like machi= nes (same configuration, same feature set, requiring the same service autho= rization etc). Sometime we want to control each of the machines but often = we want to control a group of machines. Using tags to group machines and t= hen operating on groups of machines matching a tag-set would provide a trem= endous efficiency to the network. I think that this is needed and I am available to work on this topic. On 11-08-05 14:29 , "Mark Jones" > wrote: In the last few IETF meetings, we've discussed ways of expressing groups of= sessions and reviewed how some SDOs, e.g. TISPAN, have already tackled thi= s. Marco Liebsch presented a good summary of this problem and current solut= ions in Quebec. I would like to submit an I-D that specifies a solution for this problem. I= circulated an abstract (offline) and here is the resulting version: "In large network deployments, a single Diameter peer can support over a mi= llion concurrent Diameter sessions. Recent use cases have revealed the need= for Diameter peers to apply the same operation to a large group of Diamete= r sessions concurrently. The Diameter base protocol commands operate on a s= ingle session so these use cases could result in many thousands of command = exchanges in order to enforce the same operation on each session in the gro= up. In order to reduce signaling, it would be desirable to enable bulk oper= ations on all (or part of) the sessions managed by a Diameter peer using a = single or a few command exchanges. This document specifies the Diameter pro= tocol extensions to achieve this signaling optimization." I understand that this work is not within the scope of the current DIME cha= rter and so propose the charter be amended to include the following clause: " - Protocol extensions to optimize signaling when a Diameter peer needs to= apply the same operation to large groups of sessions." Does the WG think this is a useful work item? Are there objections to amend= ing the charter to include it? Thanks Mark --_000_CA66AC8C5FBCavibridgewatersystemscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I also support Bulk Sess= ion Signalling in Diameter.  I think this is going to be useful for ex= ample in the area of Machine to Machine.

A machine= to machine deployment typically consists of a group of like machines (same= configuration, same feature set, requiring the same service authorization = etc).  Sometime we want to control each of the machines but often we w= ant to control a group of machines.  Using tags to group machines and = then operating on groups of machines matching a tag-set would provide a tre= mendous efficiency to the network.

I think that th= is is needed and I am available to work on this topic.

=

On 11-08-05 14:2= 9 , "Mark Jones" <mark@azu.ca> wro= te:

In the last few IETF meetings, we've discusse= d ways of expressing groups of sessions and reviewed how some SDOs, e.g. TI= SPAN, have already tackled this. Marco Liebsch presented a good summary of this pr= oblem and current solutions in Quebec.

I would like to s= ubmit an I-D that specifies a solution for this problem. I circulated an ab= stract (offline) and here is the resulting version:

"In large network= deployments, a single Diameter peer can support over a million concurrent = Diameter sessions. Recent use cases have revealed the need for Diameter pee= rs to apply the same operation to a large group of Diameter sessions c= oncurrently. The Diameter base protocol commands operate on a single s= ession so these use cases could result in many thousands of command ex= changes in order to enforce the same operation on each session in the = group. In order to reduce signaling, it would be desirable to enable b= ulk operations on all (or part of) the sessions managed by a Diameter peer = using a single or a few command exchanges. This document specifies the= Diameter protocol extensions to achieve this signaling optimization."=
<= br>
I unde= rstand that this work is not within the scope of the current DIME charter a= nd so propose the charter be amended to include the following clause:

=

Does the WG= think this is a useful work item? Are there objections to amending the cha= rter to include it?

Thanks
Mark


--_000_CA66AC8C5FBCavibridgewatersystemscom_-- From internet-drafts@ietf.org Fri Aug 12 13:55:15 2011 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 9DC0E11E80A0; Fri, 12 Aug 2011 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 9MwmTJsGolLw; Fri, 12 Aug 2011 13:55:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B011E8094; Fri, 12 Aug 2011 13:55:15 -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: 3.57 Message-ID: <20110812205515.27516.43554.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2011 13:55:15 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ikev2-psk-diameter-09.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, 12 Aug 2011 20:55:15 -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 W= orking Group of the IETF. Title : Diameter IKEv2 PSK: Pre-Shared Key-based Support for IKE= v2 Server to Diameter Server Interaction Author(s) : Violeta Cakulev Avi Lior Semyon Mizikovsky Filename : draft-ietf-dime-ikev2-psk-diameter-09.txt Pages : 20 Date : 2011-08-12 The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and pre-shared keys. Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for pre-shared key based authentication available with IKEv2. This document specifies the IKEv2 Server to the Diameter server communication when the IKEv2 Peer authenticates using the Internet Key Exchange v2 with Pre-Shared Key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-ikev2-psk-diameter-09.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-ikev2-psk-diameter-09.txt From internet-drafts@ietf.org Sun Aug 14 23:15:13 2011 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 5CBDB21F8B2A; Sun, 14 Aug 2011 23:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 O5fKHqjeUp7W; Sun, 14 Aug 2011 23:15:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBDE21F8B26; Sun, 14 Aug 2011 23:15:12 -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: 3.58 Message-ID: <20110815061512.27687.19303.idtracker@ietfa.amsl.com> Date: Sun, 14 Aug 2011 23:15:12 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-local-keytran-12.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: Mon, 15 Aug 2011 06:15:13 -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 W= orking Group of the IETF. Title : Diameter Attribute-Value Pairs for Cryptographic Key Tra= nsport Author(s) : Glen Zorn Qin Wu Violeta Cakulev Filename : draft-ietf-dime-local-keytran-12.txt Pages : 8 Date : 2011-08-14 Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-12.txt From internet-drafts@ietf.org Sun Aug 14 23:47:49 2011 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 839CC21F8782; Sun, 14 Aug 2011 23:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 zE3jfS0XQW5V; Sun, 14 Aug 2011 23:47:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371CA21F8742; Sun, 14 Aug 2011 23:47:44 -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: 3.58 Message-ID: <20110815064744.4538.41788.idtracker@ietfa.amsl.com> Date: Sun, 14 Aug 2011 23:47:44 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-local-keytran-13.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:47:49 -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 W= orking Group of the IETF. Title : Diameter Attribute-Value Pairs for Cryptographic Key Tra= nsport Author(s) : Glen Zorn Qin Wu Violeta Cakulev Filename : draft-ietf-dime-local-keytran-13.txt Pages : 8 Date : 2011-08-14 Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-13.txt From jouni.nospam@gmail.com Wed Aug 17 22:27:21 2011 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 C924521F85FE for ; Wed, 17 Aug 2011 22:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 ckucnWRIv8zK for ; Wed, 17 Aug 2011 22:27:21 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE6D421F8519 for ; Wed, 17 Aug 2011 22:27:20 -0700 (PDT) Received: by bkar4 with SMTP id r4so1428621bka.31 for ; Wed, 17 Aug 2011 22:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3Jo+H7zQ4YPwZbGN/xZtiERUuIA/cmp3IsLmmefDH0g=; b=VwoltTsG2f7sFEvE8FERcekEdhzK1DpgFubJSdK5s1rWCWpN9j8dinxLCGL2smFCDs owUsROkjdpter20+MU5b/3FxkbiJtJw7TNGsdYvZaZaPnUAhxf3V5BNVtoyEAIr+cJGM FfKei5wdWQINeymLSrYEIxYZckgMzbBFnx1Vw= Received: by 10.204.197.194 with SMTP id el2mr115648bkb.52.1313645293084; Wed, 17 Aug 2011 22:28:13 -0700 (PDT) Received: from [10.37.34.29] ([164.5.230.6]) by mx.google.com with ESMTPS id b17sm595295bkd.65.2011.08.17.22.28.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Aug 2011 22:28:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 18 Aug 2011 08:28:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B20@MSIS-GH1-UEA06.corp.nsa.gov> To: Tom Taylor , Glen Zorn , "Igoe, Kevin M." X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? 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, 18 Aug 2011 05:27:21 -0000 So.. folks happy if I word this: Diameter Peer If a Diameter Node shares a direct TCP or SCTP transport connection with another Diameter Node, it is a Diameter=20= Peer to that Diameter Node. And then also remove the definition for Transport Connection. - JOuni On Jun 3, 2011, at 1:23 AM, Tom Taylor wrote: > That looked good at first, but I think all you've done is add = authorization to the existing definition. It's still circular. Or are = you proposing to remove the definition of transport connection. I'd = support that. >=20 > On 02/06/2011 8:18 AM, Igoe, Kevin M. wrote: >> Glen Zorn& I have been having a sidebar discussion on the = circularity >>=20 >> of the following pair of definitions in = draft-ietf-dime-rfc3588bis-26. >>=20 >>=20 >>=20 >> Existing definitions: >>=20 >>=20 >>=20 >> Diameter Peer >>=20 >>=20 >>=20 >> If a Diameter Node shares a direct transport connection with >>=20 >> another Diameter Node, it is a Diameter Peer to that Diameter >>=20 >> Node. >>=20 >>=20 >>=20 >>=20 >>=20 >> Transport Connection >>=20 >> A transport connection is a TCP or SCTP connection existing >> directly between two Diameter peers, otherwise known as a = Peer-to- >> Peer Connection. >>=20 >>=20 >> We propose the following change to the definition of Diameter Peer >>=20 >> that removes the circularity and emphasizes the need to verify the = node >>=20 >> is properly authorized before accepting it as a peer and entering it >> into >>=20 >> the Peer list (as discussed in section 5.2). >>=20 >>=20 >>=20 >> Proposed definition: >>=20 >>=20 >>=20 >> Diameter Peer >>=20 >>=20 >>=20 >> Two Diameter Nodes are Peers if and only if a = properly >>=20 >> authorized transport (TCP or SCTP) connection exists between >>=20 >> them. >>=20 >>=20 >>=20 >>=20 >>=20 >> Comments/discussion appreciated. >>=20 >>=20 >>=20 >>=20 >>=20 >> Kevin M. Igoe | "Everyone is entitled to their own >> kmigoe@nsa.gov | opinions, but not to = their >> own facts." >> | - Daniel Patrick Moynihan - >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Thu Aug 18 00:31:39 2011 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 87D0E21F873A for ; Thu, 18 Aug 2011 00:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 YNfdJrN163RM for ; Thu, 18 Aug 2011 00:31:39 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id B434D21F871E for ; Thu, 18 Aug 2011 00:31:38 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2BF286FCC07; Thu, 18 Aug 2011 09:41:07 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1BC346FCAFB; Thu, 18 Aug 2011 09:41:07 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 09:32:28 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Aug 2011 09:32:26 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? Thread-index: AcxdZ6MZ7Vvc7BZeSne59OyXL8h33wAEFJag References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B20@MSIS-GH1-UEA06.corp.nsa.gov> From: To: , , , X-OriginalArrivalTime: 18 Aug 2011 07:32:28.0525 (UTC) FILETIME=[FB95A9D0:01CC5D78] Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? 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, 18 Aug 2011 07:31:39 -0000 I understand this definition of the context of Diameter. However for me, the notion of "peer" implicitly implies that the node is = part of a peer-to-peer application architecture, opposed to the = client-server model. Is it only a bad assumption or is it the reason why we are dealing with = Diameter peers instead of Diameter nodes? If I'm right, we should reflect this point in the definition... Sorry for this late comment. Lionel =20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de jouni korhonen Envoy=E9=A0: jeudi 18 ao=FBt 2011 07:28 =C0=A0: Tom Taylor; Glen Zorn; Igoe, Kevin M. Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? So.. folks happy if I word this: Diameter Peer If a Diameter Node shares a direct TCP or SCTP transport connection with another Diameter Node, it is a Diameter=20 Peer to that Diameter Node. And then also remove the definition for Transport Connection. - JOuni On Jun 3, 2011, at 1:23 AM, Tom Taylor wrote: > That looked good at first, but I think all you've done is add = authorization to the existing definition. It's still circular. Or are = you proposing to remove the definition of transport connection. I'd = support that. >=20 > On 02/06/2011 8:18 AM, Igoe, Kevin M. wrote: >> Glen Zorn& I have been having a sidebar discussion on the = circularity >>=20 >> of the following pair of definitions in = draft-ietf-dime-rfc3588bis-26. >>=20 >>=20 >>=20 >> Existing definitions: >>=20 >>=20 >>=20 >> Diameter Peer >>=20 >>=20 >>=20 >> If a Diameter Node shares a direct transport connection with >>=20 >> another Diameter Node, it is a Diameter Peer to that Diameter >>=20 >> Node. >>=20 >>=20 >>=20 >>=20 >>=20 >> Transport Connection >>=20 >> A transport connection is a TCP or SCTP connection existing >> directly between two Diameter peers, otherwise known as a = Peer-to- >> Peer Connection. >>=20 >>=20 >> We propose the following change to the definition of Diameter Peer >>=20 >> that removes the circularity and emphasizes the need to verify the = node >>=20 >> is properly authorized before accepting it as a peer and entering it >> into >>=20 >> the Peer list (as discussed in section 5.2). >>=20 >>=20 >>=20 >> Proposed definition: >>=20 >>=20 >>=20 >> Diameter Peer >>=20 >>=20 >>=20 >> Two Diameter Nodes are Peers if and only if a = properly >>=20 >> authorized transport (TCP or SCTP) connection exists between >>=20 >> them. >>=20 >>=20 >>=20 >>=20 >>=20 >> Comments/discussion appreciated. >>=20 >>=20 >>=20 >>=20 >>=20 >> Kevin M. Igoe | "Everyone is entitled to their own >> kmigoe@nsa.gov | opinions, but not to = their >> own facts." >> | - Daniel Patrick Moynihan - >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Thu Aug 18 01:22:15 2011 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 517B121F84D1 for ; Thu, 18 Aug 2011 01:22:15 -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 zwsMoUE2ZxY3 for ; Thu, 18 Aug 2011 01:22:14 -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 4B04E21F84BF for ; Thu, 18 Aug 2011 01:22:14 -0700 (PDT) Received: by yxp4 with SMTP id 4so1436477yxp.31 for ; Thu, 18 Aug 2011 01:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7YcCz5QhwsJtkEEI+H7NDnxnkSiPa9YaEhjUMYejDGg=; b=bwAuqB0bF9w77zA8/VWudtuX0n2s8VWn1I2olTRWw4kLNNDSfC3lhRPYw/c/oCPT4n FwPQ7kpKcRKGGVQ4aiqoz86yeTNrNvRrP2poCbXFgAh+Wvkq2YJCkynINyMQNbc3LibP CN9J5uV/rkiU03QaLC1zxMVFioZeaGnFya0/Q= Received: by 10.236.190.200 with SMTP id e48mr2139687yhn.59.1313655787267; Thu, 18 Aug 2011 01:23:07 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-121-237-194.revip2.asianet.co.th [124.121.237.194]) by mx.google.com with ESMTPS id w1sm2271531yhi.23.2011.08.18.01.23.00 (version=SSLv3 cipher=OTHER); Thu, 18 Aug 2011 01:23:06 -0700 (PDT) Message-ID: <4E4CCBDF.2020402@gmail.com> Date: Thu, 18 Aug 2011 15:22:55 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B20@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? 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, 18 Aug 2011 08:22:15 -0000 On 8/18/2011 2:32 PM, lionel.morand@orange-ftgroup.com wrote: > I understand this definition of the context of Diameter. > However for me, the notion of "peer" implicitly implies that the node is part of a peer-to-peer application architecture, opposed to the client-server model. I thought we talking about Diameter? It is a p2p protocol. > Is it only a bad assumption or is it the reason why we are dealing with Diameter peers instead of Diameter nodes? > If I'm right, we should reflect this point in the definition... > > Sorry for this late comment. > > Lionel > > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de jouni korhonen > Envoyé : jeudi 18 août 2011 07:28 > À : Tom Taylor; Glen Zorn; Igoe, Kevin M. > Cc : dime@ietf.org > Objet : Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? > > > So.. folks happy if I word this: > > Diameter Peer > > If a Diameter Node shares a direct TCP or SCTP transport > connection with another Diameter Node, it is a Diameter > Peer to that Diameter Node. & what is "that Diameter node"? Is it not a peer, as well? I think this unclear, preferring something like Diameter Peers Two Diameter Nodes sharing a direct TCP or SCTP transport connection are called Diameter Peers. or Diameter Peer Two Diameter Nodes are Peers if and only if there is a direct TCP or SCTP transport connection between them. > > And then also remove the definition for Transport Connection. > > - JOuni > > > > On Jun 3, 2011, at 1:23 AM, Tom Taylor wrote: > >> That looked good at first, but I think all you've done is add authorization to the existing definition. It's still circular. Or are you proposing to remove the definition of transport connection. I'd support that. >> >> On 02/06/2011 8:18 AM, Igoe, Kevin M. wrote: >>> Glen Zorn& I have been having a sidebar discussion on the circularity >>> >>> of the following pair of definitions in draft-ietf-dime-rfc3588bis-26. >>> >>> >>> >>> Existing definitions: >>> >>> >>> >>> Diameter Peer >>> >>> >>> >>> If a Diameter Node shares a direct transport connection with >>> >>> another Diameter Node, it is a Diameter Peer to that Diameter >>> >>> Node. >>> >>> >>> >>> >>> >>> Transport Connection >>> >>> A transport connection is a TCP or SCTP connection existing >>> directly between two Diameter peers, otherwise known as a Peer-to- >>> Peer Connection. >>> >>> >>> We propose the following change to the definition of Diameter Peer >>> >>> that removes the circularity and emphasizes the need to verify the node >>> >>> is properly authorized before accepting it as a peer and entering it >>> into >>> >>> the Peer list (as discussed in section 5.2). >>> >>> >>> >>> Proposed definition: >>> >>> >>> >>> Diameter Peer >>> >>> >>> >>> Two Diameter Nodes are Peers if and only if a properly >>> >>> authorized transport (TCP or SCTP) connection exists between >>> >>> them. >>> >>> >>> >>> >>> >>> Comments/discussion appreciated. >>> >>> >>> >>> >>> >>> Kevin M. Igoe | "Everyone is entitled to their own >>> kmigoe@nsa.gov | opinions, but not to their >>> own facts." >>> | - Daniel Patrick Moynihan - >>> >>> >>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Thu Aug 18 01:52:48 2011 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 2B81B21F8751 for ; Thu, 18 Aug 2011 01:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 BYuHYnlFWwUW for ; Thu, 18 Aug 2011 01:52:47 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 33B4A21F874F for ; Thu, 18 Aug 2011 01:52:47 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DDA79B000F; Thu, 18 Aug 2011 10:54:29 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0AB659B0007; Thu, 18 Aug 2011 10:54:25 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 10:53:33 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Aug 2011 10:53:31 +0200 Message-ID: In-reply-to: <4E4CCBDF.2020402@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? Thread-index: AcxdgCINClB4gNDvT5GZShknysV8fAAAy0Tg References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B20@MSIS-GH1-UEA06.corp.nsa.gov> <4E4CCBDF.2020402@gmail.com> From: To: X-OriginalArrivalTime: 18 Aug 2011 08:53:33.0181 (UTC) FILETIME=[4F2542D0:01CC5D84] Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? 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, 18 Aug 2011 08:52:48 -0000 Right! My point is just to say that the fact that any node can initiate = a request was for me a characteristic of the notion of "peer" in the = context of Diameter. And that specificity was not part of the = definition. In other words, for me, a peer-to-peer protocol identifies a protocol = used between two peers that can initiate requests sent to each other = i.e. it is an intrinsic characteristic of a "peer". Again, it is just my personal assumption. If you folks think that the = current proposed definition is accurate, forget my comment! Lionel -----Message d'origine----- De=A0: Glen Zorn [mailto:glenzorn@gmail.com]=20 Envoy=E9=A0: jeudi 18 ao=FBt 2011 10:23 =C0=A0: MORAND Lionel RD-CORE-ISS Cc=A0: jouni.nospam@gmail.com; tom111.taylor@bell.net; = glenzorn@gmail.com; kmigoe@nsa.gov; dime@ietf.org Objet=A0: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? On 8/18/2011 2:32 PM, lionel.morand@orange-ftgroup.com wrote: > I understand this definition of the context of Diameter. > However for me, the notion of "peer" implicitly implies that the node = is part of a peer-to-peer application architecture, opposed to the = client-server model. I thought we talking about Diameter? It is a p2p protocol. > Is it only a bad assumption or is it the reason why we are dealing = with Diameter peers instead of Diameter nodes? > If I'm right, we should reflect this point in the definition... >=20 > Sorry for this late comment. >=20 > Lionel =20 >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de jouni korhonen > Envoy=E9 : jeudi 18 ao=FBt 2011 07:28 > =C0 : Tom Taylor; Glen Zorn; Igoe, Kevin M. > Cc : dime@ietf.org > Objet : Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? >=20 >=20 > So.. folks happy if I word this: >=20 > Diameter Peer >=20 > If a Diameter Node shares a direct TCP or SCTP = transport > connection with another Diameter Node, it is a Diameter = > Peer to that Diameter Node. & what is "that Diameter node"? Is it not a peer, as well? I think this unclear, preferring something like Diameter Peers Two Diameter Nodes sharing a direct TCP or SCTP transport connection are called Diameter Peers. or Diameter Peer Two Diameter Nodes are Peers if and only if there is a direct TCP or SCTP transport connection between them. >=20 > And then also remove the definition for Transport Connection. >=20 > - JOuni >=20 >=20 >=20 > On Jun 3, 2011, at 1:23 AM, Tom Taylor wrote: >=20 >> That looked good at first, but I think all you've done is add = authorization to the existing definition. It's still circular. Or are = you proposing to remove the definition of transport connection. I'd = support that. >> >> On 02/06/2011 8:18 AM, Igoe, Kevin M. wrote: >>> Glen Zorn& I have been having a sidebar discussion on the = circularity >>> >>> of the following pair of definitions in = draft-ietf-dime-rfc3588bis-26. >>> >>> >>> >>> Existing definitions: >>> >>> >>> >>> Diameter Peer >>> >>> >>> >>> If a Diameter Node shares a direct transport connection with >>> >>> another Diameter Node, it is a Diameter Peer to that Diameter >>> >>> Node. >>> >>> >>> >>> >>> >>> Transport Connection >>> >>> A transport connection is a TCP or SCTP connection existing >>> directly between two Diameter peers, otherwise known as a = Peer-to- >>> Peer Connection. >>> >>> >>> We propose the following change to the definition of Diameter Peer >>> >>> that removes the circularity and emphasizes the need to verify the = node >>> >>> is properly authorized before accepting it as a peer and entering it >>> into >>> >>> the Peer list (as discussed in section 5.2). >>> >>> >>> >>> Proposed definition: >>> >>> >>> >>> Diameter Peer >>> >>> >>> >>> Two Diameter Nodes are Peers if and only if a = properly >>> >>> authorized transport (TCP or SCTP) connection exists between >>> >>> them. >>> >>> >>> >>> >>> >>> Comments/discussion appreciated. >>> >>> >>> >>> >>> >>> Kevin M. Igoe | "Everyone is entitled to their own >>> kmigoe@nsa.gov | opinions, but not to = their >>> own facts." >>> | - Daniel Patrick Moynihan - >>> >>> >>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Aug 18 04:50:46 2011 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 B77E621F8AF5 for ; Thu, 18 Aug 2011 04:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 he-jTzErYbVl for ; Thu, 18 Aug 2011 04:50:46 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACA621F8AF3 for ; Thu, 18 Aug 2011 04:50:43 -0700 (PDT) Received: by wwf5 with SMTP id 5so1315655wwf.13 for ; Thu, 18 Aug 2011 04:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QPx22dhQ7rwiWlGVVAd/mR08a2lszl2/CFZjaDM15Wc=; b=eA51jqwAqc5vLX7eDcoosigEMj4fD/4U2f88p7ywlmqMM/n7QRbxoSwkRnkb+c/AZu CSKiTv2kdwzznUateVDAcQeH+LXwwQqmqOqBsk8gXunHNYSiZqtacmgi9wuGXQemUoQS bW3KZIRBubdEED0MroYdakkneCjoQQYo3OwEY= Received: by 10.216.208.33 with SMTP id p33mr532574weo.27.1313668296738; Thu, 18 Aug 2011 04:51:36 -0700 (PDT) Received: from [10.255.129.211] ([192.100.123.77]) by mx.google.com with ESMTPS id h62sm1432276wee.8.2011.08.18.04.51.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 04:51:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E4CCBDF.2020402@gmail.com> Date: Thu, 18 Aug 2011 14:51:28 +0300 Content-Transfer-Encoding: 7bit Message-Id: <4751CC23-B098-4FAE-84A1-0B8A8D8DEDD0@gmail.com> References: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B20@MSIS-GH1-UEA06.corp.nsa.gov> <4E4CCBDF.2020402@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-rfc3588bis-26: circular definition? 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, 18 Aug 2011 11:50:46 -0000 On Aug 18, 2011, at 11:22 AM, Glen Zorn wrote: > > Diameter Peers > > Two Diameter Nodes sharing a direct TCP or SCTP > transport connection are called Diameter Peers. This sounds good. Thanks. - JOuni > > or > > Diameter Peer > > Two Diameter Nodes are Peers if and > only if there is a direct TCP or SCTP > transport connection between them. > >> >> And then also remove the definition for Transport Connection. >> >> - JOuni >> From jouni.nospam@gmail.com Thu Aug 18 05:17:14 2011 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 DE9D421F8801 for ; Thu, 18 Aug 2011 05:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 lSb4JXPBlbux for ; Thu, 18 Aug 2011 05:17:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBF721F87F9 for ; Thu, 18 Aug 2011 05:17:13 -0700 (PDT) Received: by wyg8 with SMTP id 8so1578565wyg.31 for ; Thu, 18 Aug 2011 05:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=rRxarjwhu1IsIaFL2w4hNvY4frDCZlndDBS2upFrHmQ=; b=iJIZTT5BC/pjXoYRzEX+3FmdaKUzqokOA/7jf/4xSOSrDOLK0/fozp6ZPYKQ0d6im2 UKun3ulpI9GGoReHTSwDelha4AxJVxcfc0t9DgWPPYZTJsrsEx5L47KewqJNvPcVxOCT VGVO0NTQZEJMDguzU6jcEFEkoFJRX+971I12I= Received: by 10.216.132.210 with SMTP id o60mr518737wei.82.1313669878157; Thu, 18 Aug 2011 05:17:58 -0700 (PDT) Received: from [10.255.129.211] ([192.100.123.77]) by mx.google.com with ESMTPS id b1sm1447424wed.10.2011.08.18.05.17.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 05:17:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: Date: Thu, 18 Aug 2011 15:17:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com> References: To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? 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, 18 Aug 2011 12:17:15 -0000 Folks, We had a discussion on unused (reserved) flags in AVP header. Here is = proposed text to Section 4.1 regarding reserved AVP flags: OLD: The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error. ... NEW: The AVP Flags field informs the receiver how each attribute must be handled. It is RECOMMENDED that new Diameter applications do=20= not to define additional AVP Flag bits. The sender of the AVP MUST set 'r' (reserved) bits to 0 and the receiver MUST ignore all 'r' (reserved) bits. Unrecognized bits SHOULD be considered an error. ... Then proposed additional text to Section 1.3.4 AVP Flag bits An existing application changes the meaning/semantics of their AVP Flags or adds new flag bits then a new Diameter application MUST be created. Any comments? - Jouni On Mar 17, 2011, at 11:35 PM, Avi Lior wrote: > Hi All, >=20 > Just summarizing and reasserting my objection. >=20 > There are two issues here: > A) Should we have a bit definition for a grouped AVP. >=20 > B) Can bits be defined by Applications etc; and >=20 > WRT to (A). And putting aside (B). I haven't heard any compelling = reason > to add the G-bit. As stated by more then one person: You either = support > the > AVP based on its command code or not - whether its a grouped AVP or = not > only becomes when you have to dive in to it - and you would only do = that > for an AVP that you support. And you would know the type of the AVP > (whether it is an int or a group etc) if you support the AVP. >=20 >=20 >=20 > As to B) I agree with Glen. As per the specification an Application = can > define its own AVP flag. > Thus if an application writer can design a new Application and add a = G-Bit > if they want. >=20 > What we cant do is add the G-bit as a general mechanism that can be > applied to all application (like the M-bit) and this is because (as > mentioned on this thread) the specification was not written properly = and > we cant deal with such modification and not break things. See "the > senders shall set to zero(clear) and receivers shall ignore" = discussion. > We can't fix that in BIS since it will break existing applications. = We > could say that new applications shall include the above statement. We = can > also RECOMMEND that new application don't define their own AVP bits = (if we > want). This may create a bit of a war as those entities that have = done so > come out of the wood work. Do we know anyone that has done that? >=20 > Here is some text: >=20 > It is recommended that new Applications not define their own AVP flags > bits. >=20 > New Applications shall treat any reserved AVP flag bits as follows: = The > sender of the AVP shall clear (set to zero) all reserved AVP flag bits = and > receivers shall ignore all reserved AVP flag bits. >=20 >=20 > Is there anything to fix in BIS. Yes. >=20 > We need to state somewhere that if an existing application changes the > meaning/semantics of their AVP Flags then a new Application ID must be > assigned to that application. >=20 > This could be added to the section describing when to get a new > Application ID. >=20 > In V2 we can support properly the notion of applications defining = their > own Flag bits (yuck) or not (my vote) >=20 >=20 > -- Avi Lior > --Bridgewater Systems >=20 >=20 >=20 >=20 >>=20 >=20 From internet-drafts@ietf.org Thu Aug 18 23:18:53 2011 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 E393421F856A; Thu, 18 Aug 2011 23:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 cumPQsjxCtto; Thu, 18 Aug 2011 23:18:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2821F8559; Thu, 18 Aug 2011 23:18:53 -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: 3.59 Message-ID: <20110819061853.14132.80749.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2011 23:18:53 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-local-keytran-14.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, 19 Aug 2011 06:18:54 -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 W= orking Group of the IETF. Title : Diameter Attribute-Value Pairs for Cryptographic Key Tra= nsport Author(s) : Glen Zorn Qin Wu Violeta Cakulev Filename : draft-ietf-dime-local-keytran-14.txt Pages : 8 Date : 2011-08-18 Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-local-keytran-14.txt From jouni.nospam@gmail.com Fri Aug 19 04:38:38 2011 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 1056221F8AD1 for ; Fri, 19 Aug 2011 04:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ZFtCj30WcZmC for ; Fri, 19 Aug 2011 04:38:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8B121F8A58 for ; Fri, 19 Aug 2011 04:38:37 -0700 (PDT) Received: by bkar4 with SMTP id r4so2582648bka.31 for ; Fri, 19 Aug 2011 04:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=v0txhgolh1p3Ydu9xBU3bdfdZ8x+jXUJQChrBHeD+tc=; b=cLRWPzixFld9nP+66YTVHLcWv0+UB9+uD3WDibmSyRo+uBrtHKa9hKQXIeQsujj/Eo ubJWkQ5ObLKit1+lNUG2x3bHyiPLf/4d1NwGszqoknuOO1FJTViQXQCK2AHuVi0PXQvH gPgTzEqyw756S2R40S5IMzcZvoMHHbwqnUHx0= Received: by 10.204.129.219 with SMTP id p27mr424417bks.11.1313753943731; Fri, 19 Aug 2011 04:39:03 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id m18sm1021241bkt.18.2011.08.19.04.39.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 04:39:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: <005e01cb9870$3ab83160$b0289420$@net> Date: Fri, 19 Aug 2011 14:39:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <005e01cb9870$3ab83160$b0289420$@net> To: Glen Zorn , dime@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [Dime] rfc3588bis next revision; was Re: Error in RFC 3588bis? 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, 19 Aug 2011 11:38:38 -0000 Would the following be OK i.e. referring to relays instead of proxies? ... acting as relay or proxy agents for other types. As with relay agents, redirect agents do not keep state with respect to sessions or NAS resources. - JOuni On Dec 10, 2010, at 3:43 PM, Glen Zorn wrote: > In Section 1.2, the definition of Redirect Agent says "As with proxy = agents, > redirect agents do not keep state with respect to sessions or NAS > resources." However, just above the definition of Proxy Agent says = "In > addition to forwarding requests and responses, proxies make policy = decisions > relating to resource usage and provisioning. This is typically = accomplished > by tracking the state of NAS devices." I seem to detect a = contradiction. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Aug 19 05:55:13 2011 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 8F45E21F8AE9 for ; Fri, 19 Aug 2011 05:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 J4EmjB-oEWHf for ; Fri, 19 Aug 2011 05:55:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C189821F8AF3 for ; Fri, 19 Aug 2011 05:55:12 -0700 (PDT) Received: by bkar4 with SMTP id r4so2637525bka.31 for ; Fri, 19 Aug 2011 05:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=E04uoAljyyYd5QUKnwElNGskYku7UQtDbqRqlZHHs5M=; b=ipxUt0CYx69QqytVTCoTGxgjhCE0BzK9A3uxcv/GNyF/rbVhvUQXqVDEgdnvoPvPqT IHmn6H/RC79SErffCX07fCmepmIiPyK2CKRWyPnOxVQkA91QBJZXd3DMCY3Um9PypxmK RBCKREuvaffg42qz9cia1vrW75ZRBEgd8Z9+w= Received: by 10.204.154.200 with SMTP id p8mr272762bkw.358.1313758568743; Fri, 19 Aug 2011 05:56:08 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id zy5sm1039079bkb.64.2011.08.19.05.56.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 05:56:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> Date: Fri, 19 Aug 2011 15:56:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> To: dime@ietf.org, Glen Zorn X-Mailer: Apple Mail (2.1084) Subject: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 19 Aug 2011 12:55:13 -0000 On Apr 29, 2011, at 9:47 AM, dime issue tracker wrote: > #20: no accounting model specified >=20 > RFC 3588bis says in Section 9.3 that >=20 > Applications have the option of using one or both of the following > accounting application extension models: >=20 > Split Accounting Service >=20 > The accounting message will carry the Application Id of the > Diameter base accounting application (see Section 2.4). > Accounting messages maybe routed to Diameter nodes other than = the > corresponding Diameter application. These nodes might be > centralized accounting servers that provide accounting service = for > multiple different Diameter applications. These nodes MUST > advertise the Diameter base accounting Application Id during > capabilities exchange. >=20 >=20 > Coupled Accounting Service >=20 > The accounting messages will carry the Application Id of the > application that is using it. The application itself will = process > the received accounting records or forward them to an accounting > server. There is no accounting application advertisement = required > during capabilities exchange and the accounting messages will be > routed the same as any of the other application messages. >=20 > However, RFC 4005 uses neither of these models, specifying that >=20 > Diameter applications conforming to this specification MUST advertise > support by including the value of one (1) in the = Auth-Application-Id > of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and = AA- > Answer (AAA) messages. All other messages use the Base application > id value [I-D.ietf-dime-rfc3588bis]. >=20 > This seems incorrect. Hmm.. how? RFC4005(bis) text to me refers to the split service.. NASREQ = App-Id is used for AAR/AAA and base accounting for the rest = (ACR/ACA...). - JOuni >=20 > --=20 > = --------------------------------+-----------------------------------------= -- > Reporter: gwz@=85 | Owner: =20 > Type: defect | Status: new > Priority: major | Milestone: =20 > Component: rfc4005bis | Version: =20 > Severity: Active WG Document | Keywords: =20 > = --------------------------------+-----------------------------------------= -- >=20 > Ticket URL: > dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Fri Aug 19 08:07:22 2011 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 4C06B21F86AA for ; Fri, 19 Aug 2011 08:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 dEzbT6SMYGdr for ; Fri, 19 Aug 2011 08:07:20 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8AC21F863E for ; Fri, 19 Aug 2011 08:07:20 -0700 (PDT) Received: by bkar4 with SMTP id r4so2742573bka.31 for ; Fri, 19 Aug 2011 08:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=vuDsKLY9ZXZXPdlnrMh2OMLA1ATZysDcV3/Q+zCiqXU=; b=j9SRH/ammOUh0Bi4s89NMcDPwsSrKJY1qWAPhhUWecGXMa2ZIliG2m3XqGT66VjueE /5AUNlamspD/QgPl5MTbEvZEeKp6eCz3haG/giZnbxZguVCivZ8NK2D4giU59RTogxAK vXYoDiS1tsosO85tI1ynbrTbsVH5oTF0brX1M= Received: by 10.204.6.198 with SMTP id a6mr382323bka.329.1313766496956; Fri, 19 Aug 2011 08:08:16 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id q15sm71072bke.4.2011.08.19.08.08.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 08:08:16 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Aug 2011 18:08:13 +0300 Message-Id: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] pre-revision of RFC3588bis-27 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, 19 Aug 2011 15:07:22 -0000 Folks, Finally got my lazy *ss up and did a revision -27. Actually now that the = S-NAPTR registry thing has stabilized it made sense to complete = RFC3588bis. The intermediate version can be found here: http://dimowine.neonsite.net/draft-ietf-dime-rfc3588bis-27.txt Following things were added/changed since -26: 0) note on Idnits: * 2 warnings on non-RFC2606-compliant FQDNs are bogus * 2 warnings on missing references are bogus * don't know the issue about boilerplate.. anyone? 1) Added text to Abstract that this document obsoleted RFC 3588 -> = pleases Idnits 2) Section 1.1.3. * s/E2ESequence/E2E-Sequence * see http://www.ietf.org/mail-archive/web/dime/current/msg04671.html 3) Section 1.2 * rewording Diameter Peer definition * removed the Transport definition * see http://www.ietf.org/mail-archive/web/dime/current/msg04805.html 4) Section 1.2 * reworded Redirect agent definition a bit * see http://www.ietf.org/mail-archive/web/dime/current/msg04810.html 5) Section 1.3.4 * added a new situation when a new application id is needed i.e. if new AVP flag bits get added * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html 6) Section 4.1 * clarified the handling of AVP flag bits * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html 7) Section 5.3.3 * clarification on Vendor-Id AVP * see http://www.ietf.org/mail-archive/web/dime/current/msg04741.html 8) Sections 7.1.3 and 7.1.5 * Result-Code numbering is now back to RFC3588 numbers.. * I did not add any notes on redundancies: o DIAMETER_INVALID_BIT_IN_HEADER vs. DIAMETER_INVALID_HDR_BITS o DIAMETER_INVALID_AVP_BIT_COMBO vs. DIAMETER_INVALID_AVP_BITS =20 There is a difference between 3xxx vs. 5xxx errors. And I think it is good to have this distinction here. * see http://www.ietf.org/mail-archive/web/dime/current/msg04616.html 9) Section 11 * IANA considerations only contains those things that get changed from RFC3588 or are new to RFC3588bis. Also some other things changed there. * added experimental use range to align with RFC5719 * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html * I kept this stuff here as the command code allocation was updated by RFC5719.. and thus not in RFC3588 10) Section 11.5 * notes to RFC-Editor added regarding S-NAPTR registries.. 11) Appendix B * corrected examples to more FC2606-complian =20 Right.. did I miss something? (except for the deadline a couple of = times..) - JOuni From glenzorn@gmail.com Sat Aug 20 01:46:22 2011 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 E0F9B21F8B3B for ; Sat, 20 Aug 2011 01:46:22 -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 Mlb+ZnOlhgLD for ; Sat, 20 Aug 2011 01:46:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5957821F8B29 for ; Sat, 20 Aug 2011 01:46:22 -0700 (PDT) Received: by ywm21 with SMTP id 21so2885331ywm.31 for ; Sat, 20 Aug 2011 01:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SjXXJjgObfgk3MSW5KDm5CBOjpoPadRhskXJ7ffqyTY=; b=gGmGX6vu8BM+dqz53yrT0Ri5Tlax3eCJg0ZzSe04EyJGmzCqlEK3AZyncFeo9Tyv4R iwInQ7oPVSWztbYzGM2zvF6MVNhNtewzG3LVvpk9vTkRubg4obDD87Y9fpL3ohlKDBrP Txm8vVOfVvURcBnrEUYEd5tOXjkZmo2YjQ2TM= Received: by 10.236.180.38 with SMTP id i26mr1746001yhm.7.1313830041201; Sat, 20 Aug 2011 01:47:21 -0700 (PDT) Received: from [192.168.1.98] (ppp-58-11-129-193.revip2.asianet.co.th [58.11.129.193]) by mx.google.com with ESMTPS id f4sm2365977yhn.83.2011.08.20.01.47.18 (version=SSLv3 cipher=OTHER); Sat, 20 Aug 2011 01:47:20 -0700 (PDT) Message-ID: <4E4F7491.5030709@gmail.com> Date: Sat, 20 Aug 2011 15:47:13 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> In-Reply-To: <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 20 Aug 2011 08:46:23 -0000 On 8/19/2011 7:56 PM, jouni korhonen wrote: > > On Apr 29, 2011, at 9:47 AM, dime issue tracker wrote: > >> #20: no accounting model specified >> >> RFC 3588bis says in Section 9.3 that >> >> Applications have the option of using one or both of the following >> accounting application extension models: >> >> Split Accounting Service >> >> The accounting message will carry the Application Id of the >> Diameter base accounting application (see Section 2.4). >> Accounting messages maybe routed to Diameter nodes other than the >> corresponding Diameter application. These nodes might be >> centralized accounting servers that provide accounting service for >> multiple different Diameter applications. These nodes MUST >> advertise the Diameter base accounting Application Id during >> capabilities exchange. >> >> >> Coupled Accounting Service >> >> The accounting messages will carry the Application Id of the >> application that is using it. The application itself will process >> the received accounting records or forward them to an accounting >> server. There is no accounting application advertisement required >> during capabilities exchange and the accounting messages will be >> routed the same as any of the other application messages. >> >> However, RFC 4005 uses neither of these models, specifying that >> >> Diameter applications conforming to this specification MUST advertise >> support by including the value of one (1) in the Auth-Application-Id >> of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and AA- >> Answer (AAA) messages. All other messages use the Base application >> id value [I-D.ietf-dime-rfc3588bis]. >> >> This seems incorrect. > > > Hmm.. how? RFC4005(bis) text to me refers to the split service.. NASREQ App-Id is used for AAR/AAA and base accounting for the rest (ACR/ACA...). No, 4005 does not say "the Diameter Base Accounting ID", it says "the Base application id"; they are different things. Actually, it would be inappropriate to use the base accounting ID for the rest, since the rest includes the STR/STA & ASR/ASA messages, which are not accounting messages. ... From jouni.nospam@gmail.com Sat Aug 20 11:48:38 2011 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 CB75D21F8591 for ; Sat, 20 Aug 2011 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Q60zCJkpuhsJ for ; Sat, 20 Aug 2011 11:48:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0119521F856B for ; Sat, 20 Aug 2011 11:48:37 -0700 (PDT) Received: by bkar4 with SMTP id r4so3468740bka.31 for ; Sat, 20 Aug 2011 11:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=V5fOcuLusGVS1b/InAOzcvThuAIG0QhW7TRfpMUO05k=; b=jFTuXPHcWw59MXlCkoGn7WaWTEzu2O3X83OK1cVBBPa0Q8y/MXjuuF9KnhzGTB76+u 4w9lqqkd+vo0RMoWEwQA0jcbB8ngXFarbss5de7YpUzbjmh37yKGo3djxTHEl073+1NO +P46FHYgeSGccUK1u5aNixJ7jcMB7UV2Kg5Es= Received: by 10.204.140.88 with SMTP id h24mr255336bku.170.1313866175116; Sat, 20 Aug 2011 11:49:35 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id z6sm1394598bks.57.2011.08.20.11.49.33 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Aug 2011 11:49:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E4F7491.5030709@gmail.com> Date: Sat, 20 Aug 2011 21:49:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA18178-E97F-4928-AC56-A83DAC8AA5E3@gmail.com> References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> <4E4F7491.5030709@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 20 Aug 2011 18:48:38 -0000 On Aug 20, 2011, at 11:47 AM, Glen Zorn wrote: [clip] >>>=20 >>> However, RFC 4005 uses neither of these models, specifying that >>>=20 >>> Diameter applications conforming to this specification MUST = advertise >>> support by including the value of one (1) in the = Auth-Application-Id >>> of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and = AA- >>> Answer (AAA) messages. All other messages use the Base = application >>> id value [I-D.ietf-dime-rfc3588bis]. >>>=20 >>> This seems incorrect. >>=20 >>=20 >> Hmm.. how? RFC4005(bis) text to me refers to the split service.. = NASREQ App-Id is used for AAR/AAA and base accounting for the rest > (ACR/ACA...). >=20 > No, 4005 does not say "the Diameter Base Accounting ID", it says "the > Base application id"; they are different things. Actually, it would = be Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA and = not base acct id? > inappropriate to use the base accounting ID for the rest, since the = rest > includes the STR/STA & ASR/ASA messages, which are not accounting = messages. Righty. > ... .... From glenzorn@gmail.com Sun Aug 21 01:23:09 2011 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 F046921F87FC for ; Sun, 21 Aug 2011 01:23:08 -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 uBNlO2mZ3GMw for ; Sun, 21 Aug 2011 01:23:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0121F87C5 for ; Sun, 21 Aug 2011 01:23:03 -0700 (PDT) Received: by gyf3 with SMTP id 3so3636553gyf.31 for ; Sun, 21 Aug 2011 01:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=W+I3unvScuQHfthxV5UNlmnjfBFIZ0496K+5drNGqp0=; b=wo8tcaW+4c9pkH/11F3rd23/tNJVklkpiIEt41MzbK9wBggtKNrM6i34VssQzlFLfc GUYo4wT4QwIlcpu1ubs1FIW16k8r3RR8D+AX8wZzTjvYGqWqccZ8HZC88zoRfUv91Mzx OidfdLPtFDH3e7jG9itPvzzFnc2N8lojcM/5Q= Received: by 10.150.206.9 with SMTP id d9mr1038962ybg.427.1313915044744; Sun, 21 Aug 2011 01:24:04 -0700 (PDT) Received: from [192.168.1.98] (ppp-171-96-13-227.revip8.asianet.co.th [171.96.13.227]) by mx.google.com with ESMTPS id s13sm4178425anm.32.2011.08.21.01.24.01 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 01:24:03 -0700 (PDT) Message-ID: <4E50C09F.7000305@gmail.com> Date: Sun, 21 Aug 2011 15:23:59 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <005e01cb9870$3ab83160$b0289420$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, Glen Zorn Subject: Re: [Dime] rfc3588bis next revision; was Re: Error in RFC 3588bis? 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, 21 Aug 2011 08:23:09 -0000 On 8/19/2011 6:39 PM, jouni korhonen wrote: > > Would the following be OK i.e. referring to relays instead of proxies? > > ... > acting as relay or proxy agents for other types. As with relay > agents, redirect agents do not keep state with respect to sessions > or NAS resources. OK w/me. ... From glenzorn@gmail.com Sun Aug 21 01:43:02 2011 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 EB7F721F8A55 for ; Sun, 21 Aug 2011 01:43:01 -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 JlEeOpxVq-tX for ; Sun, 21 Aug 2011 01:43:01 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B69621F8A23 for ; Sun, 21 Aug 2011 01:43:01 -0700 (PDT) Received: by gwb20 with SMTP id 20so3004640gwb.31 for ; Sun, 21 Aug 2011 01:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=a4Yqi0Ut6YIOSvTD9+f+2kWMR4Srz9flRE70niC2C5g=; b=vBd1pd5T+egbQgbMxXcJ+BLldfhqlyi++WG06ljjujyxogWoJ1pjX9e0Kf8NTuP2jI G/ZBO1za/lrzCNpXsvFEYNLw7bvSa65inPAVJ3M7Rs/D/K+rEgG3zR5mlWuv4BQBya+s 7WpSkTAZ7l7C2mKZecwDA9B+Sg7eU1KpR9/wo= Received: by 10.90.159.20 with SMTP id h20mr1096587age.8.1313916242745; Sun, 21 Aug 2011 01:44:02 -0700 (PDT) Received: from [192.168.1.98] (ppp-171-96-13-227.revip8.asianet.co.th [171.96.13.227]) by mx.google.com with ESMTPS id n14sm4192161ani.38.2011.08.21.01.44.00 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 01:44:02 -0700 (PDT) Message-ID: <4E50C54E.4030401@gmail.com> Date: Sun, 21 Aug 2011 15:43:58 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> <4E4F7491.5030709@gmail.com> <1DA18178-E97F-4928-AC56-A83DAC8AA5E3@gmail.com> In-Reply-To: <1DA18178-E97F-4928-AC56-A83DAC8AA5E3@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 21 Aug 2011 08:43:02 -0000 On 8/21/2011 1:49 AM, jouni korhonen wrote: ... >>>> However, RFC 4005 uses neither of these models, specifying that >>>> >>>> Diameter applications conforming to this specification MUST advertise >>>> support by including the value of one (1) in the Auth-Application-Id >>>> of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and AA- >>>> Answer (AAA) messages. All other messages use the Base application >>>> id value [I-D.ietf-dime-rfc3588bis]. >>>> >>>> This seems incorrect. >>> >>> >>> Hmm.. how? RFC4005(bis) text to me refers to the split service.. NASREQ App-Id is used for AAR/AAA and base accounting for the rest >> (ACR/ACA...). >> >> No, 4005 does not say "the Diameter Base Accounting ID", it says "the >> Base application id"; they are different things. Actually, it would be > > Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA and not base acct id? I think that it is an error in 4005. Actually, I find it hard to believe that NASREQ would ever work except in a monolithic, "toy" implementation. For example, the NASREQ version of the ASR/ASA messages includes a bunch of optional AVPs (with the 'M' bit set) that are undefined in RFC 3588 to the base protocol server; it's hard to imagine how a standard implementation of 3588 could not treat the reception of such AVPs as an error. ... From glenzorn@gmail.com Sun Aug 21 02:28:36 2011 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 AA72B21F8AB0 for ; Sun, 21 Aug 2011 02:28: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 fUTKNs7AZnAX for ; Sun, 21 Aug 2011 02:28:35 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 351E321F8AAA for ; Sun, 21 Aug 2011 02:28:35 -0700 (PDT) Received: by gxk19 with SMTP id 19so3657020gxk.31 for ; Sun, 21 Aug 2011 02:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fIfkwitnGCLI+QFDteKyRmU+ZQRNAY4uwQehBh6z4Iw=; b=LLkWyZ4S4+09SV4Ot+eu0DT73+NVzhYN08/3vcx4CNoEA5jYXMrsCEmDCGHUsZw9fu ltmKTwZk9Hka70VjLeI3Mq/73Ym/OZmcUDufyrLapMJQZJdDFdf0qw/1RImmiSakAzL9 uXSSHGYUKDSJa5wa6HAWSHjhQ3xMvq6rW6ed8= Received: by 10.100.211.5 with SMTP id j5mr1074115ang.162.1313918975085; Sun, 21 Aug 2011 02:29:35 -0700 (PDT) Received: from [192.168.1.98] (ppp-171-96-13-227.revip8.asianet.co.th [171.96.13.227]) by mx.google.com with ESMTPS id h15sm4220113ank.39.2011.08.21.02.29.30 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 02:29:34 -0700 (PDT) Message-ID: <4E50CFF6.1070103@gmail.com> Date: Sun, 21 Aug 2011 16:29:26 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> In-Reply-To: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 21 Aug 2011 09:28:36 -0000 On 8/19/2011 10:08 PM, jouni korhonen wrote: > Folks, > > Finally got my lazy *ss up and did a revision -27. Actually now that the S-NAPTR registry thing has stabilized it made sense to complete RFC3588bis. The intermediate version can be found here: > http://dimowine.neonsite.net/draft-ietf-dime-rfc3588bis-27.txt > > Following things were added/changed since -26: > > 0) note on Idnits: > * 2 warnings on non-RFC2606-compliant FQDNs are bogus > * 2 warnings on missing references are bogus > * don't know the issue about boilerplate.. anyone? No a lawyer, but it might not be a bad idea to change it. ... From jouni.nospam@gmail.com Sun Aug 21 08:25:37 2011 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 2D0EC21F87F0 for ; Sun, 21 Aug 2011 08:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 djZVAetXa8ji for ; Sun, 21 Aug 2011 08:25:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A56821F8785 for ; Sun, 21 Aug 2011 08:25:36 -0700 (PDT) Received: by bkar4 with SMTP id r4so3856412bka.31 for ; Sun, 21 Aug 2011 08:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uvr8zVTqKwNM6C4mAzB51FE9eGMGRjrKWYLg0CEWJEw=; b=sBq3VlwHYo45fEB5QxiyYKmx8ifsCPyH2n7akRixTnWXx6gb67wLTXoXsedKwHiV2W kNoYMWSO/dpTvZ9zdvmbvvZn9SosTfbHO1kSsWvgniVY2jSK33JYlsR+FVRvC5DRBRNy /KJ3Iuszzb3tzc5OwDhIDI9MuAwESoUWnBZDc= Received: by 10.204.152.216 with SMTP id h24mr505994bkw.42.1313940395944; Sun, 21 Aug 2011 08:26:35 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id o20sm1366848bku.43.2011.08.21.08.26.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 08:26:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E50C09F.7000305@gmail.com> Date: Sun, 21 Aug 2011 18:26:33 +0300 Content-Transfer-Encoding: 7bit Message-Id: <7DD5F20A-98C8-40AB-9119-A36E290F4F61@gmail.com> References: <005e01cb9870$3ab83160$b0289420$@net> <4E50C09F.7000305@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org, Glen Zorn Subject: Re: [Dime] rfc3588bis next revision; was Re: Error in RFC 3588bis? 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, 21 Aug 2011 15:25:37 -0000 Ok good. - Jouni On Aug 21, 2011, at 11:23 AM, Glen Zorn wrote: > On 8/19/2011 6:39 PM, jouni korhonen wrote: > >> >> Would the following be OK i.e. referring to relays instead of proxies? >> >> ... >> acting as relay or proxy agents for other types. As with relay >> agents, redirect agents do not keep state with respect to sessions >> or NAS resources. > > OK w/me. > > ... From jouni.nospam@gmail.com Sun Aug 21 08:27:36 2011 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 A9A7D21F8A4E for ; Sun, 21 Aug 2011 08:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 kuLxulqwZYpe for ; Sun, 21 Aug 2011 08:27:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E430A21F89CC for ; Sun, 21 Aug 2011 08:27:35 -0700 (PDT) Received: by bkar4 with SMTP id r4so3857179bka.31 for ; Sun, 21 Aug 2011 08:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ytCr5Sh95fu1j5KKAz9+Fapx5bUyg7JgmqWe5+L02ts=; b=Bq+yJZCOtCa5iEjziLoWp31UmoYuf4+F/Uw85KAzcjL81mHUgVnErGxlmYxGgkuaOY yYGhKQ2x64RG1fyTo/LIjA3iKgkjrdgoC8KJcoabkmmXrKLb2l6HcQIwFSggiDPCecqW nEW1NdxWt+nchcmPjGjfjT8Oz/4+hCqu/Psp4= Received: by 10.204.135.6 with SMTP id l6mr523380bkt.284.1313940517784; Sun, 21 Aug 2011 08:28:37 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id p12sm1633976bkp.1.2011.08.21.08.28.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 08:28:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E50C54E.4030401@gmail.com> Date: Sun, 21 Aug 2011 18:28:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9CAFBBC5-7F5A-4536-83EA-53EBF3A8AF9B@gmail.com> References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> <4E4F7491.5030709@gmail.com> <1DA18178-E97F-4928-AC56-A83DAC8AA5E3@gmail.com> <4E50C54E.4030401@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 21 Aug 2011 15:27:36 -0000 On Aug 21, 2011, at 11:43 AM, Glen Zorn wrote: > On 8/21/2011 1:49 AM, jouni korhonen wrote: >=20 > ... >=20 >>>>> However, RFC 4005 uses neither of these models, specifying that >>>>>=20 >>>>> Diameter applications conforming to this specification MUST = advertise >>>>> support by including the value of one (1) in the = Auth-Application-Id >>>>> of the Capabilities-Exchange-Request (CER), AA-Request (AAR), and = AA- >>>>> Answer (AAA) messages. All other messages use the Base = application >>>>> id value [I-D.ietf-dime-rfc3588bis]. >>>>>=20 >>>>> This seems incorrect. >>>>=20 >>>>=20 >>>> Hmm.. how? RFC4005(bis) text to me refers to the split service.. = NASREQ App-Id is used for AAR/AAA and base accounting for the rest >>> (ACR/ACA...). >>>=20 >>> No, 4005 does not say "the Diameter Base Accounting ID", it says = "the >>> Base application id"; they are different things. Actually, it would = be >>=20 >> Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA = and not base acct id? >=20 > I think that it is an error in 4005. Actually, I find it hard to > believe that NASREQ would ever work except in a monolithic, "toy" > implementation. For example, the NASREQ version of the ASR/ASA = messages > includes a bunch of optional AVPs (with the 'M' bit set) that are > undefined in RFC 3588 to the base protocol server; it's hard to = imagine > how a standard implementation of 3588 could not treat the reception of > such AVPs as an error. MAybe this is then good candidates to be fixed in 4005bis? Or do you = think it would make situation worse in real deployments from a backward = compatibility point of view? - Jouni >=20 > ... From glenzorn@gmail.com Sun Aug 21 08:46:43 2011 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 8369921F8A67 for ; Sun, 21 Aug 2011 08:46:43 -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 figPk08alOxK for ; Sun, 21 Aug 2011 08:46:43 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBA721F8804 for ; Sun, 21 Aug 2011 08:46:42 -0700 (PDT) Received: by yie12 with SMTP id 12so3774723yie.31 for ; Sun, 21 Aug 2011 08:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=H0lGaK2fC9S5r/8qeD+ZZNc9gWS7kMAz1x2TJL42Cd8=; b=CbPOEQKqsUp+8xREenWKU49e+E7XGaLbaxfwhgUkXNp6UUcUz31BgFyEOHJCPT9Mbf Qu0gHg2WQ9J002AHE+NOBT/MXkmhw9WiZb5lurXNOraswCj9+aCvJTW81Un0IFfzLlKv ZcWaqyVd7lnknZjfl/3vSM691taQEWDGKE4pA= Received: by 10.101.105.10 with SMTP id h10mr1331496anm.106.1313941665389; Sun, 21 Aug 2011 08:47:45 -0700 (PDT) Received: from [192.168.1.98] (ppp-171-96-13-227.revip8.asianet.co.th [171.96.13.227]) by mx.google.com with ESMTPS id h15sm4443600ank.39.2011.08.21.08.47.42 (version=SSLv3 cipher=OTHER); Sun, 21 Aug 2011 08:47:44 -0700 (PDT) Message-ID: <4E51289C.20401@gmail.com> Date: Sun, 21 Aug 2011 22:47:40 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> <4E4F7491.5030709@gmail.com> <1DA18178-E97F-4928-AC56-A83DAC8AA5E3@gmail.com> <4E50C54E.4030401@gmail.com> <9CAFBBC5-7F5A-4536-83EA-53EBF3A8AF9B@gmail.com> In-Reply-To: <9CAFBBC5-7F5A-4536-83EA-53EBF3A8AF9B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 21 Aug 2011 15:46:43 -0000 On 8/21/2011 10:28 PM, jouni korhonen wrote: ... >>> Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA and not base acct id? >> >> I think that it is an error in 4005. Actually, I find it hard to >> believe that NASREQ would ever work except in a monolithic, "toy" >> implementation. For example, the NASREQ version of the ASR/ASA messages >> includes a bunch of optional AVPs (with the 'M' bit set) that are >> undefined in RFC 3588 to the base protocol server; it's hard to imagine >> how a standard implementation of 3588 could not treat the reception of >> such AVPs as an error. > > MAybe this is then good candidates to be fixed in 4005bis? Or do you think it would make situation worse in real deployments from a backward compatibility point of view? I was under the impression that there are no real deployments; if there were, someone would certainly have noticed this, don't you think? ... From mark@azu.ca Mon Aug 22 00:50:28 2011 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 853EA21F84FA for ; Mon, 22 Aug 2011 00:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uydjegLSXt2s for ; Mon, 22 Aug 2011 00:50:28 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id E4E9821F84F5 for ; Mon, 22 Aug 2011 00:50:27 -0700 (PDT) Received: by iye1 with SMTP id 1so9225837iye.27 for ; Mon, 22 Aug 2011 00:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.2.195 with SMTP id 3mr5143142ibk.35.1313999490136; Mon, 22 Aug 2011 00:51:30 -0700 (PDT) Received: by 10.231.199.5 with HTTP; Mon, 22 Aug 2011 00:51:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 09:51:30 +0200 Message-ID: From: Mark Jones To: "dime@ietf.org" Content-Type: multipart/alternative; boundary=0015175773a8d83a4b04ab135820 Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 22 Aug 2011 07:50:28 -0000 --0015175773a8d83a4b04ab135820 Content-Type: text/plain; charset=ISO-8859-1 It looks like there are enough people willing to contribute to this work and no concerns except that it is not in the current charter. DIME chairs, please could you initiate the re-chartering process such that the new charter includes the following clause: " - Protocol extensions to optimize signaling when a Diameter peer needs to apply the same operation to large groups of sessions." Thanks Mark --0015175773a8d83a4b04ab135820 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It looks like there are enough people willing to contribute to this wo= rk and no concerns except that it is not in the current charter.=A0

DIME chairs, please could you initiate the re-chartering = process=A0such that the new charter includes the fo= llowing clause:
Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 22 Aug 2011 08:04:03 -0000 On 8/22/2011 2:51 PM, Mark Jones wrote: > It looks like there are enough people willing to contribute to this work > and no concerns except that it is not in the current charter. Actually, I wonder how often this need arises; if it is a rare occurrence, I question the need to modify Diameter to optimize for something that hardly ever happens... > > DIME chairs, please could you initiate the re-chartering process such > that the new charter includes the following clause: > > " - Protocol extensions to optimize signaling when a Diameter peer needs > to apply the same operation to large groups of sessions." Again, that's not enough. The current charter states that the purpose of the dime WG is to "focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility)." How does this fit in with "authentication, authorization, accounting and provisioning in network access"? BTW, if you're going to be adding a (non-AAA) wish list, I'd like to see state synchronization thrown in there, as well. > > Thanks > Mark > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Aug 22 01:31:07 2011 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 016C121F8A96 for ; Mon, 22 Aug 2011 01:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=0.980, 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 gcKsYG6Cn7+A for ; Mon, 22 Aug 2011 01:31:06 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0552E21F8548 for ; Mon, 22 Aug 2011 01:31:05 -0700 (PDT) Received: by gxk19 with SMTP id 19so4165981gxk.31 for ; Mon, 22 Aug 2011 01:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=b84oWS3sKtwkSPB5SXfjg5bTKJ1Tc5OY0/zUTSnYKTI=; b=yBtXUU6NnM/D5PDFNjhrY41pg9+XiVrFTwME/WjkdrIFu1XWYaN+GuuLqsvJTkBeu2 W0z+vjXsa7UWmYbY2DoPZTLYgHqc2Oo/DMQi7SUKDfFTg5Zy4JL0SLOdVH/X+0XG4HTh 5xmVmjNxLkV0PglxtnFbKMb/u2JaRdMOHOHxY= Received: by 10.236.78.196 with SMTP id g44mr10910158yhe.43.1314001930152; Mon, 22 Aug 2011 01:32:10 -0700 (PDT) Received: from [10.255.135.36] ([192.100.123.77]) by mx.google.com with ESMTPS id s62sm7296725yhn.61.2011.08.22.01.32.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 01:32:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E520DAD.7050402@gmail.com> Date: Mon, 22 Aug 2011 11:32:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <681ECBF0-7411-453A-BA0B-965EF09EA516@gmail.com> References: <4E520DAD.7050402@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 22 Aug 2011 08:31:07 -0000 On Aug 22, 2011, at 11:05 AM, Glen Zorn wrote: > On 8/22/2011 2:51 PM, Mark Jones wrote: >> It looks like there are enough people willing to contribute to this = work >> and no concerns except that it is not in the current charter.=20 >=20 > Actually, I wonder how often this need arises; if it is a rare > occurrence, I question the need to modify Diameter to optimize for > something that hardly ever happens... >=20 >>=20 >> DIME chairs, please could you initiate the re-chartering process such >> that the new charter includes the following clause: >>=20 >> " - Protocol extensions to optimize signaling when a Diameter peer = needs >> to apply the same operation to large groups of sessions." >=20 > Again, that's not enough. The current charter states that the purpose > of the dime WG is to "focus on maintenance and extensions to the > Diameter protocol required to enable its use for authentication, > authorization, accounting and provisioning in network access as well = as > for other applications environments (e.g., IP telephony, mobility)." > How does this fit in with "authentication, authorization, accounting = and > provisioning in network access"? BTW, if you're going to be adding a > (non-AAA) wish list, I'd like to see state synchronization thrown in > there, as well. We (chairs) took a task to propose an update of the charter text. Once = we got the first version of the text to the list, we can start looking = in more detail what actually goes in. - Jouni & Lionel >=20 >>=20 >> Thanks >> Mark >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From mark@azu.ca Mon Aug 22 01:47:21 2011 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 2416E21F8AE6 for ; Mon, 22 Aug 2011 01:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ltoXvG42aoi7 for ; Mon, 22 Aug 2011 01:47:20 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5296221F8AD8 for ; Mon, 22 Aug 2011 01:47:20 -0700 (PDT) Received: by iye1 with SMTP id 1so9293106iye.27 for ; Mon, 22 Aug 2011 01:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.45.129 with SMTP id e1mr5305950ibf.22.1314002904460; Mon, 22 Aug 2011 01:48:24 -0700 (PDT) Received: by 10.231.199.5 with HTTP; Mon, 22 Aug 2011 01:48:24 -0700 (PDT) In-Reply-To: <4E520DAD.7050402@gmail.com> References: <4E520DAD.7050402@gmail.com> Date: Mon, 22 Aug 2011 10:48:24 +0200 Message-ID: From: Mark Jones To: Glen Zorn Content-Type: multipart/alternative; boundary=0015176f1bbc5aae1804ab142449 Cc: "dime@ietf.org" Subject: Re: [Dime] Bulk Session Signaling in Diameter 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, 22 Aug 2011 08:47:21 -0000 --0015176f1bbc5aae1804ab142449 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 22, 2011 at 10:05 AM, Glen Zorn wrote: > On 8/22/2011 2:51 PM, Mark Jones wrote: > > It looks like there are enough people willing to contribute to this work > > and no concerns except that it is not in the current charter. > > Actually, I wonder how often this need arises; if it is a rare > occurrence, I question the need to modify Diameter to optimize for > something that hardly ever happens... > > Other SDOs have identified problems that they are solving or will solve using some form of bulk signaling in Diameter (see Marco's deck from IETF81). I don't want to solve their particular problems in DIME but there is enough commonality in their requirements that we should be able to define the bulk signalling solution once in DIME. > > > > DIME chairs, please could you initiate the re-chartering process such > > that the new charter includes the following clause: > > > > " - Protocol extensions to optimize signaling when a Diameter peer needs > > to apply the same operation to large groups of sessions." > > Again, that's not enough. The current charter states that the purpose > of the dime WG is to "focus on maintenance and extensions to the > Diameter protocol required to enable its use for authentication, > authorization, accounting and provisioning in network access as well as > for other applications environments (e.g., IP telephony, mobility)." How does this fit in with "authentication, authorization, accounting and > provisioning in network access"? It is an extension to the Diameter protocol to enable bulk operations against the sessions created during "authentication, authorization, accounting and provisioning in network access". > BTW, if you're going to be adding a > (non-AAA) wish list, I'd like to see state synchronization thrown in > there, as well. > > This was in Marco's deck as one of the motivations for having bulk signaling operations. Regards Mark > > > > Thanks > > Mark > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > --0015176f1bbc5aae1804ab142449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 10:05 AM, Glen Zorn <glenzorn@gmail.com> wrote:
=
On 8/22/2011 2:51 PM, Mark Jones wrote:
> It looks like there are enough people willing to contribute to this wo= rk
> and no concerns except that it is not in the current charter.

Actually, I wonder how often this need arises; if it is a rare
occurrence, I question the need to modify Diameter to optimize for
something that hardly ever happens...


Other SDOs hav= e identified problems that they are solving or will solve using some form o= f bulk signaling in Diameter (see Marco's deck from IETF81). I don'= t want to solve their particular problems in DIME but there is enough commo= nality in their requirements that we=A0should=A0be able to define the bulk = signalling solution once in DIME.
=A0
>
> DIME chairs, please could you initiate the re-chartering process such<= br> > that the new charter includes the following clause:
>
> " - Protocol extensions to optimize signaling when a Diameter pee= r needs
> to apply the same operation to large groups of sessions."

Again, that's not enough. =A0The current charter states that the = purpose
of the dime WG is to "focus on maintenance and extensions to the
Diameter protocol required to enable its use for authentication,
authorization, accounting and provisioning in network access as well as
for other applications environments (e.g., IP telephony, mobility)."
How does this fit in with "authentication, authorization, accounting a= nd
provisioning in network access"? =A0

I= t is an extension to the Diameter protocol to enable bulk operations agains= t the sessions created during=A0"authentication, authorization, accoun= ting and=A0provisioning in network access".
=A0
BTW, if you're going to b= e adding a
(non-AAA) wish list, I'd like to see state synchronization thrown in there, as well.


This was in Marco's deck as one of the motivations for having b= ulk signaling operations.

Regards
Mark
=A0
>
> Thanks
> Mark
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--0015176f1bbc5aae1804ab142449-- From jouni.nospam@gmail.com Mon Aug 22 04:57:04 2011 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 B325C21F8B09 for ; Mon, 22 Aug 2011 04:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.735, 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 F19NIZzXx9Fh for ; Mon, 22 Aug 2011 04:57:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3275C21F8A6F for ; Mon, 22 Aug 2011 04:57:04 -0700 (PDT) Received: by ywe9 with SMTP id 9so327916ywe.31 for ; Mon, 22 Aug 2011 04:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=oCBbe18XfGkZslvwN0V6CZvHhBPuzlY8zyR/oeAMRWg=; b=mydHXFgF/OB4EgmUy45q4kRjJflvsQhQQmDDKH9hoVjiPAMfaDxe/zJawaDHwrFmk2 Kg+Z4U4Vc9RNcWgHUKnIY2rlAO8IGw9YWMMsYk/9YY27MWt/pVxeiuF1hEm1ZBP6ooTb mm/1rqQCk0iaaTUI8K/+OBeaoiM/2tvUBHXx8= Received: by 10.150.72.22 with SMTP id u22mr2394833yba.254.1314014099129; Mon, 22 Aug 2011 04:54:59 -0700 (PDT) Received: from [10.255.135.36] ([192.100.123.77]) by mx.google.com with ESMTPS id o2sm697048yhl.57.2011.08.22.04.54.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 04:54:58 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 14:54:52 +0300 Message-Id: <41312C39-24FE-457F-A4C1-7A19C5076F29@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Late change to draft-ietf-dime-extended-naptr-09.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: Mon, 22 Aug 2011 11:57:04 -0000 Folks, draft-ietf-dime-extended-naptr-09, which is now in RFC Editor's queue, = has a normative reference to draft-ietf-tsvwg-iana-ports, which the = authors think is unnecessary. It should be informative as it is there = only for a background information purposes. Another point is that = draft-ietf-tsvwg-iana-ports is likely to block the document progress for = unknown time (could be a matter of days or then a whole lot more). The = possible change to the document would be handled by the RFC Editor = (accompanied with an appropriate note in the final document, if needed). So, is the working group OK if the reference to = draft-ietf-tsvwg-iana-ports is changed from normative to informative. If = you have concerns, express them by Thursday this week. Silence is = counted as "no concerns". - Jouni= From jouni.nospam@gmail.com Mon Aug 22 05:08:49 2011 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 CFF0321F8B30 for ; Mon, 22 Aug 2011 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 A+55n4Skqb3V for ; Mon, 22 Aug 2011 05:08:48 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5381521F8B29 for ; Mon, 22 Aug 2011 05:08:48 -0700 (PDT) Received: by gxk19 with SMTP id 19so4286784gxk.31 for ; Mon, 22 Aug 2011 05:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Jx2V6H+eUJPtHVz9o3D/Yl5oDCdUlbiMAZ73+t6hhUw=; b=DeZN6HXqtqKxN7Jcym6+1xZ3DJYlV9wD5zDt8tpPeGxXJu2z81tdQaourbjfzyDCz0 DBoJ5SigaxLRVDU5pYtNVZj/G7iTh0ru39PP2MiN5M1v6ztf5zfUK7CRXhnR2jJ0xW9k C4J2SyT0B1t21Av9JfxJPstgKYXI9DB8X4OSw= Received: by 10.146.30.22 with SMTP id d22mr2212087yad.32.1314014991397; Mon, 22 Aug 2011 05:09:51 -0700 (PDT) Received: from [10.255.135.36] ([192.100.123.77]) by mx.google.com with ESMTPS id q25sm5032995yhm.20.2011.08.22.05.09.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 05:09:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> Date: Mon, 22 Aug 2011 15:09:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 22 Aug 2011 12:08:49 -0000 One thing I missed in -27 is the clarification regarding SCTP PPID = (thanks for Victor for pointing this out). See=20 http://www.ietf.org/mail-archive/web/dime/current/msg04550.html It was proposed to have two PPIDs, one for plain SCTP and and for SCTP = with DTLS. However, just having "MUST be 0" for both PPIDs could also be = an alternative.. Any views? - Jouni On Aug 19, 2011, at 6:08 PM, jouni korhonen wrote: > Folks, >=20 > Finally got my lazy *ss up and did a revision -27. Actually now that = the S-NAPTR registry thing has stabilized it made sense to complete = RFC3588bis. The intermediate version can be found here: > http://dimowine.neonsite.net/draft-ietf-dime-rfc3588bis-27.txt >=20 > Following things were added/changed since -26: >=20 > 0) note on Idnits: > * 2 warnings on non-RFC2606-compliant FQDNs are bogus > * 2 warnings on missing references are bogus > * don't know the issue about boilerplate.. anyone? >=20 > 1) Added text to Abstract that this document obsoleted RFC 3588 -> = pleases Idnits >=20 > 2) Section 1.1.3. > * s/E2ESequence/E2E-Sequence > * see http://www.ietf.org/mail-archive/web/dime/current/msg04671.html >=20 > 3) Section 1.2 > * rewording Diameter Peer definition > * removed the Transport definition > * see http://www.ietf.org/mail-archive/web/dime/current/msg04805.html >=20 > 4) Section 1.2 > * reworded Redirect agent definition a bit > * see http://www.ietf.org/mail-archive/web/dime/current/msg04810.html >=20 > 5) Section 1.3.4 > * added a new situation when a new application id is needed i.e. if > new AVP flag bits get added > * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html >=20 > 6) Section 4.1 > * clarified the handling of AVP flag bits > * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html >=20 > 7) Section 5.3.3 > * clarification on Vendor-Id AVP > * see http://www.ietf.org/mail-archive/web/dime/current/msg04741.html >=20 > 8) Sections 7.1.3 and 7.1.5 > * Result-Code numbering is now back to RFC3588 numbers.. > * I did not add any notes on redundancies: > o DIAMETER_INVALID_BIT_IN_HEADER vs. DIAMETER_INVALID_HDR_BITS > o DIAMETER_INVALID_AVP_BIT_COMBO vs. DIAMETER_INVALID_AVP_BITS >=20 > There is a difference between 3xxx vs. 5xxx errors. And > I think it is good to have this distinction here. >=20 > * see http://www.ietf.org/mail-archive/web/dime/current/msg04616.html >=20 > 9) Section 11 > * IANA considerations only contains those things that get changed > from RFC3588 or are new to RFC3588bis. Also some other things > changed there. > * added experimental use range to align with RFC5719 > * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html >=20 > * I kept this stuff here as the command code allocation was updated > by RFC5719.. and thus not in RFC3588 >=20 > 10) Section 11.5 > * notes to RFC-Editor added regarding S-NAPTR registries.. >=20 > 11) Appendix B > * corrected examples to more FC2606-complian >=20 >=20 > Right.. did I miss something? (except for the deadline a couple of = times..) >=20 >=20 > - JOuni >=20 >=20 >=20 From dromasca@avaya.com Mon Aug 22 05:25:58 2011 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 A010E21F8B4A for ; Mon, 22 Aug 2011 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.329, 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 YHByv71Nytol for ; Mon, 22 Aug 2011 05:25:58 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D98ED21F8B48 for ; Mon, 22 Aug 2011 05:25:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAAlKUk7GmAcF/2dsb2JhbABBmDCPWneBQAEBAQEDAQEBDxUJCjQXBAIBCA0EBAEBAQoGDAsBBgEmHwkIAQEEARIIARmHU5lbAptChWlfBJg+i08 X-IronPort-AV: E=Sophos;i="4.68,262,1312171200"; d="scan'208";a="203235900" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Aug 2011 08:27:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Aug 2011 08:23:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 14:26:59 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] pre-revision of RFC3588bis-27 Thread-Index: AcxgxKAaCqK2doroTHOQuTVK6mWtjAAAfekQ References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 22 Aug 2011 12:25:58 -0000 Hi Jouni, When can we see draft-27 submitted? Just now the I-D is in state 'Dead' because it was left to expire.=20 Thanks and Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > jouni korhonen > Sent: Monday, August 22, 2011 3:10 PM > To: dime@ietf.org > Subject: Re: [Dime] pre-revision of RFC3588bis-27 >=20 >=20 > One thing I missed in -27 is the clarification regarding SCTP PPID > (thanks for Victor for pointing this out). See > http://www.ietf.org/mail-archive/web/dime/current/msg04550.html >=20 > It was proposed to have two PPIDs, one for plain SCTP and and for SCTP > with DTLS. However, just having "MUST be 0" for both PPIDs could also > be an alternative.. Any views? >=20 > - Jouni >=20 >=20 > On Aug 19, 2011, at 6:08 PM, jouni korhonen wrote: >=20 > > Folks, > > > > Finally got my lazy *ss up and did a revision -27. Actually now that > the S-NAPTR registry thing has stabilized it made sense to complete > RFC3588bis. The intermediate version can be found here: > > http://dimowine.neonsite.net/draft-ietf-dime-rfc3588bis-27.txt > > > > Following things were added/changed since -26: > > > > 0) note on Idnits: > > * 2 warnings on non-RFC2606-compliant FQDNs are bogus > > * 2 warnings on missing references are bogus > > * don't know the issue about boilerplate.. anyone? > > > > 1) Added text to Abstract that this document obsoleted RFC 3588 -> > pleases Idnits > > > > 2) Section 1.1.3. > > * s/E2ESequence/E2E-Sequence > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04671.html > > > > 3) Section 1.2 > > * rewording Diameter Peer definition > > * removed the Transport definition > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04805.html > > > > 4) Section 1.2 > > * reworded Redirect agent definition a bit > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04810.html > > > > 5) Section 1.3.4 > > * added a new situation when a new application id is needed i.e. if > > new AVP flag bits get added > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html > > > > 6) Section 4.1 > > * clarified the handling of AVP flag bits > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04808.html > > > > 7) Section 5.3.3 > > * clarification on Vendor-Id AVP > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04741.html > > > > 8) Sections 7.1.3 and 7.1.5 > > * Result-Code numbering is now back to RFC3588 numbers.. > > * I did not add any notes on redundancies: > > o DIAMETER_INVALID_BIT_IN_HEADER vs. DIAMETER_INVALID_HDR_BITS > > o DIAMETER_INVALID_AVP_BIT_COMBO vs. DIAMETER_INVALID_AVP_BITS > > > > There is a difference between 3xxx vs. 5xxx errors. And > > I think it is good to have this distinction here. > > > > * see http://www.ietf.org/mail-archive/web/dime/current/msg04616.html > > > > 9) Section 11 > > * IANA considerations only contains those things that get changed > > from RFC3588 or are new to RFC3588bis. Also some other things > > changed there. > > * added experimental use range to align with RFC5719 > > * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html > > > > * I kept this stuff here as the command code allocation was updated > > by RFC5719.. and thus not in RFC3588 > > > > 10) Section 11.5 > > * notes to RFC-Editor added regarding S-NAPTR registries.. > > > > 11) Appendix B > > * corrected examples to more FC2606-complian > > > > > > Right.. did I miss something? (except for the deadline a couple of > times..) > > > > > > - JOuni > > > > > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Mon Aug 22 05:36:03 2011 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 1E05B21F8B26 for ; Mon, 22 Aug 2011 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.109 X-Spam-Level: X-Spam-Status: No, score=-3.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 PLI3GU6NTg5T for ; Mon, 22 Aug 2011 05:36:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB821F8B0C for ; Mon, 22 Aug 2011 05:36:02 -0700 (PDT) Received: by ywe9 with SMTP id 9so356787ywe.31 for ; Mon, 22 Aug 2011 05:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SPJUOcQD5Er7oAqnrMjij5P9vlEdnCUJc2sayk7sDBI=; b=XaVoIXTPaqw+63bl8kyPF3Sg0T5P91N7y2wULoH+m+LafWkqzBqILA0oNov3OTqXwG XUus2knJ5JQD70H5VSXnBG7wYgb7MQpkwTAKyxf0/wnX334MaVZeUjxdN6HnSMMBDF7P XklXDZfwqccg6HWebyO+jsp3rZv4beGjgYMG0= Received: by 10.236.185.228 with SMTP id u64mr13889065yhm.91.1314016627126; Mon, 22 Aug 2011 05:37:07 -0700 (PDT) Received: from [10.255.135.36] ([192.100.123.77]) by mx.google.com with ESMTPS id f4sm3536345yhn.13.2011.08.22.05.37.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 05:37:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 22 Aug 2011 15:37:00 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 22 Aug 2011 12:36:03 -0000 Sure. On Aug 22, 2011, at 3:26 PM, Romascanu, Dan (Dan) wrote: > Hi Jouni, > > When can we see draft-27 submitted? Just now the I-D is in state 'Dead' > because it was left to expire. > > Thanks and Regards, > > Dan > > > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of >> jouni korhonen >> Sent: Monday, August 22, 2011 3:10 PM >> To: dime@ietf.org >> Subject: Re: [Dime] pre-revision of RFC3588bis-27 >> >> >> One thing I missed in -27 is the clarification regarding SCTP PPID >> (thanks for Victor for pointing this out). See >> http://www.ietf.org/mail-archive/web/dime/current/msg04550.html >> >> It was proposed to have two PPIDs, one for plain SCTP and and for SCTP >> with DTLS. However, just having "MUST be 0" for both PPIDs could also >> be an alternative.. Any views? >> >> - Jouni >> >> >> On Aug 19, 2011, at 6:08 PM, jouni korhonen wrote: >> >>> Folks, >>> >>> Finally got my lazy *ss up and did a revision -27. Actually now that >> the S-NAPTR registry thing has stabilized it made sense to complete >> RFC3588bis. The intermediate version can be found here: >>> http://dimowine.neonsite.net/draft-ietf-dime-rfc3588bis-27.txt >>> >>> Following things were added/changed since -26: >>> >>> 0) note on Idnits: >>> * 2 warnings on non-RFC2606-compliant FQDNs are bogus >>> * 2 warnings on missing references are bogus >>> * don't know the issue about boilerplate.. anyone? >>> >>> 1) Added text to Abstract that this document obsoleted RFC 3588 -> >> pleases Idnits >>> >>> 2) Section 1.1.3. >>> * s/E2ESequence/E2E-Sequence >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04671.html >>> >>> 3) Section 1.2 >>> * rewording Diameter Peer definition >>> * removed the Transport definition >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04805.html >>> >>> 4) Section 1.2 >>> * reworded Redirect agent definition a bit >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04810.html >>> >>> 5) Section 1.3.4 >>> * added a new situation when a new application id is needed i.e. if >>> new AVP flag bits get added >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04808.html >>> >>> 6) Section 4.1 >>> * clarified the handling of AVP flag bits >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04808.html >>> >>> 7) Section 5.3.3 >>> * clarification on Vendor-Id AVP >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04741.html >>> >>> 8) Sections 7.1.3 and 7.1.5 >>> * Result-Code numbering is now back to RFC3588 numbers.. >>> * I did not add any notes on redundancies: >>> o DIAMETER_INVALID_BIT_IN_HEADER vs. DIAMETER_INVALID_HDR_BITS >>> o DIAMETER_INVALID_AVP_BIT_COMBO vs. DIAMETER_INVALID_AVP_BITS >>> >>> There is a difference between 3xxx vs. 5xxx errors. And >>> I think it is good to have this distinction here. >>> >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg04616.html >>> >>> 9) Section 11 >>> * IANA considerations only contains those things that get changed >>> from RFC3588 or are new to RFC3588bis. Also some other things >>> changed there. >>> * added experimental use range to align with RFC5719 >>> * see > http://www.ietf.org/mail-archive/web/dime/current/msg03598.html >>> >>> * I kept this stuff here as the command code allocation was updated >>> by RFC5719.. and thus not in RFC3588 >>> >>> 10) Section 11.5 >>> * notes to RFC-Editor added regarding S-NAPTR registries.. >>> >>> 11) Appendix B >>> * corrected examples to more FC2606-complian >>> >>> >>> Right.. did I miss something? (except for the deadline a couple of >> times..) >>> >>> >>> - JOuni >>> >>> >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Mon Aug 22 05:44:58 2011 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 CBF5121F8B3C; Mon, 22 Aug 2011 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 cODqP5aMuExm; Mon, 22 Aug 2011 05:44:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA9821F8B26; Mon, 22 Aug 2011 05:44:58 -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: 3.59 Message-ID: <20110822124458.30079.65242.idtracker@ietfa.amsl.com> Date: Mon, 22 Aug 2011 05:44:58 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-27.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: Mon, 22 Aug 2011 12:44:58 -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 W= orking Group of the IETF. Title : Diameter Base Protocol Author(s) : Victor Fajardo Jari Arkko John Loughney Glenn Zorn Filename : draft-ietf-dime-rfc3588bis-27.txt Pages : 149 Date : 2011-08-22 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-27.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-27.txt From lionel.morand@orange-ftgroup.com Tue Aug 23 00:45:53 2011 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 2845F21F8620 for ; Tue, 23 Aug 2011 00:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 dkVzViJE-p9T for ; Tue, 23 Aug 2011 00:45:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8504F21F8563 for ; Tue, 23 Aug 2011 00:45:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 36C266FCAFC; Tue, 23 Aug 2011 09:55:42 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 304DC6FCAFA; Tue, 23 Aug 2011 09:55:42 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 09:46:58 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 09:45:32 +0200 Message-ID: In-reply-to: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Dime] pre-revision of RFC3588bis-27 Thread-index: AcxegdZG8WOX37PaS9SR+JH0KEULQwC5L39Q References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> From: To: , X-OriginalArrivalTime: 23 Aug 2011 07:46:58.0419 (UTC) FILETIME=[D625B430:01CC6168] Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 23 Aug 2011 07:45:53 -0000 Hi All, Sorry for this late Tuesday comment. 9) Section 11 * IANA considerations only contains those things that get changed from RFC3588 or are new to RFC3588bis. Also some other things changed there. * added experimental use range to align with RFC5719 * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html * I kept this stuff here as the command code allocation was updated by RFC5719.. and thus not in RFC3588 [Lionel] I'm still not convinced that referring to RFC3588 and pointing out only the differences in the "bis" is the best way to do. First, the RFC3588 will become "obsolete" and it would be strange to still rely on for implementation. Besides, from a reader point of view, it would be easier to find all the necessary information in the same document. I think that it is not an issue to replace the reference to RFC3588 in IANA by the reference to RFC3588bis. It was done for SCTP, where the SCTP related IANA registries were updated to reference RFC4960 instead of RFC2960. And we can see the IANA section of RFC4960 is self-consistent with no reference to RFC2960, even if existing parameters were initially defined by the RFC2960. Therefore, I don't see why it would be an issue for RFC3588bis. Regards, Lionel=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Tue Aug 23 01:18:01 2011 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 E948621F8AF1 for ; Tue, 23 Aug 2011 01:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.421 X-Spam-Level: X-Spam-Status: No, score=-103.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 1UlAdzC6YF9A for ; Tue, 23 Aug 2011 01:18:01 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99521F8785 for ; Tue, 23 Aug 2011 01:18:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4BADRhU07GmAcF/2dsb2JhbABBmEiDbIt0d4FAAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQELBgwLAQYBIAYfCQgBAQQBEggBEgeHU5pdApxJhWlfBJhEhEyHBQ X-IronPort-AV: E=Sophos;i="4.68,268,1312171200"; d="scan'208";a="299319163" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Aug 2011 04:19:07 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Aug 2011 04:15:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Aug 2011 10:19:04 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] pre-revision of RFC3588bis-27 Thread-Index: AcxegdZG8WOX37PaS9SR+JH0KEULQwC5L39QAAGbnDA= References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> From: "Romascanu, Dan (Dan)" To: , , Cc: Michelle Cotton Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 23 Aug 2011 08:18:02 -0000 Hi, I suggest that we get advice Michelle Cotton from IANA on this.=20 A possible mid-way solution would be to list in the IANA all allocation already made in RFC 3588 and then list the changes brought up by 3588bis.=20 Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > lionel.morand@orange-ftgroup.com > Sent: Tuesday, August 23, 2011 10:46 AM > To: jouni.nospam@gmail.com; dime@ietf.org > Subject: Re: [Dime] pre-revision of RFC3588bis-27 >=20 > Hi All, >=20 > Sorry for this late Tuesday comment. >=20 >=20 > 9) Section 11 > * IANA considerations only contains those things that get changed > from RFC3588 or are new to RFC3588bis. Also some other things > changed there. > * added experimental use range to align with RFC5719 > * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html >=20 > * I kept this stuff here as the command code allocation was updated > by RFC5719.. and thus not in RFC3588 >=20 > [Lionel] I'm still not convinced that referring to RFC3588 and pointing > out only the differences in the "bis" is the best way to do. >=20 > First, the RFC3588 will become "obsolete" and it would be strange to > still rely on for implementation. Besides, from a reader point of view, > it would be easier to find all the necessary information in the same > document. I think that it is not an issue to replace the reference to > RFC3588 in IANA by the reference to RFC3588bis. >=20 > It was done for SCTP, where the SCTP related IANA registries were > updated to reference RFC4960 instead of RFC2960. And we can see the > IANA > section of RFC4960 is self-consistent with no reference to RFC2960, > even > if existing parameters were initially defined by the RFC2960. > Therefore, > I don't see why it would be an issue for RFC3588bis. >=20 > Regards, >=20 > Lionel >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Tue Aug 23 01:53:28 2011 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 56E0121F8754 for ; Tue, 23 Aug 2011 01:53:28 -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 eRYtjz2oiF+K for ; Tue, 23 Aug 2011 01:53:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 542D721F84F9 for ; Tue, 23 Aug 2011 01:53:27 -0700 (PDT) Received: by ywe9 with SMTP id 9so1141653ywe.31 for ; Tue, 23 Aug 2011 01:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M/A47+p3gcU+ZoB44MlHn6+GXbuIgIY1RSueDzcyueE=; b=XT5JQTUgPAlhxd0lmaYZxb0JZWqwWgp2Uh501dGQzWPqJrq2eYbbl7c1LUnpXNDgpG Lk8D505w0hBwNT/0U5e5GvktivL56nzWJ3KSL/JOGLN52J0R7mBkdoohjkbym6UmL8/4 PXLdYbqIj27ClUGW5jjxh36QY1Yxm4oneDxt0= Received: by 10.91.208.19 with SMTP id k19mr3507324agq.26.1314089674364; Tue, 23 Aug 2011 01:54:34 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-183-227.revip2.asianet.co.th [124.122.183.227]) by mx.google.com with ESMTPS id s15sm6028630ank.19.2011.08.23.01.54.31 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 01:54:33 -0700 (PDT) Message-ID: <4E536AC3.8070403@gmail.com> Date: Tue, 23 Aug 2011 15:54:27 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michelle Cotton , dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 23 Aug 2011 08:53:28 -0000 On 8/23/2011 3:19 PM, Romascanu, Dan (Dan) wrote: > Hi, > > I suggest that we get advice Michelle Cotton from IANA on this. > > A possible mid-way solution would be to list in the IANA all allocation > already made in RFC 3588 and then list the changes brought up by > 3588bis. The major problem IMHO w/the IANA Considerations section as it was was that it persistently and repeatedly said things like "this document defines" some value when that clearly was not the case, the the number had already been defined in RFC 3588. This rev solves that problem, but I think in a little bit to lazy a way (& I am a _very_ lazy person, so for me to say that is somewhat remarkable!). In any case, I think that it's neither necessary nor advisable to list all the allocations made in 3588 here; after all, the authoritative reference for existing IANA allocations is IANA. However, a reference to the soon-to-be obsolete predecessor of the soon-to-be RFC seems like a poor idea, as well. Therefore, I suggest listing only the allocation policies for each type of number and any new allocations. ... From jouni.nospam@gmail.com Tue Aug 23 02:11:13 2011 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 64E9021F84DD for ; Tue, 23 Aug 2011 02:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 77E2pDV9q-4l for ; Tue, 23 Aug 2011 02:11:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A521721F84DF for ; Tue, 23 Aug 2011 02:11:11 -0700 (PDT) Received: by bkar4 with SMTP id r4so5209926bka.31 for ; Tue, 23 Aug 2011 02:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AnY3IdWLUQ/kKUfzrCuwoKbbdQNhbpg4Q/RZJt+c+eM=; b=q+cMtKg8PwQI9zhWYEYtTmKVFODaEFoznWI3WF7AqBMSJ2i1HW37Vn6BAJ5jA5xriJ qL3YTRNdTjhmKw7CbuOaulaKKjRKTzuW9D5Q8z9lmgErEo08tcgM1scBPJELwCkRg1zm 7hZkI8vhCc46j2seg12OR8KezUM9o2pYx+HKE= Received: by 10.204.136.90 with SMTP id q26mr1375733bkt.377.1314090735874; Tue, 23 Aug 2011 02:12:15 -0700 (PDT) Received: from [62.237.209.67] ([62.237.209.67]) by mx.google.com with ESMTPS id b17sm2172512bkd.32.2011.08.23.02.12.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 02:12:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E536AC3.8070403@gmail.com> Date: Tue, 23 Aug 2011 12:12:11 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> <4E536AC3.8070403@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org, Michelle Cotton Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 23 Aug 2011 09:11:13 -0000 On Aug 23, 2011, at 11:54 AM, Glen Zorn wrote: > Therefore, I suggest listing only the allocation policies for each type > of number and any new allocations. > That sounds reasonable to me at least. - Jouni > ... From jouni.nospam@gmail.com Wed Aug 24 03:28:22 2011 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 7A14321F8AF7 for ; Wed, 24 Aug 2011 03:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 vcE3okKv3mj1 for ; Wed, 24 Aug 2011 03:28:21 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 984BA21F8AAA for ; Wed, 24 Aug 2011 03:28:21 -0700 (PDT) Received: by bkar4 with SMTP id r4so920642bka.31 for ; Wed, 24 Aug 2011 03:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=fQVWsGlUWDQQ55e9hrWRWxD/dTpmqQABqIpg5uXj3tw=; b=Tdoz/chamhKIn0e1dMiJcZzJBtA/Z91DiCAqvfc1Whwi0ctS2x2+8DQtKkT10hgUog kgNOgxBuhDMEU7x+C+L4donWcoTb+vkpu+SSrtbmidqz1EUyNTkwpAHjtXCD1nfeB5jU JBrutSEu3fkTOzOvfc9MvAyuVtMwh15xzx9Iw= Received: by 10.204.156.204 with SMTP id y12mr2014817bkw.338.1314181769500; Wed, 24 Aug 2011 03:29:29 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id y7sm237666bkq.48.2011.08.24.03.29.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 03:29:28 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 Aug 2011 13:29:24 +0300 References: <20110822223218.94D9E21F8BF9@ietfa.amsl.com> To: dime@ietf.org, radiusext@ops.ietf.org Message-Id: <57C4F8E2-8E22-43E3-9ABD-F71D4971DF02@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Fwd: Nomcom 2011-2012: Call for Nominations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 10:28:22 -0000 We encourage you to participate. The chairs. Begin forwarded message: > From: NomCom Chair > Date: August 23, 2011 1:32:18 AM GMT+03:00 > To: IETF Announcement list > Cc: ietf@ietf.org > Subject: Nomcom 2011-2012: Call for Nominations > > Hi All, > > The 2011-2012 Nominating committee is seeking nominations from now > until October 2, 2011. The list of open positions can be found at: > > https://www.ietf.org/group/nomcom/2011/ > > Nominations may be made directly on the NomCom 2011-2012 pages by > selecting the Nominate link at the top of the page. The URL for > NomCom 2011-2012 pages is: > > https://www.ietf.org/group/nomcom/2011/ > > Nominations may also be made by email to nomcom11@ietf.org. > If you do so, please include the word "Nominate" in the Subject and > indicate in the email who is being nominated, their email address (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you wish to nominate someone via email > for more than one position, please use separate emails to do so. > > Self nomination is welcome. > > NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current NomCom cycle is not confidential". Willing Nominees for each > position will be publicly listed. The public nominee list will be > updated at least once a week and possibly more often as nominations are > received. > > With the exception of publicly listing willing nominees, the > confidentiality requirements of RFC 3777 remain in effect. All > feedback and NomCom deliberations will remain confidential and not > disclosed. > > Because the list of nominees this year is public, we will accept > feedback on the nominees starting August 23, 2011. Per RFC 5680, we > will accept feedback from the entire IETF community on all the nominees. > > If you wish to provide anonymous feedback, the chair or any of the > members will be happy to handle this for you. The Nominating Committee > chair can be reached at nomcom-chair@ietf.org and the entire nominating > committee can be reached at nomcom11@ietf.org. The email addresses of > individual NomCom members is also on the NomCom 2011-2012 pages. > > In addition to nominations, the Nominating Committee is actively > seeking community input on the jobs that need to be filled. We have > received the job descriptions from the IAB, IESG, and IAOC and they can > be found at: > > https://www.ietf.org/group/nomcom/2011/iab-requirements > https://www.ietf.org/group/nomcom/2011/iesg-requirements > https://www.ietf.org/group/nomcom/2011/iaoc-requirements > > However, we also need the community's views and input on the jobs > within each organization. If you have ideas on job responsibilities > (more, less, different), please let us know. Please send suggestions > and feedback to nomcom11@ietf.org. > > Thank you, > > Suresh Krishnan > Chair, NomCom 2011-2012 > nomcom-chair@ietf.org > suresh.krishnan@ericsson.com > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From victor.pascual.avila@gmail.com Wed Aug 24 04:02:30 2011 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 7E7CB21F8880 for ; Wed, 24 Aug 2011 04:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 HuCcjHxSKaLu for ; Wed, 24 Aug 2011 04:02:30 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id EECA521F8B33 for ; Wed, 24 Aug 2011 04:02:29 -0700 (PDT) Received: by iye1 with SMTP id 1so1717429iye.27 for ; Wed, 24 Aug 2011 04:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jmFqCroT7i2MesoXHVnnfFWdkt2mNa6XQu2j2wLplcc=; b=KrTa4kFOWSXu5eO0LwXRAM1suueZ+wvj1BdYQBOGMj7ESY+2ffsDnjIOjmAgNqmkr+ kowtuvrcmj5Rp75HH8aoWXTX2IwK4QBzdxIhsre9CaAzO+F1wvPSzuMH/zlFGVcjLCx3 hmUkh99/e/sEXj1OpMZN+ZNJBrLqJDiMPVUEw= MIME-Version: 1.0 Received: by 10.231.83.4 with SMTP id d4mr10142253ibl.33.1314183820077; Wed, 24 Aug 2011 04:03:40 -0700 (PDT) Received: by 10.231.17.203 with HTTP; Wed, 24 Aug 2011 04:03:40 -0700 (PDT) In-Reply-To: References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> Date: Wed, 24 Aug 2011 13:03:40 +0200 Message-ID: From: Victor Pascual Avila To: jouni korhonen Content-Type: text/plain; charset=UTF-8 Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 11:02:30 -0000 On Mon, Aug 22, 2011 at 2:09 PM, jouni korhonen wrote: > > One thing I missed in -27 is the clarification regarding SCTP PPID (thanks for Victor for pointing this out). See > http://www.ietf.org/mail-archive/web/dime/current/msg04550.html > > It was proposed to have two PPIDs, one for plain SCTP and and for SCTP with DTLS. However, just having "MUST be 0" for both PPIDs could also be an alternative.. Any views? For protocol analyzers it is much easier if specific PPIDs are used. -Victor From jouni.nospam@gmail.com Wed Aug 24 04:26:57 2011 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 8FE7921F8AD3 for ; Wed, 24 Aug 2011 04:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 4qQQPt5m2oZW for ; Wed, 24 Aug 2011 04:26:57 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D231121F856B for ; Wed, 24 Aug 2011 04:26:56 -0700 (PDT) Received: by bkar4 with SMTP id r4so962021bka.31 for ; Wed, 24 Aug 2011 04:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=10GjaSkAFRHcXQ40086qWSlgmYSZ0gnIZvE3G5ppUpg=; b=S9wf7o5sVYuuX8hLis72LHC3JHUnwCO7TWdbsXkN1AvWtoiVxUjACo5bmaPl98OhXm wKCMjDfAJeQWDPVX5RKeBvej7PFojWVStskWM49a90jkq9k1KGbq5s0Ct6p+ekG/3umH c0MVGMXYZLBUZXdpcd221ijBFekbbBi6N6sPY= Received: by 10.204.154.200 with SMTP id p8mr2041800bkw.356.1314185283232; Wed, 24 Aug 2011 04:28:03 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id s10sm254630bka.31.2011.08.24.04.28.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 04:28:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 24 Aug 2011 14:27:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> To: Victor Pascual Avila X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 11:26:57 -0000 Ok. And any proposals for names? "diameter.sctp" and "diameter.dtls" ? Would using of PPIDs then be MUST or SHOULD? - Jouni On Aug 24, 2011, at 2:03 PM, Victor Pascual Avila wrote: > On Mon, Aug 22, 2011 at 2:09 PM, jouni korhonen = wrote: >>=20 >> One thing I missed in -27 is the clarification regarding SCTP PPID = (thanks for Victor for pointing this out). See >> http://www.ietf.org/mail-archive/web/dime/current/msg04550.html >>=20 >> It was proposed to have two PPIDs, one for plain SCTP and and for = SCTP with DTLS. However, just having "MUST be 0" for both PPIDs could = also be an alternative.. Any views? >=20 > For protocol analyzers it is much easier if specific PPIDs are used. >=20 > -Victor From victor.pascual.avila@gmail.com Wed Aug 24 06:36:57 2011 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 8653F21F8678 for ; Wed, 24 Aug 2011 06:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fhmSpAynh40I for ; Wed, 24 Aug 2011 06:36:57 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB0A21F8A95 for ; Wed, 24 Aug 2011 06:36:56 -0700 (PDT) Received: by iye1 with SMTP id 1so1905645iye.27 for ; Wed, 24 Aug 2011 06:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6FrQroCyQjpNZtv80150ZJ51dZ8NOJ5YhjO3iQQ6nvU=; b=XiO9zncP2tTDhp0Jwgz1yuAGgpnY6tHVVB8OduVYNGFGoAGNXou5e8Mau3rWBXhjqt jLSOCdtPELb8tbzQtiyryWGGwEkesv2KpAGZneKt1iCqNAgzRBuoO5xkCC8QfMyHDMf+ 4uPE8646BCOm4ujhV4HKHMbFEbE5cvNoxPHPQ= MIME-Version: 1.0 Received: by 10.231.6.99 with SMTP id 35mr10421156iby.7.1314193086258; Wed, 24 Aug 2011 06:38:06 -0700 (PDT) Received: by 10.231.17.203 with HTTP; Wed, 24 Aug 2011 06:38:06 -0700 (PDT) In-Reply-To: References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> Date: Wed, 24 Aug 2011 15:38:06 +0200 Message-ID: From: Victor Pascual Avila To: jouni korhonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:36:57 -0000 According to RFC4960 Section 14.4 I think SHOULD would be fine -Victor On Wed, Aug 24, 2011 at 1:27 PM, jouni korhonen wr= ote: > > Ok. And any proposals for names? "diameter.sctp" and "diameter.dtls" ? > Would using of PPIDs then be MUST or SHOULD? > > > - Jouni > > On Aug 24, 2011, at 2:03 PM, Victor Pascual Avila wrote: > >> On Mon, Aug 22, 2011 at 2:09 PM, jouni korhonen = wrote: >>> >>> One thing I missed in -27 is the clarification regarding SCTP PPID (tha= nks for Victor for pointing this out). See >>> http://www.ietf.org/mail-archive/web/dime/current/msg04550.html >>> >>> It was proposed to have two PPIDs, one for plain SCTP and and for SCTP = with DTLS. However, just having "MUST be 0" for both PPIDs could also be an= alternative.. Any views? >> >> For protocol analyzers it is much easier if specific PPIDs are used. >> >> -Victor > > --=20 Victor Pascual =C3=81vila From internet-drafts@ietf.org Thu Aug 25 12:58:55 2011 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 C4BB221F8C65; Thu, 25 Aug 2011 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 Ru3TNow5jMwE; Thu, 25 Aug 2011 12:58:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F91D21F8C5A; Thu, 25 Aug 2011 12:58:55 -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: 3.59 Message-ID: <20110825195855.30865.57254.idtracker@ietfa.amsl.com> Date: Thu, 25 Aug 2011 12:58:55 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-28.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, 25 Aug 2011 19:58:55 -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 W= orking Group of the IETF. Title : Diameter Base Protocol Author(s) : Victor Fajardo Jari Arkko John Loughney Glenn Zorn Filename : draft-ietf-dime-rfc3588bis-28.txt Pages : 151 Date : 2011-08-25 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-28.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-28.txt From jouni.nospam@gmail.com Thu Aug 25 13:01:24 2011 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 5DF7D21F8C43 for ; Thu, 25 Aug 2011 13:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 IRolI1i0BjOe for ; Thu, 25 Aug 2011 13:01:23 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0321F86AF for ; Thu, 25 Aug 2011 13:01:23 -0700 (PDT) Received: by bkar4 with SMTP id r4so2345752bka.31 for ; Thu, 25 Aug 2011 13:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OyFqgmMSXtgwGRnwen4gyiRIrvV9xdWwooq8v16W4w0=; b=nv7J2VoF5aHozqQzQqgB4IiT8/op2WOgFYxxk17F5iKHj4HPyrKjMysekU4EfYv/+i GXd4/J46jCPecVVgr0Z7l5GMcgIeS7UpKjoZJ8phxq11Rc66muXJO5yH+BcFrRJtNLAy JWbj++UzPKJTlxHj0CG/5EDJu7EJqSRj+mzsc= Received: by 10.204.142.145 with SMTP id q17mr84532bku.275.1314302556887; Thu, 25 Aug 2011 13:02:36 -0700 (PDT) Received: from a88-114-67-122.elisa-laajakaista.fi (a88-114-67-122.elisa-laajakaista.fi [88.114.67.122]) by mx.google.com with ESMTPS id h26sm265342bkt.52.2011.08.25.13.02.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Aug 2011 13:02:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 25 Aug 2011 23:02:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <780C3BBC-6374-473F-8AF3-8CAC6CB6BC78@gmail.com> References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 25 Aug 2011 20:01:24 -0000 Ok. I posted -28 that has "more IANA considerations".. and STCP PPID = text+IANA considerations. Next time someone wants to tweak something, just propose concrete = formatted text that can be copy-pasted in ;) - Jouni On Aug 23, 2011, at 10:45 AM, = wrote: > Hi All, >=20 > Sorry for this late Tuesday comment. >=20 >=20 > 9) Section 11 > * IANA considerations only contains those things that get changed > from RFC3588 or are new to RFC3588bis. Also some other things > changed there. > * added experimental use range to align with RFC5719 > * see http://www.ietf.org/mail-archive/web/dime/current/msg03598.html >=20 > * I kept this stuff here as the command code allocation was updated > by RFC5719.. and thus not in RFC3588 >=20 > [Lionel] I'm still not convinced that referring to RFC3588 and = pointing > out only the differences in the "bis" is the best way to do. >=20 > First, the RFC3588 will become "obsolete" and it would be strange to > still rely on for implementation. Besides, from a reader point of = view, > it would be easier to find all the necessary information in the same > document. I think that it is not an issue to replace the reference to > RFC3588 in IANA by the reference to RFC3588bis. >=20 > It was done for SCTP, where the SCTP related IANA registries were > updated to reference RFC4960 instead of RFC2960. And we can see the = IANA > section of RFC4960 is self-consistent with no reference to RFC2960, = even > if existing parameters were initially defined by the RFC2960. = Therefore, > I don't see why it would be an issue for RFC3588bis. >=20 > Regards, >=20 > Lionel=20 >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Fri Aug 26 04:10:12 2011 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 1D5D121F8B57 for ; Fri, 26 Aug 2011 04:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 47RXlDF-vODY for ; Fri, 26 Aug 2011 04:10:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29421F871E for ; Fri, 26 Aug 2011 04:09:32 -0700 (PDT) Received: by gyf3 with SMTP id 3so3184502gyf.31 for ; Fri, 26 Aug 2011 04:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZiP7y982j/1I67pkk131lGev56h01JgjmaRdB7fzRRw=; b=GhsfwiTkpHcCeZKf7nCoajRTVnL1shho9BDp6JmQ0en+SI6TaMCHMuRUTj/1YpZCvo f6c7kbGXZEU3ng9F+rpTLqfWGdYzMXjA0Pifz6Ey4hpil1iJveQkAMJTK/K+tteU1vLk BSYmfhzLKOmV6A3xEpblR68NAjAV/5/L3sqZ8= Received: by 10.236.189.4 with SMTP id b4mr5599814yhn.129.1314357047152; Fri, 26 Aug 2011 04:10:47 -0700 (PDT) Received: from [192.168.1.98] (ppp-115-87-77-81.revip4.asianet.co.th [115.87.77.81]) by mx.google.com with ESMTPS id f48sm556247yhh.70.2011.08.26.04.10.40 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 04:10:46 -0700 (PDT) Message-ID: <4E577F2C.1010603@gmail.com> Date: Fri, 26 Aug 2011 18:10:36 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> <780C3BBC-6374-473F-8AF3-8CAC6CB6BC78@gmail.com> In-Reply-To: <780C3BBC-6374-473F-8AF3-8CAC6CB6BC78@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 26 Aug 2011 11:10:12 -0000 On 8/26/2011 3:02 AM, jouni korhonen wrote: > > Ok. I posted -28 that has "more IANA considerations".. and STCP PPID text+IANA considerations. > > Next time someone wants to tweak something, just propose concrete formatted text that can be copy-pasted in ;) OK, here you go: Diameter AVPs often contain security-sensitive data; for example, user passwords and location data, network addresses and cryptographic keys. The Diameter messages containing such AVPs MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages SHOULD NOT be sent via intermediate nodes that would expose the sensitive data at those nodes except in cases where an intermediary is known to be operated as part of the same administrative domain as the endpoints so that an ability to successfully compromise the intermediary would imply a high probability of being able to compromise the endpoints as well. From glenzorn@gmail.com Sun Aug 28 02:47:05 2011 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 A06A621F8880 for ; Sun, 28 Aug 2011 02:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 K6+cL6Bq132Q for ; Sun, 28 Aug 2011 02:47:05 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 24B2721F884C for ; Sun, 28 Aug 2011 02:47:05 -0700 (PDT) Received: by pzk33 with SMTP id 33so15872410pzk.18 for ; Sun, 28 Aug 2011 02:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kkbtrWdQhURj21jOgN7Xhbya/6rsNsbwMj4P6l018qU=; b=Yt11hTGeovwdbcasCU0rpoRauCYhRW1lJ6NBwHanw+vGOR0i2NGqoHo/42HAlLrZch 8YUiTi2TcKNRWpE2XPdN+JYv4KoATWjUB2BgFJg4iMcfNfY6ciqBFLL7klhcf1cD+zaH K7yUd+DB/RZRffjgTa7wqpAXcN/hcp+7kr/NY= Received: by 10.142.133.7 with SMTP id g7mr1529094wfd.117.1314524906449; Sun, 28 Aug 2011 02:48:26 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-121-211-19.revip2.asianet.co.th [124.121.211.19]) by mx.google.com with ESMTPS id x1sm2105546wfc.13.2011.08.28.02.48.22 (version=SSLv3 cipher=OTHER); Sun, 28 Aug 2011 02:48:24 -0700 (PDT) Message-ID: <4E5A0EE4.2020802@gmail.com> Date: Sun, 28 Aug 2011 16:48:20 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com> In-Reply-To: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? 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, 28 Aug 2011 09:47:05 -0000 On 8/18/2011 7:17 PM, jouni korhonen wrote: > Folks, > > We had a discussion on unused (reserved) flags in AVP header. Here is proposed text to Section 4.1 regarding reserved AVP flags: > > OLD: > > The AVP Flags field informs the receiver how each attribute must > be handled. The 'r' (reserved) bits are unused and SHOULD be set > to 0. Note that subsequent Diameter applications MAY define > additional bits within the AVP Header, and an unrecognized bit > SHOULD be considered an error. > ... > > NEW: > > The AVP Flags field informs the receiver how each attribute must > be handled. It is RECOMMENDED that new Diameter applications do > not to define additional AVP Flag bits. The sender of the AVP MUST > set 'r' (reserved) bits to 0 and the receiver MUST ignore all 'r' > (reserved) bits. Unrecognized bits SHOULD be considered an error. > ... If you're going to say "SHOULD NOT", why not just say it? Also, I would prefer that we maintain the policy of strictness in reception and tolerance in transmission (RFC 1958). I.e., The AVP Flags field informs the receiver how each attribute must be handled. New Diameter applications SHOULD NOT define additional AVP Flag bits. The sender of the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD ignore all 'r' (reserved) bits. Unrecognized bits SHOULD be considered an error. ... From jouni.nospam@gmail.com Mon Aug 29 00:43:01 2011 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 9768721F8781 for ; Mon, 29 Aug 2011 00:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 HWJHSDMny3Ra for ; Mon, 29 Aug 2011 00:43:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1957E21F86AF for ; Mon, 29 Aug 2011 00:43:01 -0700 (PDT) Received: by gyf3 with SMTP id 3so5363671gyf.31 for ; Mon, 29 Aug 2011 00:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WB51gK7dWneoC57oDvhmytlMnN7WjGajRt2F7ZYnXPY=; b=wJw4pK46HfLw17swgw4Vp5+vZU3zPz17yUbby47yCamhOpmAK9dhqKfmmVOynA81x1 tSd71yyFzdsSWHrigCUrxEzdLnBYtvXZHStl2zh769NuCFgZwwTcvJXXwh5QJic1o9Dh vWKfJPjqS8liOrrS2Zsntvz62vpWfLIHCJnlw= Received: by 10.42.76.10 with SMTP id c10mr4686656ick.328.1314603862747; Mon, 29 Aug 2011 00:44:22 -0700 (PDT) Received: from [10.255.134.182] ([192.100.123.77]) by mx.google.com with ESMTPS id ib5sm5194393icc.12.2011.08.29.00.44.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Aug 2011 00:44:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E577F2C.1010603@gmail.com> Date: Mon, 29 Aug 2011 10:44:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5560AEED-0BB0-476C-BBDF-A9F9C98FC220@gmail.com> References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> <780C3BBC-6374-473F-8AF3-8CAC6CB6BC78@gmail.com> <4E577F2C.1010603@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 29 Aug 2011 07:43:01 -0000 Ok.. and where exactly you want this text to be placed? - Jouni On Aug 26, 2011, at 2:10 PM, Glen Zorn wrote: > On 8/26/2011 3:02 AM, jouni korhonen wrote: >>=20 >> Ok. I posted -28 that has "more IANA considerations".. and STCP PPID = text+IANA considerations. >>=20 >> Next time someone wants to tweak something, just propose concrete = formatted text that can be copy-pasted in ;) >=20 > OK, here you go: >=20 > Diameter AVPs often contain security-sensitive data; for example, > user passwords and location data, network addresses and cryptographic > keys. The Diameter messages containing such AVPs MUST only be sent > protected via mutually authenticated TLS or IPsec. In addition, = those > messages SHOULD NOT be sent via intermediate nodes that would > expose the sensitive data at those nodes except in cases where > an intermediary is known to be operated as part of the same > administrative domain as the endpoints so that an ability to > successfully compromise the intermediary would imply a high > probability of being able to compromise the endpoints as well. From jouni.nospam@gmail.com Mon Aug 29 00:45:03 2011 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 8DC5B21F8A23 for ; Mon, 29 Aug 2011 00:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 JLGuU+Hdn2zE for ; Mon, 29 Aug 2011 00:45:03 -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 172C121F89CC for ; Mon, 29 Aug 2011 00:45:02 -0700 (PDT) Received: by iakc1 with SMTP id c1so441387iak.31 for ; Mon, 29 Aug 2011 00:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0sjioislXQhQp257ZJ7wcFaM/Dkm6QC7HRQKBOoV3io=; b=KTbHv6WEEmxO+rpl2yqwPPwj6kNKlqTOGrZReu8efMErjLPVil707T4m+H0/+B2ac+ r+5WT4UPp2ZdBEdcM9j7mPk1HCkh5qGeygW56BQ5KoAgSrBWmqqgexnwqg/0j2EjCOFX t+JDPNOVkQGUl30I5khvldpN4jhcrb2EMjpiA= Received: by 10.231.24.66 with SMTP id u2mr9929620ibb.11.1314603986774; Mon, 29 Aug 2011 00:46:26 -0700 (PDT) Received: from [10.255.134.182] ([192.100.123.77]) by mx.google.com with ESMTPS id v5sm2471792ibk.27.2011.08.29.00.46.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Aug 2011 00:46:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E5A0EE4.2020802@gmail.com> Date: Mon, 29 Aug 2011 10:46:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <54B5FC19-CBC1-492E-B7F1-CD1DD16E6036@gmail.com> References: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com> <4E5A0EE4.2020802@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? 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, 29 Aug 2011 07:45:03 -0000 On Aug 28, 2011, at 12:48 PM, Glen Zorn wrote: > On 8/18/2011 7:17 PM, jouni korhonen wrote: >> Folks, >>=20 >> We had a discussion on unused (reserved) flags in AVP header. Here = is proposed text to Section 4.1 regarding reserved AVP flags: >>=20 >> OLD: >>=20 >> The AVP Flags field informs the receiver how each attribute must >> be handled. The 'r' (reserved) bits are unused and SHOULD be = set >> to 0. Note that subsequent Diameter applications MAY define >> additional bits within the AVP Header, and an unrecognized bit >> SHOULD be considered an error. >> ... >>=20 >> NEW: >>=20 >> The AVP Flags field informs the receiver how each attribute must >> be handled. It is RECOMMENDED that new Diameter applications do=20= >> not to define additional AVP Flag bits. The sender of the AVP = MUST >> set 'r' (reserved) bits to 0 and the receiver MUST ignore all = 'r' >> (reserved) bits. Unrecognized bits SHOULD be considered an = error. >> ... >=20 > If you're going to say "SHOULD NOT", why not just say it? Also, I = would > prefer that we maintain the policy of strictness in reception and > tolerance in transmission (RFC 1958). I.e., >=20 > The AVP Flags field informs the receiver how each attribute must > be handled. New Diameter applications SHOULD NOT define > additional AVP Flag bits. The sender of the AVP MUST set 'r' > (reserved) bits to 0 and the receiver SHOULD ignore all 'r' > (reserved) bits. Unrecognized bits SHOULD be considered an = error. This works for me. Anyone else? - Jouni >=20 > ... From glenzorn@gmail.com Mon Aug 29 00:45:24 2011 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 20FA421F8A4F for ; Mon, 29 Aug 2011 00:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 oDl9yS3gQvBN for ; Mon, 29 Aug 2011 00:45:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC2B21F89CC for ; Mon, 29 Aug 2011 00:45:23 -0700 (PDT) Received: by ywe9 with SMTP id 9so5280122ywe.31 for ; Mon, 29 Aug 2011 00:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ndSGN0rSg5h5GMDBts0VoTG0LlGaJE4Fg6Lq2w2EJlU=; b=eo8xGpkY1TdQtFaD/Wbqg46Q/2rNWPC7cCwPZ6mofxSMCJUadGuxFaMGUxuoXGRJVH f+f8N0q5hk0WOE6xJVWVaT1DgkxxOoQ3rKZEZH6054B8raQ0L16gn9VHQhPyyp0DmZC0 kSj4w8tfB8UJP2n42CQsX7q7O6/qj10wclNyY= Received: by 10.91.201.23 with SMTP id d23mr3552406agq.208.1314604007231; Mon, 29 Aug 2011 00:46:47 -0700 (PDT) Received: from [192.168.1.98] (ppp-110-169-236-161.revip5.asianet.co.th [110.169.236.161]) by mx.google.com with ESMTPS id o8sm4596514anm.33.2011.08.29.00.46.44 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 00:46:46 -0700 (PDT) Message-ID: <4E5B43E2.7050704@gmail.com> Date: Mon, 29 Aug 2011 14:46:42 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: jouni korhonen References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> <780C3BBC-6374-473F-8AF3-8CAC6CB6BC78@gmail.com> <4E577F2C.1010603@gmail.com> <5560AEED-0BB0-476C-BBDF-A9F9C98FC220@gmail.com> In-Reply-To: <5560AEED-0BB0-476C-BBDF-A9F9C98FC220@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 29 Aug 2011 07:45:24 -0000 On 8/29/2011 2:44 PM, jouni korhonen wrote: > > Ok.. and where exactly you want this text to be placed? In the Security Considerations section. > > - Jouni > > On Aug 26, 2011, at 2:10 PM, Glen Zorn wrote: > >> On 8/26/2011 3:02 AM, jouni korhonen wrote: >>> >>> Ok. I posted -28 that has "more IANA considerations".. and STCP PPID text+IANA considerations. >>> >>> Next time someone wants to tweak something, just propose concrete formatted text that can be copy-pasted in ;) >> >> OK, here you go: >> >> Diameter AVPs often contain security-sensitive data; for example, >> user passwords and location data, network addresses and cryptographic >> keys. The Diameter messages containing such AVPs MUST only be sent >> protected via mutually authenticated TLS or IPsec. In addition, those >> messages SHOULD NOT be sent via intermediate nodes that would >> expose the sensitive data at those nodes except in cases where >> an intermediary is known to be operated as part of the same >> administrative domain as the endpoints so that an ability to >> successfully compromise the intermediary would imply a high >> probability of being able to compromise the endpoints as well. > From lionel.morand@orange-ftgroup.com Mon Aug 29 03:04:27 2011 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 6BDDD21F8A91 for ; Mon, 29 Aug 2011 03:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ukDZ7cqyJzzl for ; Mon, 29 Aug 2011 03:04:27 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82121F8A51 for ; Mon, 29 Aug 2011 03:04:26 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 06F2AFC40BC; Mon, 29 Aug 2011 11:04:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 803EFFC4084; Mon, 29 Aug 2011 10:44:53 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 10:41:57 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 10:41:56 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Dime] pre-revision of RFC3588bis-27 Thread-index: AcxhckfxEgXNBUx4SMKrckpvG/mViAAAZbSgASzlUKA= References: <5181C6E5-4CD8-4115-B6BC-467E0BF47481@gmail.com> <4E536AC3.8070403@gmail.com> From: To: , X-OriginalArrivalTime: 29 Aug 2011 08:41:57.0107 (UTC) FILETIME=[82CC0C30:01CC6627] Cc: michelle.cotton@icann.org, dime@ietf.org Subject: Re: [Dime] pre-revision of RFC3588bis-27 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, 29 Aug 2011 10:04:27 -0000 Blocked in the server last week. Lionel -----Message d'origine----- De=A0: MORAND Lionel RD-CORE-ISS=20 Envoy=E9=A0: mardi 23 ao=FBt 2011 11:14 =C0=A0: glenzorn@gmail.com; dromasca@avaya.com Cc=A0: jouni.nospam@gmail.com; dime@ietf.org; michelle.cotton@icann.org Objet=A0: RE: [Dime] pre-revision of RFC3588bis-27 Here is an example of the wording used in SCTP, not referring to "this = document" but to the protocol itself. SCTP defines three registries that IANA maintains: - through definition of additional chunk types, - through definition of additional parameter types, or - through definition of additional cause codes within ERROR chunks. SCTP requires that the IANA Port Numbers registry be opened for SCTP port registrations, Section 14.5 describes how. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests. So, wherever the text is placed RFCXXXX or RFCYYYY, it remains valid. And providing only the allocation policies is a good solution IMHO. Regards, Lionel -----Message d'origine----- De=A0: Glen Zorn [mailto:glenzorn@gmail.com]=20 Envoy=E9=A0: mardi 23 ao=FBt 2011 10:54 =C0=A0: Romascanu, Dan (Dan) Cc=A0: MORAND Lionel RD-CORE-ISS; jouni.nospam@gmail.com; dime@ietf.org; = Michelle Cotton Objet=A0: Re: [Dime] pre-revision of RFC3588bis-27 On 8/23/2011 3:19 PM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > I suggest that we get advice Michelle Cotton from IANA on this.=20 >=20 > A possible mid-way solution would be to list in the IANA all = allocation > already made in RFC 3588 and then list the changes brought up by > 3588bis.=20 The major problem IMHO w/the IANA Considerations section as it was was that it persistently and repeatedly said things like "this document defines" some value when that clearly was not the case, the the number had already been defined in RFC 3588. This rev solves that problem, but I think in a little bit to lazy a way (& I am a _very_ lazy person, so for me to say that is somewhat remarkable!). In any case, I think that it's neither necessary nor advisable to list all the allocations made in 3588 here; after all, the authoritative reference for existing IANA allocations is IANA. However, a reference to the soon-to-be obsolete predecessor of the soon-to-be RFC seems like a poor idea, as well. Therefore, I suggest listing only the allocation policies for each type of number and any new allocations. ... From jouni.nospam@gmail.com Tue Aug 30 03:15:13 2011 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 9158E21F8BD5 for ; Tue, 30 Aug 2011 03:15:13 -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 sOsUbjVtVcR9 for ; Tue, 30 Aug 2011 03:15:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE86421F8B6E for ; Tue, 30 Aug 2011 03:15:12 -0700 (PDT) Received: by bkar4 with SMTP id r4so5927443bka.31 for ; Tue, 30 Aug 2011 03:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ypwJLYplm3KUBIXQ3iEFB5ekBUwTriNS5vKNQ96+fg0=; b=e0RU9TVd3LDBsYPKOQCYgKS0REUmOXotMwRESylawhtzVAqg13vvp4jpH0/iMJSh5R xZNuFCirga4NI0NxNgVLgkxilAby136gGqE4AGea/GvxTuR5fU5JxZd+yJbtvFPZy9qj 6LiE3ucMq48HBeOFYm0wBwCHQwyKv3B8R6neg= Received: by 10.204.154.150 with SMTP id o22mr2775909bkw.363.1314699350110; Tue, 30 Aug 2011 03:15:50 -0700 (PDT) Received: from a88-112-142-200.elisa-laajakaista.fi (a88-112-142-200.elisa-laajakaista.fi [88.112.142.200]) by mx.google.com with ESMTPS id o20sm814152bku.43.2011.08.30.03.15.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Aug 2011 03:15:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E51289C.20401@gmail.com> Date: Tue, 30 Aug 2011 13:14:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8231E519-1888-4D74-9B8A-293C21E812B6@gmail.com> References: <057.0ca7cc0abc305c0fa4d3c5ae33d14fe6@trac.tools.ietf.org> <8C993400-B596-4A55-A229-B8432EC5EEB6@gmail.com> <4E4F7491.5030709@gmail.com> <1DA18178-E97F-4928-AC56-A83DAC8AA5E3@gmail.com> <4E50C54E.4030401@gmail.com> <9CAFBBC5-7F5A-4536-83EA-53EBF3A8AF9B@gmail.com> <4E51289C.20401@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: [dime] #20: no accounting model specified 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, 30 Aug 2011 10:15:13 -0000 On Aug 21, 2011, at 6:47 PM, Glen Zorn wrote: > On 8/21/2011 10:28 PM, jouni korhonen wrote: >=20 > ... >=20 >>>> Hmm.. Any particular reason why NASREQ uses base app id for ACR/ACA = and not base acct id? >>>=20 >>> I think that it is an error in 4005. Actually, I find it hard to >>> believe that NASREQ would ever work except in a monolithic, "toy" >>> implementation. For example, the NASREQ version of the ASR/ASA = messages >>> includes a bunch of optional AVPs (with the 'M' bit set) that are >>> undefined in RFC 3588 to the base protocol server; it's hard to = imagine >>> how a standard implementation of 3588 could not treat the reception = of >>> such AVPs as an error. >>=20 >> MAybe this is then good candidates to be fixed in 4005bis? Or do you = think it would make situation worse in real deployments from a backward = compatibility point of view? >=20 > I was under the impression that there are no real deployments; if = there > were, someone would certainly have noticed this, don't you think? It seems to be the situations.. ;) Thus, fixing the above in RFC4005bis = shouldn't then be an issue. - Jouni >=20 > ... From internet-drafts@ietf.org Tue Aug 30 06:29:26 2011 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 2179321F8C14; Tue, 30 Aug 2011 06:29:26 -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.018, 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 GknJwmYHM94n; Tue, 30 Aug 2011 06:29:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07D621F8B37; Tue, 30 Aug 2011 06:29:25 -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: 3.60 Message-ID: <20110830132925.19243.95995.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 06:29:25 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-29.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, 30 Aug 2011 13:29:26 -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 W= orking Group of the IETF. Title : Diameter Base Protocol Author(s) : Victor Fajardo Jari Arkko John Loughney Glenn Zorn Filename : draft-ietf-dime-rfc3588bis-29.txt Pages : 151 Date : 2011-08-30 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-29.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-29.txt From jouni.nospam@gmail.com Tue Aug 30 06:34:38 2011 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 7963121F8B2F for ; Tue, 30 Aug 2011 06:34:38 -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 x1EVUtqsIctm for ; Tue, 30 Aug 2011 06:34:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B503021F8B25 for ; Tue, 30 Aug 2011 06:34:37 -0700 (PDT) Received: by bkar4 with SMTP id r4so6101569bka.31 for ; Tue, 30 Aug 2011 06:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=Nb6VztO/gpfgQw2prMqO1PkteYkAu9G9jKmQLZ723N0=; b=NhCs2Ax9gPnV3XKbTi+TqeKszCYjso9CKe0CfO5hX/5DhweBJPyBPYfrVd9dHriSbE B8DakSzxP87V7xjwuoEuGiqB/94UuFuatm41cIDB39oyawZnNenH9fBKOm9YDB1ZYaSZ 4nUsXOIfLql9k10IqK1QQoeAl4n1t+2WSAsHo= Received: by 10.204.133.3 with SMTP id d3mr80744bkt.313.1314711357765; Tue, 30 Aug 2011 06:35:57 -0700 (PDT) Received: from a88-112-142-200.elisa-laajakaista.fi (a88-112-142-200.elisa-laajakaista.fi [88.112.142.200]) by mx.google.com with ESMTPS id y3sm26335bkw.16.2011.08.30.06.35.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Aug 2011 06:35:56 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 16:35:53 +0300 References: <20110830132925.19243.95995.idtracker@ietfa.amsl.com> To: dime@ietf.org Message-Id: <1C5EFE17-F192-40DA-8EE0-1212F2E78687@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Fwd: I-D Action: draft-ietf-dime-rfc3588bis-29.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, 30 Aug 2011 13:34:38 -0000 Folks, Changes since -28: Lionel had found some typos: o DTSL -> DTLS Glen's comments addressed: o http://www.ietf.org/mail-archive/web/dime/current/msg04844.html o http://www.ietf.org/mail-archive/web/dime/current/msg04841.html I hope you all are now fine with the latest revision. - Jouni Begin forwarded message: > From: internet-drafts@ietf.org > Date: August 30, 2011 4:29:25 PM GMT+03:00 > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: I-D Action: draft-ietf-dime-rfc3588bis-29.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Diameter Maintenance and = Extensions Working Group of the IETF. >=20 > Title : Diameter Base Protocol > Author(s) : Victor Fajardo > Jari Arkko > John Loughney > Glenn Zorn > Filename : draft-ietf-dime-rfc3588bis-29.txt > Pages : 151 > Date : 2011-08-30 >=20 > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications such = as > network access or IP mobility in both local and roaming situations. > This document specifies the message format, transport, error > reporting, accounting and security services used by all Diameter > applications. The Diameter base protocol as defined in this = document > obsoletes RFC 3588 and must be supported by all new Diameter > implementations. From lionel.morand@orange-ftgroup.com Tue Aug 30 06:39:45 2011 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 46A1021F8A7A for ; Tue, 30 Aug 2011 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 hTLePio2q5Bo for ; Tue, 30 Aug 2011 06:39:44 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8707F21F8A57 for ; Tue, 30 Aug 2011 06:39:44 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 987478B8033; Tue, 30 Aug 2011 15:42:25 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 373F97B805F; Tue, 30 Aug 2011 15:40:38 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 15:38:57 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 15:38:55 +0200 Message-ID: In-reply-to: <54B5FC19-CBC1-492E-B7F1-CD1DD16E6036@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? Thread-index: AcxmH8lABqKHTXemTcuzgXWnw7eZfwA89SHA References: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com><4E5A0EE4.2020802@gmail.com> <54B5FC19-CBC1-492E-B7F1-CD1DD16E6036@gmail.com> From: To: , X-OriginalArrivalTime: 30 Aug 2011 13:38:57.0141 (UTC) FILETIME=[2AC73250:01CC671A] Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? 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, 30 Aug 2011 13:39:45 -0000 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de jouni korhonen Envoy=E9=A0: lundi 29 ao=FBt 2011 09:46 =C0=A0: Glen Zorn Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: = Type? On Aug 28, 2011, at 12:48 PM, Glen Zorn wrote: > On 8/18/2011 7:17 PM, jouni korhonen wrote: >> Folks, >>=20 >> We had a discussion on unused (reserved) flags in AVP header. Here = is proposed text to Section 4.1 regarding reserved AVP flags: >>=20 >> OLD: >>=20 >> The AVP Flags field informs the receiver how each attribute must >> be handled. The 'r' (reserved) bits are unused and SHOULD be = set >> to 0. Note that subsequent Diameter applications MAY define >> additional bits within the AVP Header, and an unrecognized bit >> SHOULD be considered an error. >> ... >>=20 >> NEW: >>=20 >> The AVP Flags field informs the receiver how each attribute must >> be handled. It is RECOMMENDED that new Diameter applications do = >> not to define additional AVP Flag bits. The sender of the AVP = MUST >> set 'r' (reserved) bits to 0 and the receiver MUST ignore all = 'r' >> (reserved) bits. Unrecognized bits SHOULD be considered an = error. >> ... >=20 > If you're going to say "SHOULD NOT", why not just say it? Also, I = would > prefer that we maintain the policy of strictness in reception and > tolerance in transmission (RFC 1958). I.e., >=20 > The AVP Flags field informs the receiver how each attribute must > be handled. New Diameter applications SHOULD NOT define > additional AVP Flag bits. The sender of the AVP MUST set 'r' > (reserved) bits to 0 and the receiver SHOULD ignore all 'r' > (reserved) bits. Unrecognized bits SHOULD be considered an = error. This works for me. Anyone else? [Lionel] if "the receiver SHOULD ignore all 'r' (reserved) bits", how = would the receiver be able detect "Unrecognized bits"? Is it implied "if = not ignored, unrecognized bits SHOULD be considered an error"? - Jouni >=20 > ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From iesg-secretary@ietf.org Tue Aug 30 08:05:47 2011 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 183FB21F8CAE; Tue, 30 Aug 2011 08:05:47 -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=[AWL=0.000, 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 DvXYRjRlJDBG; Tue, 30 Aug 2011 08:05:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F7D21F8C80; Tue, 30 Aug 2011 08:05:46 -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: 3.60 Message-ID: <20110830150546.12919.59066.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 08:05:46 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Base Protocol) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 15:05:47 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Base Protocol' as a Proposed Standard The document was already last-called, but because of the extensive and non-editorial changes it went through, the editors, document shepherd and Area Director decided to submit it again to broad IETF review. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1437/ From glenzorn@gmail.com Tue Aug 30 08:15:00 2011 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 3476721F8C7B for ; Tue, 30 Aug 2011 08:15:00 -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 blN9l6cZuL8b for ; Tue, 30 Aug 2011 08:14:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6104D21F8CA5 for ; Tue, 30 Aug 2011 08:14:59 -0700 (PDT) Received: by wwf5 with SMTP id 5so4594037wwf.13 for ; Tue, 30 Aug 2011 08:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=d2KePSepYgQeorxuTEuTpty237PJcmoIm85zQHB52Yc=; b=NhraBO1v3Ot40g8lz4P/DavU+aRCCDFkN5RQ6e6ShNggl6yF06+1H81r0d6CHEgvWt RCc4jnnVsJXRckGQ73kFNshtca2HxZskcbIa6qLw9I/kdOX/BEmA151bAAC2kpaflAYU YrJFpahtmHhlebbyaKY/ULXz5Cpvnz7Xgh4q0= Received: by 10.227.11.85 with SMTP id s21mr2381219wbs.59.1314717386199; Tue, 30 Aug 2011 08:16:26 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-231-171.revip2.asianet.co.th [124.120.231.171]) by mx.google.com with ESMTPS id ew4sm4710341wbb.8.2011.08.30.08.16.20 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 08:16:24 -0700 (PDT) Message-ID: <4E5CFEAC.8070503@gmail.com> Date: Tue, 30 Aug 2011 22:15:56 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com><4E5A0EE4.2020802@gmail.com> <54B5FC19-CBC1-492E-B7F1-CD1DD16E6036@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? 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, 30 Aug 2011 15:15:00 -0000 On 8/30/2011 8:38 PM, lionel.morand@orange-ftgroup.com wrote: ... >> If you're going to say "SHOULD NOT", why not just say it? Also, I would >> prefer that we maintain the policy of strictness in reception and >> tolerance in transmission (RFC 1958). I.e., >> >> The AVP Flags field informs the receiver how each attribute must >> be handled. New Diameter applications SHOULD NOT define >> additional AVP Flag bits. The sender of the AVP MUST set 'r' >> (reserved) bits to 0 and the receiver SHOULD ignore all 'r' >> (reserved) bits. Unrecognized bits SHOULD be considered an error. > > > This works for me. Anyone else? > > [Lionel] if "the receiver SHOULD ignore all 'r' (reserved) bits", how would the receiver be able detect "Unrecognized bits"? Is it implied "if not ignored, unrecognized bits SHOULD be considered an error"? > I suppose so, & if the implementation ignores both "SHOULDS", maybe just go non-linear? ;-) ... From dromasca@avaya.com Tue Aug 30 08:18:07 2011 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 350B221F8CBF for ; Tue, 30 Aug 2011 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 L0tAopYneaGM for ; Tue, 30 Aug 2011 08:18:06 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 596E221F8B84 for ; Tue, 30 Aug 2011 08:18:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIAAAb/XE7GmAcF/2dsb2JhbABCmDOPaneBQAEBAQEDAQEBDx4KNAsMBAIBCA0EBAEBAQoGDAsBBgEmHwkIAQEEARIIGodUnRcCnFiFbWAEmFCLWw X-IronPort-AV: E=Sophos;i="4.68,302,1312171200"; d="scan'208";a="265172395" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Aug 2011 11:19:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Aug 2011 11:15:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Aug 2011 17:19:30 +0200 Message-ID: In-Reply-To: <4E5CFEAC.8070503@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? Thread-Index: AcxnJ8wbW6pttkTOQxCfKDr2/y5gXAAACo8A References: <52D16EA2-0548-4D46-9D1E-7DEB31700964@gmail.com><4E5A0EE4.2020802@gmail.com><54B5FC19-CBC1-492E-B7F1-CD1DD16E6036@gmail.com> <4E5CFEAC.8070503@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , Cc: dime@ietf.org Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type? 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, 30 Aug 2011 15:18:07 -0000 Hi, As the document is now in IETF Last Call, please do not make any changes until the end of the Last Call period.=20 All agreed edits should be incorporated in the post IETFLC version together with other changes resulting from LC comments.=20 Thanks and Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Tuesday, August 30, 2011 6:16 PM > To: lionel.morand@orange-ftgroup.com > Cc: dime@ietf.org > Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: > Type? >=20 > On 8/30/2011 8:38 PM, lionel.morand@orange-ftgroup.com wrote: >=20 > ... >=20 > >> If you're going to say "SHOULD NOT", why not just say it? Also, I > would > >> prefer that we maintain the policy of strictness in reception and > >> tolerance in transmission (RFC 1958). I.e., > >> > >> The AVP Flags field informs the receiver how each attribute > must > >> be handled. New Diameter applications SHOULD NOT define > >> additional AVP Flag bits. The sender of the AVP MUST set 'r' > >> (reserved) bits to 0 and the receiver SHOULD ignore all 'r' > >> (reserved) bits. Unrecognized bits SHOULD be considered an > error. > > > > > > This works for me. Anyone else? > > > > [Lionel] if "the receiver SHOULD ignore all 'r' (reserved) bits", how > would the receiver be able detect "Unrecognized bits"? Is it implied > "if not ignored, unrecognized bits SHOULD be considered an error"? > > >=20 > I suppose so, & if the implementation ignores both "SHOULDS", maybe > just > go non-linear? ;-) >=20 > ... >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From iesg-secretary@ietf.org Tue Aug 30 09:14:25 2011 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 9DDD421F8D54; Tue, 30 Aug 2011 09:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNvEqqXmazNz; Tue, 30 Aug 2011 09:14:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE221F8D55; Tue, 30 Aug 2011 09:14:25 -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: 3.60 Message-ID: <20110830161425.2745.19536.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 09:14:25 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to Proposed Standard (draft-ietf-dime-local-keytran-14.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, 30 Aug 2011 16:14:25 -0000 The IESG has approved the following document: - 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' (draft-ietf-dime-local-keytran-14.txt) as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-local-keytran/ Technical Summary Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. Working Group Summary The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. Document Quality The document is complete, straightforward, simple and well-written. Personnel Dan Romascanu is the Document Shepherd for this document. Lionel Morand is Responsible Area Director.