From jouni.nospam@gmail.com Wed Jun 2 01:00:07 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869F928C130 for ; Wed, 2 Jun 2010 01:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHFydoteXLIL for ; Wed, 2 Jun 2010 01:00:06 -0700 (PDT) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 7F8BF3A6968 for ; Wed, 2 Jun 2010 01:00:06 -0700 (PDT) Received: by ewy1 with SMTP id 1so1302097ewy.13 for ; Wed, 02 Jun 2010 00:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=2PlIHKd4pV7mnDZgYn3CzeLlqt4lrZ8Gg1GkuJdVYaI=; b=QmfM1auvTY4bApFq1GIUkCy5fVn2u/E/UH3DJf6/HZXpf+WLGeSV+U07MQh4239oBW 7opr8FvBwSeMpKxYQJwdkr5vPQ2mo+bcY+h1ftDaaUnry/FcLwcZSli/yZ4tJjuYkToq 3JWD2OT7z0g9EFWr4T1Rei+9QQT0mXR7xBpZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=L2Xc2V+H9wPub4wK1K6NpTvwU4evu7NuCfyykdc2asjkEqWFSpIQOLWGLh3jzwpJPK KwWpi5/RSugblVMpMQy72yRAxdzLuB2BywEqiapF6LUwY/YWJnKn/4bRw9s1pXbnZQmf n0LznCULXAkAR26sb9BX7C4ouX4+1wJn9U5iE= Received: by 10.213.33.134 with SMTP id h6mr4562403ebd.46.1275465591150; Wed, 02 Jun 2010 00:59:51 -0700 (PDT) Received: from [10.239.3.48] ([192.100.124.156]) by mx.google.com with ESMTPS id 13sm4276288ewy.1.2010.06.02.00.59.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Jun 2010 00:59:49 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Jun 2010 10:59:47 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Request for agenda slots X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 08:00:07 -0000 Hi all, (resending as I used wrong email address again when sending..) We have requested a 2 hour slot for the DIME WG meeting at IETF#78. If you need a slot on the agenda to present an I-D related to the DIME charter, please send a request (to chairs) including: 1. I-D name 2. Time required 3. How is the I-D associated with the charter and WG goals Please note that WG items will take priority over others. - Chairs From gwz@net-zen.net Wed Jun 2 01:31:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A803A6A3B for ; Wed, 2 Jun 2010 01:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.58 X-Spam-Level: ** X-Spam-Status: No, score=2.58 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEdxvkEqILrq for ; Wed, 2 Jun 2010 01:31:29 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id E35843A6A1E for ; Wed, 2 Jun 2010 01:31:28 -0700 (PDT) Received: (qmail 21948 invoked from network); 2 Jun 2010 08:31:15 -0000 Received: from unknown (180.210.216.74) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 02 Jun 2010 08:31:14 -0000 From: "Glen Zorn" To: Date: Wed, 2 Jun 2010 15:30:55 +0700 Organization: Network Zen Message-ID: <00bb01cb022d$efa0ae60$cee20b20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsCLebw9PZt/1pQQ72ltLbdqwbOqg== Content-Language: en-us x-cr-hashedpuzzle: q2I= AVZL BSXo BnPh Cg/J EP/c FrYi GRd+ Gc6+ HqaI IYlW Jz2s J9BX KLxk Ki2e Oxps; 2; ZABpAG0AZQAtAGMAaABhAGkAcgBzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {3F257612-D5BD-4F6A-A351-E8351C8559CB}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Wed, 02 Jun 2010 08:30:48 GMT; ZAByAGEAZgB0AC0AegBvAHIAbgAtAGQAaQBtAGUALQByAGYAYwA0ADAAMAA1AGIAaQBzAC0AMAAxAA== x-cr-puzzleid: {3F257612-D5BD-4F6A-A351-E8351C8559CB} Cc: dime@ietf.org Subject: [Dime] draft-zorn-dime-rfc4005bis-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 08:31:29 -0000 I would like to request that the subject draft be adopted as a WG document. Thank you. From James.Winterbottom@andrew.com Wed Jun 2 01:31:59 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F193A6966 for ; Wed, 2 Jun 2010 01:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFSBIuHAAxp5 for ; Wed, 2 Jun 2010 01:31:57 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 99F123A696A for ; Wed, 2 Jun 2010 01:31:57 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:47834 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S22063590Ab0FBIbm convert rfc822-to-8bit (ORCPT ); Wed, 2 Jun 2010 03:31:42 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 2 Jun 2010 03:31:42 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 2 Jun 2010 16:31:39 +0800 From: "Winterbottom, James" To: jouni korhonen , "dime@ietf.org" Date: Wed, 2 Jun 2010 16:27:17 +0800 Thread-Topic: [Dime] Request for agenda slots Thread-Index: AcsCKZr/vCXdJr7zTsuncC1Hi/iwUgAA856H Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E58AD6D6@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Dime] Request for agenda slots X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 08:31:59 -0000 Hi Jouni, I think that at this point in time it is very important for you to indicate that NO new drafts will be accepted as WG items until the current backlog is cleared. This will avoid people submitting drafts that are important, but have no hope of adoption any time soon. Cheers James ________________________________________ From: dime-bounces@ietf.org [dime-bounces@ietf.org] On Behalf Of jouni korhonen [jouni.nospam@gmail.com] Sent: Wednesday, June 02, 2010 2:59 AM To: dime@ietf.org Subject: [Dime] Request for agenda slots Hi all, (resending as I used wrong email address again when sending..) We have requested a 2 hour slot for the DIME WG meeting at IETF#78. If you need a slot on the agenda to present an I-D related to the DIME charter, please send a request (to chairs) including: 1. I-D name 2. Time required 3. How is the I-D associated with the charter and WG goals Please note that WG items will take priority over others. - Chairs _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Wed Jun 2 07:56:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3639D3A6826; Wed, 2 Jun 2010 07:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqMbE6c4dHnk; Wed, 2 Jun 2010 07:56:43 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id F13383A6986; Wed, 2 Jun 2010 07:56:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,347,1272859200"; d="scan'208";a="18738694" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 02 Jun 2010 10:56:30 -0400 X-IronPort-AV: E=Sophos;i="4.53,347,1272859200"; d="scan'208";a="480260585" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Jun 2010 10:56:28 -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: Wed, 2 Jun 2010 16:56:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FEDAUTH BOF request Thread-Index: AcsCY8D3YG4qrCIAT927dkDMQ1m8hw== From: "Romascanu, Dan (Dan)" To: , "radext mailing list" , Subject: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 14:56:44 -0000 Diameter and RADIUS experts should pay attention to the request to hold a Federated Authentication (FEDAUTH) BOF which will be discussed this morning by the IAB and the IESG.=20 The Draft Charter is available at http://www.project-moonshot.org/bof/charter/, and more information about this BOF or other BOF requests can be examined at http://trac.tools.ietf.org/bof/trac/ Dan From root@core3.amsl.com Wed Jun 2 09:45:01 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E3ADD28C0E9; Wed, 2 Jun 2010 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100602164501.E3ADD28C0E9@core3.amsl.com> Date: Wed, 2 Jun 2010 09:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-21.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 16:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-21.txt Pages : 159 Date : 2010-06-02 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 must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-02093922.I-D@ietf.org> --NextPart-- From tena@huawei.com Wed Jun 2 21:03:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A9F3A672E; Wed, 2 Jun 2010 21:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.039 X-Spam-Level: X-Spam-Status: No, score=-99.039 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqWc5erV6bS1; Wed, 2 Jun 2010 21:03:02 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id EC6D13A6835; Wed, 2 Jun 2010 21:03:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F00F4Y78MOG@szxga02-in.huawei.com>; Thu, 03 Jun 2010 12:02:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F006CC78MOC@szxga02-in.huawei.com>; Thu, 03 Jun 2010 12:02:46 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3F00HS878LTS@szxml04-in.huawei.com>; Thu, 03 Jun 2010 12:02:46 +0800 (CST) Date: Thu, 03 Jun 2010 12:02:46 +0800 From: Tina TSOU To: aaa-doctors@ietf.org, radext mailing list , dime@ietf.org, "Romascanu, Dan (Dan)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 04:03:06 -0000 Comments are below. 1. This might be of interest to ngHLR (Unified Subscriber Center) kind of solutions who provide Identity Management services 2. From protocol side, I think it may be more interesting for RADIUS as I doubt the suitability of Diameter for this. B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: ; "radext mailing list" ; Sent: Wednesday, June 02, 2010 10:56 PM Subject: FEDAUTH BOF request Diameter and RADIUS experts should pay attention to the request to hold a Federated Authentication (FEDAUTH) BOF which will be discussed this morning by the IAB and the IESG. The Draft Charter is available at http://www.project-moonshot.org/bof/charter/, and more information about this BOF or other BOF requests can be examined at http://trac.tools.ietf.org/bof/trac/ Dan -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From bernard_aboba@hotmail.com Wed Jun 2 22:03:35 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E773A693B; Wed, 2 Jun 2010 22:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqeRuJmcNqea; Wed, 2 Jun 2010 22:03:34 -0700 (PDT) Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by core3.amsl.com (Postfix) with ESMTP id 423B63A6832; Wed, 2 Jun 2010 22:03:34 -0700 (PDT) Received: from BLU137-W35 ([65.55.111.72]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 22:03:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d7e3c6e9-fe8b-4f07-b2af-c6d5841ccbd2_" X-Originating-IP: [64.134.138.42] From: Bernard Aboba To: , , "radiusext@ops.ietf.org" , , "dromasca@avaya.com" Date: Wed, 2 Jun 2010 22:03:16 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2010 05:03:20.0939 (UTC) FILETIME=[163CA3B0:01CB02DA] Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 05:03:36 -0000 --_d7e3c6e9-fe8b-4f07-b2af-c6d5841ccbd2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tina said:=20 > Comments are below. > 1. This might be of interest to ngHLR (Unified Subscriber Center) kind of= =20 > solutions who provide Identity Management services > 2. From protocol side=2C I think it may be more interesting for RADIUS as= I doubt the suitability of Diameter for this. Not sure why RADIUS would be more suitable than Diameter for carrying large= payloads such as SAML assertions. The 4096 octet RADIUS PDU limit is not = transport-specific -- that is=2C transporting the RADIUS payload over TCP d= oes not solve the problem.=20 =20 > ----- Original Message -----=20 > From: "Romascanu=2C Dan (Dan)" > To: =3B "radext mailing list" =3B= =20 > > Sent: Wednesday=2C June 02=2C 2010 10:56 PM > Subject: FEDAUTH BOF request >=20 >=20 > Diameter and RADIUS experts should pay attention to the request to hold > a Federated Authentication (FEDAUTH) BOF which will be discussed this > morning by the IAB and the IESG. >=20 > The Draft Charter is available at > http://www.project-moonshot.org/bof/charter/=2C and more information abou= t > this BOF or other BOF requests can be examined at > http://trac.tools.ietf.org/bof/trac/ >=20 > Dan >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: = --_d7e3c6e9-fe8b-4f07-b2af-c6d5841ccbd2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tina said:

>=3B Comments are below.
>=3B 1. This might be of= interest to ngHLR (Unified Subscriber Center) kind of
>=3B solutions= who provide Identity Management services
>=3B 2. From protocol side= =2C I think it may be more interesting for RADIUS as I =3B doubt the su= itability of Diameter for this.

Not sure why RADIUS would be more su= itable than Diameter for carrying large payloads such as SAML assertions.&n= bsp=3B The 4096 octet RADIUS PDU limit is not transport-specific -- that is= =2C transporting the RADIUS payload over TCP does not solve the problem.
 =3B
>=3B ----- Original Message -----
>=3B From: "Rom= ascanu=2C Dan (Dan)" <=3Bdromasca@avaya.com>=3B
>=3B To: <=3Bdim= e@ietf.org>=3B=3B "radext mailing list" <=3Bradiusext@ops.ietf.org>= =3B=3B
>=3B <=3Baaa-doctors@ietf.org>=3B
>=3B Sent: Wednesda= y=2C June 02=2C 2010 10:56 PM
>=3B Subject: FEDAUTH BOF request
>= =3B
>=3B
>=3B Diameter and RADIUS experts should pay attention = to the request to hold
>=3B a Federated Authentication (FEDAUTH) BOF w= hich will be discussed this
>=3B morning by the IAB and the IESG.
&= gt=3B
>=3B The Draft Charter is available at
>=3B http://www.pro= ject-moonshot.org/bof/charter/=2C and more information about
>=3B this= BOF or other BOF requests can be examined at
>=3B http://trac.tools.= ietf.org/bof/trac/
>=3B
>=3B Dan
>=3B
>=3B --
>= =3B to unsubscribe send a message to radiusext-request@ops.ietf.org with>=3B the word 'unsubscribe' in a single line as the message text body.>=3B archive: <=3Bhttp://psg.com/lists/radiusext/>=3B
>=3B >=3B
>=3B
>=3B --
>=3B to unsubscribe send a message to= radiusext-request@ops.ietf.org with
>=3B the word 'unsubscribe' in a = single line as the message text body.
>=3B archive: <=3Bhttp://psg.c= om/lists/radiusext/>=3B
= --_d7e3c6e9-fe8b-4f07-b2af-c6d5841ccbd2_-- From bernard_aboba@hotmail.com Wed Jun 2 22:26:54 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2314B3A67C1; Wed, 2 Jun 2010 22:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+8+KNbr0T77; Wed, 2 Jun 2010 22:26:46 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id EC7863A6926; Wed, 2 Jun 2010 22:26:39 -0700 (PDT) Received: from BLU137-W24 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Jun 2010 22:26:26 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b105dacf-0e73-4ddb-9eaa-2a8bfde017a9_" X-Originating-IP: [64.134.138.42] From: Bernard Aboba To: , , "radiusext@ops.ietf.org" , , "dromasca@avaya.com" Date: Wed, 2 Jun 2010 22:26:26 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2010 05:26:26.0401 (UTC) FILETIME=[50095D10:01CB02DD] Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 05:26:54 -0000 --_b105dacf-0e73-4ddb-9eaa-2a8bfde017a9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me provide a bit of context about what I think the problem is here.=20 As noted by Sam in a previous conversation=2C the basic use case is "cloud = services"=2C where an education institution or enterprise is making use of = hosted services. In these situations=2C the institution may not just want = the service provider to host an application=2C but may want to keep their c= redentials local=2C rather than hosting this in the cloud as well.=20 In the original Moonshot investigation=2C Kerberos was considered as a pote= ntial solution. However=2C while Kerberos is well understood from a securi= ty point of view=2C and could relatively easily be modified to support EAP-= based pre-auth (numerous proposals for this have been advanced and in some = cases implemented) Kerberos federation has not been widely deployed.=20 One of the basic problems with putting a KDC on the Internet is that there = is no easy way to protect it=2C since both clients and other KDCs may need = to send packets to and from the KDC. For this reason if there are roaming = clients there is no easy way to filter traffic to/from the KDC. In additio= n=2C the Kerberos protocol is vulnerable to passive attacks in the absence = of extensions such as PKINIT or Kerberos Hardening.=20 In contrast=2C the AAA roaming model has been widely deployed=2C in part be= cause it is much easier to protect a AAA server. AAA servers only talk to = AAA clients=2C not to users directly. This means that it is typically poss= ible to filter traffic to the AAA server so that only packets originating f= rom legitimate AAA clients can be sent to/from the AAA server. =20 In addition to these basic security issues=2C the AAA delegation model is m= uch simpler than Kerberos. Obtaining a Kerberos TGT for a local realm invo= lves first obtaining a TGT from a "home" realm and then requesting a TGT fo= r the local realm. This involves multiple exchanges=2C and as noted earlie= r requires both the local KDC and the home KDC to be available over the Int= ernet. In contrast=2C a AAA client implicitly delegates authority to the A= AA server for the Accept/Reject decision=2C so that explicit trust relation= ships don't need to be configured. As long as the AAA client can reach the= AAA server via a chain of proxies the trust relationship can succeed.=20 Given these basic characteristics of Kerberos and AAA delegation=2C the Moo= nshot team has decided that a AAA-based approach to delegation is more like= ly to be widely deployed than a Kerberos-based one. My take on this is tha= t this assessment is probably realistic.=20 Where I get lost is making the leap between the AAA delegation model and us= e of EAP. As we saw with Digest authentication (RFC 5090)=2C it is possibl= e to extend AAA to support application-layer authentication without use of = EAP. For example=2C using AAA to carry GSS-API payloads would not require = much more than defining a GSS-Message attribute. EAP has no unique propert= ies that make it more suitable for use with AAA. In fact=2C I would argue = that the fit between EAP and AAA has always been tenuous at best -- witness= the issues encountered in federated EAP authentication that RADSEC has bee= n needed to address. =20 In particular=2C the problems of EAP auth (e.g. multiple round-trips=2C gen= eral fragility in federated uses) become highly toxic when applied to Realt= ime applications such as XMPP and SIP. As we have learned=2C Digest auth (= RFC 5090) has not been widely deployed=2C in part because of concern about = the additional latency added by a AAA exchange. For users of real-time app= lications=2C additional latency is a basic=2C non-negotiable goal. If the = relatively modest number of exchanges implied by RFC 5090 were intolerable = in realtime applications=2C how can we expect EAP exchanges (which can inv= olve 4-5 times the number of roundtrips of RFC 5090) to be deployed? The a= nswer unfortunately=2C is that there is no chance at all. =20 So in summary=2C I believe that some aspects of the problem statement make = sense=2C but that a solution has been chosen prematurely. The right way to= move forward in a situation like this is to begin with a problem statement= =2C which should include carefully validating the uses cases. =20 =20 > ----- Original Message -----=20 > From: "Romascanu=2C Dan (Dan)" > To: =3B "radext mailing list" =3B= =20 > > Sent: Wednesday=2C June 02=2C 2010 10:56 PM > Subject: FEDAUTH BOF request >=20 >=20 > Diameter and RADIUS experts should pay attention to the request to hold > a Federated Authentication (FEDAUTH) BOF which will be discussed this > morning by the IAB and the IESG. >=20 > The Draft Charter is available at > http://www.project-moonshot.org/bof/charter/=2C and more information abou= t > this BOF or other BOF requests can be examined at > http://trac.tools.ietf.org/bof/trac/ >=20 > Dan >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: = --_b105dacf-0e73-4ddb-9eaa-2a8bfde017a9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me provide a bit of =3B context about what I think the problem is h= ere.

As noted by Sam in a previous conversation=2C the basic use ca= se is "cloud services"=2C where an education institution or enterprise is m= aking use of hosted services. =3B In these situations=2C the institutio= n may not just want the service provider to host an application=2C but may = want to keep their credentials local=2C rather than hosting this in the clo= ud as well.

In the original Moonshot investigation=2C Kerberos was = considered as a potential solution. =3B However=2C while Kerberos is we= ll understood from a security point of view=2C and could relatively easily = be modified to support EAP-based pre-auth (numerous proposals for this have= been advanced and in some cases implemented) =3B Kerberos federation h= as not been widely deployed.

One of the basic problems with putting= a KDC on the Internet is that there is no easy way to protect it=2C since = both clients and other KDCs may need to send packets to and from the KDC.&n= bsp=3B For this reason if there are roaming clients there is no easy way to= filter traffic to/from the KDC. =3B In addition=2C the Kerberos protoc= ol is vulnerable to passive attacks in the absence of extensions such as PK= INIT or Kerberos Hardening.

In contrast=2C the AAA roaming model ha= s been widely deployed=2C in part because it is much easier to protect a AA= A server. =3B AAA servers only talk to AAA clients=2C not to users dire= ctly. =3B This means that it is typically possible to filter traffic to= the AAA server so that only packets originating from legitimate AAA client= s can be sent to/from the AAA server. =3B =3B

In addition t= o these basic security issues=2C the AAA delegation model is much simpler t= han Kerberos. =3B Obtaining a Kerberos TGT for a local realm involves f= irst obtaining a TGT from a "home" realm and then requesting a TGT for the = local realm. =3B This involves multiple exchanges=2C and as noted earli= er requires both the local KDC and the home KDC to be available over the In= ternet. =3B In contrast=2C a AAA client implicitly delegates authority = to the AAA server for the Accept/Reject decision=2C so that explicit trust = relationships don't need to be configured. =3B As long as the AAA clien= t can reach the AAA server via a chain of proxies the trust relationship ca= n succeed.

Given these basic characteristics of Kerberos and AAA de= legation=2C the Moonshot team has decided that a AAA-based approach to dele= gation is more likely to be widely deployed than a Kerberos-based one. = =3B My take on this is that this assessment is probably realistic.

= Where I get lost is making the leap between the AAA delegation model and us= e of EAP. =3B As we saw with Digest authentication (RFC 5090)=2C it is = possible to extend AAA to support application-layer authentication without = use of EAP. =3B For example=2C using AAA to carry GSS-API payloads woul= d not require much more than defining a GSS-Message attribute. =3B EAP = has no unique properties that make it more suitable for use with AAA. = =3B In fact=2C I would argue that the fit between EAP and AAA has always be= en tenuous at best -- witness the issues encountered in federated EAP authe= ntication that RADSEC has been needed to address. =3B

In partic= ular=2C the problems of EAP auth (e.g. multiple round-trips=2C general frag= ility in federated uses) become highly toxic when applied to Realtime appli= cations such as XMPP and SIP. =3B As we have learned=2C Digest auth (RF= C 5090) has not been widely deployed=2C in part because of concern about th= e additional latency added by a AAA exchange. =3B For users of real-tim= e applications=2C additional latency is a basic=2C non-negotiable goal.&nbs= p=3B If the relatively modest number of exchanges implied by RFC 5090 were = intolerable in realtime applications=2C =3B how can we expect EAP excha= nges (which can involve 4-5 times the number of roundtrips of RFC 5090) to = be deployed? =3B The answer unfortunately=2C is that there is no chance= at all. =3B

So in summary=2C I believe that some aspects of th= e problem statement make sense=2C but that a solution has been chosen prema= turely. =3B The right way to move forward in a situation like this is t= o begin with a problem statement=2C which should include carefully validati= ng the uses cases. =3B
 =3B

>=3B ----- Original Messa= ge -----
>=3B From: "Romascanu=2C Dan (Dan)" <=3Bdromasca@avaya.com= >=3B
>=3B To: <=3Bdime@ietf.org>=3B=3B "radext mailing list" <= =3Bradiusext@ops.ietf.org>=3B=3B
>=3B <=3Baaa-doctors@ietf.org>= =3B
>=3B Sent: Wednesday=2C June 02=2C 2010 10:56 PM
>=3B Subject= : FEDAUTH BOF request
>=3B
>=3B
>=3B Diameter and RADIUS e= xperts should pay attention to the request to hold
>=3B a Federated Au= thentication (FEDAUTH) BOF which will be discussed this
>=3B morning b= y the IAB and the IESG.
>=3B
>=3B The Draft Charter is available= at
>=3B http://www.project-moonshot.org/bof/charter/=2C and more info= rmation about
>=3B this BOF or other BOF requests can be examined at<= br>>=3B http://trac.tools.ietf.org/bof/trac/
>=3B
>=3B Dan
= >=3B
>=3B --
>=3B to unsubscribe send a message to radiusext-r= equest@ops.ietf.org with
>=3B the word 'unsubscribe' in a single line = as the message text body.
>=3B archive: <=3Bhttp://psg.com/lists/rad= iusext/>=3B
>=3B
>=3B
>=3B
>=3B --
>=3B to un= subscribe send a message to radiusext-request@ops.ietf.org with
>=3B t= he word 'unsubscribe' in a single line as the message text body.
>=3B = archive: <=3Bhttp://psg.com/lists/radiusext/>=3B
= --_b105dacf-0e73-4ddb-9eaa-2a8bfde017a9_-- From Wolfgang.Steigerwald@telekom.de Thu Jun 3 00:16:54 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DCE3A6867; Thu, 3 Jun 2010 00:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVYZbB-zivXe; Thu, 3 Jun 2010 00:16:52 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 121773A6850; Thu, 3 Jun 2010 00:16:51 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 03 Jun 2010 09:16:33 +0200 Received: from S4DE9JSAAII.ost.t-com.de ([10.125.177.194]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Jun 2010 09:16: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, 3 Jun 2010 09:16:28 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FEDAUTH BOF request Thread-Index: AcsC0aidQ02izmSBSNyywMJWJZ76pQAGbcXg References: From: To: , , , , X-OriginalArrivalTime: 03 Jun 2010 07:16:33.0338 (UTC) FILETIME=[B213F1A0:01CB02EC] Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 07:16:54 -0000 Hello Tina, what assumption let you think RADIUS is more suitable then DIAMETER? = DIAMETER is much more developed, is a peer to peer protocol, designed to = transport also structured data, not as limited on payload and therefore = much better suitable for the purpose of IdM. Best Regards Wolfgang -----Urspr=FCngliche Nachricht----- Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im Auftrag von = Tina TSOU Gesendet: Donnerstag, 3. Juni 2010 06:03 An: aaa-doctors@ietf.org; radext mailing list; dime@ietf.org; Romascanu, = Dan (Dan) Betreff: Re: [Dime] FEDAUTH BOF request Comments are below. 1. This might be of interest to ngHLR (Unified Subscriber Center) kind = of=20 solutions who provide Identity Management services 2. From protocol side, I think it may be more interesting for RADIUS as = I=20 doubt the suitability of Diameter for this. B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message -----=20 From: "Romascanu, Dan (Dan)" To: ; "radext mailing list" ;=20 Sent: Wednesday, June 02, 2010 10:56 PM Subject: FEDAUTH BOF request Diameter and RADIUS experts should pay attention to the request to hold a Federated Authentication (FEDAUTH) BOF which will be discussed this morning by the IAB and the IESG. The Draft Charter is available at http://www.project-moonshot.org/bof/charter/, and more information about this BOF or other BOF requests can be examined at http://trac.tools.ietf.org/bof/trac/ Dan -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From hannes.tschofenig@nsn.com Thu Jun 3 00:18:13 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA683A689B; Thu, 3 Jun 2010 00:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=1.330, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KujAOA5E7Tvk; Thu, 3 Jun 2010 00:18:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 389193A6850; Thu, 3 Jun 2010 00:18:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o537HoDM030181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Jun 2010 09:17:51 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o537HoWH012859; Thu, 3 Jun 2010 09:17:50 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Jun 2010 09:17:50 +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, 3 Jun 2010 10:18:00 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502A8093D@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FEDAUTH BOF request Thread-Index: AcsC0aidQ02izmSBSNyywMJWJZ76pQAGbcXgAABgRDA= References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , , , , X-OriginalArrivalTime: 03 Jun 2010 07:17:50.0524 (UTC) FILETIME=[E01597C0:01CB02EC] Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 07:18:13 -0000 Looking forward to hear that answer as well :-)=20 >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of ext Wolfgang.Steigerwald@telekom.de >Sent: 03 June, 2010 10:16 >To: tena@huawei.com; aaa-doctors@ietf.org;=20 >radiusext@ops.ietf.org; dime@ietf.org; dromasca@avaya.com >Subject: Re: [Dime] FEDAUTH BOF request > >Hello Tina, > >what assumption let you think RADIUS is more suitable then=20 >DIAMETER? DIAMETER is much more developed, is a peer to peer=20 >protocol, designed to transport also structured data, not as=20 >limited on payload and therefore much better suitable for the=20 >purpose of IdM. > >Best Regards > > Wolfgang > >-----Urspr=FCngliche Nachricht----- >Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im=20 >Auftrag von Tina TSOU >Gesendet: Donnerstag, 3. Juni 2010 06:03 >An: aaa-doctors@ietf.org; radext mailing list; dime@ietf.org;=20 >Romascanu, Dan (Dan) >Betreff: Re: [Dime] FEDAUTH BOF request > >Comments are below. >1. This might be of interest to ngHLR (Unified Subscriber=20 >Center) kind of solutions who provide Identity Management=20 >services 2. From protocol side, I think it may be more=20 >interesting for RADIUS as I doubt the suitability of Diameter for this. > >B. R. >Tina >http://tinatsou.weebly.com/contact.html > >----- Original Message ----- >From: "Romascanu, Dan (Dan)" >To: ; "radext mailing list"=20 >; >Sent: Wednesday, June 02, 2010 10:56 PM >Subject: FEDAUTH BOF request > > >Diameter and RADIUS experts should pay attention to the=20 >request to hold a Federated Authentication (FEDAUTH) BOF which=20 >will be discussed this morning by the IAB and the IESG. > >The Draft Charter is available at >http://www.project-moonshot.org/bof/charter/, and more=20 >information about this BOF or other BOF requests can be=20 >examined at http://trac.tools.ietf.org/bof/trac/ > >Dan > >-- >to unsubscribe send a message to=20 >radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 >a single line as the message text body. >archive: > > >_______________________________________________ >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 tena@huawei.com Thu Jun 3 06:54:57 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6273A67D4; Thu, 3 Jun 2010 06:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.009 X-Spam-Level: X-Spam-Status: No, score=-100.009 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT2bo6gFiRCX; Thu, 3 Jun 2010 06:54:56 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B483E3A67AD; Thu, 3 Jun 2010 06:54:55 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F001D1YMWQD@szxga05-in.huawei.com>; Thu, 03 Jun 2010 21:54:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F005QIYMV0K@szxga05-in.huawei.com>; Thu, 03 Jun 2010 21:54:31 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3F00F79YMVTB@szxml04-in.huawei.com>; Thu, 03 Jun 2010 21:54:31 +0800 (CST) Date: Thu, 03 Jun 2010 21:54:28 +0800 From: Tina TSOU To: dromasca@avaya.com, dime@ietf.org, radiusext@ops.ietf.org, aaa-doctors@ietf.org, Bernard Aboba Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: multipart/alternative; boundary="Boundary_(ID_6hv+ML6mj+wcKfSI/Z8TQg)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 13:54:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6hv+ML6mj+wcKfSI/Z8TQg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Bernard, Comments are in line. B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Bernard Aboba To: tena@huawei.com ; aaa-doctors@ietf.org ; radiusext@ops.ietf.org ; dime@ietf.org ; dromasca@avaya.com Sent: Thursday, June 03, 2010 1:03 PM Subject: RE: FEDAUTH BOF request Tina said: > Comments are below. > 1. This might be of interest to ngHLR (Unified Subscriber Center) kind of > solutions who provide Identity Management services > 2. From protocol side, I think it may be more interesting for RADIUS as I doubt the suitability of Diameter for this. Not sure why RADIUS would be more suitable than Diameter for carrying large payloads such as SAML assertions. The 4096 octet RADIUS PDU limit is not transport-specific -- that is, transporting the RADIUS payload over TCP does not solve the problem. [Tina: You are also right from the aspect you raised. Diameter roaming model is well established (in use cases like WLAN-3GPP interworking) without the use of EAP or SAML. I fail to see what would be the benefits of using EAP or SAML with Diameter which the current roaming model does not already have. Everything has pros and cons, as you said in another email, let's begin with a problem statement, and then protocols.] > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: ; "radext mailing list" ; > > Sent: Wednesday, June 02, 2010 10:56 PM > Subject: FEDAUTH BOF request > > > Diameter and RADIUS experts should pay attention to the request to hold > a Federated Authentication (FEDAUTH) BOF which will be discussed this > morning by the IAB and the IESG. > > The Draft Charter is available at > http://www.project-moonshot.org/bof/charter/, and more information about > this BOF or other BOF requests can be examined at > http://trac.tools.ietf.org/bof/trac/ > > Dan > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --Boundary_(ID_6hv+ML6mj+wcKfSI/Z8TQg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Bernard,
Comments are in line.
 
----- Original Message -----
Sent: Thursday, June 03, 2010 1:03 PM
Subject: RE: FEDAUTH BOF request

Tina said:

> Comments are below.
> 1. This might be of interest to ngHLR (Unified Subscriber Center) kind of
> solutions who provide Identity Management services
> 2. From protocol side, I think it may be more interesting for RADIUS as I  doubt the suitability of Diameter for this.

Not sure why RADIUS would be more suitable than Diameter for carrying large payloads such as SAML assertions.  The 4096 octet RADIUS PDU limit is not transport-specific -- that is, transporting the RADIUS payload over TCP does not solve the problem. 
 
[Tina: You are also right from the aspect you raised.
Diameter roaming model is well established (in use cases like WLAN-3GPP interworking) without the use of EAP or SAML. I fail to see what would be the benefits of using EAP or SAML with Diameter which the current roaming model does not already have.
Everything has pros and cons, as you said in another email, let's begin with a problem statement, and then protocols.]


 
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> To: <dime@ietf.org>; "radext mailing list" <radiusext@ops.ietf.org>;
> <aaa-doctors@ietf.org>
> Sent: Wednesday, June 02, 2010 10:56 PM
> Subject: FEDAUTH BOF request
>
>
> Diameter and RADIUS experts should pay attention to the request to hold
> a Federated Authentication (FEDAUTH) BOF which will be discussed this
> morning by the IAB and the IESG.
>
> The Draft Charter is available at
> http://www.project-moonshot.org/bof/charter/, and more information about
> this BOF or other BOF requests can be examined at
> http://trac.tools.ietf.org/bof/trac/
>
> Dan
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>
>
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
--Boundary_(ID_6hv+ML6mj+wcKfSI/Z8TQg)-- From tena@huawei.com Thu Jun 3 06:58:24 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC6E3A67D4; Thu, 3 Jun 2010 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.203 X-Spam-Level: X-Spam-Status: No, score=-100.203 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAG9DWL7aWLX; Thu, 3 Jun 2010 06:58:23 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C1C783A67AD; Thu, 3 Jun 2010 06:58:23 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F004TIYSOWK@szxga01-in.huawei.com>; Thu, 03 Jun 2010 21:58:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3F00KOGYSOYD@szxga01-in.huawei.com>; Thu, 03 Jun 2010 21:58:00 +0800 (CST) Received: from z00147053k ([10.70.39.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3F00FSMYSMTB@szxml04-in.huawei.com>; Thu, 03 Jun 2010 21:58:00 +0800 (CST) Date: Thu, 03 Jun 2010 21:57:56 +0800 From: Tina TSOU To: dromasca@avaya.com, dime@ietf.org, radiusext@ops.ietf.org, aaa-doctors@ietf.org, Wolfgang.Steigerwald@telekom.de, "Tschofenig, Hannes (NSN - FI/Espoo)" Message-id: <87BAC297AD614E1E8E885DA28CA60DD2@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: <3D3C75174CB95F42AD6BCC56E5555B4502A8093D@FIESEXC015.nsn-intra.net> Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 13:58:24 -0000 Hi Wolfgang and Hannes, You are also right from the good nature of Diameter. I just mentioned one possible interesting point in my previous email replying to Bernard et al. B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: ; ; ; ; ; Sent: Thursday, June 03, 2010 3:18 PM Subject: RE: [Dime] FEDAUTH BOF request Looking forward to hear that answer as well :-) >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Wolfgang.Steigerwald@telekom.de >Sent: 03 June, 2010 10:16 >To: tena@huawei.com; aaa-doctors@ietf.org; >radiusext@ops.ietf.org; dime@ietf.org; dromasca@avaya.com >Subject: Re: [Dime] FEDAUTH BOF request > >Hello Tina, > >what assumption let you think RADIUS is more suitable then >DIAMETER? DIAMETER is much more developed, is a peer to peer >protocol, designed to transport also structured data, not as >limited on payload and therefore much better suitable for the >purpose of IdM. > >Best Regards > > Wolfgang > >-----Ursprüngliche Nachricht----- >Von: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] Im >Auftrag von Tina TSOU >Gesendet: Donnerstag, 3. Juni 2010 06:03 >An: aaa-doctors@ietf.org; radext mailing list; dime@ietf.org; >Romascanu, Dan (Dan) >Betreff: Re: [Dime] FEDAUTH BOF request > >Comments are below. >1. This might be of interest to ngHLR (Unified Subscriber >Center) kind of solutions who provide Identity Management >services 2. From protocol side, I think it may be more >interesting for RADIUS as I doubt the suitability of Diameter for this. > >B. R. >Tina >http://tinatsou.weebly.com/contact.html > >----- Original Message ----- >From: "Romascanu, Dan (Dan)" >To: ; "radext mailing list" >; >Sent: Wednesday, June 02, 2010 10:56 PM >Subject: FEDAUTH BOF request > > >Diameter and RADIUS experts should pay attention to the >request to hold a Federated Authentication (FEDAUTH) BOF which >will be discussed this morning by the IAB and the IESG. > >The Draft Charter is available at >http://www.project-moonshot.org/bof/charter/, and more >information about this BOF or other BOF requests can be >examined at http://trac.tools.ietf.org/bof/trac/ > >Dan > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > > >_______________________________________________ >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 hannes.tschofenig@nsn.com Thu Jun 3 07:24:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35783A685A; Thu, 3 Jun 2010 07:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR908b02uyqX; Thu, 3 Jun 2010 07:24:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 90C423A680E; Thu, 3 Jun 2010 07:24:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o53EOR0D022994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Jun 2010 16:24:27 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o53EOOoo024469; Thu, 3 Jun 2010 16:24:27 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Jun 2010 16:23:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0328.59FB5FAD" Date: Thu, 3 Jun 2010 17:23:48 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502ABE0A5@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] FEDAUTH BOF request Thread-Index: AcsDJFV6M+HC0wk3SHCL7LKaHUNzSAAA4e5g References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Tina TSOU" , , , , , "Bernard Aboba" X-OriginalArrivalTime: 03 Jun 2010 14:23:36.0044 (UTC) FILETIME=[5A669AC0:01CB0328] Subject: Re: [Dime] [AAA-DOCTORS] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 14:24:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0328.59FB5FAD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The idea these folks have, if I understood it correctly, is to use SAML assertion mainly as a container for the attributes inside it.=20 =20 In some sense one could argue that it is also not too complicated to carry the actual attributes in Diameter itself (encoded in Diameter AVP format instead of using an XML-based encoding). =20 Ciao Hannes =20 ________________________________ From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of ext Tina TSOU Sent: 03 June, 2010 16:54 To: dromasca@avaya.com; dime@ietf.org; radiusext@ops.ietf.org; aaa-doctors@ietf.org; Bernard Aboba Subject: Re: [AAA-DOCTORS] FEDAUTH BOF request =09 =09 Hi Bernard, Comments are in line. =20 B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message -----=20 From: Bernard Aboba =20 To: tena@huawei.com ; aaa-doctors@ietf.org ; radiusext@ops.ietf.org ; dime@ietf.org ; dromasca@avaya.com=20 Sent: Thursday, June 03, 2010 1:03 PM Subject: RE: FEDAUTH BOF request Tina said:=20 =09 > Comments are below. > 1. This might be of interest to ngHLR (Unified Subscriber Center) kind of=20 > solutions who provide Identity Management services > 2. From protocol side, I think it may be more interesting for RADIUS as I doubt the suitability of Diameter for this. =09 Not sure why RADIUS would be more suitable than Diameter for carrying large payloads such as SAML assertions. The 4096 octet RADIUS PDU limit is not transport-specific -- that is, transporting the RADIUS payload over TCP does not solve the problem.=20 =20 [Tina: You are also right from the aspect you raised. Diameter roaming model is well established (in use cases like WLAN-3GPP interworking) without the use of EAP or SAML. I fail to see what would be the benefits of using EAP or SAML with Diameter which the current roaming model does not already have. Everything has pros and cons, as you said in another email, let's begin with a problem statement, and then protocols.] =09 =09 =20 > ----- Original Message -----=20 > From: "Romascanu, Dan (Dan)" > To: ; "radext mailing list" ;=20 > > Sent: Wednesday, June 02, 2010 10:56 PM > Subject: FEDAUTH BOF request >=20 >=20 > Diameter and RADIUS experts should pay attention to the request to hold > a Federated Authentication (FEDAUTH) BOF which will be discussed this > morning by the IAB and the IESG. >=20 > The Draft Charter is available at > http://www.project-moonshot.org/bof/charter/, and more information about > this BOF or other BOF requests can be examined at > http://trac.tools.ietf.org/bof/trac/ >=20 > Dan >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: =09 ------_=_NextPart_001_01CB0328.59FB5FAD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The idea these folks have, if I understood it = correctly, is=20 to use SAML assertion mainly as a container for the attributes inside = it.=20
 
In some sense one could argue that it is also = not too=20 complicated to carry the actual attributes in Diameter itself (encoded = in=20 Diameter AVP format instead of using an XML-based = encoding).
 
Ciao
Hannes
 

From: aaa-doctors-bounces@ietf.org = [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of ext Tina=20 TSOU
Sent: 03 June, 2010 16:54
To: = dromasca@avaya.com;=20 dime@ietf.org; radiusext@ops.ietf.org; aaa-doctors@ietf.org; Bernard=20 Aboba
Subject: Re: [AAA-DOCTORS] FEDAUTH BOF=20 request

Hi Bernard,
Comments are in = line.
 
B. R.
Tina
http://tinatsou.weebly.c= om/contact.html
----- Original Message -----
From:=20 Bernard Aboba
To: tena@huawei.com ; aaa-doctors@ietf.org ; radiusext@ops.ietf.org ; = dime@ietf.org ; dromasca@avaya.com
Sent: Thursday, June 03, 2010 = 1:03=20 PM
Subject: RE: FEDAUTH BOF = request

Tina said:

> Comments are below.
> 1. This = might be of=20 interest to ngHLR (Unified Subscriber Center) kind of
> = solutions who=20 provide Identity Management services
> 2. From protocol side, = I think=20 it may be more interesting for RADIUS as I  doubt the = suitability of=20 Diameter for this.

Not sure why RADIUS would be more suitable = than=20 Diameter for carrying large payloads such as SAML assertions.  = The 4096=20 octet RADIUS PDU limit is not transport-specific -- that is, = transporting=20 the RADIUS payload over TCP does not solve the problem. 
 
[Tina: You are also right = from the=20 aspect you raised.
Diameter roaming model is = well=20 established (in use cases like WLAN-3GPP interworking) without the = use of=20 EAP or SAML. I fail to see what would be the benefits of using EAP = or SAML=20 with Diameter which the current roaming model does not already=20 have.
Everything has pros = and cons, as=20 you said in another email, let's begin with a problem statement, and = then=20 protocols.]


 
> ----- Original = Message=20 -----
> From: "Romascanu, Dan (Dan)"=20 <dromasca@avaya.com>
> To: <dime@ietf.org>; = "radext=20 mailing list" <radiusext@ops.ietf.org>;
>=20 <aaa-doctors@ietf.org>
> Sent: Wednesday, June 02, 2010 = 10:56=20 PM
> Subject: FEDAUTH BOF request
>
>
> = Diameter=20 and RADIUS experts should pay attention to the request to = hold
> a=20 Federated Authentication (FEDAUTH) BOF which will be discussed = this
>=20 morning by the IAB and the IESG.
>
> The Draft Charter = is=20 available at
> http://www.project-moonshot.org/bof/charter/, = and more=20 information about
> this BOF or other BOF requests can be = examined=20 at
> http://trac.tools.ietf.org/bof/trac/
>
> = Dan
>=20
> --
> to unsubscribe send a message to=20 radiusext-request@ops.ietf.org with
> the word 'unsubscribe' = in a=20 single line as the message text body.
> archive:=20 <http://psg.com/lists/radiusext/>
>
>
> =
>=20 --
> to unsubscribe send a message to = radiusext-request@ops.ietf.org=20 with
> the word 'unsubscribe' in a single line as the message = text=20 body.
> archive:=20 = <http://psg.com/lists/radiusext/>
------_=_NextPart_001_01CB0328.59FB5FAD-- From lionel.morand@orange-ftgroup.com Thu Jun 3 16:59:03 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB763A6862 for ; Thu, 3 Jun 2010 16:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFMbmuQD-R69 for ; Thu, 3 Jun 2010 16:59:02 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2724B3A6813 for ; Thu, 3 Jun 2010 16:59:02 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EE18057C298 for ; Fri, 4 Jun 2010 01:58:51 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id E5F6E57C292 for ; Fri, 4 Jun 2010 01:58:51 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 01:58:43 +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: Fri, 4 Jun 2010 01:58:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 78 - Meeting and Sponsorship Information Thread-Index: AcsDVjuIlllrqRnYT0S+Ebr1Ubm0JwAIjv6A From: To: X-OriginalArrivalTime: 03 Jun 2010 23:58:43.0354 (UTC) FILETIME=[B25C3FA0:01CB0378] Subject: [Dime] IETF 78 - Meeting and Sponsorship Information X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 23:59:03 -0000 =20 FYI. Jouni & Lionel =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010=20 =20 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html Sponsorship Opportunities under General. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. =20 Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organizations spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! From alper.yegin@yegin.org Fri Jun 4 00:31:50 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2473A6A26; Fri, 4 Jun 2010 00:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.451 X-Spam-Level: * X-Spam-Status: No, score=1.451 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq6I6RsV8qsx; Fri, 4 Jun 2010 00:31:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 6352D3A6926; Fri, 4 Jun 2010 00:31:42 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MY7Qm-1OpI2f3O8u-00VID5; Fri, 04 Jun 2010 03:31:26 -0400 From: "Alper Yegin" To: "'Bernard Aboba'" , , , , , References: , In-Reply-To: Date: Fri, 4 Jun 2010 10:30:58 +0300 Message-ID: <019f01cb03b7$e63fcaf0$b2bf60d0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A0_01CB03D1.0B8D02F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsC3Vu3xwQsiPtKT8+vfB1gbF+XiAA2UOhg Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18y1cDDDbHwzc0rK+re1041lchS1Dg/3U9B3ek zrDOUvkjOhWErTfZBgfmWbJCOxwOu3DJT47CFQbCimRLqJVL6u OOecGjtXfoBXG9HHEBhW97gRdtYxZyP Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 07:31:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A0_01CB03D1.0B8D02F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In particular, the problems of EAP auth (e.g. multiple round-trips, general fragility in federated uses) become highly toxic when applied to Realtime applications such as XMPP and SIP. As we have learned, Digest auth (RFC 5090) has not been widely deployed, in part because of concern about the additional latency added by a AAA exchange. For users of real-time applications, additional latency is a basic, non-negotiable goal. If the relatively modest number of exchanges implied by RFC 5090 were intolerable in realtime applications, how can we expect EAP exchanges (which can involve 4-5 times the number of roundtrips of RFC 5090) to be deployed? The answer unfortunately, is that there is no chance at all. So in summary, I believe that some aspects of the problem statement make sense, but that a solution has been chosen prematurely. The right way to move forward in a situation like this is to begin with a problem statement, which should include carefully validating the uses cases. Alper> I agree. Alper> Anyone who was around the ICOS BoF in IETF 62 would remember that the community was convinced(!) that using EAP for anything other than network access was a no-no. Now before we embark on marching in 180-degree opposite direction, I'd say the community needs to be "unconvinced" first. I'm not saying this is not doable, but something we need to go through first. Alper > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: ; "radext mailing list" ; > > Sent: Wednesday, June 02, 2010 10:56 PM > Subject: FEDAUTH BOF request > > > Diameter and RADIUS experts should pay attention to the request to hold > a Federated Authentication (FEDAUTH) BOF which will be discussed this > morning by the IAB and the IESG. > > The Draft Charter is available at > http://www.project-moonshot.org/bof/charter/, and more information about > this BOF or other BOF requests can be examined at > http://trac.tools.ietf.org/bof/trac/ > > Dan > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_01A0_01CB03D1.0B8D02F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


In particular, the problems of EAP auth (e.g. multiple round-trips, = general fragility in federated uses) become highly toxic when applied to = Realtime applications such as XMPP and SIP.  As we have learned, Digest auth = (RFC 5090) has not been widely deployed, in part because of concern about the additional latency added by a AAA exchange.  For users of real-time applications, additional latency is a basic, non-negotiable goal.  = If the relatively modest number of exchanges implied by RFC 5090 were = intolerable in realtime applications,  how can we expect EAP exchanges (which can = involve 4-5 times the number of roundtrips of RFC 5090) to be deployed?  = The answer unfortunately, is that there is no chance at all. 

So in summary, I believe that some aspects of the problem statement make = sense, but that a solution has been chosen prematurely.  The right way to = move forward in a situation like this is to begin with a problem statement, = which should include carefully validating the uses cases. 

 

 

Alper> I agree.

 

Alper> Anyone who was around the ICOS BoF in IETF 62 = would remember that the community was convinced(!) that using EAP for anything = other than network access was a no-no. Now before we embark on marching in =  180-degree opposite direction, I’d say the community needs to be = “unconvinced” first. I’m not saying this is not doable, but something we need to = go through first.

 

Alper

 

 

 

> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" = <dromasca@avaya.com>
> To: <dime@ietf.org>; "radext mailing list" <radiusext@ops.ietf.org>;
> <aaa-doctors@ietf.org>
> Sent: Wednesday, June 02, 2010 10:56 PM
> Subject: FEDAUTH BOF request
>
>
> Diameter and RADIUS experts should pay attention to the request to = hold
> a Federated Authentication (FEDAUTH) BOF which will be discussed = this
> morning by the IAB and the IESG.
>
> The Draft Charter is available at
> http://www.project-moonshot.org/bof/charter/, and more information = about
> this BOF or other BOF requests can be examined at
> http://trac.tools.ietf.org/bof/trac/
>
> Dan
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org = with
> the word 'unsubscribe' in a single line as the message text = body.
> archive: <http://psg.com/lists/radiusext/>
>
>
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org = with
> the word 'unsubscribe' in a single line as the message text = body.
> archive: = <http://psg.com/lists/radiusext/>

------=_NextPart_000_01A0_01CB03D1.0B8D02F0-- From jsalowey@cisco.com Fri Jun 4 10:11:43 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F7A3A68F2; Fri, 4 Jun 2010 10:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.051 X-Spam-Level: X-Spam-Status: No, score=-9.051 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTcwQkkAWDSp; Fri, 4 Jun 2010 10:11:39 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 95A993A6874; Fri, 4 Jun 2010 10:11:37 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEfQCEyrRN+K/2dsb2JhbACeRnGlSJoRgl+COASDSYM5 X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="139524287" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Jun 2010 17:11:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o54HBN6O004272; Fri, 4 Jun 2010 17:11:23 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 10:11:23 -0700 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: Fri, 4 Jun 2010 10:11:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FEDAUTH BOF request Thread-Index: AcsC3V6qlMZy6lk0TKacZwhNYrbcbgBJ7grw References: , From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , , , , , X-OriginalArrivalTime: 04 Jun 2010 17:11:23.0825 (UTC) FILETIME=[F5ADD210:01CB0408] Subject: Re: [Dime] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 17:11:43 -0000 I agree with a lot of what Bernard says below. For better or for worse EAP is closely associated with AAA. The fit may be odd in some cases, but deployments have found success in making it work. This is why it is attractive. I don't think that replacing EAP in AAA with some other framework, such as GSSAPI, is going to lead to better results. It is true that along the way modifications, such as RADSEC, have been deployed to make things work better. It is risky to assume that AAA and EAP can be successfully applied to any arbitrary scenario without a firm grip on the use cases. If at the end of the design you end up with something that is called EAP and AAA, but actually is completely different you will lose the perceived advantage of building on top of existing AAA and EAP infrastructure I'm not as convinced as Bernard that it can't work, but I think there needs to be a firm understanding of the use cases to determine what is required to deliver a solution and what changes may be necessary. =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Bernard Aboba > Sent: Wednesday, June 02, 2010 10:26 PM > To: tena@huawei.com; aaa-doctors@ietf.org; radiusext@ops.ietf.org; > dime@ietf.org; dromasca@avaya.com > Subject: Re: [Dime] FEDAUTH BOF request >=20 > Let me provide a bit of context about what I think the problem is here. >=20 > As noted by Sam in a previous conversation, the basic use case is "cloud > services", where an education institution or enterprise is making use of > hosted services. In these situations, the institution may not just want > the service provider to host an application, but may want to keep their > credentials local, rather than hosting this in the cloud as well. >=20 > In the original Moonshot investigation, Kerberos was considered as a > potential solution. However, while Kerberos is well understood from a > security point of view, and could relatively easily be modified to support > EAP-based pre-auth (numerous proposals for this have been advanced and in > some cases implemented) Kerberos federation has not been widely deployed. >=20 > One of the basic problems with putting a KDC on the Internet is that there > is no easy way to protect it, since both clients and other KDCs may need > to send packets to and from the KDC. For this reason if there are roaming > clients there is no easy way to filter traffic to/from the KDC. In > addition, the Kerberos protocol is vulnerable to passive attacks in the > absence of extensions such as PKINIT or Kerberos Hardening. >=20 > In contrast, the AAA roaming model has been widely deployed, in part > because it is much easier to protect a AAA server. AAA servers only talk > to AAA clients, not to users directly. This means that it is typically > possible to filter traffic to the AAA server so that only packets > originating from legitimate AAA clients can be sent to/from the AAA > server. >=20 > In addition to these basic security issues, the AAA delegation model is > much simpler than Kerberos. Obtaining a Kerberos TGT for a local realm > involves first obtaining a TGT from a "home" realm and then requesting a > TGT for the local realm. This involves multiple exchanges, and as noted > earlier requires both the local KDC and the home KDC to be available over > the Internet. In contrast, a AAA client implicitly delegates authority to > the AAA server for the Accept/Reject decision, so that explicit trust > relationships don't need to be configured. As long as the AAA client can > reach the AAA server via a chain of proxies the trust relationship can > succeed. >=20 > Given these basic characteristics of Kerberos and AAA delegation, the > Moonshot team has decided that a AAA-based approach to delegation is more > likely to be widely deployed than a Kerberos-based one. My take on this > is that this assessment is probably realistic. >=20 > Where I get lost is making the leap between the AAA delegation model and > use of EAP. As we saw with Digest authentication (RFC 5090), it is > possible to extend AAA to support application-layer authentication without > use of EAP. For example, using AAA to carry GSS-API payloads would not > require much more than defining a GSS-Message attribute. EAP has no > unique properties that make it more suitable for use with AAA. In fact, I > would argue that the fit between EAP and AAA has always been tenuous at > best -- witness the issues encountered in federated EAP authentication > that RADSEC has been needed to address. >=20 > In particular, the problems of EAP auth (e.g. multiple round-trips, > general fragility in federated uses) become highly toxic when applied to > Realtime applications such as XMPP and SIP. As we have learned, Digest > auth (RFC 5090) has not been widely deployed, in part because of concern > about the additional latency added by a AAA exchange. For users of real- > time applications, additional latency is a basic, non-negotiable goal. If > the relatively modest number of exchanges implied by RFC 5090 were > intolerable in realtime applications, how can we expect EAP exchanges > (which can involve 4-5 times the number of roundtrips of RFC 5090) to be > deployed? The answer unfortunately, is that there is no chance at all. >=20 [Joe]=20 > So in summary, I believe that some aspects of the problem statement make > sense, but that a solution has been chosen prematurely. The right way to > move forward in a situation like this is to begin with a problem > statement, which should include carefully validating the uses cases. >=20 >=20 > > ----- Original Message ----- > > From: "Romascanu, Dan (Dan)" > > To: ; "radext mailing list" ; > > > > Sent: Wednesday, June 02, 2010 10:56 PM > > Subject: FEDAUTH BOF request > > > > > > Diameter and RADIUS experts should pay attention to the request to > > hold a Federated Authentication (FEDAUTH) BOF which will be discussed > > this morning by the IAB and the IESG. > > > > The Draft Charter is available at > > http://www.project-moonshot.org/bof/charter/, and more information > > about this BOF or other BOF requests can be examined at > > http://trac.tools.ietf.org/bof/trac/ > > > > Dan > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > > > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: From bernard_aboba@hotmail.com Mon Jun 7 08:38:11 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF1C3A6826; Mon, 7 Jun 2010 08:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q2beLdh+7BT; Mon, 7 Jun 2010 08:37:37 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by core3.amsl.com (Postfix) with ESMTP id 81C753A86AD; Sun, 6 Jun 2010 09:13:18 -0700 (PDT) Received: from BLU137-DS5 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 6 Jun 2010 09:13:18 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alper Yegin'" , , , , , References: , <019f01cb03b7$e63fcaf0$b2bf60d0$@yegin@yegin.org> In-Reply-To: <019f01cb03b7$e63fcaf0$b2bf60d0$@yegin@yegin.org> Date: Sun, 6 Jun 2010 09:13:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CB0558.818885A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsC3Vu3xwQsiPtKT8+vfB1gbF+XiAA2UOhgAHbjbHA= Content-Language: en-us X-OriginalArrivalTime: 06 Jun 2010 16:13:18.0263 (UTC) FILETIME=[2CF2C470:01CB0593] Subject: Re: [Dime] [AAA-DOCTORS] FEDAUTH BOF request X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:38:12 -0000 ------=_NextPart_000_001C_01CB0558.818885A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Previous tests have shown problems with use of RADIUS/EAP over UDP in federated scenarios: http://www.cesnet.cz/doc/techzpravy/2008/eduroam-authentication-over-jammed- network/ As noted in the above paper, once packet loss is introduced, completing the multiple roundtrips of EAP authentication becomes increasingly difficult. RADIUS over TCP holds up much better until a threshold is reached, and then authentication success fractions fall dramatically. Due to the transport issues and RADIUS packet size limitation of 4096 (which may impact the ability to transport SAML assertions), it seems like Diameter would be more suitable. From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Friday, June 04, 2010 12:31 AM To: 'Bernard Aboba'; tena@huawei.com; aaa-doctors@ietf.org; radiusext@ops.ietf.org; dime@ietf.org; dromasca@avaya.com Subject: Re: [AAA-DOCTORS] [Dime] FEDAUTH BOF request In particular, the problems of EAP auth (e.g. multiple round-trips, general fragility in federated uses) become highly toxic when applied to Realtime applications such as XMPP and SIP. As we have learned, Digest auth (RFC 5090) has not been widely deployed, in part because of concern about the additional latency added by a AAA exchange. For users of real-time applications, additional latency is a basic, non-negotiable goal. If the relatively modest number of exchanges implied by RFC 5090 were intolerable in realtime applications, how can we expect EAP exchanges (which can involve 4-5 times the number of roundtrips of RFC 5090) to be deployed? The answer unfortunately, is that there is no chance at all. So in summary, I believe that some aspects of the problem statement make sense, but that a solution has been chosen prematurely. The right way to move forward in a situation like this is to begin with a problem statement, which should include carefully validating the uses cases. Alper> I agree. Alper> Anyone who was around the ICOS BoF in IETF 62 would remember that the community was convinced(!) that using EAP for anything other than network access was a no-no. Now before we embark on marching in 180-degree opposite direction, I'd say the community needs to be "unconvinced" first. I'm not saying this is not doable, but something we need to go through first. Alper > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: ; "radext mailing list" ; > > Sent: Wednesday, June 02, 2010 10:56 PM > Subject: FEDAUTH BOF request > > > Diameter and RADIUS experts should pay attention to the request to hold > a Federated Authentication (FEDAUTH) BOF which will be discussed this > morning by the IAB and the IESG. > > The Draft Charter is available at > http://www.project-moonshot.org/bof/charter/, and more information about > this BOF or other BOF requests can be examined at > http://trac.tools.ietf.org/bof/trac/ > > Dan > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_001C_01CB0558.818885A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Previous tests have shown problems with use of RADIUS/EAP = over UDP in federated scenarios:

http://www.cesnet.cz/doc/techzpravy/2008/eduroam-authentic= ation-over-jammed-network/

 

As noted in the above paper, once packet loss is = introduced, completing the multiple roundtrips of EAP authentication becomes increasingly = difficult.

 

RADIUS over TCP holds up much better until a threshold is reached, and then authentication success fractions fall dramatically. =   

 

Due to the transport issues and RADIUS packet size = limitation of 4096 (which may impact the ability to transport SAML assertions), it = seems like Diameter would be more suitable.  

 

 

 

 

From:= aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On = Behalf Of Alper Yegin
Sent: Friday, June 04, 2010 12:31 AM
To: 'Bernard Aboba'; tena@huawei.com; aaa-doctors@ietf.org; radiusext@ops.ietf.org; dime@ietf.org; dromasca@avaya.com
Subject: Re: [AAA-DOCTORS] [Dime] FEDAUTH BOF = request

 


In particular, the problems of EAP auth (e.g. multiple round-trips, = general fragility in federated uses) become highly toxic when applied to = Realtime applications such as XMPP and SIP.  As we have learned, Digest auth = (RFC 5090) has not been widely deployed, in part because of concern about the additional latency added by a AAA exchange.  For users of real-time applications, additional latency is a basic, non-negotiable goal.  = If the relatively modest number of exchanges implied by RFC 5090 were = intolerable in realtime applications,  how can we expect EAP exchanges (which can = involve 4-5 times the number of roundtrips of RFC 5090) to be deployed?  = The answer unfortunately, is that there is no chance at all. 

So in summary, I believe that some aspects of the problem statement make = sense, but that a solution has been chosen prematurely.  The right way to = move forward in a situation like this is to begin with a problem statement, = which should include carefully validating the uses cases. 

 

 

Alper> I agree.

 

Alper> Anyone who was around the ICOS BoF in IETF 62 = would remember that the community was convinced(!) that using EAP for anything = other than network access was a no-no. Now before we embark on marching in  180-degree opposite direction, I’d say the community needs = to be “unconvinced” first. I’m not saying this is not = doable, but something we need to go through first.

 

Alper

 

 

 

> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" = <dromasca@avaya.com>
> To: <dime@ietf.org>; "radext mailing list" <radiusext@ops.ietf.org>;
> <aaa-doctors@ietf.org>
> Sent: Wednesday, June 02, 2010 10:56 PM
> Subject: FEDAUTH BOF request
>
>
> Diameter and RADIUS experts should pay attention to the request to = hold
> a Federated Authentication (FEDAUTH) BOF which will be discussed = this
> morning by the IAB and the IESG.
>
> The Draft Charter is available at
> http://www.project-moonshot.org/bof/charter/, and more information = about
> this BOF or other BOF requests can be examined at
> http://trac.tools.ietf.org/bof/trac/
>
> Dan
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org = with
> the word 'unsubscribe' in a single line as the message text = body.
> archive: <http://psg.com/lists/radiusext/>
>
>
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org = with
> the word 'unsubscribe' in a single line as the message text = body.
> archive: = <http://psg.com/lists/radiusext/>

------=_NextPart_000_001C_01CB0558.818885A0-- From root@core3.amsl.com Mon Jun 14 10:45:22 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 480A13A6977; Mon, 14 Jun 2010 10:45:18 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100614174521.480A13A6977@core3.amsl.com> Date: Mon, 14 Jun 2010 10:45:18 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jun 2010 17:45:24 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Priority Attribute Value Pairs Author(s) : K. Carlberg, T. Taylor Filename : draft-ietf-dime-priority-avps-01.txt Pages : 7 Date : 2010-6-11 This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-priority-avps-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-priority-avps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-14103830.I-D@ietf.org> --NextPart-- From lionel.morand@orange-ftgroup.com Tue Jun 15 03:16:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081043A68AD for ; Tue, 15 Jun 2010 03:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQmjyVud3v6G for ; Tue, 15 Jun 2010 03:16:36 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D4BF23A6893 for ; Tue, 15 Jun 2010 03:16:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A3D1B8B802C; Tue, 15 Jun 2010 12:13:37 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 53FFB8B800B; Tue, 15 Jun 2010 12:12:03 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 12:11:29 +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, 15 Jun 2010 12:11:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additional comments on draft-ietf-dime-priority-avps-00.txt Thread-Index: AcsMcxxo0Uay5f47SyimWqEOwdCNnA== From: To: X-OriginalArrivalTime: 15 Jun 2010 10:11:29.0858 (UTC) FILETIME=[1F72CA20:01CB0C73] Cc: tom.taylor@rogers.com Subject: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 10:16:37 -0000 In addition to the previous comments, here is my feedback on this draft. *************** Section 3.1. The Defending-Priority is set when the reservation has been admitted. The Preemption-Priority of a newly requested reservation is compared with the Defending Priority of a previously admitted flow. The actions taken based upon the result of this comparison are a function of local policy. Here we are describing how to set and use the value conatined in the AVPs and not the AVP itself. Would a simple reference to RFC3181 be enough to know to use this information? This would avoid any possible misalignment... ******************** Section 3.3/section 3.4 ALRP is just another namespace defined in the same Registry. Moreover, there are additional namespace defined in RFC 5478. Would it be simpler to rely on the same AVP to convey the same kind of information. Here is a proposal: The SIP-Resource-Priority AVP is of type Grouped. It provides the Resource-Priority namespace and the Resource-Priority value contained in a SIP Resource-Priority header as defined in [RFC4412]. SIP-Resource-Priority ::=3D < AVP Header: TBD > { SIP-Resource-Priority-Namespace } { SIP-Resource-Priority-Value } The SIP-Resource-Priority-Namespace AVP is of type Grouped. It contains a unique string and the associated numerical value identifying the namespace. SIP-Resource-Priority-Namespace ::=3D < AVP Header: TBD > { SIP-Resource-Priority-Namespace-String } { SIP-Resource-Priority-Namespace-Value } The SIP-Resource-Priority-Namespace-String AVP (AVP Code TBD) is of type UTF8String. The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD) is of type Unsigned32. The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of type Unsigned32. Would it be acceptable? regards Lionel Morand From jgunn6@csc.com Tue Jun 15 05:21:31 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAAB3A6A63; Tue, 15 Jun 2010 05:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.304 X-Spam-Level: X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF3joUG0sG3E; Tue, 15 Jun 2010 05:21:27 -0700 (PDT) Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by core3.amsl.com (Postfix) with ESMTP id EA6AF3A682A; Tue, 15 Jun 2010 05:21:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-164.messagelabs.com!1276604489!8117019!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 16765 invoked from network); 15 Jun 2010 12:21:29 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2010 12:21:29 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o5FCLSPb025895; Tue, 15 Jun 2010 08:21:28 -0400 In-Reply-To: References: To: MIME-Version: 1.0 X-KeepSent: 4D93F050:FDC2B636-85257743:004163F4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Tue, 15 Jun 2010 08:21:24 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF293|April 16, 2010) at 06/15/2010 08:22:03 AM, Serialize complete at 06/15/2010 08:22:03 AM Content-Type: multipart/alternative; boundary="=_alternative 0043E0AD85257743_=" Cc: dime-bounces@ietf.org, dime@ietf.org, tom.taylor@rogers.com Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 12:21:31 -0000 This is a multipart message in MIME format. --=_alternative 0043E0AD85257743_= Content-Type: text/plain; charset="US-ASCII" I do not understand your statement that "ALRP is just another namespace defined in the same Registry." As I understand it, the reason for supporting both RPH and ALRP (even though they contain the same information) is for ease in mapping to or from protocols that use RPH (e.g., SIP) as well as protocols that use ALRP (e.g., RSVP) without having to go through a mapping from text to digits, or vice versa. Your proposal, if I am reading it correctly, would require mapping from the text priority value (e.g., routine, priority, immediate, flash, flash-override) to numerical values. It would also require mapping from the RPH (text) namespace to the ALRP (numerical) namespace (or vice versa) in order to include both. If you are going to go through that mapping , you might as well map the entire RPH into ALRP and be done with it. If you want to avoid the need to map back and forth between text and digits (which I thought was the point), you need to support both RPH (all text) and ALRP (all digits) independently. Janet dime-bounces@ietf.org wrote on 06/15/2010 06:11:24 AM: > [image removed] > > [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt > > lionel.morand > > to: > > dime > > 06/15/2010 06:16 AM > > Sent by: > > dime-bounces@ietf.org > > Cc: > > tom.taylor > > In addition to the previous comments, here is my feedback on this draft. > ... > > Section 3.3/section 3.4 > > ALRP is just another namespace defined in the same Registry. Moreover, > there are additional namespace defined in RFC 5478. Would it be simpler > to rely on the same AVP to convey the same kind of information. > > Here is a proposal: > > The SIP-Resource-Priority AVP is of type Grouped. It provides > the Resource-Priority namespace and the Resource-Priority value > contained in a SIP Resource-Priority header as defined in [RFC4412]. > > SIP-Resource-Priority ::= < AVP Header: TBD > > { SIP-Resource-Priority-Namespace } > { SIP-Resource-Priority-Value } > > The SIP-Resource-Priority-Namespace AVP is of type Grouped. It > contains a unique string and the associated numerical value > identifying the namespace. > > SIP-Resource-Priority-Namespace ::= < AVP Header: TBD > > { SIP-Resource-Priority-Namespace-String > } > { SIP-Resource-Priority-Namespace-Value } > > > The SIP-Resource-Priority-Namespace-String AVP (AVP Code TBD) is > of type UTF8String. > > The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD) is > of type Unsigned32. > > The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of type > Unsigned32. > > Would it be acceptable? > > regards > > Lionel Morand > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --=_alternative 0043E0AD85257743_= Content-Type: text/html; charset="US-ASCII"
I do not understand your statement that   "ALRP is just another namespace defined in the same Registry."  

As I understand it, the reason for supporting both RPH and ALRP (even though they contain the same information) is for ease in mapping to or from protocols that use RPH (e.g., SIP) as well as protocols that use ALRP (e.g., RSVP) without having to go through a mapping from text to digits, or vice versa.

 Your proposal, if I am reading it correctly, would require mapping from the text priority value (e.g., routine, priority, immediate, flash, flash-override) to numerical values.
It would also require  mapping from the RPH (text) namespace to the  ALRP (numerical) namespace (or vice versa) in order to include both.

  If you are going to go through that mapping , you might as well map the entire RPH into ALRP and be done with it.

If you want to avoid the need to map back and forth between text and digits (which I thought was the point), you need to support both RPH (all text) and ALRP (all digits) independently.

Janet

dime-bounces@ietf.org wrote on 06/15/2010 06:11:24 AM:

> [image removed]
>
> [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt
>
> lionel.morand
>
> to:
>
> dime
>
> 06/15/2010 06:16 AM
>
> Sent by:
>
> dime-bounces@ietf.org
>
> Cc:
>
> tom.taylor
>
> In addition to the previous comments, here is my feedback on this draft.
>
...
>
> Section 3.3/section 3.4
>
> ALRP is just another namespace defined in the same Registry. Moreover,
> there are additional namespace defined in RFC 5478. Would it be simpler
> to rely on the same AVP to convey the same kind of information.
>
> Here is a proposal:
>
>    The SIP-Resource-Priority AVP is of type Grouped. It provides
> the Resource-Priority namespace and the Resource-Priority value
> contained in a SIP Resource-Priority header as defined in [RFC4412].
>
>    SIP-Resource-Priority ::= < AVP Header: TBD >
>                          { SIP-Resource-Priority-Namespace }
>                          { SIP-Resource-Priority-Value }
>
>    The SIP-Resource-Priority-Namespace AVP is of type Grouped. It
> contains a unique string and the associated numerical value
> identifying the namespace.
>
>    SIP-Resource-Priority-Namespace ::= < AVP Header: TBD >
>                                { SIP-Resource-Priority-Namespace-String
> }
>                                { SIP-Resource-Priority-Namespace-Value }
>
>
>    The SIP-Resource-Priority-Namespace-String AVP (AVP Code TBD) is
> of type UTF8String.
>
>    The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD) is
> of type Unsigned32.
>
>    The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of type
> Unsigned32.
>
> Would it be acceptable?
>
> regards
>
> Lionel Morand
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
 --=_alternative 0043E0AD85257743_=-- From lionel.morand@orange-ftgroup.com Tue Jun 15 06:11:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE773A681E; Tue, 15 Jun 2010 06:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1bJzOLQaXsB; Tue, 15 Jun 2010 06:11:07 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 3D2483A6828; Tue, 15 Jun 2010 06:11:06 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6328DFC4030; Tue, 15 Jun 2010 15:07:35 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 583CCFC4033; Tue, 15 Jun 2010 15:07:35 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 15:07:18 +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, 15 Jun 2010 15:07:11 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt Thread-Index: AcsMhW7ZkovEcKrrTmOSVHVHcCji/gAAyW3A References: From: To: X-OriginalArrivalTime: 15 Jun 2010 13:07:18.0424 (UTC) FILETIME=[AEE23980:01CB0C8B] Cc: dime-bounces@ietf.org, dime@ietf.org, tom.taylor@rogers.com Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 13:11:08 -0000 Hi Janet, Please see below. Regards, Lionel ________________________________ De : Janet P Gunn [mailto:jgunn6@csc.com]=20 Envoy=E9 : mardi 15 juin 2010 14:21 =C0 : MORAND Lionel RD-CORE-ISS Cc : dime@ietf.org; dime-bounces@ietf.org; tom.taylor@rogers.com Objet : Re: [Dime] Additional comments on = draft-ietf-dime-priority-avps-00.txt =09 =09 I do not understand your statement that "ALRP is just another = namespace defined in the same Registry." =20 =09 [Lionel Morand] My mistake! ;)=20 =09 As I understand it, the reason for supporting both RPH and ALRP (even = though they contain the same information) is for ease in mapping to or = from protocols that use RPH (e.g., SIP) as well as protocols that use = ALRP (e.g., RSVP) without having to go through a mapping from text to = digits, or vice versa.=20 =09 Your proposal, if I am reading it correctly, would require mapping = from the text priority value (e.g., routine, priority, immediate, flash, = flash-override) to numerical values.=20 It would also require mapping from the RPH (text) namespace to the = ALRP (numerical) namespace (or vice versa) in order to include both.=20 =09 If you are going to go through that mapping , you might as well map = the entire RPH into ALRP and be done with it.=20 =09 If you want to avoid the need to map back and forth between text and = digits (which I thought was the point), you need to support both RPH = (all text) and ALRP (all digits) independently.=20 =09 [Lionel Morand] I was assuming that this mapping was provided, = considering the text in IANA considerations in = http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 = and the updated version of = http://www.iana.org/assignments/sip-parameters.=20 If I'm wrong, please ignore my comment. If I'm correct, there is a one-to-one mapping between any namespace in = string format and associated numerical value. It is therefore possible = to rely on one single AVP to convey name space and priority value, for = SIP of RSVP or whatever... Right? Please forgive me if I misunderstood something... Lionel =09 Janet =09 =09 dime-bounces@ietf.org wrote on 06/15/2010 06:11:24 AM: =09 > [image removed]=20 >=20 > [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt=20 >=20 > lionel.morand=20 >=20 > to:=20 >=20 > dime=20 >=20 > 06/15/2010 06:16 AM=20 >=20 > Sent by:=20 >=20 > dime-bounces@ietf.org=20 >=20 > Cc:=20 >=20 > tom.taylor=20 >=20 > In addition to the previous comments, here is my feedback on this = draft. >=20 ... >=20 > Section 3.3/section 3.4 >=20 > ALRP is just another namespace defined in the same Registry. = Moreover, > there are additional namespace defined in RFC 5478. Would it be = simpler > to rely on the same AVP to convey the same kind of information. >=20 > Here is a proposal: >=20 > The SIP-Resource-Priority AVP is of type Grouped. It provides > the Resource-Priority namespace and the Resource-Priority value > contained in a SIP Resource-Priority header as defined in [RFC4412]. >=20 > SIP-Resource-Priority ::=3D < AVP Header: TBD > > { SIP-Resource-Priority-Namespace } > { SIP-Resource-Priority-Value } >=20 > The SIP-Resource-Priority-Namespace AVP is of type Grouped. It > contains a unique string and the associated numerical value > identifying the namespace. >=20 > SIP-Resource-Priority-Namespace ::=3D < AVP Header: TBD > > { = SIP-Resource-Priority-Namespace-String > } > { = SIP-Resource-Priority-Namespace-Value } >=20 >=20 > The SIP-Resource-Priority-Namespace-String AVP (AVP Code TBD) is > of type UTF8String. >=20 > The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD) is > of type Unsigned32. >=20 > The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of type > Unsigned32. >=20 > Would it be acceptable? >=20 > regards >=20 > Lionel Morand > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime = =20 =09 From carlberg@g11.org.uk Tue Jun 15 06:28:36 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F43D3A6A05 for ; Tue, 15 Jun 2010 06:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSllX6PnNis7 for ; Tue, 15 Jun 2010 06:28:35 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 740D23A687D for ; Tue, 15 Jun 2010 06:28:35 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:53652 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1OOWBw-00050i-90; Tue, 15 Jun 2010 13:28:36 +0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Tue, 15 Jun 2010 09:28:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1078) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: dime@ietf.org, tom.taylor@rogers.com Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 13:28:36 -0000 Hi Lionel, > Section 3.1. >=20 > The Defending-Priority is set when the reservation has been > admitted. > The Preemption-Priority of a newly requested reservation is = compared > with the Defending Priority of a previously admitted flow. = The > actions taken based upon the result of this comparison are a = function > of local policy. >=20 > Here we are describing how to set and use the value conatined in the > AVPs and not the AVP itself. Would a simple reference to RFC3181 be > enough to know to use this information? This would avoid any possible > misalignment... I have a preference to leave the description of the defending and = preemption priority as is. Its consistent with the other subsections in = that each provides a brief description of the AVP, along with a = reference of where more in-depth information may be found. And = unfortunately, most folks are not as diligent and careful as you are to = follow all the references thoroughly :-), and thus they'll ask why we = have various AVPs that seemingly deal with the same priority (not = knowing that priority comes in various flavors). Having said that, please let me know if you feel my description in 3.1 = is not as accurate as it should be with respect to rfc-3181. I'll respond to your other points in a subsequent email. -ken From jgunn6@csc.com Tue Jun 15 06:53:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5698D3A67D6; Tue, 15 Jun 2010 06:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.313 X-Spam-Level: X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9I+JW2T7YHD; Tue, 15 Jun 2010 06:53:37 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by core3.amsl.com (Postfix) with ESMTP id 8FFC53A67D4; Tue, 15 Jun 2010 06:53:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-87.messagelabs.com!1276610019!70235036!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 7786 invoked from network); 15 Jun 2010 13:53:40 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2010 13:53:40 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o5FDrbwK021833; Tue, 15 Jun 2010 09:53:37 -0400 In-Reply-To: References: To: MIME-Version: 1.0 X-KeepSent: C7ED2650:E65C9D14-85257743:0049DB8C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Tue, 15 Jun 2010 09:53:34 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF293|April 16, 2010) at 06/15/2010 09:54:12 AM, Serialize complete at 06/15/2010 09:54:12 AM Content-Type: multipart/alternative; boundary="=_alternative 004C519485257743_=" Cc: dime-bounces@ietf.org, dime@ietf.org, tom.taylor@rogers.com Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 13:53:39 -0000 This is a multipart message in MIME format. --=_alternative 004C519485257743_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Lionel, Yes, there is a one-to-one mapping between RPH (text namespace, text=20 priority) and ALRP (numerical namespace, numerical priority) But if you want to convert from one to the other (or from either to your=20 proposed approach) you need to go and look up that mapping, which is extra = work for the processor. My understanding is that the authors wanted to avoid that extra work- so=20 if you receive a message with RPH, you just blindly copy the text values=20 into the its AVP, if you receive ALRP, you blindly copy the numerical=20 values into its AVP, no need to go look up the one-to-one mapping.=20 Janet From: To: Janet P Gunn/USA/CSC@CSC Cc: , , Date: 06/15/2010 09:11 AM Subject: RE: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt Hi Janet, Please see below. Regards, Lionel =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F De : Janet P Gunn [mailto:jgunn6@csc.com]=20 Envoy=E9 : mardi 15 juin 2010 14:21 =C0 : MORAND Lionel RD-CORE-ISS Cc : dime@ietf.org; dime-bounces@ietf.org;=20 tom.taylor@rogers.com Objet : Re: [Dime] Additional comments on=20 draft-ietf-dime-priority-avps-00.txt =20 =20 I do not understand your statement that "ALRP is just=20 another namespace defined in the same Registry."=20 =20 [Lionel Morand] My mistake! ;)=20 =20 As I understand it, the reason for supporting both RPH=20 and ALRP (even though they contain the same information) is for ease in=20 mapping to or from protocols that use RPH (e.g., SIP) as well as protocols = that use ALRP (e.g., RSVP) without having to go through a mapping from=20 text to digits, or vice versa.=20 =20 Your proposal, if I am reading it correctly, would=20 require mapping from the text priority value (e.g., routine, priority,=20 immediate, flash, flash-override) to numerical values.=20 It would also require mapping from the RPH (text)=20 namespace to the ALRP (numerical) namespace (or vice versa) in order to=20 include both.=20 =20 If you are going to go through that mapping , you might = as well map the entire RPH into ALRP and be done with it.=20 =20 If you want to avoid the need to map back and forth=20 between text and digits (which I thought was the point), you need to=20 support both RPH (all text) and ALRP (all digits) independently.=20 =20 [Lionel Morand] I was assuming that this mapping was provided, considering = the text in IANA considerations in=20 http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7=20 and the updated version of http://www.iana.org/assignments/sip-parameters. = If I'm wrong, please ignore my comment. If I'm correct, there is a one-to-one mapping between any namespace in=20 string format and associated numerical value. It is therefore possible to=20 rely on one single AVP to convey name space and priority value, for SIP of = RSVP or whatever... Right? Please forgive me if I misunderstood something... Lionel =20 Janet =20 =20 dime-bounces@ietf.org wrote on 06/15/2010 06:11:24 AM: =20 > [image removed]=20 >=20 > [Dime] Additional comments on=20 draft-ietf-dime-priority-avps-00.txt=20 >=20 > lionel.morand=20 >=20 > to:=20 >=20 > dime=20 >=20 > 06/15/2010 06:16 AM=20 >=20 > Sent by:=20 >=20 > dime-bounces@ietf.org=20 >=20 > Cc:=20 >=20 > tom.taylor=20 >=20 > In addition to the previous comments, here is my=20 feedback on this draft. >=20 ... >=20 > Section 3.3/section 3.4 >=20 > ALRP is just another namespace defined in the same=20 Registry. Moreover, > there are additional namespace defined in RFC 5478.=20 Would it be simpler > to rely on the same AVP to convey the same kind of=20 information. >=20 > Here is a proposal: >=20 > The SIP-Resource-Priority AVP is of type Grouped. It = provides > the Resource-Priority namespace and the=20 Resource-Priority value > contained in a SIP Resource-Priority header as defined=20 in [RFC4412]. >=20 > SIP-Resource-Priority ::=3D < AVP Header: TBD > > {=20 SIP-Resource-Priority-Namespace } > { SIP-Resource-Priority-Value=20 } >=20 > The SIP-Resource-Priority-Namespace AVP is of type=20 Grouped. It > contains a unique string and the associated numerical=20 value > identifying the namespace. >=20 > SIP-Resource-Priority-Namespace ::=3D < AVP Header:=20 TBD > > {=20 SIP-Resource-Priority-Namespace-String > } > {=20 SIP-Resource-Priority-Namespace-Value } >=20 >=20 > The SIP-Resource-Priority-Namespace-String AVP (AVP=20 Code TBD) is > of type UTF8String. >=20 > The SIP-Resource-Priority-Namespace-Value AVP (AVP=20 Code TBD) is > of type Unsigned32. >=20 > The SIP-Resource-Priority-Value AVP (AVP Code TBD)=20 is of type > Unsigned32. >=20 > Would it be acceptable? >=20 > regards >=20 > Lionel Morand > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime < https://www.ietf.org/mailman/listinfo/dime>=20 =20 --=_alternative 004C519485257743_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Lionel,

Yes, there is a one-to-one mapping b= etween RPH (text namespace, text priority) and ALRP (numerical namespace, numerical priority)

But if you want to convert from one to the other (or from either to your proposed approach) you need to go and look up that mapping, which is extra work for the processor.

My understanding is that  the a= uthors wanted to avoid that extra work- so if you receive  a message with RPH, you just blindly copy the text values into the its AVP, if you receive ALRP, you blindly copy the numerical values into its AVP, no need to go look up the one-to-one mapping.

Janet


From: <lionel.morand@orange-ftgroup.com= >
To: Janet P Gunn/USA/CSC@CSC
Cc: <dime@ietf.org>, <dime-boun= ces@ietf.org>, <tom.taylor@rogers.com>
Date: 06/15/2010 09:11 AM
Subject: RE: [Dime] Additional comments on dr= aft-ietf-dime-priority-avps-00.txt




Hi Janet,

Please see below.

Regards,

Lionel

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F

                De : Janet P Gunn [mailto:jgunn6@csc.com]
                Envoy=E9 : mardi 15 juin 2010 14:21
                =C0 : MORAND Lionel RD-CORE-ISS
                Cc : dime@ietf.org; dime-bounces@ietf.org; tom.taylor@rogers.com
                Objet : Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.= txt
               
               

                I do not understand your statement that   "ALRP is just another namespace defined in the same Registry."  
               
[Lionel Morand] My mistake! ;)
               
                As I understand it, the reason for supporting both RPH and ALRP (even though they contain the same information) is for ease in mapping to or from protoc= ols that use RPH (e.g., SIP) as well as protocols that use ALRP (e.g., RSVP) without having to go through a mapping from text to digits, or vice versa.
               
                 Your proposal, if I am reading it correctly, would require mapping from the text priority value (e.g., routine, priority, immediate, flash, flash-override) to numerical values.
                It would also require  mapping from the RPH (text) namespace to the  ALRP (numerical) namespace (or vice versa) in order to include both.
               
                  If you are going to go through that mapping , you might as well map the entire RPH into ALRP and be done with it.
               
                If you want to avoid the need to map back and forth between text and digits (which I thought was the point), you need to support both RPH (all text) and ALRP (all digits) independently.
               
[Lionel Morand] I was assuming that this mapping was provided, considering the text in IANA considerations in = http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 and the updated version of http://www.iana.org/assignments/s= ip-parameters.
If I'm wrong, please ignore my comment.
If I'm correct, there is a one-to-one mapping between any namespace in string format and associated numerical value. It is therefore possible to rely on one single AVP to convey name space and priority value, for SIP of RSVP or whatever... Right?

Please forgive me if I misunderstood something...

Lionel
               
                Janet
               
               
                dime-bounces@ietf.org wrote on 06/15/2010 06:11:24 AM:
               
                > [image removed]
                >
                > [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt
                >
                > lionel.morand
                >
                > to:
                >
                > dime
                >
                > 06/15/2010 06:16 AM
                >
                > Sent by:
                >
                > dime-bounces@ietf.org
                >
                > Cc:
                >
                > tom.taylor
                >
                > In addition to the previous comments, here is my feedback on this draft.
                >
                ...
                >
                > Section 3.3/section 3.4
                >
                > ALRP is just another namespace defined in the same Registry. Moreover,=
                > there are additional namespace defined in RFC 5478. Would it be simple= r
                > to rely on the same AVP to convey the same kind of information.
                >
                > Here is a proposal:
                >
                >    The SIP-Resource-Priority AVP is of type Grouped. It provides
                > the Resource-Priority namespace and the Resource-Priority value
                > contained in a SIP Resource-Priority header as defined in [RFC4412].                 >
                >    SIP-Resource-Priority ::=3D < AVP Header: TBD >
                >                          { SIP-Resource-Priority-Namespace }
                >                          { SIP-Resource-Priority-Value }
                >
                >    The SIP-Resource-Priority-Namespace AVP is of type Groupe= d. It
                > contains a unique string and the associated numerical value
                > identifying the namespace.
                >
                >    SIP-Resource-Priority-Namespace ::=3D < AVP Header: TBD >
                >                                { SIP-Resource-Priority-Namespace-= String
                > }
                >                                { SIP-Resource-Priority-Namespace-= Value }
                >
                >
                >    The SIP-Resource-Priority-Namespace-String AVP (AVP Code TBD) is
                > of type UTF8String.
                >
                >    The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD) is
                > of type Unsigned32.
                >
                >    The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of type
                > Unsigned32.
                >
                > Would it be acceptable?
                >
                > regards
                >
                > Lionel Morand
                > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
                > DiME mailing list
                > DiME@ietf.org
                > <= font size=3D2>https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime= >
               



--=_alternative 004C519485257743_=-- From carlberg@g11.org.uk Tue Jun 15 06:58:42 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC623A6801 for ; Tue, 15 Jun 2010 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbBS1RMS95Hc for ; Tue, 15 Jun 2010 06:58:38 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 5E6053A67D4 for ; Tue, 15 Jun 2010 06:58:38 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:53868 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1OOWey-0001w5-J1; Tue, 15 Jun 2010 13:58:36 +0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Tue, 15 Jun 2010 09:58:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <75D214AC-F5F2-41EC-862D-60F18D5F9028@g11.org.uk> References: To: X-Mailer: Apple Mail (2.1078) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: James Polk , dime@ietf.org Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 13:58:42 -0000 Lionel, > [Lionel Morand] I was assuming that this mapping was provided, = considering the text in IANA considerations = inhttp://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 = and the updated version = ofhttp://www.iana.org/assignments/sip-parameters.=20 > If I'm wrong, please ignore my comment. > If I'm correct, there is a one-to-one mapping between any namespace in = string format and associated numerical value. It is therefore possible = to rely on one single AVP to convey name space and priority value, for = SIP of RSVP or whatever... Right? the mapping described in the IANA considerations of the = tsvwg-emergency-rsvp draft was designed to help ensure interoperability = concerning a priority value that could be found from different protocols = -- namely SIP (with its alphanumeric representation, and RSVP (with its = numeric only representation). We specifically wanted to avoid two = different registries because even with the most careful of individuals, = there would eventually be a mistake in trying to make sure that = different representations of the same priority value would be = misaligned. At first glance, your proposal of a single group AVP versus two distinct = AVPs has an appeal because of its potential simplicity through = reduction/subtraction. However, taking this one step further in terms = of the scenarios that these AVPs could be applied would seem to add more = complexity than originally intended. For example, if a policy decision = point received an RSVP message with an ALRP policy element (but whose = packet payload did *not* contain a SIP message with an RPH header), then = it would have the information for the = SIP-Resource-Priority-Namespace-Value but nothing for the = SIP-Resource-Priority-Namespace-String. Do we then require a null entry = for the latter? In addition, your suggested format in the previous email is incomplete = because we would still need a group entry defining a string and numeric = entry for the Value portion of the RPH tuple. As such, I have a preference to keep the defined AVPs as is. If there = is still some concern or confusion, we can discuss this offline or in = person at the July IETF meeting. cheers, -ken ps, James and Francois, I cc'ed you just to make sure you were in the = loop. pps, Lionel, thanks a lot for the additional review and thoughts on the = topic! From lionel.morand@orange-ftgroup.com Tue Jun 15 13:55:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EBD3A69EA; Tue, 15 Jun 2010 13:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8M+Och+-Wng; Tue, 15 Jun 2010 13:55:38 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C65933A6934; Tue, 15 Jun 2010 13:55:37 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2370E798004; Tue, 15 Jun 2010 22:56:17 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B7311778001; Tue, 15 Jun 2010 22:55:31 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 22:53:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0CCC.DDDCEFBB" Date: Tue, 15 Jun 2010 22:53:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt Thread-Index: AcsMkj3L7TCSttotTxenynXm/pKjOAAOpC9w References: From: To: X-OriginalArrivalTime: 15 Jun 2010 20:53:55.0330 (UTC) FILETIME=[DE570E20:01CB0CCC] Cc: dime-bounces@ietf.org, dime@ietf.org, tom.taylor@rogers.com Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 20:55:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0CCC.DDDCEFBB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable got it ;) =20 Thank you! =20 Lionel ________________________________ De : Janet P Gunn [mailto:jgunn6@csc.com]=20 Envoy=E9 : mardi 15 juin 2010 15:54 =C0 : MORAND Lionel RD-CORE-ISS Cc : dime@ietf.org; dime-bounces@ietf.org; tom.taylor@rogers.com Objet : RE: [Dime] Additional comments on = draft-ietf-dime-priority-avps-00.txt =09 =09 Lionel,=20 =09 Yes, there is a one-to-one mapping between RPH (text namespace, text = priority) and ALRP (numerical namespace, numerical priority)=20 =09 But if you want to convert from one to the other (or from either to = your proposed approach) you need to go and look up that mapping, which = is extra work for the processor.=20 =09 My understanding is that the authors wanted to avoid that extra work- = so if you receive a message with RPH, you just blindly copy the text = values into the its AVP, if you receive ALRP, you blindly copy the = numerical values into its AVP, no need to go look up the one-to-one = mapping.=20 =09 Janet =09 =09 =09 =09 =09 From: =20 To: Janet P Gunn/USA/CSC@CSC=20 Cc: , , =20 Date: 06/15/2010 09:11 AM=20 Subject: RE: [Dime] Additional comments on = draft-ietf-dime-priority-avps-00.txt ________________________________ Hi Janet, =09 Please see below. =09 Regards, =09 Lionel =09 ________________________________ =09 De : Janet P Gunn [mailto:jgunn6@csc.com = ]=20 Envoy=E9 : mardi 15 juin 2010 14:21 =C0 : MORAND Lionel RD-CORE-ISS Cc : dime@ietf.org; dime-bounces@ietf.org; = tom.taylor@rogers.com Objet : Re: [Dime] Additional comments on = draft-ietf-dime-priority-avps-00.txt =20 =20 =09 I do not understand your statement that "ALRP is just = another namespace defined in the same Registry." =20 =20 [Lionel Morand] My mistake! ;)=20 =20 As I understand it, the reason for supporting both RPH = and ALRP (even though they contain the same information) is for ease in = mapping to or from protocols that use RPH (e.g., SIP) as well as = protocols that use ALRP (e.g., RSVP) without having to go through a = mapping from text to digits, or vice versa.=20 =20 Your proposal, if I am reading it correctly, would = require mapping from the text priority value (e.g., routine, priority, = immediate, flash, flash-override) to numerical values.=20 It would also require mapping from the RPH (text) = namespace to the ALRP (numerical) namespace (or vice versa) in order to = include both.=20 =20 If you are going to go through that mapping , you = might as well map the entire RPH into ALRP and be done with it.=20 =20 If you want to avoid the need to map back and forth = between text and digits (which I thought was the point), you need to = support both RPH (all text) and ALRP (all digits) independently.=20 =20 [Lionel Morand] I was assuming that this mapping was provided, = considering the text in IANA considerations in = http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 = = and the updated version of = http://www.iana.org/assignments/sip-parameters = .=20 If I'm wrong, please ignore my comment. If I'm correct, there is a one-to-one mapping between any namespace in = string format and associated numerical value. It is therefore possible = to rely on one single AVP to convey name space and priority value, for = SIP of RSVP or whatever... Right? =09 Please forgive me if I misunderstood something... =09 Lionel =20 Janet =20 =20 dime-bounces@ietf.org wrote on 06/15/2010 06:11:24 AM: =20 > [image removed]=20 >=20 > [Dime] Additional comments on = draft-ietf-dime-priority-avps-00.txt=20 >=20 > lionel.morand=20 >=20 > to:=20 >=20 > dime=20 >=20 > 06/15/2010 06:16 AM=20 >=20 > Sent by:=20 >=20 > dime-bounces@ietf.org=20 >=20 > Cc:=20 >=20 > tom.taylor=20 >=20 > In addition to the previous comments, here is my = feedback on this draft. >=20 ... >=20 > Section 3.3/section 3.4 >=20 > ALRP is just another namespace defined in the same = Registry. Moreover, > there are additional namespace defined in RFC 5478. = Would it be simpler > to rely on the same AVP to convey the same kind of = information. >=20 > Here is a proposal: >=20 > The SIP-Resource-Priority AVP is of type Grouped. = It provides > the Resource-Priority namespace and the = Resource-Priority value > contained in a SIP Resource-Priority header as = defined in [RFC4412]. >=20 > SIP-Resource-Priority ::=3D < AVP Header: TBD > > { = SIP-Resource-Priority-Namespace } > { = SIP-Resource-Priority-Value } >=20 > The SIP-Resource-Priority-Namespace AVP is of type = Grouped. It > contains a unique string and the associated numerical = value > identifying the namespace. >=20 > SIP-Resource-Priority-Namespace ::=3D < AVP = Header: TBD > > { = SIP-Resource-Priority-Namespace-String > } > { = SIP-Resource-Priority-Namespace-Value } >=20 >=20 > The SIP-Resource-Priority-Namespace-String AVP = (AVP Code TBD) is > of type UTF8String. >=20 > The SIP-Resource-Priority-Namespace-Value AVP (AVP = Code TBD) is > of type Unsigned32. >=20 > The SIP-Resource-Priority-Value AVP (AVP Code TBD) = is of type > Unsigned32. >=20 > Would it be acceptable? >=20 > regards >=20 > Lionel Morand > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime = = >=20 =20 =09 =09 =09 =09 ------_=_NextPart_001_01CB0CCC.DDDCEFBB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
got it ;)
 
Thank you!
 
Lionel

De : Janet P Gunn = [mailto:jgunn6@csc.com]=20
Envoy=E9 : mardi 15 juin 2010 = 15:54
=C0 : MORAND=20 Lionel RD-CORE-ISS
Cc : dime@ietf.org; = dime-bounces@ietf.org;=20 tom.taylor@rogers.com
Objet : RE: [Dime] Additional = comments on=20 draft-ietf-dime-priority-avps-00.txt


Lionel, =

Yes, there is a one-to-one mapping between = RPH (text=20 namespace, text priority) and ALRP (numerical namespace, numerical=20 priority)

But if you = want to=20 convert from one to the other (or from either to your proposed = approach) you=20 need to go and look up that mapping, which is extra work for the=20 processor.

My = understanding is=20 that  the authors wanted to avoid that extra work- so if you = receive=20  a message with RPH, you just blindly copy the text values into = the its=20 AVP, if you receive ALRP, you blindly copy the numerical values into = its AVP,=20 no need to go look up the one-to-one mapping.

Janet




From:=20 <lionel.morand@orange-ftgroup.com>=20
To:=20 Janet P = Gunn/USA/CSC@CSC=20
Cc:=20 <dime@ietf.org>,=20 <dime-bounces@ietf.org>, = <tom.taylor@rogers.com>=20
Date:=20 06/15/2010 09:11 AM=20
Subject:=20 RE: [Dime] Additional = comments on=20 = draft-ietf-dime-priority-avps-00.txt




Hi Janet,

Please see=20 = below.

Regards,

Lionel

_____________________________= ___

 =20               De : Janet P Gunn=20 [mailto:jgunn6@csc.com] =
 =20               Envoy=E9 : mardi 15 = juin 2010=20 14:21
                =C0 : = MORAND=20 Lionel RD-CORE-ISS
              =  =20 Cc : dime@ietf.org; dime-bounces@ietf.org; = tom.taylor@rogers.com
 =20               Objet : Re: [Dime] = Additional=20 comments on draft-ietf-dime-priority-avps-00.txt
    =  =20          
        =  =20      

            =  =20   I do not understand your statement that   "ALRP is just = another=20 namespace defined in the same Registry."  
    =  =20          
[Lionel Morand] My mistake! ;)=20
               
  =  =20             As I understand it, the = reason for=20 supporting both RPH and ALRP (even though they contain the same = information)=20 is for ease in mapping to or from protocols that use RPH (e.g., SIP) = as well=20 as protocols that use ALRP (e.g., RSVP) without having to go through a = mapping=20 from text to digits, or vice versa.
        =  =20      
            =  =20    Your proposal, if I am reading it correctly, would = require=20 mapping from the text priority value (e.g., routine, priority, = immediate,=20 flash, flash-override) to numerical values.
      =  =20         It would also require  mapping from = the RPH=20 (text) namespace to the  ALRP (numerical) namespace (or vice = versa) in=20 order to include both.
            =  =20  
                =   If=20 you are going to go through that mapping , you might as well map the = entire=20 RPH into ALRP and be done with it.
        =  =20      
            =  =20   If you want to avoid the need to map back and forth between = text and=20 digits (which I thought was the point), you need to support both RPH = (all=20 text) and ALRP (all digits) independently.
      =  =20        
[Lionel Morand] I was assuming that = this=20 mapping was provided, considering the text in IANA considerations in=20 http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#se= ction-7 and the updated version of http://www.iana.org/assignments/sip-parameters.
If I'm wrong, please ignore my comment.
If I'm = correct, there=20 is a one-to-one mapping between any namespace in string format and = associated=20 numerical value. It is therefore possible to rely on one single AVP to = convey=20 name space and priority value, for SIP of RSVP or whatever...=20 Right?

Please forgive me if I misunderstood=20 something...

Lionel
          =    =20  
               =20 Janet
                =
 =20              
    =  =20           dime-bounces@ietf.org wrote on = 06/15/2010=20 06:11:24 AM:
              =  =20
                > = [image=20 removed]
                = >=20
                > = [Dime]=20 Additional comments on draft-ietf-dime-priority-avps-00.txt
  =  =20             >
    =    =20         > lionel.morand
    =    =20         >
        =    =20     > to:
            =  =20   >
              =   >=20 dime
                >=20
                > = 06/15/2010=20 06:16 AM
                = >=20
                > Sent = by:=20
                > =
 =20               > = dime-bounces@ietf.org=20
                > =
 =20               > Cc:
  =  =20             >
    =    =20         > tom.taylor
      =  =20         >
        =    =20     > In addition to the previous comments, here is my = feedback=20 on this draft.
              =   >=20
                = ...
 =20               >
  =    =20           > Section 3.3/section = 3.4
 =20               >
  =    =20           > ALRP is just another namespace = defined=20 in the same Registry. Moreover,
          =  =20     > there are additional namespace defined in RFC 5478. = Would=20 it be simpler
              =   >=20 to rely on the same AVP to convey the same kind of = information.
 =20               >
  =    =20           > Here is a proposal:
  =  =20             >
    =    =20         >    The = SIP-Resource-Priority AVP is=20 of type Grouped. It provides
          =  =20     > the Resource-Priority namespace and the = Resource-Priority=20 value
                >=20 contained in a SIP Resource-Priority header as defined in = [RFC4412].
 =20               >
  =    =20           >   =  SIP-Resource-Priority ::=3D=20 < AVP Header: TBD >
            =  =20   >                 =  =20        { SIP-Resource-Priority-Namespace = }
 =20               >     =  =20                    { = SIP-Resource-Priority-Value }
          =  =20     >
            =    =20 >    The SIP-Resource-Priority-Namespace AVP is of type = Grouped.=20 It
                > = contains a=20 unique string and the associated numerical value
    =  =20           > identifying the = namespace.
 =20               >
  =    =20           >  =20  SIP-Resource-Priority-Namespace ::=3D < AVP Header: TBD = >
 =20               >     =  =20                     =  =20    { SIP-Resource-Priority-Namespace-String
    =  =20           > }
      =  =20         >           =  =20                    { = SIP-Resource-Priority-Namespace-Value }
        =  =20       >
          =    =20   >
              =   >=20    The SIP-Resource-Priority-Namespace-String AVP (AVP Code = TBD)=20 is
                > of = type=20 UTF8String.
                = >=20
                > =  =20  The SIP-Resource-Priority-Namespace-Value AVP (AVP Code TBD)=20 is
                > of = type=20 Unsigned32.
                = >=20
                > =  =20  The SIP-Resource-Priority-Value AVP (AVP Code TBD) is of = type
 =20               > = Unsigned32.
 =20               >
  =    =20           > Would it be = acceptable?
 =20               >
  =    =20           > regards
    =    =20         >
        =    =20     > Lionel Morand
          =  =20     > = _______________________________________________
 =20               > DiME mailing=20 list
                >=20 DiME@ietf.org
              =   >=20 https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>
              =  =20



------_=_NextPart_001_01CB0CCC.DDDCEFBB-- From lionel.morand@orange-ftgroup.com Tue Jun 15 13:59:05 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001E93A694E for ; Tue, 15 Jun 2010 13:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOKRmgyGEXN2 for ; Tue, 15 Jun 2010 13:59:03 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 7D26A3A6934 for ; Tue, 15 Jun 2010 13:59:03 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E8CBA760007; Tue, 15 Jun 2010 22:59:43 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A6185768001; Tue, 15 Jun 2010 22:58:13 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 22:56:23 +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, 15 Jun 2010 22:56:21 +0200 Message-ID: In-Reply-To: <75D214AC-F5F2-41EC-862D-60F18D5F9028@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt Thread-Index: AcsMku8F1xnezZ2XRrWjU0VWonIGjgAOg6tg References: <75D214AC-F5F2-41EC-862D-60F18D5F9028@g11.org.uk> From: To: X-OriginalArrivalTime: 15 Jun 2010 20:56:23.0710 (UTC) FILETIME=[36C80BE0:01CB0CCD] Cc: jmpolk@cisco.com, dime@ietf.org Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 20:59:05 -0000 Thank you for the clarification. I may have additional minor comments but I will post them in a different = mail. Cheers, Lionel > -----Message d'origine----- > De : ken carlberg [mailto:carlberg@g11.org.uk]=20 > Envoy=E9 : mardi 15 juin 2010 15:59 > =C0 : MORAND Lionel RD-CORE-ISS > Cc : Janet Gunn; dime@ietf.org; Tom Taylor; James Polk;=20 > Francois Le Faucheur > Objet : Re: [Dime] Additional comments on=20 > draft-ietf-dime-priority-avps-00.txt >=20 > Lionel, >=20 > > [Lionel Morand] I was assuming that this mapping was=20 > provided, considering the text in IANA considerations=20 > inhttp://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-1 > 5#section-7 and the updated version=20 > ofhttp://www.iana.org/assignments/sip-parameters.=20 > > If I'm wrong, please ignore my comment. > > If I'm correct, there is a one-to-one mapping between any=20 > namespace in string format and associated numerical value. It=20 > is therefore possible to rely on one single AVP to convey=20 > name space and priority value, for SIP of RSVP or whatever... Right? >=20 > the mapping described in the IANA considerations of the=20 > tsvwg-emergency-rsvp draft was designed to help ensure=20 > interoperability concerning a priority value that could be=20 > found from different protocols -- namely SIP (with its=20 > alphanumeric representation, and RSVP (with its numeric only=20 > representation). We specifically wanted to avoid two=20 > different registries because even with the most careful of=20 > individuals, there would eventually be a mistake in trying to=20 > make sure that different representations of the same priority=20 > value would be misaligned. >=20 > At first glance, your proposal of a single group AVP versus=20 > two distinct AVPs has an appeal because of its potential=20 > simplicity through reduction/subtraction. However, taking=20 > this one step further in terms of the scenarios that these=20 > AVPs could be applied would seem to add more complexity than=20 > originally intended. For example, if a policy decision point=20 > received an RSVP message with an ALRP policy element (but=20 > whose packet payload did *not* contain a SIP message with an=20 > RPH header), then it would have the information for the=20 > SIP-Resource-Priority-Namespace-Value but nothing for the=20 > SIP-Resource-Priority-Namespace-String. Do we then require a=20 > null entry for the latter? >=20 > In addition, your suggested format in the previous email is=20 > incomplete because we would still need a group entry defining=20 > a string and numeric entry for the Value portion of the RPH tuple. >=20 > As such, I have a preference to keep the defined AVPs as is. =20 > If there is still some concern or confusion, we can discuss=20 > this offline or in person at the July IETF meeting. >=20 > cheers, >=20 > -ken >=20 > ps, James and Francois, I cc'ed you just to make sure you=20 > were in the loop. >=20 > pps, Lionel, thanks a lot for the additional review and=20 > thoughts on the topic! >=20 >=20 From lionel.morand@orange-ftgroup.com Tue Jun 15 15:25:30 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972713A697A for ; Tue, 15 Jun 2010 15:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShWvBkUIBwsY for ; Tue, 15 Jun 2010 15:25:29 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 42DBD3A68DF for ; Tue, 15 Jun 2010 15:25:29 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E33EA8B8006 for ; Wed, 16 Jun 2010 00:25:51 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id DC4998B8005 for ; Wed, 16 Jun 2010 00:25:51 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 00:25: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Jun 2010 00:25:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-dime-priority-avps-01.txt Thread-Index: AcsM2arS7tN/MDfiQ62l61GrXJQiWw== From: To: X-OriginalArrivalTime: 15 Jun 2010 22:25:33.0384 (UTC) FILETIME=[AB6F8480:01CB0CD9] Subject: [Dime] Comments on draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 22:25:30 -0000 Here is a new set of comments, after the review of http://www.ietf.org/id/draft-ietf-dime-priority-avps-01.txt Regards, Lionel ******** Abstract: This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework.=20 =3D=3D> Acronyms in Abstract should be avoided. ******* Section 1. Introduction: This document defines a number of Attribute-Value Pairs (AVPs) that can be used within the Diameter protocol [RFC3588] to convey a specific set of priority parameters. The parameters themselves are specified in other documents, but are described briefly below. =3D=3D> Should it be for use in Diameter QoS application (RFC5866) = instead of diameter base protocol (rfc3588)? ******* Section 3.1. Dual-Priority AVP The Dual-Priority AVP is a grouped AVP consisting of two AVPs; the Preemption-Priority and the Defending-Priority AVP. These AVPs are derived from the corresponding priority fields in the Signaled Preemption Priority Policy Element [RFC3181] of RSVP [RFC2205]. The Defending-Priority is set when the reservation has been admitted. The Preemption-Priority of a newly requested reservation is compared with the Defending Priority of a previously admitted flow. The actions taken based upon the result of this comparison are a function of local policy. =3D=3D> I think that it would be useful to repeat at the end of this = text that the use of theses parameters is specified in RFC3181. ******* Section 3.3 SIP-RPH AVP =3D=3D> "RPH" is not defined. If a new version is required, would it be simpler to have a explicit name such like "SIP-Resource-Priority"? The same comment may also apply for the other AVPs. We would have therefore SIP-Resource-Priority-Namespace and SIP-Resource-Priority-Value if agreed. ******* Section 3.3.1. SIP-Namespace AVP The SIP-RPH-Namespace AVP (AVP Code TBD) is of type UTF8String. =3D=3D> Inconsistency between name of the AVP in Title and the body. Previous comment maybe taken into account. ****** Section 3.4. App-Level-Resource-Priority AVP The App-Level-Resource-Priority (ALRP) AVP is a grouped AVP consisting of two AVPs, the ALRP-Namespace AVP and the ALRP-Priority AVP. =3D=3D> "App-Level-Resource-Priority" may also be "Application-Level-Resource-Priority" as in I-D.ietf-tsvwg-emergency-rsvp. =3D=3D> to ease the mapping with I-D.ietf-tsvwg-emergency-rsvp, the = second AVP in the grouped AVP should be renamed "ALRP-Value AVP", as the name of the field is Application-Level Resource Priority policy element. ****** Section 5. Security Considerations TBD =3D=3D> Is there any ongoing discussion on this topic. If there is no specific security issue with the introduction of this set of AVP, maybe a text like in RFC 5777 would be good enough (http://tools.ietf.org/html/rfc5777#section-11): "This document describes the extension of Diameter for conveying Quality of Service information. The security considerations of the Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol." From lionel.morand@orange-ftgroup.com Wed Jun 16 07:22:04 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8039328C0CF for ; Wed, 16 Jun 2010 07:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kf-26wuZOZC for ; Wed, 16 Jun 2010 07:22:02 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 60D393A6A75 for ; Wed, 16 Jun 2010 07:21:59 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 19EBF6C008E; Wed, 16 Jun 2010 16:07:52 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A75FF6C0091; Wed, 16 Jun 2010 15:55:40 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Jun 2010 15:55:21 +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: Wed, 16 Jun 2010 15:54:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of the draft-ietf-dime-capablities-update-04 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28A== From: To: X-OriginalArrivalTime: 16 Jun 2010 13:55:21.0641 (UTC) FILETIME=[8FD3F990:01CB0D5B] Subject: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 16 Jun 2010 14:22:04 -0000 Hi, Please find below the comments/questions after the review of the last version of draft-ietf-dime-capablities-update (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-04) Regards, Lionel ****** Section 3. Diameter Protocol Considerations This document specifies Diameter Application-ID . Diameter nodes conforming to this specification MUST advertise support by including the value in the Auth-Application-Id of the Capabilities-Exchange-Req and Capabilities-Exchange-Answer commands [RFC3588]. =3D=3D> s/Capabilities-Exchange-Req and/Capabilities-Exchange-Request = and ****** Section 4. Capabilities Update When the capabilities of a Diameter node conforming to this specification change, it SHOULD notify all of the nodes with which it has an open transport connection and have also advertised support for the Capabilities Update application using the Capabilities-Update- Request message (Section 4.1.1). This message allows the update of a peer's capabilities (supported Diameter applications, etc.). =3D=3D> Any specific reason for a SHOULD? I understand that the = assumption here is that there is a kind of "always-on" connection between peers and if you want to advertize the other peer of any change, you have to send this notification. Is it assumed the ONLY drawback of not sending the notification is that the other peers will remain unaware of the change, making useless of the whole application? =3D=3D> s/using the Capabilities-Update-Request message (Section 4.1.1)/using the Capabilities-Update-Request (CUR) message (Section 4.1.1) ******** Section 4 A Diameter node only issues a given command to those peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. =3D=3D> the second sentence is correct, but "MUST" refers to the RFC = 3588, not to this specification. ****** Section 4 The receiver of the CUR MUST determine common applications by computing the intersection of its own set of supported Application Id against all of the application identifier AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-Specific- Application-Id) present in the CUR. =20 =3D=3D> First occurrence of CUR in the first sentence. s/The receiver of the CUR/The receiver of the Capabilities-Update-Request (CUR) ****** Section 4 If the receiver of a Capabilities-Update-Req (CUR) message does not have any applications in common with the sender then it MUST return a Capabilities-Update-Answer (CUA) (Section 4.1.2) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport layer connection; however, if active sessions are using the connection, peers MAY delay disconnection until the sessions can be redirected or gracefully terminated. Note that receiving a CUA from a peer advertising itself as a Relay (see [RFC3588], Section 2.4) MUST be interpreted as having common applications with the peer. =3D=3D> If there no (more) common application, what will be the purpose = of maintaining transport layer connection? You may delay the release of any ongoing user session (while trying to redirect AAA signaling to another peer) but it will be anyway inpossible to rely on the "previous" diameter connection with the "updated" peer anyway for sending/receiving Diameter commands. Could you please clarify the intention of this "MAY delay disconnection"? ****** Section 4 The CUR and CUA messages MUST NOT be proxied, redirected or relayed. =3D=3D> woudl be useful to add that it is excatly in the same way as for CER/CEA, just to understand. ****** Section 4 Even though the CUR/CUA messages cannot be proxied, it is still possible for an upstream agent to receive a message for which there are no peers available to handle the application that corresponds to the Command-Code. This could happen if, for example, the peers are too busy or down. In such instances, the 'E' bit MUST be set in the answer message with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER to inform the downstream peer to take action (e.g., re-routing requests to an alternate peer). =3D=3D> Is there any specificity here compared to the normal behaviour described in RFC3588; If not, is it really needed to keep this text, as it is anyway assume that you need the RFC3588 to handle correctly this diameter application? ****** Section 4.1.2. Capabilities-Update-Answer The Capabilities-Update-Answer indicated by the Command-Code set to and the Command Flags' 'R' bit set, is sent in response to a CUR message. =3D=3D> s/'R' bit set/'R' bit cleared Lionel Morand From gwz@net-zen.net Fri Jun 18 01:18:03 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABD73A6A09 for ; Fri, 18 Jun 2010 01:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXCCZnnW8JMR for ; Fri, 18 Jun 2010 01:18:02 -0700 (PDT) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id E74D83A6A04 for ; Fri, 18 Jun 2010 01:18:01 -0700 (PDT) Received: (qmail 18577 invoked from network); 18 Jun 2010 08:18:07 -0000 Received: from unknown (110.164.136.212) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 18 Jun 2010 08:18:05 -0000 From: "Glen Zorn" To: References: In-Reply-To: Date: Fri, 18 Jun 2010 15:17:55 +0700 Organization: Network Zen Message-ID: <000001cb0ebe$c2b63fd0$4822bf70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jun 2010 08:18:03 -0000 Lionel Morand [mailto://lionel.morand@orange-ftgroup.com] writes: > Hi, > > Please find below the comments/questions after the review of the last > version of draft-ietf-dime-capablities-update > (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-04) > > Regards, > > Lionel > > ****** > Section 3. Diameter Protocol Considerations > > This document specifies Diameter Application-ID . Diameter > nodes conforming to this specification MUST advertise support by > including the value in the Auth-Application-Id of the > Capabilities-Exchange-Req and Capabilities-Exchange-Answer commands > [RFC3588]. > > ==> s/Capabilities-Exchange-Req and/Capabilities-Exchange-Request and OK, good catch; the same change must be made globally in http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-21.txt, since the same error occurs there. > > ****** > Section 4. Capabilities Update > > > When the capabilities of a Diameter node conforming to this > specification change, it SHOULD notify all of the nodes with which it > has an open transport connection and have also advertised support for > the Capabilities Update application using the Capabilities-Update- > Request message (Section 4.1.1). This message allows the update of a > peer's capabilities (supported Diameter applications, etc.). > > ==> Any specific reason for a SHOULD? I understand that the assumption > here is that there is a kind of "always-on" connection between peers and > if you want to advertize the other peer of any change, you have to send > this notification. Is it assumed the ONLY drawback of not sending the > notification is that the other peers will remain unaware of the change, > making useless of the whole application? Changed to MUST. > > ==> s/using the Capabilities-Update-Request message (Section > 4.1.1)/using the Capabilities-Update-Request (CUR) message (Section > 4.1.1) > OK > ******** > Section 4 > > A Diameter node only issues a given command to those peers that have > advertised support for the Diameter application that defines the > command. A Diameter node MUST cache the supported applications in > order to ensure that unrecognized commands and/or AVPs are not > unnecessarily sent to a peer. > > ==> the second sentence is correct, but "MUST" refers to the RFC 3588, > not to this specification. Don't understand. > > ****** > Section 4 > > The receiver of the CUR MUST determine common applications by > computing the intersection of its own set of supported Application Id > against all of the application identifier AVPs (Auth-Application-Id, > Acct-Application-Id and Vendor-Specific- Application-Id) present in > the CUR. > > ==> First occurrence of CUR in the first sentence. > s/The receiver of the CUR/The receiver of the > Capabilities-Update-Request (CUR) Why? The acronym has been expanded before... > > ****** > Section 4 > > If the receiver of a Capabilities-Update-Req (CUR) message does not > have any applications in common with the sender then it MUST return a > Capabilities-Update-Answer (CUA) (Section 4.1.2) with the Result-Code > AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the > transport layer connection; however, if active sessions are using the > connection, peers MAY delay disconnection until the sessions can be > redirected or gracefully terminated. Note that receiving a CUA from > a peer advertising itself as a Relay (see [RFC3588], Section 2.4) > MUST be interpreted as having common applications with the peer. > > ==> If there no (more) common application, what will be the purpose of > maintaining transport layer connection? You may delay the release of any > ongoing user session (while trying to redirect AAA signaling to another > peer) but it will be anyway inpossible to rely on the "previous" > diameter connection with the "updated" peer anyway for sending/receiving > Diameter commands. Could you please clarify the intention of this "MAY > delay disconnection"? I'm assuming that an administrator might want to signal that an certain app will no longer be available (thereby avoiding service interruption) _before_ the application is actually removed/disabled. > > ****** > Section 4 > > The CUR and CUA messages MUST NOT be proxied, redirected or relayed. > > ==> woudl be useful to add that it is excatly in the same way as for > CER/CEA, just to understand. Again, I'm not sure why this would be needed... > > ****** > Section 4 > > Even though the CUR/CUA messages cannot be proxied, it is still > possible for an upstream agent to receive a message for which there > are no peers available to handle the application that corresponds to > the Command-Code. This could happen if, for example, the peers are > too busy or down. In such instances, the 'E' bit MUST be set in the > answer message with the Result-Code AVP set to > DIAMETER_UNABLE_TO_DELIVER to inform the downstream peer to take > action (e.g., re-routing requests to an alternate peer). > > ==> Is there any specificity here compared to the normal behaviour > described in RFC3588; If not, is it really needed to keep this text, as > it is anyway assume that you need the RFC3588 to handle correctly this > diameter application? Don't understand: RFC 3588 (BTW, I've changed the refs to RFC 3588 to draft-ietf-dime-rfc3588bis) doesn't talk about this app at all; why would one assume that the CUR/CUA commands are the same as CER/CEA? > > ****** > Section 4.1.2. Capabilities-Update-Answer > > > The Capabilities-Update-Answer indicated by the Command-Code set to > and the Command Flags' 'R' bit set, is sent in response to a > CUR message. > > ==> s/'R' bit set/'R' bit cleared OK From root@core3.amsl.com Fri Jun 18 01:30:22 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 14CD53A6A06; Fri, 18 Jun 2010 01:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100618083022.14CD53A6A06@core3.amsl.com> Date: Fri, 18 Jun 2010 01:30:03 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-capablities-update-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jun 2010 08:30:22 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : The Diameter Capabilities Update Application Author(s) : J. Kang, G. Zorn Filename : draft-ietf-dime-capablities-update-05.txt Pages : 7 Date : 2010-06-18 This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-capablities-update-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-capablities-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-18012723.I-D@ietf.org> --NextPart-- From lionel.morand@orange-ftgroup.com Fri Jun 18 16:43:15 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF22D28C106 for ; Fri, 18 Jun 2010 16:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs3csXoq0zKE for ; Fri, 18 Jun 2010 16:43:14 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 220413A69D7 for ; Fri, 18 Jun 2010 16:43:14 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 698FCFC4007; Sat, 19 Jun 2010 01:43:18 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5C210FC4002; Sat, 19 Jun 2010 01:43:18 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Jun 2010 01:43:18 +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: Sat, 19 Jun 2010 01:43:15 +0200 Message-ID: In-Reply-To: <000001cb0ebe$c2b63fd0$4822bf70$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of the draft-ietf-dime-capablities-update-04 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQACa3HSA= References: <000001cb0ebe$c2b63fd0$4822bf70$@net> From: To: X-OriginalArrivalTime: 18 Jun 2010 23:43:18.0448 (UTC) FILETIME=[07450B00:01CB0F40] Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jun 2010 23:43:16 -0000 Hi Glen, Thank you for a so prompt answer. See below. Regards, Lionel > -----Message d'origine----- > De : Glen Zorn [mailto:gwz@net-zen.net]=20 > Envoy=E9 : vendredi 18 juin 2010 10:18 > =C0 : MORAND Lionel RD-CORE-ISS > Cc : kangjiao@huawei.com; dime@ietf.org > Objet : RE: review of the draft-ietf-dime-capablities-update-04 >=20 > Lionel Morand [mailto://lionel.morand@orange-ftgroup.com] writes: >=20 > > Hi, > >=20 > > Please find below the comments/questions after the review=20 > of the last=20 > > version of draft-ietf-dime-capablities-update > > (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-04) > >=20 > > Regards, > >=20 > > Lionel > >=20 > > ****** > > Section 3. Diameter Protocol Considerations > >=20 > > This document specifies Diameter Application-ID . Diameter > > nodes conforming to this specification MUST advertise support by > > including the value in the Auth-Application-Id of the > > Capabilities-Exchange-Req and=20 > Capabilities-Exchange-Answer commands > > [RFC3588]. > >=20 > > =3D=3D> s/Capabilities-Exchange-Req=20 > and/Capabilities-Exchange-Request and >=20 > OK, good catch; the same change must be made globally in=20 > http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-21.txt,=20 > since the same error occurs there. >=20 > >=20 > > ****** > > Section 4. Capabilities Update > >=20 > >=20 > > When the capabilities of a Diameter node conforming to this > > specification change, it SHOULD notify all of the nodes=20 > with which it > > has an open transport connection and have also=20 > advertised support for > > the Capabilities Update application using the=20 > Capabilities-Update- > > Request message (Section 4.1.1). This message allows=20 > the update of a > > peer's capabilities (supported Diameter applications, etc.). > >=20 > > =3D=3D> Any specific reason for a SHOULD? I understand that the=20 > > assumption here is that there is a kind of "always-on" connection=20 > > between peers and if you want to advertize the other peer of any=20 > > change, you have to send this notification. Is it assumed the ONLY=20 > > drawback of not sending the notification is that the other=20 > peers will=20 > > remain unaware of the change, making useless of the whole=20 > application? >=20 > Changed to MUST. OK. >=20 > >=20 > > =3D=3D> s/using the Capabilities-Update-Request message (Section=20 > > 4.1.1)/using the Capabilities-Update-Request (CUR) message (Section > > 4.1.1) > >=20 >=20 > OK >=20 > > ******** > > Section 4 > >=20 > > A Diameter node only issues a given command to those=20 > peers that have > > advertised support for the Diameter application that defines the > > command. A Diameter node MUST cache the supported=20 > applications in > > order to ensure that unrecognized commands and/or AVPs are not > > unnecessarily sent to a peer. > >=20 > > =3D=3D> the second sentence is correct, but "MUST" refers to=20 > the RFC 3588,=20 > > not to this specification. >=20 > Don't understand. Sorry. The question is: why MUST in capital letters in this = specification whereas this one is related to a normal behaviour of peer = following the RC3588? If I'm correct "MUST", SHOULD", etc. applies to = requirements defined by the present specification according to RFC2119. = >=20 > >=20 > > ****** > > Section 4 > >=20 > > The receiver of the CUR MUST determine common applications by > > computing the intersection of its own set of supported=20 > Application Id > > against all of the application identifier AVPs=20 > (Auth-Application-Id, > > Acct-Application-Id and Vendor-Specific- Application-Id)=20 > present in > > the CUR. > >=20 > > =3D=3D> First occurrence of CUR in the first sentence. > > s/The receiver of the CUR/The receiver of the=20 > > Capabilities-Update-Request (CUR) >=20 > Why? The acronym has been expanded before... OK. It was there OR at the previous occurrence ;) >=20 > >=20 > > ****** > > Section 4 > >=20 > > If the receiver of a Capabilities-Update-Req (CUR)=20 > message does not > > have any applications in common with the sender then it=20 > MUST return a > > Capabilities-Update-Answer (CUA) (Section 4.1.2) with=20 > the Result-Code > > AVP set to DIAMETER_NO_COMMON_APPLICATION, and SHOULD=20 > disconnect the > > transport layer connection; however, if active sessions=20 > are using the > > connection, peers MAY delay disconnection until the=20 > sessions can be > > redirected or gracefully terminated. Note that=20 > receiving a CUA from > > a peer advertising itself as a Relay (see [RFC3588], Section 2.4) > > MUST be interpreted as having common applications with the peer. > >=20 > > =3D=3D> If there no (more) common application, what will be the=20 > purpose of=20 > > maintaining transport layer connection? You may delay the=20 > release of=20 > > any ongoing user session (while trying to redirect AAA signaling to=20 > > another > > peer) but it will be anyway inpossible to rely on the "previous" > > diameter connection with the "updated" peer anyway for=20 > > sending/receiving Diameter commands. Could you please clarify the=20 > > intention of this "MAY delay disconnection"? >=20 > I'm assuming that an administrator might want to signal that=20 > an certain app will no longer be available (thereby avoiding=20 > service interruption) _before_ the application is actually=20 > removed/disabled. OK. >=20 > >=20 > > ****** > > Section 4 > >=20 > > The CUR and CUA messages MUST NOT be proxied, redirected=20 > or relayed. > >=20 > > =3D=3D> woudl be useful to add that it is excatly in the same=20 > way as for=20 > > CER/CEA, just to understand. >=20 > Again, I'm not sure why this would be needed... The main purpose of this application is to "enhance" the general purpose = of capability exchange. So, in my understanding, what is applicable to = CER/CEA applies automatically to CUR/CUA except stated otherwise. But it = was just an open proposal. Something like: "As for CER/CEA messages, the CUR and CUA messages MUST NOT be = proxied, redirected or relayed." >=20 > >=20 > > ****** > > Section 4 > >=20 > > Even though the CUR/CUA messages cannot be proxied, it is still > > possible for an upstream agent to receive a message for=20 > which there > > are no peers available to handle the application that=20 > corresponds to > > the Command-Code. This could happen if, for example,=20 > the peers are > > too busy or down. In such instances, the 'E' bit MUST=20 > be set in the > > answer message with the Result-Code AVP set to > > DIAMETER_UNABLE_TO_DELIVER to inform the downstream peer to take > > action (e.g., re-routing requests to an alternate peer). > >=20 > > =3D=3D> Is there any specificity here compared to the normal = behaviour=20 > > described in RFC3588; If not, is it really needed to keep=20 > this text,=20 > > as it is anyway assume that you need the RFC3588 to handle=20 > correctly=20 > > this diameter application? >=20 > Don't understand: RFC 3588 (BTW, I've changed the refs to RFC 3588 to > draft-ietf-dime-rfc3588bis) doesn't talk about this app at=20 > all; why would one assume that the CUR/CUA commands are the=20 > same as CER/CEA? I was referring here to the description on how to handle unsupported = command-code, that is specified in RFC3588 and may be not needed here, = except if you want to highlight something specific.=20 >=20 > >=20 > > ****** > > Section 4.1.2. Capabilities-Update-Answer > >=20 > >=20 > > The Capabilities-Update-Answer indicated by the=20 > Command-Code set to > > and the Command Flags' 'R' bit set, is sent in=20 > response to a > > CUR message. > >=20 > > =3D=3D> s/'R' bit set/'R' bit cleared >=20 > OK >=20 >=20 >=20 From gwz@net-zen.net Sat Jun 19 02:23:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16983A6939 for ; Sat, 19 Jun 2010 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=2.176, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nYAw1yOV0f8 for ; Sat, 19 Jun 2010 02:23:46 -0700 (PDT) Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id 643C43A6872 for ; Sat, 19 Jun 2010 02:23:46 -0700 (PDT) Received: (qmail 23905 invoked from network); 19 Jun 2010 09:23:51 -0000 Received: from unknown (110.164.136.212) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 19 Jun 2010 09:23:51 -0000 From: "Glen Zorn" To: References: <000001cb0ebe$c2b63fd0$4822bf70$@net> In-Reply-To: Date: Sat, 19 Jun 2010 16:23:35 +0700 Organization: Network Zen Message-ID: <00aa01cb0f91$199f83b0$4cde8b10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQACa3HSAAEz9koA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 09:23:48 -0000 Lionel Morand [mailto://lionel.morand@orange-ftgroup.com] writes: ... > > > ******** > > > Section 4 > > > > > > A Diameter node only issues a given command to those > > peers that have > > > advertised support for the Diameter application that defines the > > > command. A Diameter node MUST cache the supported > > applications in > > > order to ensure that unrecognized commands and/or AVPs are not > > > unnecessarily sent to a peer. > > > > > > ==> the second sentence is correct, but "MUST" refers to > > the RFC 3588, > > > not to this specification. > > > > Don't understand. > > Sorry. The question is: why MUST in capital letters in this > specification whereas this one is related to a normal behaviour of peer > following the RC3588? If I'm correct "MUST", SHOULD", etc. applies to > requirements defined by the present specification according to RFC2119. So the desired change is from "A Diameter node MUST cache" to "A Diameter node must cache"? ... > > > ****** > > > Section 4 > > > > > > The CUR and CUA messages MUST NOT be proxied, redirected > > or relayed. > > > > > > ==> woudl be useful to add that it is excatly in the same > > way as for > > > CER/CEA, just to understand. > > > > Again, I'm not sure why this would be needed... > > The main purpose of this application is to "enhance" the general purpose > of capability exchange. So, in my understanding, what is applicable to > CER/CEA applies automatically to CUR/CUA except stated otherwise. OK, but I don't think that the draft says (or even really implies) that anywhere... > But it > was just an open proposal. Something like: > > "As for CER/CEA messages, the CUR and CUA messages MUST NOT be > proxied, redirected or relayed." OK. > > > > > > > > > ****** > > > Section 4 > > > > > > Even though the CUR/CUA messages cannot be proxied, it is still > > > possible for an upstream agent to receive a message for > > which there > > > are no peers available to handle the application that > > corresponds to > > > the Command-Code. This could happen if, for example, > > the peers are > > > too busy or down. In such instances, the 'E' bit MUST > > be set in the > > > answer message with the Result-Code AVP set to > > > DIAMETER_UNABLE_TO_DELIVER to inform the downstream peer to take > > > action (e.g., re-routing requests to an alternate peer). > > > > > > ==> Is there any specificity here compared to the normal behaviour > > > described in RFC3588; If not, is it really needed to keep > > this text, > > > as it is anyway assume that you need the RFC3588 to handle > > correctly > > > this diameter application? > > > > Don't understand: RFC 3588 (BTW, I've changed the refs to RFC 3588 to > > draft-ietf-dime-rfc3588bis) doesn't talk about this app at > > all; why would one assume that the CUR/CUA commands are the > > same as CER/CEA? > > I was referring here to the description on how to handle unsupported > command-code, that is specified in RFC3588 and may be not needed here, > except if you want to highlight something specific. I'm not sure what harm it does, though. ... From lionel.morand@orange-ftgroup.com Sun Jun 20 14:37:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8263A6828 for ; Sun, 20 Jun 2010 14:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzqClUdAegyx for ; Sun, 20 Jun 2010 14:37:32 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 7F9EA3A6814 for ; Sun, 20 Jun 2010 14:37:32 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A6BCF760002; Sun, 20 Jun 2010 23:39:14 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9D97A760001; Sun, 20 Jun 2010 23:39:14 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Jun 2010 23:37:37 +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: Sun, 20 Jun 2010 23:37:34 +0200 Message-ID: In-Reply-To: <00aa01cb0f91$199f83b0$4cde8b10$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of the draft-ietf-dime-capablities-update-04 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQACa3HSAAEz9koABKjEHQ References: <000001cb0ebe$c2b63fd0$4822bf70$@net> <00aa01cb0f91$199f83b0$4cde8b10$@net> From: To: X-OriginalArrivalTime: 20 Jun 2010 21:37:37.0361 (UTC) FILETIME=[CD41FC10:01CB10C0] Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jun 2010 21:37:33 -0000 Hi Glen, See below. Lionel > -----Message d'origine----- > De : Glen Zorn [mailto:gwz@net-zen.net]=20 > Envoy=E9 : samedi 19 juin 2010 11:24 > =C0 : MORAND Lionel RD-CORE-ISS > Cc : kangjiao@huawei.com; dime@ietf.org > Objet : RE: review of the draft-ietf-dime-capablities-update-04 >=20 > Lionel Morand [mailto://lionel.morand@orange-ftgroup.com] writes: >=20 > ... >=20 > > > > ******** > > > > Section 4 > > > > > > > > A Diameter node only issues a given command to those > > > peers that have > > > > advertised support for the Diameter application that=20 > defines the > > > > command. A Diameter node MUST cache the supported > > > applications in > > > > order to ensure that unrecognized commands and/or=20 > AVPs are not > > > > unnecessarily sent to a peer. > > > > > > > > =3D=3D> the second sentence is correct, but "MUST" refers to > > > the RFC 3588, > > > > not to this specification. > > > > > > Don't understand. > >=20 > > Sorry. The question is: why MUST in capital letters in this=20 > > specification whereas this one is related to a normal behaviour of=20 > > peer following the RC3588? If I'm correct "MUST", SHOULD", etc.=20 > > applies to requirements defined by the present=20 > specification according to RFC2119. >=20 > So the desired change is from "A Diameter node MUST cache" to=20 > "A Diameter node must cache"? Actually, I would propose to remove the second paragraph and modify the = beginning of the section as follow: New: When the capabilities of a Diameter node conforming to this specification change, it MUST notify all of the nodes with which it has an open transport connection and have also advertised support for the Capabilities Update application using the Capabilities-Update- Request (CUR) message (Section 4.1.1). This message allows the update of a peer's capabilities (supported Diameter applications, etc.) [received in an initial Capability-Exchange-Request or in a = previous CUR]. [As with a CER], the receiver of the CUR MUST determine common applications by computing the intersection of its own set of=20 supported Application Id against all of the application identifier = AVPs (Auth-Application-Id, Acct-Application-Id and Vendor-Specific- Application-Id) present in the CUR [and MUST cache the resulting set=20 of applications supported by the peer]. The value of the Vendor-Id = AVP in the=20 Vendor-Specific-Application-Id MUST NOT be used during computation. According to the proposed modification at the end of the first = paragraph, do you confirm that CUR will be always sent after an initial = CER? Therefore, what should be the behaviour of a peer receiving the CUR from = a known peer which has no ongoing connection with? Should it reject the = request or process it as a CER? > ... >=20 > > > > ****** > > > > Section 4 > > > > > > > > The CUR and CUA messages MUST NOT be proxied, redirected > > > or relayed. > > > > > > > > =3D=3D> woudl be useful to add that it is excatly in the same > > > way as for > > > > CER/CEA, just to understand. > > > > > > Again, I'm not sure why this would be needed... > >=20 > > The main purpose of this application is to "enhance" the general=20 > > purpose of capability exchange. So, in my understanding, what is=20 > > applicable to CER/CEA applies automatically to CUR/CUA=20 > except stated otherwise. >=20 > OK, but I don't think that the draft says (or even really=20 > implies) that anywhere... >=20 > > But it > > was just an open proposal. Something like: > >=20 > > "As for CER/CEA messages, the CUR and CUA messages MUST NOT be=20 > > proxied, redirected or relayed." >=20 > OK. >=20 > >=20 > > > > > > > > > > > ****** > > > > Section 4 > > > > > > > > Even though the CUR/CUA messages cannot be proxied,=20 > it is still > > > > possible for an upstream agent to receive a message for > > > which there > > > > are no peers available to handle the application that > > > corresponds to > > > > the Command-Code. This could happen if, for example, > > > the peers are > > > > too busy or down. In such instances, the 'E' bit MUST > > > be set in the > > > > answer message with the Result-Code AVP set to > > > > DIAMETER_UNABLE_TO_DELIVER to inform the downstream=20 > peer to take > > > > action (e.g., re-routing requests to an alternate peer). > > > > > > > > =3D=3D> Is there any specificity here compared to the=20 > normal behaviour=20 > > > > described in RFC3588; If not, is it really needed to keep > > > this text, > > > > as it is anyway assume that you need the RFC3588 to handle > > > correctly > > > > this diameter application? > > > > > > Don't understand: RFC 3588 (BTW, I've changed the refs to=20 > RFC 3588=20 > > > to > > > draft-ietf-dime-rfc3588bis) doesn't talk about this app=20 > at all; why=20 > > > would one assume that the CUR/CUA commands are the same=20 > as CER/CEA? > >=20 > > I was referring here to the description on how to handle=20 > unsupported=20 > > command-code, that is specified in RFC3588 and may be not=20 > needed here,=20 > > except if you want to highlight something specific. >=20 > I'm not sure what harm it does, though. >=20 > ... >=20 >=20 >=20 From gwz@net-zen.net Sun Jun 20 18:31:30 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66BB3A69A5 for ; Sun, 20 Jun 2010 18:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_05=-1.11, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Pk8QkC+uQLU for ; Sun, 20 Jun 2010 18:31:07 -0700 (PDT) Received: from smtpauth13.prod.mesa1.secureserver.net (smtpauth13.prod.mesa1.secureserver.net [64.202.165.37]) by core3.amsl.com (Postfix) with SMTP id A81F93A69AE for ; Sun, 20 Jun 2010 18:31:06 -0700 (PDT) Received: (qmail 7791 invoked from network); 21 Jun 2010 01:31:11 -0000 Received: from unknown (110.164.136.86) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 21 Jun 2010 01:31:11 -0000 From: "Glen Zorn" To: References: <000001cb0ebe$c2b63fd0$4822bf70$@net> <00aa01cb0f91$199f83b0$4cde8b10$@net> In-Reply-To: Date: Mon, 21 Jun 2010 08:30:46 +0700 Organization: Network Zen Message-ID: <005601cb10e1$617c8e70$2475ab50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQACa3HSAAEz9koABKjEHQAAwBYLA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 01:31:30 -0000 Lionel Morand [mailto://lionel.morand@orange-ftgroup.com] writes: ... > > > > > ******** > > > > > Section 4 > > > > > > > > > > A Diameter node only issues a given command to those > > > > peers that have > > > > > advertised support for the Diameter application that > > defines the > > > > > command. A Diameter node MUST cache the supported > > > > applications in > > > > > order to ensure that unrecognized commands and/or > > AVPs are not > > > > > unnecessarily sent to a peer. > > > > > > > > > > ==> the second sentence is correct, but "MUST" refers to > > > > the RFC 3588, > > > > > not to this specification. > > > > > > > > Don't understand. > > > > > > Sorry. The question is: why MUST in capital letters in this > > > specification whereas this one is related to a normal behaviour of > > > peer following the RC3588? If I'm correct "MUST", SHOULD", etc. > > > applies to requirements defined by the present > > specification according to RFC2119. > > > > So the desired change is from "A Diameter node MUST cache" to > > "A Diameter node must cache"? > > Actually, I would propose to remove the second paragraph and modify the > beginning of the section as follow: > > New: > > When the capabilities of a Diameter node conforming to this > specification change, it MUST notify all of the nodes with which it > has an open transport connection and have also advertised support for > the Capabilities Update application using the Capabilities-Update- > Request (CUR) message (Section 4.1.1). This message allows the > update of a peer's capabilities (supported Diameter applications, > etc.) [received in an initial Capability-Exchange-Request or in a > previous CUR]. > > [As with a CER], the receiver of the CUR MUST determine common > applications by computing the intersection of its own set of > supported Application Id against all of the application identifier > AVPs > (Auth-Application-Id, Acct-Application-Id and Vendor-Specific- > Application-Id) present in the CUR [and MUST cache the resulting set > of applications supported by the peer]. The value of the Vendor-Id > AVP in the > Vendor-Specific-Application-Id MUST NOT be used during computation. > > According to the proposed modification at the end of the first > paragraph, do you confirm that CUR will be always sent after an initial > CER? Of course; the proposed change seems to just beat one to death with the club of the obvious ;-) > Therefore, what should be the behaviour of a peer receiving the CUR from > a known peer which has no ongoing connection with? Should it reject the > request or process it as a CER? Again, that's pretty obviously a protocol error. What should happen if a AAR is received before a CER? It's the same thing... ... From lionel.morand@orange-ftgroup.com Sun Jun 20 18:48:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E099F3A67FC for ; Sun, 20 Jun 2010 18:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dLh4jwXg3Kp for ; Sun, 20 Jun 2010 18:48:47 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id AA3FB3A69A5 for ; Sun, 20 Jun 2010 18:48:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 757A9FC4007; Mon, 21 Jun 2010 03:48:47 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 696ACFC4003; Mon, 21 Jun 2010 03:48:47 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jun 2010 03:48:44 +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: Mon, 21 Jun 2010 03:48:45 +0200 Message-ID: In-Reply-To: <005601cb10e1$617c8e70$2475ab50$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of the draft-ietf-dime-capablities-update-04 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQACa3HSAAEz9koABKjEHQAAwBYLAAAE0PgA== References: <000001cb0ebe$c2b63fd0$4822bf70$@net> <00aa01cb0f91$199f83b0$4cde8b10$@net> <005601cb10e1$617c8e70$2475ab50$@net> From: To: X-OriginalArrivalTime: 21 Jun 2010 01:48:44.0329 (UTC) FILETIME=[E1DED990:01CB10E3] Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 01:48:48 -0000 > ... >=20 > > > > > > ******** > > > > > > Section 4 > > > > > > > > > > > > A Diameter node only issues a given command to those > > > > > peers that have > > > > > > advertised support for the Diameter application that > > > defines the > > > > > > command. A Diameter node MUST cache the supported > > > > > applications in > > > > > > order to ensure that unrecognized commands and/or > > > AVPs are not > > > > > > unnecessarily sent to a peer. > > > > > > > > > > > > =3D=3D> the second sentence is correct, but "MUST" refers to > > > > > the RFC 3588, > > > > > > not to this specification. > > > > > > > > > > Don't understand. > > > > > > > > Sorry. The question is: why MUST in capital letters in this=20 > > > > specification whereas this one is related to a normal=20 > behaviour of=20 > > > > peer following the RC3588? If I'm correct "MUST", SHOULD", etc. > > > > applies to requirements defined by the present > > > specification according to RFC2119. > > > > > > So the desired change is from "A Diameter node MUST cache" to "A=20 > > > Diameter node must cache"? > >=20 > > Actually, I would propose to remove the second paragraph and modify=20 > > the beginning of the section as follow: > >=20 > > New: > >=20 > > When the capabilities of a Diameter node conforming to this > > specification change, it MUST notify all of the nodes=20 > with which it > > has an open transport connection and have also=20 > advertised support for > > the Capabilities Update application using the=20 > Capabilities-Update- > > Request (CUR) message (Section 4.1.1). This message allows the > > update of a peer's capabilities (supported Diameter applications, > > etc.) [received in an initial=20 > Capability-Exchange-Request or in a=20 > > previous CUR]. > >=20 > > [As with a CER], the receiver of the CUR MUST determine common > > applications by computing the intersection of its own set of > > supported Application Id against all of the application=20 > identifier=20 > > AVPs > > (Auth-Application-Id, Acct-Application-Id and Vendor-Specific- > > Application-Id) present in the CUR [and MUST cache the=20 > resulting set > > of applications supported by the peer]. The value of the=20 > Vendor-Id=20 > > AVP in the > > Vendor-Specific-Application-Id MUST NOT be used during=20 > computation. > >=20 > > According to the proposed modification at the end of the first=20 > > paragraph, do you confirm that CUR will be always sent after an=20 > > initial CER? >=20 > Of course; the proposed change seems to just beat one to=20 > death with the club of the obvious ;-) >=20 > > Therefore, what should be the behaviour of a peer receiving the CUR=20 > > from a known peer which has no ongoing connection with? Should it=20 > > reject the request or process it as a CER? >=20 > Again, that's pretty obviously a protocol error. What should=20 > happen if a AAR is received before a CER? It's the same thing... >=20 I admit that it is obvious... But not said in the draft. According to the current text, the receiving peer just compares the supported applications received in the CUR to in its own set of supported applications, without checking if there is an ongoing connection. I think that this check should be an additional step compared to the normal handling of the CER. But I may be wrong... From gwz@net-zen.net Sun Jun 20 21:12:02 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3EF3A67FA for ; Sun, 20 Jun 2010 21:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=1.756, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsj45Zl7mNUo for ; Sun, 20 Jun 2010 21:12:00 -0700 (PDT) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id 746743A63CB for ; Sun, 20 Jun 2010 21:12:00 -0700 (PDT) Received: (qmail 14256 invoked from network); 21 Jun 2010 04:12:06 -0000 Received: from unknown (110.164.136.86) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 21 Jun 2010 04:12:06 -0000 From: "Glen Zorn" To: References: <000001cb0ebe$c2b63fd0$4822bf70$@net> <00aa01cb0f91$199f83b0$4cde8b10$@net> <005601cb10e1$617c8e70$2475ab50$@net> In-Reply-To: Date: Mon, 21 Jun 2010 11:11:40 +0700 Organization: Network Zen Message-ID: <006f01cb10f7$dc2c04f0$94840ed0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsNW2yJ7Ur5EBy8Rvm9qmzySFC28ABQz2wQACa3HSAAEz9koABKjEHQAAwBYLAAAE0PgAAFYJYA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] review of the draft-ietf-dime-capablities-update-04 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 04:12:02 -0000 Lionel Morand [mailto://lionel.morand@orange-ftgroup.com] writes: > > ... > > > > > > > > > ******** > > > > > > > Section 4 > > > > > > > > > > > > > > A Diameter node only issues a given command to those > > > > > > peers that have > > > > > > > advertised support for the Diameter application that > > > > defines the > > > > > > > command. A Diameter node MUST cache the supported > > > > > > applications in > > > > > > > order to ensure that unrecognized commands and/or > > > > AVPs are not > > > > > > > unnecessarily sent to a peer. > > > > > > > > > > > > > > ==> the second sentence is correct, but "MUST" refers to > > > > > > the RFC 3588, > > > > > > > not to this specification. > > > > > > > > > > > > Don't understand. > > > > > > > > > > Sorry. The question is: why MUST in capital letters in this > > > > > specification whereas this one is related to a normal > > behaviour of > > > > > peer following the RC3588? If I'm correct "MUST", SHOULD", etc. > > > > > applies to requirements defined by the present > > > > specification according to RFC2119. > > > > > > > > So the desired change is from "A Diameter node MUST cache" to "A > > > > Diameter node must cache"? > > > > > > Actually, I would propose to remove the second paragraph and modify > > > the beginning of the section as follow: > > > > > > New: > > > > > > When the capabilities of a Diameter node conforming to this > > > specification change, it MUST notify all of the nodes > > with which it > > > has an open transport connection and have also > > advertised support for > > > the Capabilities Update application using the > > Capabilities-Update- > > > Request (CUR) message (Section 4.1.1). This message allows the > > > update of a peer's capabilities (supported Diameter applications, > > > etc.) [received in an initial > > Capability-Exchange-Request or in a > > > previous CUR]. > > > > > > [As with a CER], the receiver of the CUR MUST determine common > > > applications by computing the intersection of its own set of > > > supported Application Id against all of the application > > identifier > > > AVPs > > > (Auth-Application-Id, Acct-Application-Id and Vendor-Specific- > > > Application-Id) present in the CUR [and MUST cache the > > resulting set > > > of applications supported by the peer]. The value of the > > Vendor-Id > > > AVP in the > > > Vendor-Specific-Application-Id MUST NOT be used during > > computation. > > > > > > According to the proposed modification at the end of the first > > > paragraph, do you confirm that CUR will be always sent after an > > > initial CER? > > > > Of course; the proposed change seems to just beat one to > > death with the club of the obvious ;-) > > > > > Therefore, what should be the behaviour of a peer receiving the CUR > > > from a known peer which has no ongoing connection with? Should it > > > reject the request or process it as a CER? > > > > Again, that's pretty obviously a protocol error. What should > > happen if a AAR is received before a CER? It's the same thing... > > > > I admit that it is obvious... But not said in the draft. According to > the current text, the receiving peer just compares the supported > applications received in the CUR to in its own set of supported > applications, without checking if there is an ongoing connection. I > think that this check should be an additional step compared to the > normal handling of the CER. But I may be wrong... This is an _application_. How is it possible to receive an application message w/o an active transport connection? How is it possible to have an active transport connection w/o there having been a CER/CEA exchange? I don't understand. From lionel.morand@orange-ftgroup.com Tue Jun 22 00:54:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBBD3A680E for ; Tue, 22 Jun 2010 00:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIvwrEOB5+Qd for ; Tue, 22 Jun 2010 00:54:46 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A78903A6824 for ; Tue, 22 Jun 2010 00:54:45 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0EAD6768006 for ; Tue, 22 Jun 2010 09:52:27 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D2A75760012 for ; Tue, 22 Jun 2010 09:47:31 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jun 2010 09:45: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 09:45:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2010-2011: Second Call for Volunteers Thread-Index: AcsRi69iPyW/6713SAamFuPK+NQPhQAUJCBQAAA0Q8A= From: To: X-OriginalArrivalTime: 22 Jun 2010 07:45:33.0233 (UTC) FILETIME=[E4FC1A10:01CB11DE] Subject: [Dime] Nomcom 2010-2011: Second Call for Volunteers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 07:54:47 -0000 Hi Folks, Please consider this opportunity to support the IETF by being volunteer for Nomcom. It is important part of the IETF community. Regards, Lionel & Jouni -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Tuesday, June 22, 2010 12:49 AM To: IETF Announcement list Subject: Nomcom 2010-2011: Second Call for Volunteers=20 Hi all,=20 This is the Second call for Volunteers for the 2010-11 nomcom. We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon.=20 I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. =20 If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF pouplation. =20 As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. =20 The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of nomcom may be found in RFC 3777. The process on how to volunteer for nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are:=20 Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA=20 John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks=20 Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. =20 While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November.=20 If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name=20 // typically what goes in the Company field // in the IETF Registration Form=20 [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From carlberg@g11.org.uk Thu Jun 24 04:13:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F1E3A697B for ; Thu, 24 Jun 2010 04:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24qySmOWhLAX for ; Thu, 24 Jun 2010 04:13:04 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 345703A684D for ; Thu, 24 Jun 2010 04:13:03 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:50812 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1ORkMm-0001AJ-Of; Thu, 24 Jun 2010 11:13:09 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Thu, 24 Jun 2010 07:13:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <320B7A65-ADBC-42BF-8FA2-FAFE4C18CDA0@g11.org.uk> References: To: X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: dime@ietf.org Subject: Re: [Dime] Comments on draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:13:07 -0000 Hi Lionel, my apologies for the very tardy reply > Abstract: >=20 > This document defines Attribute-Value Pair (AVP) containers = for > various priority parameters for use with Diameter and the = AAA > framework.=20 >=20 > =3D=3D> Acronyms in Abstract should be avoided. the I-D guidelines only stress that acronyms should be expanded, so I = think we are fine here. http://www.ietf.org/id-info/guidelines.html#anchor11 > ******* > Section 1. Introduction: >=20 > This document defines a number of Attribute-Value Pairs (AVPs) = that > can be used within the Diameter protocol [RFC3588] to convey = a > specific set of priority parameters. The parameters themselves = are > specified in other documents, but are described briefly below. >=20 > =3D=3D> Should it be for use in Diameter QoS application (RFC5866) = instead > of diameter base protocol (rfc3588)? You raise a good point. i think its good to keep a reference in the = Introduction to rfc3588, but I should also add in this section that this = particular draft also represents an extension to rfc5866 > ******* > Section 3.1. Dual-Priority AVP >=20 > The Dual-Priority AVP is a grouped AVP consisting of two AVPs; = the > Preemption-Priority and the Defending-Priority AVP. These AVPs = are > derived from the corresponding priority fields in the = Signaled > Preemption Priority Policy Element [RFC3181] of RSVP [RFC2205]. = The > Defending-Priority is set when the reservation has been = admitted. > The Preemption-Priority of a newly requested reservation is = compared > with the Defending Priority of a previously admitted flow. = The > actions taken based upon the result of this comparison are a = function > of local policy. >=20 > =3D=3D> I think that it would be useful to repeat at the end of this = text > that the use of theses parameters is specified in RFC3181. that would seem to be a bit redundant within the same paragraph. If its = important for us to use the word "specified" in the text, I can insert = it in the second sentence above so that it looks like this: "These AVPs are derived from the corresponding priority fields specified = in the Signaled Preemption Priority Policy Element [RFC3181] of RSVP = [RFC2205]." > ******* > Section 3.3 SIP-RPH AVP >=20 > =3D=3D> "RPH" is not defined. If a new version is required, would it = be > simpler to have a explicit name such like "SIP-Resource-Priority"? The > same comment may also apply for the other AVPs. We would have = therefore > SIP-Resource-Priority-Namespace and SIP-Resource-Priority-Value if > agreed. that's fine, I'll expand to name as you suggest. > ******* > Section 3.3.1. SIP-Namespace AVP >=20 > The SIP-RPH-Namespace AVP (AVP Code TBD) is of type UTF8String. >=20 > =3D=3D> Inconsistency between name of the AVP in Title and the body. > Previous comment maybe taken into account. ok > ****** > Section 3.4. App-Level-Resource-Priority AVP >=20 > The App-Level-Resource-Priority (ALRP) AVP is a grouped = AVP > consisting of two AVPs, the ALRP-Namespace AVP and the = ALRP-Priority > AVP. >=20 > =3D=3D> "App-Level-Resource-Priority" may also be > "Application-Level-Resource-Priority" as in > I-D.ietf-tsvwg-emergency-rsvp. ok > =3D=3D> to ease the mapping with I-D.ietf-tsvwg-emergency-rsvp, the = second > AVP in the grouped AVP should be renamed "ALRP-Value AVP", as the name > of the field is Application-Level Resource Priority policy element. ok > ****** > Section 5. Security Considerations >=20 > TBD >=20 > =3D=3D> Is there any ongoing discussion on this topic. If there is no > specific security issue with the introduction of this set of AVP, = maybe > a text like in RFC 5777 would be good enough > (http://tools.ietf.org/html/rfc5777#section-11): >=20 >=20 > "This document describes the extension of Diameter for conveying > Quality of Service information. The security considerations of the > Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. > Use of the AVPs defined in this document MUST take into = consideration > the security issues and requirements of the Diameter base protocol." Sounds fine, I'll add it in. =20 Thanks again for your comments. -ken =20 From wwwrun@core3.amsl.com Wed Jun 23 12:30:18 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C034F3A683F; Wed, 23 Jun 2010 12:30:15 -0700 (PDT) To: gwz@net-zen.net, Hannes.Tschofenig@gmx.net, pete.mccann@motorola.com, tena@huawei.com, avri@ltu.se, d.sun@alcatel-lucent.com From: IETF Secretariat Message-Id: <20100623193016.C034F3A683F@core3.amsl.com> Date: Wed, 23 Jun 2010 12:30:16 -0700 (PDT) X-Mailman-Approved-At: Thu, 24 Jun 2010 04:24:18 -0700 Cc: jouni.korhonen@nsn.com, dime@ietf.org, rbonica@juniper.net, ipr-announce@ietf.org Subject: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:30:18 -0000 Dear Glen Zorn, Hannes Tschofenig, Pete McCann, Tina Tsou (Ting ZOU), Avri Doria, Dong Sun: An IPR disclosure that pertains to your RFC entitled "Diameter Quality of Service Application" (RFC5866) was submitted to the IETF Secretariat on 2010-06-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1344/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 5866." The IETF Secretariat From hannes.tschofenig@nsn.com Thu Jun 24 04:34:02 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD83A3A67AF for ; Thu, 24 Jun 2010 04:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=0.959, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ut78dwniAA1 for ; Thu, 24 Jun 2010 04:34:02 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 85D7E3A6958 for ; Thu, 24 Jun 2010 04:34:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5OBY2ZV004540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Jun 2010 13:34:02 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5OBY0Lu027857; Thu, 24 Jun 2010 13:34:00 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 13:34:00 +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: Thu, 24 Jun 2010 14:32:27 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450286985B@FIESEXC015.nsn-intra.net> In-Reply-To: <20100623193016.C034F3A683F@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 Thread-Index: AcsTj9ENoxH/6eKUS1KVWujFCwZ+2AAAP6fA References: <20100623193016.C034F3A683F@core3.amsl.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: , , , , , X-OriginalArrivalTime: 24 Jun 2010 11:34:00.0111 (UTC) FILETIME=[23BF33F0:01CB1391] Cc: "Korhonen, Jouni \(NSN - FI/Espoo\)" , dime@ietf.org, rbonica@juniper.net Subject: Re: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:34:02 -0000 I believe the chairs need to investigate this very late IPR disclosure. > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of ext IETF Secretariat > Sent: Wednesday, June 23, 2010 10:30 PM > To: gwz@net-zen.net; Hannes.Tschofenig@gmx.net;=20 > pete.mccann@motorola.com; tena@huawei.com; avri@ltu.se;=20 > d.sun@alcatel-lucent.com > Cc: Korhonen, Jouni (NSN - FI/Espoo); dime@ietf.org;=20 > rbonica@juniper.net; ipr-announce@ietf.org > Subject: [Dime] IPR Disclosure: Huawei Technologies Co.,Ltd's=20 > Statement about IPR related to RFC 5866 >=20 > Dear Glen Zorn, Hannes Tschofenig, Pete McCann, Tina Tsou=20 > (Ting ZOU), Avri Doria, Dong Sun: >=20 > An IPR disclosure that pertains to your RFC entitled=20 > "Diameter Quality of > Service Application" (RFC5866) was submitted to the IETF=20 > Secretariat on > 2010-06-23 and has been posted on the "IETF Page of=20 > Intellectual Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1344/). The=20 > title of the IPR > disclosure is "Huawei Technologies Co.,Ltd's Statement about=20 > IPR related to RFC > 5866." >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From gwz@net-zen.net Thu Jun 24 04:41:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5063A67E5 for ; Thu, 24 Jun 2010 04:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj+ERMaHxRnu for ; Thu, 24 Jun 2010 04:41:33 -0700 (PDT) Received: from smtpout07.prod.mesa1.secureserver.net (smtpout07-01.prod.mesa1.secureserver.net [64.202.165.230]) by core3.amsl.com (Postfix) with SMTP id BB4653A6833 for ; Thu, 24 Jun 2010 04:41:33 -0700 (PDT) Received: (qmail 11558 invoked from network); 24 Jun 2010 11:41:41 -0000 Received: from unknown (124.157.141.39) by smtpout07.prod.mesa1.secureserver.net (64.202.165.230) with ESMTP; 24 Jun 2010 11:41:40 -0000 From: "Glen Zorn" To: "'ken carlberg'" , "'lionel.morand@orange-ftgroup.comlionel.morand@orange-ftgroup.com'"@core3.amsl.com References: <320B7A65-ADBC-42BF-8FA2-FAFE4C18CDA0@g11.org.uk> In-Reply-To: <320B7A65-ADBC-42BF-8FA2-FAFE4C18CDA0@g11.org.uk> Date: Thu, 24 Jun 2010 18:41:31 +0700 Organization: Network Zen Message-ID: <003401cb1392$32b66bc0$98234340$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsTjkEtHgV2Gca/QFiIuYmnnqfMjgAA5G5Q Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Comments on draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:41:34 -0000 Ken Carlberg [mailto://carlberg@g11.org.uk] writes: > Hi Lionel, > > my apologies for the very tardy reply > > > Abstract: > > > > This document defines Attribute-Value Pair (AVP) containers > for > > various priority parameters for use with Diameter and the > AAA > > framework. > > > > ==> Acronyms in Abstract should be avoided. > > the I-D guidelines only stress that acronyms should be expanded, so I > think we are fine here. > http://www.ietf.org/id-info/guidelines.html#anchor11 Isn't "AAA" an acronym? ... From carlberg@g11.org.uk Thu Jun 24 04:45:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBB73A6873 for ; Thu, 24 Jun 2010 04:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=1.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHK0-dA3yuLP for ; Thu, 24 Jun 2010 04:45:32 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id DA72E3A6860 for ; Thu, 24 Jun 2010 04:45:31 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51077 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1ORksD-0006fK-Er; Thu, 24 Jun 2010 11:45:37 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <003401cb1392$32b66bc0$98234340$@net> Date: Thu, 24 Jun 2010 07:45:37 -0400 Content-Transfer-Encoding: 7bit Message-Id: <17E417A5-C999-4EE0-8293-4C7C14441672@g11.org.uk> References: <320B7A65-ADBC-42BF-8FA2-FAFE4C18CDA0@g11.org.uk> <003401cb1392$32b66bc0$98234340$@net> To: "Glen Zorn" X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: dime@ietf.org Subject: Re: [Dime] Comments on draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:45:33 -0000 yes -ken On Jun 24, 2010, at 7:41 AM, Glen Zorn wrote: > Ken Carlberg [mailto://carlberg@g11.org.uk] writes: > >> Hi Lionel, >> >> my apologies for the very tardy reply >> >>> Abstract: >>> >>> This document defines Attribute-Value Pair (AVP) containers >> for >>> various priority parameters for use with Diameter and the >> AAA >>> framework. >>> >>> ==> Acronyms in Abstract should be avoided. >> >> the I-D guidelines only stress that acronyms should be expanded, so I >> think we are fine here. >> http://www.ietf.org/id-info/guidelines.html#anchor11 > > Isn't "AAA" an acronym? > > ... > > From carlberg@g11.org.uk Thu Jun 24 04:42:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E753A69AC for ; Thu, 24 Jun 2010 04:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYa+IFj+TtqM for ; Thu, 24 Jun 2010 04:42:38 -0700 (PDT) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id D3D463A6991 for ; Thu, 24 Jun 2010 04:42:37 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51055 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1ORkpD-0006Ba-ND; Thu, 24 Jun 2010 11:42:31 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450286985B@FIESEXC015.nsn-intra.net> Date: Thu, 24 Jun 2010 07:42:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18E90F92-7C21-4138-8086-3808FA9467AD@g11.org.uk> References: <20100623193016.C034F3A683F@core3.amsl.com> <3D3C75174CB95F42AD6BCC56E5555B450286985B@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Thu, 24 Jun 2010 04:46:27 -0700 Cc: pete.mccann@motorola.com, rbonica@juniper.net, avri@ltu.se, dime@ietf.org, d.sun@alcatel-lucent.com, "Korhonen, Jouni \(NSN - FI/Espoo\)" Subject: Re: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:42:39 -0000 I quite agree. Can someone enlighten the rest of us as to whether there = is a deadline as to when these IPR disclosures can be brought up during = the I-D to RFC stage? -ken On Jun 24, 2010, at 7:32 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I believe the chairs need to investigate this very late IPR = disclosure. >=20 >=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >> Behalf Of ext IETF Secretariat >> Sent: Wednesday, June 23, 2010 10:30 PM >> To: gwz@net-zen.net; Hannes.Tschofenig@gmx.net;=20 >> pete.mccann@motorola.com; tena@huawei.com; avri@ltu.se;=20 >> d.sun@alcatel-lucent.com >> Cc: Korhonen, Jouni (NSN - FI/Espoo); dime@ietf.org;=20 >> rbonica@juniper.net; ipr-announce@ietf.org >> Subject: [Dime] IPR Disclosure: Huawei Technologies Co.,Ltd's=20 >> Statement about IPR related to RFC 5866 >>=20 >> Dear Glen Zorn, Hannes Tschofenig, Pete McCann, Tina Tsou=20 >> (Ting ZOU), Avri Doria, Dong Sun: >>=20 >> An IPR disclosure that pertains to your RFC entitled=20 >> "Diameter Quality of >> Service Application" (RFC5866) was submitted to the IETF=20 >> Secretariat on >> 2010-06-23 and has been posted on the "IETF Page of=20 >> Intellectual Property Rights >> Disclosures" (https://datatracker.ietf.org/ipr/1344/). The=20 >> title of the IPR >> disclosure is "Huawei Technologies Co.,Ltd's Statement about=20 >> IPR related to RFC >> 5866." >>=20 >> The IETF Secretariat >>=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 d.b.nelson@comcast.net Thu Jun 24 05:04:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052C63A689F for ; Thu, 24 Jun 2010 05:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.082 X-Spam-Level: * X-Spam-Status: No, score=1.082 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj5oD7aHnbK2 for ; Thu, 24 Jun 2010 05:04:27 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by core3.amsl.com (Postfix) with ESMTP id D9F503A6860 for ; Thu, 24 Jun 2010 05:04:26 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id ZmDC1e0051swQuc5Fo4bxB; Thu, 24 Jun 2010 12:04:35 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta15.westchester.pa.mail.comcast.net with comcast id Zo4b1e0060yip6Y3bo4brC; Thu, 24 Jun 2010 12:04:35 +0000 From: "Dave Nelson" To: References: <20100623193016.C034F3A683F@core3.amsl.com><3D3C75174CB95F42AD6BCC56E5555B450286985B@FIESEXC015.nsn-intra.net> <18E90F92-7C21-4138-8086-3808FA9467AD@g11.org.uk> Date: Thu, 24 Jun 2010 08:04:44 -0400 Message-ID: <1E59D00A9CE442A18B7EF5DEBFF5ACC6@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <18E90F92-7C21-4138-8086-3808FA9467AD@g11.org.uk> Thread-Index: AcsTkugUjuNUo3HyR4+YuOblmfGFQgAAbQ8g Subject: Re: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 12:04:28 -0000 > Can someone enlighten the rest of us as to whether there > is a deadline as to when these IPR disclosures can be > brought up during the I-D to RFC stage? I don't have a definitive answer as to IETF policy, but I think that literally speaking a disclosure *can* be made at any time, even after an RFC is published. My understanding is that IETF policy requires that disclosures *should* be made as soon as any IETF participant is aware of applicable IPR. Late disclosure may be considered anti-social behavior in the IETF community, but unfortunately that doesn't carry much weight in a court of law when patent infringement is being litigated. :-( From lionel.morand@orange-ftgroup.com Thu Jun 24 10:45:25 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27313A6896 for ; Thu, 24 Jun 2010 10:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP7+xX9ojB7Q for ; Thu, 24 Jun 2010 10:45:24 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id DCB653A681D for ; Thu, 24 Jun 2010 10:45:23 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 833BA76000E; Thu, 24 Jun 2010 19:46:57 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1E64C760004; Thu, 24 Jun 2010 19:46:45 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Jun 2010 19:44:39 +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, 24 Jun 2010 19:43:50 +0200 Message-ID: In-Reply-To: <1E59D00A9CE442A18B7EF5DEBFF5ACC6@NEWTON603> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 Thread-Index: AcsTkugUjuNUo3HyR4+YuOblmfGFQgAAbQ8gAAwB+NA= References: <20100623193016.C034F3A683F@core3.amsl.com><3D3C75174CB95F42AD6BCC56E5555B450286985B@FIESEXC015.nsn-intra.net><18E90F92-7C21-4138-8086-3808FA9467AD@g11.org.uk> <1E59D00A9CE442A18B7EF5DEBFF5ACC6@NEWTON603> From: To: , X-OriginalArrivalTime: 24 Jun 2010 17:44:39.0962 (UTC) FILETIME=[EBBB27A0:01CB13C4] Subject: Re: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 17:45:25 -0000 >From RFC 3939, to complement the answer provided by Dave: " IPR disclosures can come at any point in the IETF Standards Process, e.g., before the first Internet-Draft has been submitted, prior to RFC publication, or after an RFC has been published and the working group has been closed down;" Regards, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Dave Nelson > Envoy=E9 : jeudi 24 juin 2010 14:05 > =C0 : dime@ietf.org > Objet : Re: [Dime] IPR Disclosure: Huawei Technologies=20 > Co.,Ltd's Statement about IPR related to RFC 5866 >=20 > > Can someone enlighten the rest of us as to whether there is=20 > a deadline=20 > > as to when these IPR disclosures can be brought up during=20 > the I-D to=20 > > RFC stage? >=20 > I don't have a definitive answer as to IETF policy, but I=20 > think that literally speaking a disclosure *can* be made at=20 > any time, even after an RFC is published. My understanding=20 > is that IETF policy requires that disclosures *should* be=20 > made as soon as any IETF participant is aware of applicable IPR. >=20 > Late disclosure may be considered anti-social behavior in the=20 > IETF community, but unfortunately that doesn't carry much=20 > weight in a court of law when patent infringement is being=20 > litigated. :-( >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From scott.brim@gmail.com Fri Jun 25 07:32:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECB13A69D4 for ; Fri, 25 Jun 2010 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP2-acuJVFDm for ; Fri, 25 Jun 2010 07:32:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id EBDCF3A6A0F for ; Fri, 25 Jun 2010 07:32:14 -0700 (PDT) Received: by vws2 with SMTP id 2so1350371vws.31 for ; Fri, 25 Jun 2010 07:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=E/aEbCV89qq42NGie9veWe9jD/d4bWJsA/uznA6tnbQ=; b=v1UQJ/CtsfgxtjN8AvKmrFeY22LybanGt6sNrJKtQNyJucBCQWJWs1u9ivctVzSQWv 6cOQgAEM2tkANfYXC5rhbN0D61yCwLMDVoeTKB+iN6sjMa6cQ+lzDvRj7ihCZjll/KiL KWMlc0feq5QqMk4qH+pPrt+i6UT3epr/CDUA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=s+6lqI01gEL1xGMs5PFPUt4L9TgpYrc0W7ZKTSCd/TCBwMroho3P5xhteCiAVmWY6I x1Tl0JDo/YXnR1Huc4Xn+dLquA7fiz+OGgFjtBRvGQZ6/PDV+/JLi5gspQtO2T/JfBde mNwaSHYtj7zyv/MtsMe9HSqKkpZquHAh8oCUw= Received: by 10.220.63.207 with SMTP id c15mr454444vci.225.1277476276062; Fri, 25 Jun 2010 07:31:16 -0700 (PDT) Received: from che-vpn-cluster-2-41.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id m9sm643517vcz.17.2010.06.25.07.31.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 07:31:14 -0700 (PDT) Message-ID: <4C24BDB0.3000805@gmail.com> Date: Fri, 25 Jun 2010 10:31:12 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <20100623193016.C034F3A683F@core3.amsl.com><3D3C75174CB95F42AD6BCC56E5555B450286985B@FIESEXC015.nsn-intra.net><18E90F92-7C21-4138-8086-3808FA9467AD@g11.org.uk> <1E59D00A9CE442A18B7EF5DEBFF5ACC6@NEWTON603> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 5866 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 14:32:34 -0000 lionel.morand@orange-ftgroup.com allegedly wrote on 06/24/2010 13:43 EDT: > From RFC 3939, to complement the answer provided by Dave: > > " IPR disclosures can come at any point in the IETF Standards Process, > e.g., before the first Internet-Draft has been submitted, prior to > RFC publication, or after an RFC has been published and the working > group has been closed down;" first it's 3979 :-) Second, you want section 6.2.2: "The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible". The only discussion point is "reasonably possible". That's a question for the courts to decide, but in essence it's a question of good faith. If the IPR information is "reasonably and personally known" by someone actively participating in a discussion, and is not disclosed right away, there had better be a good reason. From dlehmann@ulticom.com Fri Jun 25 13:13:27 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F773A6A2D for ; Fri, 25 Jun 2010 13:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3uxR5Aozf5g for ; Fri, 25 Jun 2010 13:13:20 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 92CDB3A6A36 for ; Fri, 25 Jun 2010 13:13:18 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 8386B14E8DC1CD5B for ; Fri, 25 Jun 2010 16:13:18 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o5PKD5oB006238 for ; Fri, 25 Jun 2010 16:13:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB14A2.D2751B95" Date: Fri, 25 Jun 2010 16:13:05 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AVP mandatory bit Thread-Index: AcsUorO6eLBJT1MJQTahWDbwSAfqdA== From: "David Lehmann" To: Received-SPF: none Subject: [Dime] AVP mandatory bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 20:13:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB14A2.D2751B95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 A question about RFC 3588: What is the purpose of the mandatory bit in the AVP header? I see the explanation in section 4.1. It seems that the determination of whether a AVP is needed is an application level rule. I don't see why this information is encoded in the protocol itself. =20 -David =20 ------_=_NextPart_001_01CB14A2.D2751B95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

A question about RFC 3588:  What is the = purpose of the mandatory bit in the AVP header? I see the explanation in section = 4.1.  It seems that the determination of whether a AVP is needed is an = application level rule.  I don’t see why this information is encoded in the = protocol itself.

 

-David

 

------_=_NextPart_001_01CB14A2.D2751B95-- From vinstrikes@gmail.com Fri Jun 25 18:09:11 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE303A6858 for ; Fri, 25 Jun 2010 18:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eYzdbpXeWUj for ; Fri, 25 Jun 2010 18:09:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8F2473A6814 for ; Fri, 25 Jun 2010 18:09:09 -0700 (PDT) Received: by vws2 with SMTP id 2so1988429vws.31 for ; Fri, 25 Jun 2010 18:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3vojQ65lxJla6ISpVfM+u8jpLuFaGdwAiG5sApN7F70=; b=hTiHq/5FhqPokFeKBy+W4KCOT2u2IUqPuevCRQTcDkfPGJ6hnaGCbCkY9zrBVGjTAg 35eGwVaLRja7Qs6w9vbGL7+D01EbIZqTRR8T09PZoeKBLDPIaHu2UYZFiv5XK7eEyUpq wGHMkQj1sZSK2V66VdEawnXbP6oLZ+2MQB2m0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pnbu5hb9tEQ7xX8YghRtbtEN+NOsBOTF2ukGoqtGRRBuG/usyl+Q2wt/6yDXfnbdn8 RPDFKplNm1CUqYUBSzSMnphxaGWbOPVqH8Ru7hyDzUGrHNsDIDVZTsnpdbeucmc2QTio IeoLv14zNOrMdi9kNrhlaFUlkv9DamdOPU16E= MIME-Version: 1.0 Received: by 10.220.122.88 with SMTP id k24mr878944vcr.253.1277514555584; Fri, 25 Jun 2010 18:09:15 -0700 (PDT) Received: by 10.220.202.194 with HTTP; Fri, 25 Jun 2010 18:09:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Jun 2010 06:39:15 +0530 Message-ID: From: vinay murudi To: David Lehmann Content-Type: multipart/alternative; boundary=001636d34e6f47f2cf0489e48971 Cc: dime@ietf.org Subject: Re: [Dime] AVP mandatory bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 26 Jun 2010 01:09:11 -0000 --001636d34e6f47f2cf0489e48971 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi David I think the reason is - since RFC3588 has the mandate to define the AVP structure and format - even though the Applications can define the new AVPs for extensibility. regards Vinay Murudi On Sat, Jun 26, 2010 at 1:43 AM, David Lehmann wrote= : > Hello, > > > > A question about RFC 3588: What is the purpose of the mandatory bit in t= he > AVP header? I see the explanation in section 4.1. It seems that the > determination of whether a AVP is needed is an application level rule. I > don=92t see why this information is encoded in the protocol itself. > > > > -David > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --001636d34e6f47f2cf0489e48971 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi David

I think the reason is - since RFC3588 has the m= andate to define the AVP structure and format - even though the Application= s can define the new AVPs for=A0extensibility.

reg= ards
Vinay Murudi
=A0

On Sat, J= un 26, 2010 at 1:43 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Hello,

=A0

A question about RFC 3588:=A0 What is the purpose of= the mandatory bit in the AVP header? I see the explanation in section 4.1.=A0 I= t seems that the determination of whether a AVP is needed is an application l= evel rule.=A0 I don=92t see why this information is encoded in the protocol itself.

=A0

-David

=A0


_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime


--001636d34e6f47f2cf0489e48971-- From dlehmann@ulticom.com Tue Jun 29 13:17:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA233A6953 for ; Tue, 29 Jun 2010 13:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQNT7mPgA696 for ; Tue, 29 Jun 2010 13:17:41 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 7E2E03A67F9 for ; Tue, 29 Jun 2010 13:17:40 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 8FAEA35E01C11586 for ; Tue, 29 Jun 2010 16:17:49 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o5TKHbe8016890 for ; Tue, 29 Jun 2010 16:17:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB17C8.1E0596BE" Date: Tue, 29 Jun 2010 16:14:49 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AVP mandatory bit Thread-Index: AcsUzDh8U5joU5DrT8ORnkrLrajX+gC+udgw References: From: "David Lehmann" To: Received-SPF: none Subject: Re: [Dime] AVP mandatory bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 29 Jun 2010 20:17:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB17C8.1E0596BE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I still see it as unnecessary. =20 =20 If I am a Diameter application, for a given message command code, I look for AVP A, B, and C to do my processing. If there is an AVP D, which I do not need, why do I care if the mandatory bit is set? In the real world, I will simply ignore D. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: vinay murudi [mailto:vinstrikes@gmail.com]=20 Sent: Friday, June 25, 2010 9:09 PM To: David Lehmann Cc: dime@ietf.org Subject: Re: [Dime] AVP mandatory bit =20 Hi David =20 I think the reason is - since RFC3588 has the mandate to define the AVP structure and format - even though the Applications can define the new AVPs for extensibility. =20 regards Vinay Murudi =20 On Sat, Jun 26, 2010 at 1:43 AM, David Lehmann wrote: Hello, =20 A question about RFC 3588: What is the purpose of the mandatory bit in the AVP header? I see the explanation in section 4.1. It seems that the determination of whether a AVP is needed is an application level rule. I don't see why this information is encoded in the protocol itself. =20 -David =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------_=_NextPart_001_01CB17C8.1E0596BE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I still see it as unnecessary.  =

 

If I am a Diameter application, for a given message = command code, I look for AVP A, B, and C to do my processing.  If there is = an AVP D, which I do not need, why do I care if the mandatory bit is set?  = In the real world, I will simply ignore D.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= vinay = murudi [mailto:vinstrikes@gmail.com]
Sent: Friday, June 25, 2010 9:09 PM
To: David Lehmann
Cc: dime@ietf.org
Subject: Re: [Dime] AVP mandatory bit

 

Hi David

 

I think the reason is - since RFC3588 has the = mandate to define the AVP structure and format - even though the Applications can = define the new AVPs for extensibility.

 

regards

Vinay Murudi

 

On Sat, Jun 26, 2010 at 1:43 AM, David Lehmann = <dlehmann@ulticom.com> = wrote:

Hello,<= /o:p>

 <= /o:p>

A question about RFC 3588:  What is the purpose of the mandatory bit = in the AVP header? I see the explanation in section 4.1.  It seems that = the determination of whether a AVP is needed is an application level = rule.  I don’t see why this information is encoded in the protocol = itself.

 <= /o:p>

-David<= /o:p>

 <= /o:p>


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

 

------_=_NextPart_001_01CB17C8.1E0596BE-- From root@core3.amsl.com Wed Jun 30 22:30:11 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 59E063A6812; Wed, 30 Jun 2010 22:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100701053010.59E063A6812@core3.amsl.com> Date: Wed, 30 Jun 2010 22:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 05:30:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Attribute-Value Pairs for Cryptographic Key Transport Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-local-keytran-07.txt Pages : 8 Date : 2010-06-30 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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-local-keytran-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-30221608.I-D@ietf.org> --NextPart-- From gwz@net-zen.net Wed Jun 30 22:53:22 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B76E3A68BD for ; Wed, 30 Jun 2010 22:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD6QoJA5EMjA for ; Wed, 30 Jun 2010 22:53:21 -0700 (PDT) Received: from smtpauth21.prod.mesa1.secureserver.net (smtpauth21.prod.mesa1.secureserver.net [64.202.165.38]) by core3.amsl.com (Postfix) with SMTP id E04393A6855 for ; Wed, 30 Jun 2010 22:53:20 -0700 (PDT) Received: (qmail 29899 invoked from network); 1 Jul 2010 05:53:05 -0000 Received: from unknown (124.157.141.182) by smtpauth21.prod.mesa1.secureserver.net (64.202.165.38) with ESMTP; 01 Jul 2010 05:53:04 -0000 From: "Glen Zorn" To: References: <20100701053010.59E063A6812@core3.amsl.com> In-Reply-To: <20100701053010.59E063A6812@core3.amsl.com> Date: Thu, 1 Jul 2010 12:52:57 +0700 Organization: Network Zen Message-ID: <004501cb18e1$aa2faaf0$fe8f00d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsY3ocuqoVOMsSPSXCzmxFuYeWyhAAAuYXQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-local-keytran-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 05:53:22 -0000 I believe that all the open issues have been resolved, so is it time to move this to IETF LC? Hope this helps. ~gwz > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, July 01, 2010 12:30 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-07.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Diameter Maintenance and Extensions > Working Group of the IETF. > > > Title : Diameter Attribute-Value Pairs for Cryptographic > Key Transport > Author(s) : G. Zorn, et al. > Filename : draft-ietf-dime-local-keytran-07.txt > Pages : 8 > Date : 2010-06-30 > > 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-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From dromasca@avaya.com Wed Jun 30 23:42:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D029B3A67D7 for ; Wed, 30 Jun 2010 23:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsqhES6h4XEi for ; Wed, 30 Jun 2010 23:42:46 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 81CEB3A67C3 for ; Wed, 30 Jun 2010 23:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,518,1272859200"; d="scan'208";a="23204096" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 01 Jul 2010 02:42:57 -0400 X-IronPort-AV: E=Sophos;i="4.53,518,1272859200"; d="scan'208";a="487903170" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jul 2010 02:42:56 -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: Thu, 1 Jul 2010 08:42:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Editorial Errata Reported] RFC4072 (2317) Thread-Index: AcsY1ige+KLIbwB9TGepu7S0z3jI5wAEZT9g From: "Romascanu, Dan (Dan)" To: Cc: souheil.benayed@gmail.com Subject: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jul 2010 06:42:47 -0000 Dime WG, Please assess this errata report.=20 If I understand well then Souheil's observation is that more Accounting-EAP-Auth-Method AVPs can be included. This seems more like a Technical errata, which if accepted can create interoperability problems with existing deployment. Am I correct?=20 Thanks and Regards, Dan -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Thursday, July 01, 2010 7:31 AM To: pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com; Romascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com; david@mitton.com; john.loughney@nokia.com Cc: souheil.benayed@gmail.com; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC4072 (2317) The following errata report has been submitted for RFC4072, "Diameter Extensible Authentication Protocol (EAP) Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4072&eid=3D2317 -------------------------------------- Type: Editorial Reported by: Souheil Ben Ayed Section: 3.2. Original Text ------------- ::=3D < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ EAP-Payload ] [ EAP-Reissued-Payload ] [ EAP-Master-Session-Key ] [ EAP-Key-Name ] [ Multi-Round-Time-Out ] [ Accounting-EAP-Auth-Method ] [ Service-Type ] Corrected Text -------------- ::=3D < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ EAP-Payload ] [ EAP-Reissued-Payload ] [ EAP-Master-Session-Key ] [ EAP-Key-Name ] [ Multi-Round-Time-Out ] * [ Accounting-EAP-Auth-Method ] [ Service-Type ] Notes ----- When one or more EAP methods used for authenticating the user, for each used EAP method an Accounting-EAP-Auth-Method AVP is added in the Diameter-EAP-Answer with a successful result code. In the message format of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can be included. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC4072 (draft-ietf-aaa-eap-10) -------------------------------------- Title : Diameter Extensible Authentication Protocol (EAP) Application Publication Date : August 2005 Author(s) : P. Eronen, Ed., T. Hiller, G. Zorn Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG