From root@core3.amsl.com Sat May 1 00:30:02 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 347723A6AB0; Sat, 1 May 2010 00:30: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: <20100501073002.347723A6AB0@core3.amsl.com> Date: Sat, 1 May 2010 00:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-03.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: Sat, 01 May 2010 07:30: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 Attribute-Value Pairs for Cryptographic Key Transport Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-local-keytran-03.txt Pages : 8 Date : 2010-05-01 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-01002543.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Mon May 3 02:50: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 9690528C0F3 for ; Mon, 3 May 2010 02:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 4XsxxIP5xeF3 for ; Mon, 3 May 2010 02:50:21 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id 62BC528C0F1 for ; Mon, 3 May 2010 02:50:21 -0700 (PDT) Received: from a88-114-64-198.elisa-laajakaista.fi (a88-114-64-198.elisa-laajakaista.fi [88.114.64.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 3ED951513DB for ; Mon, 3 May 2010 12:50:04 +0300 (EEST) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 May 2010 12:50:03 +0300 Message-Id: <0CA7D616-AD2E-4CEC-B585-0093AFAB3702@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Dime Wiki pages have been updated 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, 03 May 2010 09:50:22 -0000 Hi all, I took some time to put the Dime wiki pages up to date. What probably is = going to be most interesting thing there is the "Ongoing Dime Topics" = section, where we plan/aim to keep better track on documents in last = call, their comments etc. - Jouni= From victor.pascual.avila@gmail.com Mon May 3 03:27: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 8555028C119 for ; Mon, 3 May 2010 03:27:05 -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.083, 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 fNm6LRF6Ui-q for ; Mon, 3 May 2010 03:27:04 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 994EA3A6C26 for ; Mon, 3 May 2010 03:27:02 -0700 (PDT) Received: by bwz9 with SMTP id 9so1285859bwz.29 for ; Mon, 03 May 2010 03:26:44 -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:content-type :content-transfer-encoding; bh=0aq+YhLMRzFVTpAI5Hi/4htGGgrERnkzQBpi/DlAIkI=; b=PpEFPXesPhLqMDnu6tSZ7V+h9Kq2lcGLDHf0lzGdW/baOBDhvpssi40+RNs3T2B/SQ yGxKbNjnY+f3cfgyhyQ+a4gbeClt8b1S0BjiwKzj6FBh+CPVJr4yMJEckhlThR9G6HHz sQwV7MeAr/ec4qNawIFL8WYEOARceLA021aA0= 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 :content-type:content-transfer-encoding; b=oPR4Tm9EG0fgyECrfJmKCjVnshe1mLj0YgHeKjq2p185TfOxmfZYD/EwC5ldPmWw74 gmD0cjEBqM1+ZGTv7MklTsqotDLGKsO0581XdjdJ571CHYD/0rHV0/U4l8d1qHofBrI2 Os8V4gKzLW7ueqqix0FLLHwKaf0mJ86BIQXSU= MIME-Version: 1.0 Received: by 10.204.126.88 with SMTP id b24mr9588106bks.79.1272882404784; Mon, 03 May 2010 03:26:44 -0700 (PDT) Received: by 10.204.71.9 with HTTP; Mon, 3 May 2010 03:26:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 12:26:44 +0200 Message-ID: From: Victor Pascual Avila To: dime@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 03 May 2010 10:27:05 -0000 Any opinions? Is the below worth to be clarified in 3588bis? Thanks, -Victor On Mon, Apr 26, 2010 at 9:54 AM, Victor Pascual Avila wrote: > Hi, > > Apologies in case this is not the appropriate list for the question > below-- I'd appreciate pointers to any other list. > > RFC 3588 - Section =C2=A02.1.1 (SCTP Guidelines) states the following: "T= o > prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams > available to the association to prevent head-of-the-line blocking." > While RFC 3539 - Section 3.8.1 (Using SCTP Streams to Prevent Head of > Line Blocking) also addresses multi-streaming, it's not clear to me > whether: > > a) Diameter transactions need to be mapped into SCTP streams (ie; send > Diameter messages belonging to the same transaction over the same SCTP > stream and messages belonging to different transactions over different > SCTP streams-- as long as there are enough available streams) > b) Ordered vs unordered delivery: for the above mechanism, I > understand TLS would require ordered delivery. When TLS is not used > (say, IPSec is used instead), do we really need ordered delivery? > > Thanks in advance for any clarification, > -- > Victor Pascual =C3=81vila > --=20 Victor Pascual =C3=81vila From vf0213@gmail.com Mon May 3 10:41: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 4A1B83A6A85 for ; Mon, 3 May 2010 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=-0.296, 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 2wv9V0Gjp9Wt for ; Mon, 3 May 2010 10:41:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B1A7B3A659A for ; Mon, 3 May 2010 10:41:43 -0700 (PDT) Received: by wwi18 with SMTP id 18so411262wwi.31 for ; Mon, 03 May 2010 10:41:25 -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=CrHlp7p7ex22a6tKw17TM4OwoC93Rm/V+5sB8pUf7P4=; b=vVtf+7ndzixVAj3JqkrgNiamVAu9/OwoAaOu40/6kUmVoBcAVyuIvSFubQ8yVOx5wG R2lUAGxwqD8YLesxIxANVuHXInYJZyY5n6Ph8OlDtXWckeYGUP+wOjvg7EWVY3RhFnPr khrGLrNSkbSsgqFopJDihQqArj6wUFyqFexo8= 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=daOvAvso33cqQZ+ewVxlEgzSdBccHoubh1SYW+H+2VGt7WR96jJEx7B7G/djR/0qxV oe9FqQrL/GafyMJagVk+H2wEi8TWIe9eh71YPNFy+IE7fJt/uJ1AU9RTnkeI2qxYqV0k o8PKWkeRJ8h8KtfYFjLSTgydVeCtVmFmI3Np0= MIME-Version: 1.0 Received: by 10.216.89.203 with SMTP id c53mr2032678wef.79.1272908484949; Mon, 03 May 2010 10:41:24 -0700 (PDT) Received: by 10.216.187.195 with HTTP; Mon, 3 May 2010 10:41:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 13:41:24 -0400 Message-ID: From: Victor Fajardo To: Victor Pascual Avila Content-Type: multipart/alternative; boundary=0016e6d7efca13b8820485b41ab9 Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 03 May 2010 17:41:45 -0000 --0016e6d7efca13b8820485b41ab9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, For me I think message ordering and/or delivery is an implementation issue (and hence SCTP stream assignments/usage as well). There are many ways to g= o about this (ordered global rx queues, per-session queues ... etc) and all o= f the depends on how you architecture your implementation. This is a good reason not to have it in a protocol spec. regards, victor On Mon, May 3, 2010 at 6:26 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > Any opinions? Is the below worth to be clarified in 3588bis? > > Thanks, > -Victor > > On Mon, Apr 26, 2010 at 9:54 AM, Victor Pascual Avila > wrote: > > Hi, > > > > Apologies in case this is not the appropriate list for the question > > below-- I'd appreciate pointers to any other list. > > > > RFC 3588 - Section 2.1.1 (SCTP Guidelines) states the following: "To > > prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams > > available to the association to prevent head-of-the-line blocking." > > While RFC 3539 - Section 3.8.1 (Using SCTP Streams to Prevent Head of > > Line Blocking) also addresses multi-streaming, it's not clear to me > > whether: > > > > a) Diameter transactions need to be mapped into SCTP streams (ie; send > > Diameter messages belonging to the same transaction over the same SCTP > > stream and messages belonging to different transactions over different > > SCTP streams-- as long as there are enough available streams) > > b) Ordered vs unordered delivery: for the above mechanism, I > > understand TLS would require ordered delivery. When TLS is not used > > (say, IPSec is used instead), do we really need ordered delivery? > > > > Thanks in advance for any clarification, > > -- > > Victor Pascual =C1vila > > > > > > -- > Victor Pascual =C1vila > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0016e6d7efca13b8820485b41ab9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
For me I think message ordering and/or delivery is an implementation i= ssue (and hence SCTP stream assignments/usage as well). There are many ways= to go about this (ordered global rx queues, per-session queues ... etc) an= d all of the depends on=A0how you architecture your implementation. This is= a good reason not to have it in a protocol spec.
=A0
regards,
victor
=A0


=A0
On Mon, May 3, 2010 at 6:26 AM, Victor Pascual A= vila <victor.pascual.avila@gmail.com> wrote:
Any opinions? Is the below worth= to be clarified in 3588bis?

Thanks,
-Vic= tor

On Mon, Apr 26, 2010 at 9:54 AM, Victor Pascual Avila=
<victor.pascual.av= ila@gmail.com> wrote:
> Hi,
>
> Apologies in case = this is not the appropriate list for the question
> below-- I'd appreciate pointers to any other list.
>
>= RFC 3588 - Section =A02.1.1 (SCTP Guidelines) states the following: "= To
> prevent blocking: All Diameter nodes SHOULD utilize all SCTP str= eams
> available to the association to prevent head-of-the-line blocking.&quo= t;
> While RFC 3539 - Section 3.8.1 (Using SCTP Streams to Prevent He= ad of
> Line Blocking) also addresses multi-streaming, it's not c= lear to me
> whether:
>
> a) Diameter transactions need to be mapped in= to SCTP streams (ie; send
> Diameter messages belonging to the same t= ransaction over the same SCTP
> stream and messages belonging to diff= erent transactions over different
> SCTP streams-- as long as there are enough available streams)
> = b) Ordered vs unordered delivery: for the above mechanism, I
> unders= tand TLS would require ordered delivery. When TLS is not used
> (say,= IPSec is used instead), do we really need ordered delivery?
>
> Thanks in advance for any clarification,
> --
> Vi= ctor Pascual =C1vila
>



--
Victor Pascual =C1vila_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--0016e6d7efca13b8820485b41ab9-- From stefan.winter@restena.lu Mon May 3 22:51:26 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 1FF1B3A6915 for ; Mon, 3 May 2010 22:51:26 -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 FYv8RREqA2hH for ; Mon, 3 May 2010 22:51:25 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF1C43A68A3 for ; Mon, 3 May 2010 22:51:24 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C464A105FF for ; Tue, 4 May 2010 07:51:07 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id A414510592 for ; Tue, 4 May 2010 07:51:07 +0200 (CEST) Message-ID: <4BDFB5CC.5080908@restena.lu> Date: Tue, 04 May 2010 07:51:08 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9D03E5B690C991609BB50960" X-Virus-Scanned: ClamAV Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 04 May 2010 05:51:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9D03E5B690C991609BB50960 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =20 > For me I think message ordering and/or delivery is an implementation > issue (and hence SCTP stream assignments/usage as well). There are > many ways to go about this (ordered global rx queues, per-session > queues ... etc) and all of the depends on how you architecture your > implementation. This is a good reason not to have it in a protocol spec= =2E > I don't quite understand that. If you leave the decision of message ordering to the implementation, you can easily run into one implementation sending its transactions unordered or in different streams, while the implementation on the other end expects them to come in ordered and in the same stream. This will lead to poor/no interoperability between the two implementations. I'd consider this property to be part of the spec. At the very least, it should be spec'd that the receiving end MUST be prepared to handle out-of-order or cross-stream transactions. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig9D03E5B690C991609BB50960 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvftcwACgkQ+jm90f8eFWY2OQCfV3qWJRxKkUmQeEQEA6YIs4ps 858An26c/weQfO5+bE0PpUREs2uzWPCb =EOFo -----END PGP SIGNATURE----- --------------enig9D03E5B690C991609BB50960-- From naveen.sarma@gmail.com Tue May 4 03:28:00 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 B2E2C3A6914 for ; Tue, 4 May 2010 03:28:00 -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 bgrbHIpmal8l for ; Tue, 4 May 2010 03:27:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 55F523A67A6 for ; Tue, 4 May 2010 03:27:59 -0700 (PDT) Received: by fxm4 with SMTP id 4so3350048fxm.31 for ; Tue, 04 May 2010 03:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=DsM5QShlorVOoouImBgQ+mC+b4VmuGFp0b0Gb7iVQEo=; b=vsAcZ2HOIxwIaOhBRnCu7qsxCO0LLrTXOXZbhkNbii4ZNTjCvLQPGqJjY8KATsa1+d RvswjRZxlfygyqYXWHmw5oAORK3T3HrXKP38an2RaB9919lB3Izo729C8jdP32GvUSZe 4Uzdsgz5PlIdhWplbPyj8mA6AQkza59JYLi70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ma/RsUHlWr3VVyX1dmBMACBv8mHvxI6K88JVM2Eyf3U735tMQMwyK6hmoNyVgwp/0i gMNmGy8Jcbzb08lCI3ippSlGfA32QegIZaKs+H9Yn9Hv0eAaL0jsuShi75Ihqe6J9xul SlpJGB+NHm3IJOJthZpMe0HxaDWmRX7lF9Q+o= Received: by 10.239.161.84 with SMTP id g20mr1551315hbd.200.1272968862294; Tue, 04 May 2010 03:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.165.194 with HTTP; Tue, 4 May 2010 03:27:22 -0700 (PDT) In-Reply-To: <4BDFB5CC.5080908@restena.lu> References: <4BDFB5CC.5080908@restena.lu> From: Naveen Kottapalli Date: Tue, 4 May 2010 11:27:22 +0100 Message-ID: To: Stefan Winter Content-Type: multipart/alternative; boundary=001485f04032d8e4d40485c228f4 Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 04 May 2010 10:28:00 -0000 --001485f04032d8e4d40485c228f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IMHO we can specify the same as a caution note in the RFC like some of the SIGTRAN protocols did. Yours, Naveen. On 4 May 2010 06:51, Stefan Winter wrote: > Hi, > > > For me I think message ordering and/or delivery is an implementation > > issue (and hence SCTP stream assignments/usage as well). There are > > many ways to go about this (ordered global rx queues, per-session > > queues ... etc) and all of the depends on how you architecture your > > implementation. This is a good reason not to have it in a protocol spec= . > > > > I don't quite understand that. If you leave the decision of message > ordering to the implementation, you can easily run into one > implementation sending its transactions unordered or in different > streams, while the implementation on the other end expects them to come > in ordered and in the same stream. This will lead to poor/no > interoperability between the two implementations. I'd consider this > property to be part of the spec. At the very least, it should be spec'd > that the receiving end MUST be prepared to handle out-of-order or > cross-stream transactions. > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de > la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --001485f04032d8e4d40485c228f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IMHO we can specify the same as a caution note=A0in the RFC=A0like som= e of the SIGTRAN protocols did.

Yours,
Naveen.


On 4 May 2010 06:51, Stefan Winter <stefan.winter@restena.= lu> wrote:
Hi,

> For me I think message ordering and/or de= livery is an implementation
> issue (and hence SCTP stream assignment= s/usage as well). There are
> many ways to go about this (ordered glo= bal rx queues, per-session
> queues ... etc) and all of the depends on how you architecture your> implementation. This is a good reason not to have it in a protocol sp= ec.
>

I don't quite understand that. If you leave th= e decision of message
ordering to the implementation, you can easily run into one
implementati= on sending its transactions unordered or in different
streams, while the= implementation on the other end expects them to come
in ordered and in = the same stream. This will lead to poor/no
interoperability between the two implementations. I'd consider this
= property to be part of the spec. At the very least, it should be spec'd=
that the receiving end MUST be prepared to handle out-of-order or
cross-stream transactions.

Greetings,

Stefan Winter

--=
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau= T=E9l=E9informatique de l'Education Nationale et de la Recherche
6,= rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


=
_______________________________________________
DiME mailing listDiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime


--001485f04032d8e4d40485c228f4-- From victor.pascual.avila@gmail.com Tue May 4 03:40:38 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 02E623A67B5 for ; Tue, 4 May 2010 03:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-0.558, 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 pIKdkUNtyUoh for ; Tue, 4 May 2010 03:40:37 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id C3EEA3A683C for ; Tue, 4 May 2010 03:40:36 -0700 (PDT) Received: by bwz9 with SMTP id 9so2034254bwz.29 for ; Tue, 04 May 2010 03:40:18 -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 :content-transfer-encoding; bh=+xsLz3q8f6fYCJFB1do70LYcZayxmaVuDFTs7il17Lk=; b=eQuwhHFZ3T3AGTnwTnpbCzufuVk/au2Scgiw5BqZLhWpFFTkGH5lg0sy+VIdmaqxWn fajTIWkVnwIxqOyM6i/TPhvwmmjbXKpUU1j3RaYKzW2cIH8p6AuTZK6xFNyc9XGQHVwn 3pH8NOD6mqI8+dQlfaqNQiSBC8y82w7R2n5v0= 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:content-transfer-encoding; b=ty7F5Cca9kOX8QFytuZ7k/flQrE80lgnA6JfTB0DPMzxzJ5fQ3NxHNncg+nUPJnUQ1 aBbMuVbpWowA/rK+ZIeF2Y871EYvVTQG2YCMxK1dDh2iz6RF+VDFwsU0DAh/6WudKep5 1zcd+ITOi8nnowKw+mtnRFuHCPeigEkRVDyBk= MIME-Version: 1.0 Received: by 10.204.133.146 with SMTP id f18mr3304690bkt.153.1272969618543; Tue, 04 May 2010 03:40:18 -0700 (PDT) Received: by 10.204.71.9 with HTTP; Tue, 4 May 2010 03:40:18 -0700 (PDT) In-Reply-To: References: <4BDFB5CC.5080908@restena.lu> Date: Tue, 4 May 2010 12:40:18 +0200 Message-ID: From: Victor Pascual Avila To: Naveen Kottapalli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 04 May 2010 10:40:38 -0000 IMO rfc4168 is pretty clear on the topic: http://tools.ietf.org/html/rfc4168#section-5 -Victor On Tue, May 4, 2010 at 12:27 PM, Naveen Kottapalli wrote: > IMHO we can specify the same as a caution note=C2=A0in the RFC=C2=A0like = some of the > SIGTRAN protocols did. > Yours, > Naveen. > > > On 4 May 2010 06:51, Stefan Winter wrote: >> >> Hi, >> >> > For me I think message ordering and/or delivery is an implementation >> > issue (and hence SCTP stream assignments/usage as well). There are >> > many ways to go about this (ordered global rx queues, per-session >> > queues ... etc) and all of the depends on how you architecture your >> > implementation. This is a good reason not to have it in a protocol spe= c. >> > >> >> I don't quite understand that. If you leave the decision of message >> ordering to the implementation, you can easily run into one >> implementation sending its transactions unordered or in different >> streams, while the implementation on the other end expects them to come >> in ordered and in the same stream. This will lead to poor/no >> interoperability between the two implementations. I'd consider this >> property to be part of the spec. At the very least, it should be spec'd >> that the receiving end MUST be prepared to handle out-of-order or >> cross-stream transactions. >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educatio= n Nationale et de >> la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --=20 Victor Pascual =C3=81vila From vf0213@gmail.com Tue May 4 05:25: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 3B1B03A6BBA for ; Tue, 4 May 2010 05:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.566, 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 gbqgz6V7VyW2 for ; Tue, 4 May 2010 05:25:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0247F3A68E4 for ; Tue, 4 May 2010 05:24:33 -0700 (PDT) Received: by wwi18 with SMTP id 18so1073576wwi.31 for ; Tue, 04 May 2010 05:24: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:content-type; bh=mLmt47WG1Ii+Aig4tM236Uat5UIQNofUH4qN8GSmIh8=; b=qL/AavDZpMdUSPshxjy6XUpvChuLtRmzyILywyR52JpWrOnd/CVvqkK/2mq94gPGnt oRz4EqczlZslrBywRdfyVL395QL92eTn6qsLCslbEz/fZSUpDBesI0ni1Pr/EZrMa//R MlR1ysKjciUVdVeWLfxp5+R+gYH7Se3aVm69c= 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 :content-type; b=xtPJkSTd+xzxOWBwoEF3t/Aqru77WiL2fZzald8Aw4PKeze7hFTJ6ryyNUgrmy0/zK jSLAQCNWlNixLA+Vqskud+of0jgH9WunNc52yTURMjSXJ12O5NmdG0rajx0tzF0VaQE6 Unl9MFGx5xSNNHhPV1ofItOBF3hlibg2S2pi0= MIME-Version: 1.0 Received: by 10.216.93.21 with SMTP id k21mr1647491wef.68.1272975855453; Tue, 04 May 2010 05:24:15 -0700 (PDT) Received: by 10.216.187.195 with HTTP; Tue, 4 May 2010 05:24:15 -0700 (PDT) In-Reply-To: References: <4BDFB5CC.5080908@restena.lu> Date: Tue, 4 May 2010 08:24:15 -0400 Message-ID: From: Victor Fajardo To: Stefan Winter , dime@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7e9a3ac07f60485c3c90c Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 04 May 2010 12:25:27 -0000 --0016e6d7e9a3ac07f60485c3c90c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stefan, I don't mind stating in the spec that a node MUST be prepared to handle out-of-order messages. What I do mind is stating in the spec how it should be done. I don't consider the 'how' part a property of the spec. regards, victor On Tue, May 4, 2010 at 8:23 AM, Victor Fajardo wrote: > Hi Stefan, > > I don't mind stating in the spec that a node MUST be prepared to handle > out-of-order messages. What I do mind is stating in the spec how it shoul= d > be done. I don't consider the 'how' part a property of the spec. > > regards, > victor > > On Tue, May 4, 2010 at 1:51 AM, Stefan Winter wrote: > >> Hi, >> >> > For me I think message ordering and/or delivery is an implementation >> > issue (and hence SCTP stream assignments/usage as well). There are >> > many ways to go about this (ordered global rx queues, per-session >> > queues ... etc) and all of the depends on how you architecture your >> > implementation. This is a good reason not to have it in a protocol spe= c. >> > >> >> I don't quite understand that. If you leave the decision of message >> ordering to the implementation, you can easily run into one >> implementation sending its transactions unordered or in different >> streams, while the implementation on the other end expects them to come >> in ordered and in the same stream. This will lead to poor/no >> interoperability between the two implementations. I'd consider this >> property to be part of the spec. At the very least, it should be spec'd >> that the receiving end MUST be prepared to handle out-of-order or >> cross-stream transactions. >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationa= le et de >> la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > --0016e6d7e9a3ac07f60485c3c90c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stefan,
=A0
I don't mind stating in the spec that a node MUST be prepared to h= andle out-of-order messages. What I do mind is stating in the spec how it s= hould be done. I don't consider the 'how' part a property of th= e spec.
=A0
regards,
victor


On Tue, May 4, 2010 at 8:23 AM, Victor Fajardo <= span dir=3D"ltr"><vf0213@gmail.com> wrote:
Hi Stefan,
=A0
I don't mind stating in the spec that a node MUST be prepared to h= andle out-of-order messages. What I do mind is stating in the spec how it s= hould be done. I don't consider the 'how' part a property of th= e spec.
=A0
regards,
victor

Hi,

> For me I think message ordering and/or delivery is an = implementation
> issue (and hence SCTP stream assignments/usage as we= ll). There are
> many ways to go about this (ordered global rx queues= , per-session
> queues ... etc) and all of the depends on how you architecture your> implementation. This is a good reason not to have it in a protocol sp= ec.
>

I don't quite understand that. If you leave th= e decision of message
ordering to the implementation, you can easily run into one
implementati= on sending its transactions unordered or in different
streams, while the= implementation on the other end expects them to come
in ordered and in = the same stream. This will lead to poor/no
interoperability between the two implementations. I'd consider this
= property to be part of the spec. At the very least, it should be spec'd=
that the receiving end MUST be prepared to handle out-of-order or
cross-stream transactions.

Greetings,

Stefan Winter

--=
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau= T=E9l=E9informatique de l'Education Nationale et de la Recherche
6,= rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


=
_______________________________________________
DiME m= ailing list
DiME@ietf= .org
https://www.ietf.org/mailman/listinfo/dime



--0016e6d7e9a3ac07f60485c3c90c-- From vf0213@gmail.com Tue May 4 05:35: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 9FC113A6BC1 for ; Tue, 4 May 2010 05:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.509, 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 vWg+mYmzrl2o for ; Tue, 4 May 2010 05:35:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A83283A67D3 for ; Tue, 4 May 2010 05:34:39 -0700 (PDT) Received: by wwi18 with SMTP id 18so1081242wwi.31 for ; Tue, 04 May 2010 05:34:22 -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=cyYPaPGcB5vYjvKEN6erQ+ggRskr4sDQWuyPWk8cCYk=; b=kGqxz4j4PNA4tm19jKz5kylEeI4+sk7pGXmb6743Z1yEhnvishewzRSHfuiBRoPo63 cfkvJC0rA9ME4sdMSwKCOEf2c1YVsIj1k2C+U8Se2gU5UcUVd8FFluCfi+vNUAcMeT2M /usLrQgxSRZPDfoRfRcn/aAAvKi0kVnM6meaU= 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=kerWRk2ttYi96hw1MDtVWkyRinuu/9BdLCbVTasHNVaZEYhVz/2c30uPK9sIIld9pK gx0MYUFMjU3z53Fo3/RqRr/MTWKon6JaorHU2jAwhEDHoKyR7zIV0hkcGgGNBkBSER5V iQ8Gav5JY6frFVBitAWWKnvUMgj+IUbcYPcU4= MIME-Version: 1.0 Received: by 10.216.166.8 with SMTP id f8mr6883767wel.182.1272976462374; Tue, 04 May 2010 05:34:22 -0700 (PDT) Received: by 10.216.187.195 with HTTP; Tue, 4 May 2010 05:34:22 -0700 (PDT) In-Reply-To: References: <4BDFB5CC.5080908@restena.lu> Date: Tue, 4 May 2010 08:34:22 -0400 Message-ID: From: Victor Fajardo To: Victor Pascual Avila Content-Type: multipart/alternative; boundary=00163641747bd8ea1b0485c3ed5e Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines 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, 04 May 2010 12:35:05 -0000 --00163641747bd8ea1b0485c3ed5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I see. Then I would propose that in the current state of this spec, we can simply state a minimum (as stefan has mentioned) that a peer MUST be ready to handle un-ordered messages. Then someone can volunteer a more proper guideline for SCTP stream usage/assignment either in an errata or an anothe= r draft. regards, victor On Tue, May 4, 2010 at 6:40 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > IMO rfc4168 is pretty clear on the topic: > http://tools.ietf.org/html/rfc4168#section-5 > > -Victor > > On Tue, May 4, 2010 at 12:27 PM, Naveen Kottapalli > wrote: > > IMHO we can specify the same as a caution note in the RFC like some of > the > > SIGTRAN protocols did. > > Yours, > > Naveen. > > > > > > On 4 May 2010 06:51, Stefan Winter wrote: > >> > >> Hi, > >> > >> > For me I think message ordering and/or delivery is an implementation > >> > issue (and hence SCTP stream assignments/usage as well). There are > >> > many ways to go about this (ordered global rx queues, per-session > >> > queues ... etc) and all of the depends on how you architecture your > >> > implementation. This is a good reason not to have it in a protocol > spec. > >> > > >> > >> I don't quite understand that. If you leave the decision of message > >> ordering to the implementation, you can easily run into one > >> implementation sending its transactions unordered or in different > >> streams, while the implementation on the other end expects them to com= e > >> in ordered and in the same stream. This will lead to poor/no > >> interoperability between the two implementations. I'd consider this > >> property to be part of the spec. At the very least, it should be spec'= d > >> that the receiving end MUST be prepared to handle out-of-order or > >> cross-stream transactions. > >> > >> Greetings, > >> > >> Stefan Winter > >> > >> -- > >> Stefan WINTER > >> Ingenieur de Recherche > >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et > de > >> la Recherche > >> 6, rue Richard Coudenhove-Kalergi > >> L-1359 Luxembourg > >> > >> Tel: +352 424409 1 > >> Fax: +352 422473 > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > > > -- > Victor Pascual =C1vila > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --00163641747bd8ea1b0485c3ed5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I see. Then I would propose that in the current state of this spec, we= can simply state=A0a minimum (as stefan has mentioned) that a peer MUST be= ready to handle un-ordered messages. Then someone can volunteer a more pro= per guideline for SCTP stream usage/assignment either in an errata or an an= other draft.
=A0
regards,
victor

On Tue, May 4, 2010 at 6:40 AM, Victor Pascual A= vila <victor.pascual.avila@gmail.com> wrote:
IMO rfc4168 is pretty clear on t= he topic:
http://tools.ietf.org/html/rfc4168#section-5

-Victor

On Tue, May 4, 2010 at 12:27 PM, Naveen Kottapalli
<naveen.sarma@gmail.com= > wrote:
> IMHO we can specify the same as a caution note=A0in= the RFC=A0like some of the
> SIGTRAN protocols did.
> Yours,
> Naveen.
>
><= br>> On 4 May 2010 06:51, Stefan Winter <stefan.winter@restena.lu> wrote: >>
>> Hi,
>>
>> > For me I think messag= e ordering and/or delivery is an implementation
>> > issue (and= hence SCTP stream assignments/usage as well). There are
>> > m= any ways to go about this (ordered global rx queues, per-session
>> > queues ... etc) and all of the depends on how you architectur= e your
>> > implementation. This is a good reason not to have i= t in a protocol spec.
>> >
>>
>> I don't = quite understand that. If you leave the decision of message
>> ordering to the implementation, you can easily run into one
>= ;> implementation sending its transactions unordered or in different
= >> streams, while the implementation on the other end expects them to= come
>> in ordered and in the same stream. This will lead to poor/no
&g= t;> interoperability between the two implementations. I'd consider t= his
>> property to be part of the spec. At the very least, it shou= ld be spec'd
>> that the receiving end MUST be prepared to handle out-of-order or<= br>>> cross-stream transactions.
>>
>> Greetings,>>
>> Stefan Winter
>>
>> --
>>= Stefan WINTER
>> Ingenieur de Recherche
>> Fondation RESTENA - R=E9seau T= =E9l=E9informatique de l'Education Nationale et de
>> la Reche= rche
>> 6, rue Richard Coudenhove-Kalergi
>> L-1359 Luxem= bourg
>>
>> Tel: +352 424409 1
>> Fax: +352 422473
>= ;>
>>
>>
>> _________________________________= ______________
>> 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
>
>

=

--
Victor Pascual =C1vila
_______________________________________________
DiME mailing listDiME@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/dime" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/dime

--00163641747bd8ea1b0485c3ed5e-- From root@core3.amsl.com Tue May 4 11:45:02 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 086A93A6A40; Tue, 4 May 2010 11: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: <20100504184502.086A93A6A40@core3.amsl.com> Date: Tue, 4 May 2010 11:45:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-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, 04 May 2010 18: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 Extended NAPTR Author(s) : M. Jones, J. Korhonen Filename : draft-ietf-dime-extended-naptr-01.txt Pages : 9 Date : 2010-05-04 This document describes an extended format for the S-NAPTR Application Service Tag used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-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-extended-naptr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-04114057.I-D@ietf.org> --NextPart-- From jgunn6@csc.com Tue May 4 13:56: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 62C3328C3A8; Tue, 4 May 2010 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.834 X-Spam-Level: X-Spam-Status: No, score=-4.834 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 VL6jLw1D+GwG; Tue, 4 May 2010 13:56:38 -0700 (PDT) Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with ESMTP id 4241328C539; Tue, 4 May 2010 13:06:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-145.messagelabs.com!1273003588!16067948!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 21965 invoked from network); 4 May 2010 20:06:28 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-13.tower-145.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 May 2010 20:06:28 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id o44K6RHJ030400; Tue, 4 May 2010 16:06:28 -0400 To: dime@ietf.org, dime-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: 5EBF267D:2E913548-85257719:006DCB4A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Tue, 4 May 2010 16:06:33 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/04/2010 04:07:11 PM, Serialize complete at 05/04/2010 04:07:11 PM Content-Type: multipart/alternative; boundary="=_alternative 006E78E785257719_=" Subject: [Dime] 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, 04 May 2010 20:56:39 -0000 This is a multipart message in MIME format. --=_alternative 006E78E785257719_= Content-Type: text/plain; charset="US-ASCII" Mostly Nits End of sec 1- What is [draft.rsvp-priority-extension]? Do you mean draft-ietf-tsvwg-emergency-rsvp? (And it is now up to rev 15, rather than the 14 cited in your references) Sec 3.2 I think "the admission priority parameter defined in Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp]." should refer to sec 5.1 Sec 3.3, 3.4 It might be a good idea to put something in the text explaining the rationale for specifying both the full text "Namespace, Value" pair and the numerical encoding defined in sec 5.2 and sec 7 of [I-D.ietf-tsvwg-emergency-rsvp]. They contain the same information, though in quite different formats. It is presumably because SIP uses one format and RSVP uses a different format, but it wouldn't hurt to add a sentence of explanation. Lower level question- If you are using the full text "Namespace, value" pair, I suggest calling it "RPH-Namespace" or "SIP-RPH-Namespace" rather than "SIP-Namespace". (Same for SIP-Value), to avoid confusion with other SIP Namespaces and other SIP Values. Sec 3.4 The subsections should be renumbered 3.4.1 and 3.4.2. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 006E78E785257719_= Content-Type: text/html; charset="US-ASCII"
Mostly Nits


End of sec 1- What is [draft.rsvp-priority-extension]?   Do you mean draft-ietf-tsvwg-emergency-rsvp? (And it is now up to rev 15, rather than the 14 cited in your references)

Sec 3.2  I think "the admission priority parameter defined in Section 3.1 of   [I-D.ietf-tsvwg-emergency-rsvp]." should refer to sec 5.1

Sec 3.3, 3.4

It might be a good idea to put something in the text explaining the rationale for specifying both the full text "Namespace, Value" pair and the numerical encoding defined in sec 5.2 and sec 7 of [I-D.ietf-tsvwg-emergency-rsvp].  They contain the same information, though in quite different formats. It is presumably because SIP uses one format and RSVP uses a different format, but it wouldn't hurt to add a sentence of explanation.


Lower level question-
If you are using the full text "Namespace, value" pair, I suggest calling it "RPH-Namespace" or "SIP-RPH-Namespace" rather than "SIP-Namespace". (Same for SIP-Value), to avoid confusion with other SIP Namespaces and other SIP Values.


Sec 3.4
The subsections should be renumbered 3.4.1 and 3.4.2.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 006E78E785257719_=-- From jouni.nospam@gmail.com Wed May 5 05:15:10 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 3270128C0E2 for ; Wed, 5 May 2010 05:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.879, 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 IY1w7+yM40sL for ; Wed, 5 May 2010 05:15:09 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 250C428C0F5 for ; Wed, 5 May 2010 05:15:02 -0700 (PDT) Received: by fxm4 with SMTP id 4so4524796fxm.31 for ; Wed, 05 May 2010 05:14:45 -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:to:mime-version :x-mailer; bh=usPyoo3koXOATzUmfqFMvsjJ0OE50eiH+UrKTBDp3uQ=; b=t8GaJUzapWkikNNe4mKt+Rfs9QCpHSwuNAWs7ZwMnqgGc6sgcmPuIWYm48+3P8sGqT 2NPYhXwCHDMQfDWEtlV9nHly6JAAm6SSafzmhiVCxFupBqNXbJBBCpDOApC2zui+g5E+ x/51OLcCvlGkVyd6AOH4HuT4fMFqvpueo4zbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=D+8laJB8inIXIZ7TmcUH7gsH1KfBA9S9xBpaz1JESNo2k/QeCpin5XtRoTjq7GRX8e RXVCLl3rrudwqGq49Dho4DxkbSgPABo+MsDfbYokFGRqxeyBq5vwvvVcYZrcE75VGFkz glnMQoZ7A1Raa7fpwB0grHbBVA20NuV2NovkQ= Received: by 10.223.44.86 with SMTP id z22mr5299343fae.13.1273061684769; Wed, 05 May 2010 05:14:44 -0700 (PDT) Received: from a88-114-70-236.elisa-laajakaista.fi (a88-114-70-236.elisa-laajakaista.fi [88.114.70.236]) by mx.google.com with ESMTPS id p9sm13560339fkb.33.2010.05.05.05.14.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 May 2010 05:14:43 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 5 May 2010 15:14:40 +0300 Message-Id: <488FCF80-CAC1-4372-B1DD-702EF5A032D7@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Reminder about the WGLC ending 10th May 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, 05 May 2010 12:15:10 -0000 You can see the progress of the WGLCs from the link below: http://trac.tools.ietf.org/wg/dime/trac/wiki/DimeLastCall1 So far the review rate has been.. low. - Jouni From carlberg@g11.org.uk Wed May 5 06:36: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 24F1D3A6A79 for ; Wed, 5 May 2010 06:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 NvclMsH++0oz for ; Wed, 5 May 2010 06:36:05 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 1AD863A68C0 for ; Wed, 5 May 2010 06:36:04 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51327 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O9elP-0004fY-Qg; Wed, 05 May 2010 13:35:48 +0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-72-554089103 From: ken carlberg In-Reply-To: Date: Wed, 5 May 2010 09:35:48 -0400 Message-Id: <9EC8C347-4718-4910-B2E0-645E11B8B6E9@g11.org.uk> References: To: Janet P Gunn 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.eukhost.com 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 Subject: Re: [Dime] 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: Wed, 05 May 2010 13:36:06 -0000 --Apple-Mail-72-554089103 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Janet, Thanks for the comments. > Mostly Nits=20 >=20 > End of sec 1- What is [draft.rsvp-priority-extension]? Do you mean = draft-ietf-tsvwg-emergency-rsvp? (And it is now up to rev 15, rather = than the 14 cited in your references)=20 yes, good catch. I'll correct this > Sec 3.2 I think "the admission priority parameter defined in Section = 3.1 of [I-D.ietf-tsvwg-emergency-rsvp]." should refer to sec 5.1=20 yes, another good catch. > Sec 3.3, 3.4=20 >=20 > It might be a good idea to put something in the text explaining the = rationale for specifying both the full text "Namespace, Value" pair and = the numerical encoding defined in sec 5.2 and sec 7 of = [I-D.ietf-tsvwg-emergency-rsvp]. They contain the same information, = though in quite different formats. It is presumably because SIP uses one = format and RSVP uses a different format, but it wouldn't hurt to add a = sentence of explanation.=20 Your understanding is correct, and I'll add some text to make this clear = to the reader. > Lower level question-=20 > If you are using the full text "Namespace, value" pair, I suggest = calling it "RPH-Namespace" or "SIP-RPH-Namespace" rather than = "SIP-Namespace". (Same for SIP-Value), to avoid confusion with other SIP = Namespaces and other SIP Values.=20 ok, I'll alter the text to be more descriptive to relate to the optional = RPH field. > Sec 3.4=20 > The subsections should be renumbered 3.4.1 and 3.4.2.=20 right. thanks again, -ken --Apple-Mail-72-554089103 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Janet,

Thanks for the comments.

Mostly Nits

End of sec 1- What is [draft.rsvp-priority-extension]?   Do you mean draft-ietf-tsvwg-emergency-rsvp? (And it is now up to rev 15, rather than the 14 cited in your references)

yes, good catch.  I'll correct this

Sec 3.2  I think "the admission priority parameter defined in Section 3.1 of   [I-D.ietf-tsvwg-emergency-rsvp]." should refer to sec 5.1

yes, another good catch.

Sec 3.3, 3.4

It might be a good idea to put something in the text explaining the rationale for specifying both the full text "Namespace, Value" pair and the numerical encoding defined in sec 5.2 and sec 7 of [I-D.ietf-tsvwg-emergency-rsvp].  They contain the same information, though in quite different formats. It is presumably because SIP uses one format and RSVP uses a different format, but it wouldn't hurt to add a sentence of explanation.

Your understanding is correct, and I'll add some text to make this clear to the reader.

Lower level question-
If you are using the full text "Namespace, value" pair, I suggest calling it "RPH-Namespace" or "SIP-RPH-Namespace" rather than "SIP-Namespace". (Same for SIP-Value), to avoid confusion with other SIP Namespaces and other SIP Values.

ok, I'll alter the text to be more descriptive to relate to the optional RPH field.

Sec 3.4
The subsections should be renumbered 3.4.1 and 3.4.2.

right.

thanks again,

-ken

--Apple-Mail-72-554089103-- From vipul2.aggarwal@aricent.com Thu May 6 06:06: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 F2A9128C17C for ; Thu, 6 May 2010 06:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 AdwEZmNF3tu7 for ; Thu, 6 May 2010 06:06:12 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by core3.amsl.com (Postfix) with ESMTP id 594893A6BC6 for ; Thu, 6 May 2010 06:04:09 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 7BE7636B4C for ; Thu, 6 May 2010 18:29:42 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 66A3236B24 for ; Thu, 6 May 2010 18:29:42 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Thu, 6 May 2010 18:33:52 +0530 From: Vipul2 Aggarwal To: "dime@ietf.org" Date: Thu, 6 May 2010 18:33:51 +0530 Thread-Topic: Origin-State-Id AVP Thread-Index: AcrtHJMB/7tXid0FRu+wKP5L3x/O/Q== Message-ID: <082B8F090E42374E91BDB6571C58FF990228B245B0@GUREXMB01.ASIAN.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_082B8F090E42374E91BDB6571C58FF990228B245B0GUREXMB01ASIA_" MIME-Version: 1.0 Subject: [Dime] Origin-State-Id AVP 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, 06 May 2010 13:06:15 -0000 --_000_082B8F090E42374E91BDB6571C58FF990228B245B0GUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a query regarding usage of Origin-State-Id AVP in Diameter. The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY be in= cluded in any diameter message. Now, some diameter based application (like a 3GPP defined application) defi= nes new commands and in those commands' ABNF Origin-State-Id AVP is not pre= sent. Then does this imply that Origin-State-Id AVP MUST not be sent in these com= mands or it can be sent because RFC 3588 says it can be sent in any diamete= r message? Thanks n Regards, Vipul Aggarwal ARICENT Gurgaon India ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_082B8F090E42374E91BDB6571C58FF990228B245B0GUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a query regarding usage of Origin-State-Id AVP in= Diameter.

 

The Diameter Base Protocol RFC 3588 says that Origin-Sta= te-Id AVP MAY be included in any diameter message.=

 

Now, some diameter based application (like a 3GPP define= d application) defines new commands and in those commands’ ABNF Origi= n-State-Id AVP is not present.

Then does this imply that Origin-State-Id AVP MUST not b= e sent in these commands or it can be sent because RFC 3588 says it can be = sent in any diameter message?

 

Thanks n Regards,

Vipul Aggarwal

ARICENT

Gurgaon

India

 


"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error, please notify the originator immediately. If you= are not the intended recipient, you are notified that you are strictly pro= hibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
 --_000_082B8F090E42374E91BDB6571C58FF990228B245B0GUREXMB01ASIA_-- From p.ohanlon@gmail.com Thu May 6 10:16:26 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 C93AC3A692D for ; Thu, 6 May 2010 10:16:26 -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 NCtp4MFTfbdT for ; Thu, 6 May 2010 10:16:26 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 4F3303A6A81 for ; Thu, 6 May 2010 10:15:58 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so55773eyf.51 for ; Thu, 06 May 2010 10:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:reply-to:from :date:message-id:subject:to:content-type; bh=APLWbajDMN266ODpWAsr1SEtTOe/hl2okrAtD6ML7yM=; b=FOZZOQAbSVfI5QoS8cv2Nir6IBByz6Un5Y9oCyp3AipcoVYnotNGNyyqnNTyc1Fvsr SNu1Qr0XvumbcFmHo4o7wMkj4YlBt7yQR1VflsMl/xELibdCscrXqsMQWIN8wTaIQQ8t yOGv/x+umdG50y2iZ5c6ZsRfYybnUw5V738Qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; b=wB7ZYUFtAmkyn/m0iHLM9CWl/xc1KPCjMtBqRAqQNd5qr0TSvmTP9aa5X6BYKKrCUs up0CubWTGUAnvT++bXPnXXWEVfg2eNGDlGDV7GZ3AlhoQUAwXmPL0krdZKx+rM5X65iN /4/JThFrdWfWnE/eagE1IwmikYStSzR1Pd+ho= Received: by 10.213.91.76 with SMTP id l12mr8213810ebm.47.1273166140604; Thu, 06 May 2010 10:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.16.77 with HTTP; Thu, 6 May 2010 10:15:18 -0700 (PDT) From: "P O'Hanlon" Date: Thu, 6 May 2010 18:15:18 +0100 Message-ID: To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Dime] Further comments on draft-ietf-dime-priority-avps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: p.ohanlon@cs.ucl.ac.uk List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 17:16:26 -0000 A few more comments. Sec 3. - It's probably worth adding a specific reference for the "DIAMETER QoS application.." ie soon-to-be RFC5866 (see: http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-15). Sec 5. - It would be good to add some explanatory text to the example. Where SIP is mentioned it may be useful to state any implications or otherwise for "Diameter Session Initiation Protocol (SIP) Application" (RFC4740). At a minimum it should be mentioned in Section 5 as it refers to the MAA/MAR messages defined in RFC4740. Piers From jouni.nospam@gmail.com Thu May 6 11:25:48 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 2BA0B3A6A36 for ; Thu, 6 May 2010 11:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_40=-0.185] 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 OEgUK26baIof for ; Thu, 6 May 2010 11:25:46 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 7967528C160 for ; Thu, 6 May 2010 11:22:58 -0700 (PDT) Received: from a88-114-64-198.elisa-laajakaista.fi (a88-114-64-198.elisa-laajakaista.fi [88.114.64.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 7979D13961A; Thu, 6 May 2010 21:22:41 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: <082B8F090E42374E91BDB6571C58FF990228B245B0@GUREXMB01.ASIAN.AD.ARICENT.COM> Date: Thu, 6 May 2010 21:22:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <167B065D-8FC2-40AE-860B-4A42E8637ABF@gmail.com> References: <082B8F090E42374E91BDB6571C58FF990228B245B0@GUREXMB01.ASIAN.AD.ARICENT.COM> To: Vipul2 Aggarwal X-Mailer: Apple Mail (2.1078) Cc: "dime@ietf.org" Subject: Re: [Dime] Origin-State-Id AVP 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, 06 May 2010 18:25:48 -0000 Hi, Eventually it is up to the command ABNF. If the command ABNF has *[AVP] = then including Origin-State-Id AVP is ok.=20 - Jouni On May 6, 2010, at 4:03 PM, Vipul2 Aggarwal wrote: > Hi, > =20 > I have a query regarding usage of Origin-State-Id AVP in Diameter. > =20 > The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY = be included in any diameter message. > =20 > Now, some diameter based application (like a 3GPP defined application) = defines new commands and in those commands=92 ABNF Origin-State-Id AVP = is not present. > Then does this imply that Origin-State-Id AVP MUST not be sent in = these commands or it can be sent because RFC 3588 says it can be sent in = any diameter message? > =20 > Thanks n Regards, > Vipul Aggarwal > ARICENT > Gurgaon > India > =20 >=20 > "DISCLAIMER: This message is proprietary to Aricent and is intended = solely for the use of the individual to whom it is addressed. It may = contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. = If you have received this message in error, please notify the originator = immediately. If you are not the intended recipient, you are notified = that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no = responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from virus." > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jsalowey@cisco.com Thu May 6 20:43:10 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 D30F33A68EE for ; Thu, 6 May 2010 20:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.163 X-Spam-Level: X-Spam-Status: No, score=-9.163 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_40=-0.185, HTML_MESSAGE=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 OZki6gvcEuZ6 for ; Thu, 6 May 2010 20:43:06 -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 9BE663A67B2 for ; Thu, 6 May 2010 20:43:06 -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: AgUFAKoo40urR7Hu/2dsb2JhbACBP5AajDNxojWZQYUTBINB X-IronPort-AV: E=Sophos;i="4.52,345,1270425600"; d="scan'208,217";a="126050878" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 07 May 2010 03:42:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o473gs72000569 for ; Fri, 7 May 2010 03:42:54 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); Thu, 6 May 2010 20:42:53 -0700 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_01CAED97.6005DD5D" Date: Thu, 6 May 2010 20:42:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-dime-local-keytran-03 Thread-Index: Acrtl12sPac6N9K9TPSXykaaNEhQSw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 07 May 2010 03:42:53.0985 (UTC) FILETIME=[5FFEA910:01CAED97] Subject: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 07 May 2010 03:43:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAED97.6005DD5D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this specification is useful. Here are some comments: =20 1. Key types - The document lists USRK and DSUSRK as key types. These are a class of keys and do not necessarily refer to a specific application. How would one represent different USRKs for different usages? Are rMSK and rRK examples of USRKs? =20 2. IN 3.1.2 and 3.1.3 it mentions that this depends upon the link layer. Could these keys be used for other purposes (say at the IP layer)? If they could perhaps it would be better to say "usage" instead of link layer. If not then the current text is fine. =20 3. The key lifetime is specified from when the key is first used. In this case if there is a long period of time between when the key is generated and used then the key life time may exceed the lifetime of the root key. This indicates that the key generator can't determine when a particular set of keys will expire. Is this what is desired? Why not start the timer from when it is received? =20 4. Key-SPI - is there a particular example for a usage of this? How does it differ from key ID? =20 5. Section 3.1 states certain attributes as optional it seems that key name is also optional so it seems the text is a bit misleading. You might also mention that additional attributes can be defined to pertain to a key (I think this is the case from the *[ AVP ] Joe ------_=_NextPart_001_01CAED97.6005DD5D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think this specification is useful.   =  Here are some  comments:

 

1.       Key types -  The document lists USRK and = DSUSRK as key types.    These are a class of keys and do not = necessarily refer to a specific application.  How would one represent different = USRKs for different usages?  Are rMSK and rRK examples of USRKs?  =

2.       IN 3.1.2 and 3.1.3 it mentions that this depends = upon the link layer.  Could these keys be used for other purposes =  (say at the IP layer)?  If they could perhaps it would be better to say = “usage” instead of link layer.   If not then the current text is = fine. 

3.       The key lifetime is specified from when the key = is first used.   In this case if there is a long period of time between = when the key is generated and used then the key life time may exceed the = lifetime of the root key.   This indicates that the key generator = can’t determine when a particular set of keys  will expire.  Is this = what is desired?  Why not start the timer from when it is = received? 

4.       Key-SPI – is there a particular example = for a usage of this?   How does it differ from key ID?  =

5.       Section 3.1 states certain attributes as = optional it seems that key name is also optional so it seems the text is a bit = misleading.   You might also mention that additional attributes can be defined to = pertain to a key (I think this is the case from the  *[ AVP ]

Joe

------_=_NextPart_001_01CAED97.6005DD5D-- From vipul2.aggarwal@aricent.com Thu May 6 22:44: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 3017B28B797 for ; Thu, 6 May 2010 22:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 JmZ6CGzRwGGZ for ; Thu, 6 May 2010 22:44:04 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 7EC093A6C92 for ; Thu, 6 May 2010 22:37:04 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 33B6936B78; Fri, 7 May 2010 11:02:39 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 1CAB736B4E; Fri, 7 May 2010 11:02:39 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Fri, 7 May 2010 11:06:50 +0530 From: Vipul2 Aggarwal To: Jouni Date: Fri, 7 May 2010 11:06:49 +0530 Thread-Topic: [Dime] Origin-State-Id AVP Thread-Index: AcrtSSHr04+FVwroSNO+vX4fwWJMYAAXHHMg Message-ID: <082B8F090E42374E91BDB6571C58FF990228B246A9@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <082B8F090E42374E91BDB6571C58FF990228B245B0@GUREXMB01.ASIAN.AD.ARICENT.COM> <167B065D-8FC2-40AE-860B-4A42E8637ABF@gmail.com> In-Reply-To: <167B065D-8FC2-40AE-860B-4A42E8637ABF@gmail.com> 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: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Origin-State-Id AVP 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, 07 May 2010 05:44:08 -0000 Hi, Thanks Jouni for the clarification. I think now I need to take my query with 3GPP. But, in case, anyone can help me here, I am describing my query below. =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=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 I am specifically concerned about 3GPP S6a application defined in 29.272. S6a is the interface between MME and HSS. The Origin-State-Id AVP is not present in any of the 8 commands' ABNF defin= ed in 29.272. However, there is *[AVP]. So, I now know that Origin-State-Id AVP can theoretically come. But, I doubt whether it is really required in S6a, as the Auth-Session-Stat= e AVP for S6a is NO_STATE_MAINTAINED i.e. no state information about a sess= ion is maintained? Moreover, there is a Reset Request command from HSS to indicate to the MME = about the restart of HSS. So, I think Origin-State-Id AVP is not required in S6a Application. Does an= yone have different views? =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=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 Thanks n Regds, Vipul -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Thursday, May 06, 2010 11:53 PM To: Vipul2 Aggarwal Cc: dime@ietf.org Subject: Re: [Dime] Origin-State-Id AVP Hi, Eventually it is up to the command ABNF. If the command ABNF has *[AVP] the= n including Origin-State-Id AVP is ok. - Jouni On May 6, 2010, at 4:03 PM, Vipul2 Aggarwal wrote: > Hi, > > I have a query regarding usage of Origin-State-Id AVP in Diameter. > > The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY be = included in any diameter message. > > Now, some diameter based application (like a 3GPP defined application) de= fines new commands and in those commands' ABNF Origin-State-Id AVP is not p= resent. > Then does this imply that Origin-State-Id AVP MUST not be sent in these c= ommands or it can be sent because RFC 3588 says it can be sent in any diame= ter message? > > Thanks n Regards, > Vipul Aggarwal > ARICENT > Gurgaon > India > > > "DISCLAIMER: This message is proprietary to Aricent and is intended solel= y for the use of the individual to whom it is addressed. It may contain pri= vileged or confidential information and should not be circulated or used fo= r any purpose other than for what it is intended. If you have received this= message in error, please notify the originator immediately. If you are not= the intended recipient, you are notified that you are strictly prohibited = from using, copying, altering, or disclosing the contents of this message. = Aricent accepts no responsibility for loss or damage arising from the use o= f the information transmitted by this email including damage from virus." > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From jouni.nospam@gmail.com Fri May 7 00:25: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 6C2933A6AD3 for ; Fri, 7 May 2010 00:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.720, 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 0JELfpzCXuuw for ; Fri, 7 May 2010 00:25:44 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 2D10A3A6C84 for ; Fri, 7 May 2010 00:24:59 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so1919840fge.13 for ; Fri, 07 May 2010 00:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=CSofHS5nLjFYEyEzQe8MANArh7qaAYrMB4+RvJrpnOY=; b=BrSqxKdiYO2uqgUP5r79x6/miiMidfsFq4fGa1pQYGuYmNFw3bAWOfzdKbevtZabpp qvBiiYAA6bTq+d/abgQhGE40GS6AKXbOJraEInj6JzzB/ms+VBbLAgkgv6aVPehUM0eP UZhfov1Wb1XzlYLif+OOR+umQhXGduLEmqLW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B2sU8TKnJyy3DMo2C3eG/8kMostVavFFS2Jjsdme7vMQvFXKTYO/agvhV8W9DLQawU Hfb3RzDTHwd0dvZ7NEqHV/tw1tEIGv4hpzfOPZDq86d2Vc/Mp7nygoXHgs8GVGzBq0FX aVx3ZZB0MImZxXcsoksEArDeSg87bO7jpqJPg= Received: by 10.87.63.1 with SMTP id q1mr3020832fgk.38.1273217084077; Fri, 07 May 2010 00:24:44 -0700 (PDT) Received: from a88-114-64-208.elisa-laajakaista.fi (a88-114-64-208.elisa-laajakaista.fi [88.114.64.208]) by mx.google.com with ESMTPS id 1sm3529409fkt.41.2010.05.07.00.24.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 May 2010 00:24:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <082B8F090E42374E91BDB6571C58FF990228B246A9@GUREXMB01.ASIAN.AD.ARICENT.COM> Date: Fri, 7 May 2010 10:24:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082B8F090E42374E91BDB6571C58FF990228B245B0@GUREXMB01.ASIAN.AD.ARICENT.COM> <167B065D-8FC2-40AE-860B-4A42E8637ABF@gmail.com> <082B8F090E42374E91BDB6571C58FF990228B246A9@GUREXMB01.ASIAN.AD.ARICENT.COM> To: Vipul2 Aggarwal X-Mailer: Apple Mail (2.1078) Cc: "dime@ietf.org" Subject: Re: [Dime] Origin-State-Id AVP 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, 07 May 2010 07:25:45 -0000 Hi, On May 7, 2010, at 8:36 AM, Vipul2 Aggarwal wrote: > Hi, >=20 > Thanks Jouni for the clarification. >=20 > I think now I need to take my query with 3GPP. > But, in case, anyone can help me here, I am describing my query below. >=20 > = =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=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 > I am specifically concerned about 3GPP S6a application defined in = 29.272. > S6a is the interface between MME and HSS. > The Origin-State-Id AVP is not present in any of the 8 commands' ABNF = defined in 29.272. However, there is *[AVP]. > So, I now know that Origin-State-Id AVP can theoretically come. Yes, it can. However, in this particular case my concern would be the = content of M-bit. As S6a is based on base protocol, it would sound = logical that S6a application should then understand RFC3588 AVPs with = M-bit set. Based on the earlier experience on 3GPP interfaces such = assumption would be rather risky though ;) > But, I doubt whether it is really required in S6a, as the = Auth-Session-State AVP for S6a is NO_STATE_MAINTAINED i.e. no state = information about a session is maintained? > Moreover, there is a Reset Request command from HSS to indicate to the = MME about the restart of HSS. > So, I think Origin-State-Id AVP is not required in S6a Application. = Does anyone have different views? There are people here who are familiar with S6a (and basically the whole = plethora of 3GPP Diameter interfaces). However, the question as such is = rather specific to 3GPP, especially as the S6a *is* a 3GPP vendor = specific application. We really don't have much control over it. So I = advice you to bring your question to 3GPP CT4 mailing list = (http://list.etsi.org/3gpp_tsg_ct_wg4.html) and ask there. - Jouni > = =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=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 >=20 > Thanks n Regds, > Vipul >=20 > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com] > Sent: Thursday, May 06, 2010 11:53 PM > To: Vipul2 Aggarwal > Cc: dime@ietf.org > Subject: Re: [Dime] Origin-State-Id AVP >=20 > Hi, >=20 > Eventually it is up to the command ABNF. If the command ABNF has = *[AVP] then including Origin-State-Id AVP is ok. >=20 > - Jouni >=20 >=20 > On May 6, 2010, at 4:03 PM, Vipul2 Aggarwal wrote: >=20 >> Hi, >>=20 >> I have a query regarding usage of Origin-State-Id AVP in Diameter. >>=20 >> The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY = be included in any diameter message. >>=20 >> Now, some diameter based application (like a 3GPP defined = application) defines new commands and in those commands' ABNF = Origin-State-Id AVP is not present. >> Then does this imply that Origin-State-Id AVP MUST not be sent in = these commands or it can be sent because RFC 3588 says it can be sent in = any diameter message? >>=20 >> Thanks n Regards, >> Vipul Aggarwal >> ARICENT >> Gurgaon >> India >>=20 >>=20 >> "DISCLAIMER: This message is proprietary to Aricent and is intended = solely for the use of the individual to whom it is addressed. It may = contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. = If you have received this message in error, please notify the originator = immediately. If you are not the intended recipient, you are notified = that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no = responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from virus." >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > "DISCLAIMER: This message is proprietary to Aricent and is intended = solely for the use of the individual to whom it is addressed. It may = contain privileged or confidential information and should not be = circulated or used for any purpose other than for what it is intended. = If you have received this message in error, please notify the originator = immediately. If you are not the intended recipient, you are notified = that you are strictly prohibited from using, copying, altering, or = disclosing the contents of this message. Aricent accepts no = responsibility for loss or damage arising from the use of the = information transmitted by this email including damage from virus." From gwz@net-zen.net Fri May 7 02:15: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 947E43A6CAA for ; Fri, 7 May 2010 02:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 mlE9OjwZnnXk for ; Fri, 7 May 2010 02:14:53 -0700 (PDT) Received: from p3plsmtpa01-04.prod.phx3.secureserver.net (p3plsmtpa01-04.prod.phx3.secureserver.net [72.167.82.84]) by core3.amsl.com (Postfix) with SMTP id 96ECF3A6999 for ; Fri, 7 May 2010 02:14:29 -0700 (PDT) Received: (qmail 16488 invoked from network); 7 May 2010 09:14:15 -0000 Received: from unknown (115.67.96.71) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 07 May 2010 09:14:09 -0000 From: "Glen Zorn" To: "'Joseph Salowey \(jsalowey\)'" References: In-Reply-To: Date: Fri, 7 May 2010 16:13:25 +0700 Organization: Network Zen Message-ID: <00b701caedc5$92e4d150$b8ae73f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01CAEE00.3F43A950" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrtl12sPac6N9K9TPSXykaaNEhQSwALJAvA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 07 May 2010 09:15:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B8_01CAEE00.3F43A950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Joseph Salowey [mailto://jsalowey@cisco.com] writes: I think this specification is useful. Here are some comments: 1. Key types - The document lists USRK and DSUSRK as key types. These are a class of keys and do not necessarily refer to a specific application. How would one represent different USRKs for different usages? Are rMSK and rRK examples of USRKs? Any recommendations? 2. IN 3.1.2 and 3.1.3 it mentions that this depends upon the link layer. Could these keys be used for other purposes (say at the IP layer)? If they could perhaps it would be better to say "usage" instead of link layer. If not then the current text is fine. Good idea, I can make that change (see below). 3. The key lifetime is specified from when the key is first used. In this case if there is a long period of time between when the key is generated and used then the key life time may exceed the lifetime of the root key. This indicates that the key generator can't determine when a particular set of keys will expire. Is this what is desired? Why not start the timer from when it is received? OK 4. Key-SPI - is there a particular example for a usage of this? How does it differ from key ID? Check https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/. In fact, this AVP was added in response to a request from the authors of that draft, so that they remove the key-related stuff from that document (which is, unfortunately, yet to be updated). 5. Section 3.1 states certain attributes as optional it seems that key name is also optional so it seems the text is a bit misleading. Good point. How's this: The Key AVP (AVP Code ) is of type Grouped [RFC3588] It contains the type and keying material and optionally an indication of the usable lifetime of the key, the name of the key and a SPI with which the key is associated. You might also mention that additional attributes can be defined to pertain to a key (I think this is the case from the *[ AVP ] OK Joe ------=_NextPart_000_00B8_01CAEE00.3F43A950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joseph Salowey [mailto://jsalowey@cisco.com] = writes:

 

I think this specification is useful.   =  Here are some  comments:

 

1.       Key types -  The document lists USRK and = DSUSRK as key types.    These are a class of keys and do not = necessarily refer to a specific application.  How would one represent different = USRKs for different usages?  Are rMSK and rRK examples of USRKs?  =

Any recommendations?

2.       IN 3.1.2 and 3.1.3 it mentions that this depends = upon the link layer.  Could these keys be used for other purposes =  (say at the IP layer)?  If they could perhaps it would be better to say “usage” instead of link layer.   If not then the = current text is fine. 

Good idea, I can make that change (see = below).

3.       The key lifetime is specified from when the key = is first used.   In this case if there is a long period of time = between when the key is generated and used then the key life time may exceed the lifetime of the root key.   This indicates that the key = generator can’t determine when a particular set of keys  will = expire.  Is this what is desired?  Why not start the timer from when it is received? 

OK

4.       Key-SPI – is there a particular example = for a usage of this?   How does it differ from key ID?  =

Check https://datatracker.ietf.org= /doc/draft-ietf-dime-ikev2-psk-diameter/.  In fact, this AVP was added in response to a request from the authors of = that draft, so that they remove the key-related stuff from that document = (which is, unfortunately, yet to be updated).

5.       Section 3.1 states certain attributes as = optional it seems that key name is also optional so it seems the text is a bit misleading.  

Good point.  How’s this:

   The Key AVP (AVP Code = <AC1>) is of type Grouped [RFC3588] It contains the type and =

   keying material and optionally = an indication of the usable lifetime of the key, the

   name of the key and a SPI with = which the key is associated.

You might also mention = that additional attributes can be defined to pertain to a key (I think this = is the case from the  *[ AVP ]

OK

Joe

------=_NextPart_000_00B8_01CAEE00.3F43A950-- From carlberg@g11.org.uk Fri May 7 07:26:01 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 5513B3A69DB for ; Fri, 7 May 2010 07:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_40=-0.185] 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 CTi7ktJjq5fu for ; Fri, 7 May 2010 07:26:00 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 3F2FF3A6AB2 for ; Fri, 7 May 2010 07:26:00 -0700 (PDT) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:58613 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OAOUq-000289-It; Fri, 07 May 2010 14:25:44 +0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Fri, 7 May 2010 10:25:45 -0400 Content-Transfer-Encoding: 7bit Message-Id: <94A3AFA2-935C-4C96-945E-D7A93F2EA7AD@g11.org.uk> References: To: p.ohanlon@cs.ucl.ac.uk 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.eukhost.com 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 Subject: Re: [Dime] Further 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: Fri, 07 May 2010 14:26:01 -0000 Piers, thanks. I'll address your comments in the next rev. -ken On May 6, 2010, at 1:15 PM, P O'Hanlon wrote: > A few more comments. > > Sec 3. > - It's probably worth adding a specific reference for the "DIAMETER > QoS application.." ie soon-to-be RFC5866 (see: > http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-15). > > Sec 5. > - It would be good to add some explanatory text to the example. > > Where SIP is mentioned it may be useful to state any implications or > otherwise for "Diameter Session Initiation Protocol (SIP) Application" > (RFC4740). At a minimum it should be mentioned in Section 5 as it > refers to the MAA/MAR messages defined in RFC4740. > > Piers > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From tom111.taylor@bell.net Sun May 9 16:25:10 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 5FA1628B56A for ; Sun, 9 May 2010 16:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.98 X-Spam-Level: X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 k5-J3jbUyKwX for ; Sun, 9 May 2010 16:25:09 -0700 (PDT) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by core3.amsl.com (Postfix) with ESMTP id 08D0B3A66B4 for ; Sun, 9 May 2010 16:25:08 -0700 (PDT) Received: from BLU0-SMTP31 ([65.55.116.72]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 May 2010 16:24:57 -0700 X-Originating-IP: [70.26.23.183] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP31.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 May 2010 16:24:57 -0700 Date: Sun, 09 May 2010 19:24:54 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Glen Zorn References: <00b701caedc5$92e4d150$b8ae73f0$@net> In-Reply-To: <00b701caedc5$92e4d150$b8ae73f0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2010 23:24:57.0798 (UTC) FILETIME=[D6B52E60:01CAEFCE] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 09 May 2010 23:25:10 -0000 Below. Glen Zorn wrote: > Joseph Salowey > [mailto://jsalowey@cisco.com] writes: > > > > I think this specification is useful. Here are some comments: > > > > 1. Key types - The document lists USRK and DSUSRK as key types. > These are a class of keys and do not necessarily refer to a specific > application. How would one represent different USRKs for different usages? > Are rMSK and rRK examples of USRKs? > >[GZ] Any recommendations? [PTT] Looking at that section it seemed natural to me to specify applicable domain and key usage as separate attributes. ... From tom111.taylor@bell.net Sun May 9 16:55:41 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 70CF828C0F1 for ; Sun, 9 May 2010 16:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 y1K8t7MDM8No for ; Sun, 9 May 2010 16:55:40 -0700 (PDT) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by core3.amsl.com (Postfix) with ESMTP id A535028C0DB for ; Sun, 9 May 2010 16:55:40 -0700 (PDT) Received: from BLU0-SMTP85 ([65.55.116.72]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 May 2010 16:55:29 -0700 X-Originating-IP: [70.26.23.183] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP85.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 May 2010 16:55:28 -0700 Date: Sun, 09 May 2010 19:55:25 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "dime@ietf.org" , wuqin , Glen Zorn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2010 23:55:29.0086 (UTC) FILETIME=[1A3D8DE0:01CAEFD3] Subject: [Dime] Comments on draft-ietf-dime-local-keytran-03 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, 09 May 2010 23:55:41 -0000 I have a couple of comments on draft-ietf-dime-local-keytran-03. 1) As suggested in my previous E-mail, the attributes contained in the Key AVP should probably include an applicable domain identifier (in the absence of which the key is not domain-specific), and an enumeration indicating usage. The two usages I see are reauthentication root key and master session root key. In a bow to RFC 5295, I suppose DSRK should be added to and stand at the head of this list. Obviously the usage list has to be extensible -- another IANA registry. 2) Minor comment: I would think section 5.2 itself would contain a table listing the values to be registered. Of course, if my suggestion is adopted the details of this will be different. Tom taylor From sdecugis@nict.go.jp Sun May 9 19:01: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 73D583A68BB for ; Sun, 9 May 2010 19:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.708 X-Spam-Level: X-Spam-Status: No, score=0.708 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_50=0.001, HELO_EQ_JP=1.244] 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 XSrSI8LMVZ74 for ; Sun, 9 May 2010 19:01:35 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 574F53A677E for ; Sun, 9 May 2010 19:01:33 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o4A21KJ8029173 for ; Mon, 10 May 2010 11:01:20 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o4A21KVI017478 for ; Mon, 10 May 2010 11:01:20 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o4A21KZU017475 for ; Mon, 10 May 2010 11:01:20 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 154031687C for ; Mon, 10 May 2010 11:01:20 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 089D01687A for ; Mon, 10 May 2010 11:01:20 +0900 (JST) Message-ID: <4BE768D7.4090702@nict.go.jp> Date: Mon, 10 May 2010 11:00:55 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] ERP: about notification of handovers to the home domain 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, 10 May 2010 02:01:36 -0000 Hello, During the Hiroshima and Anaheim meetings, the following question was discussed at length: should a peer moving locally in a foreign domain be notified to the home domain? I believe these discussions made the following conclusion clear: different people have different needs with this respect. As such, it seems obvious that the Diameter ERP protocol must be able to accommodate both situations. One possibility of achieving this is by having the home domain notify the foreign domain in advance of its policy with regards to this matter, at the time where the DSRK key is delivered. This can be achieved by including a new AVP in the message that contains the DSRK. This new AVP (name TBD) can have the following values: - HOME_AUTH_REQUIRED: for each local handover in the foreign domain, the re-authentication is achieved with the local ERP server. However, an authorization request is sent to the home domain when the authentication step is completed successfully. This allows the home domain to be always aware of the current point of attachment of the peer, almost in real time. - NO_HOME_AUTH_REQUIRED: After a local handover, the new network access server can be granted the same authorization attributes as the previous point of attachment, with the natural adjustments (decreased lifetimes, ...). This requires the local Diameter ERP server to cache these attributes. It also means that the home domain may not know the exact point of attachment of the peer, but only the realm, depending on how accounting is performed. I would like to gather the feedback of the group on this issue -- in particular, what should be the default behavior -- and reach a consensus to update the document. Thank you for reading, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Tue May 11 00:45: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 93C8B3A6B13 for ; Tue, 11 May 2010 00:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[AWL=1.088, 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 EzBqoBkEdBuh for ; Tue, 11 May 2010 00:45:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E6C723A6B11 for ; Tue, 11 May 2010 00:45:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2800LRSW4GTG@szxga04-in.huawei.com> for dime@ietf.org; Tue, 11 May 2010 15:43:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L28007RKW4G46@szxga04-in.huawei.com> for dime@ietf.org; Tue, 11 May 2010 15:43:28 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2800LY4W4FYK@szxml06-in.huawei.com> for dime@ietf.org; Tue, 11 May 2010 15:43:27 +0800 (CST) Date: Tue, 11 May 2010 15:43:27 +0800 From: Qin Wu To: Sebastien Decugis , dime@ietf.org Message-id: <00d701caf0dd$a4f097b0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4BE768D7.4090702@nict.go.jp> Subject: Re: [Dime] ERP: about notification of handovers to the home domain 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, 11 May 2010 07:45:30 -0000 Hi, Sebastien: If my understanding is correct, your proposal is: a) Negotiate between local ER server and home server on whether to hide point of attachment from the home server using new AVP. b) This new AVP is only carried during ERP bootstrapping,i.e.,at the time when the DSRK is delivered from the home server to the local ER server. c) This new AVP is only for authorization. If in this case, I think this proposal sounds one reasonable choice to me. Following up this proposal, I have several comments or questions: 1). It is not clear that two values for the new AVP is used for authorization only or authentication only? If the new AVP is used for authorization only, then it is better to change HOME_AUTH_REQUIED into HOME_AUTHZ_REQUIED. 2). Since authorization is separated from authentication, is it the only possiblity to use Diameter ERP message to transport this new AVP? 3). Which Diameter message will be used to transport authorization attribute after the value in the new AVP is set? 4) Which of the existing AVP will be used to send point of attachment to the home realm? 5). How the ERP session is managed during handoff? Hope to get clarified. Regards! -Qin ----- Original Message ----- From: "Sebastien Decugis" To: Sent: Monday, May 10, 2010 10:00 AM Subject: [Dime] ERP: about notification of handovers to the home domain > Hello, > > During the Hiroshima and Anaheim meetings, the following question was > discussed at length: should a peer moving locally in a foreign domain be > notified to the home domain? > > I believe these discussions made the following conclusion clear: > different people have different needs with this respect. As such, it > seems obvious that the Diameter ERP protocol must be able to accommodate > both situations. One possibility of achieving this is by having the home > domain notify the foreign domain in advance of its policy with regards > to this matter, at the time where the DSRK key is delivered. This can be > achieved by including a new AVP in the message that contains the DSRK. > This new AVP (name TBD) can have the following values: > - HOME_AUTH_REQUIRED: for each local handover in the foreign domain, the > re-authentication is achieved with the local ERP server. However, an > authorization request is sent to the home domain when the authentication > step is completed successfully. This allows the home domain to be always > aware of the current point of attachment of the peer, almost in real time. > - NO_HOME_AUTH_REQUIRED: After a local handover, the new network access > server can be granted the same authorization attributes as the previous > point of attachment, with the natural adjustments (decreased lifetimes, > ...). This requires the local Diameter ERP server to cache these > attributes. It also means that the home domain may not know the exact > point of attachment of the peer, but only the realm, depending on how > accounting is performed. > > I would like to gather the feedback of the group on this issue -- in > particular, what should be the default behavior -- and reach a consensus > to update the document. > > Thank you for reading, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Tue May 11 03:28: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 BBD4128C16E for ; Tue, 11 May 2010 03:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.608, 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 q6qeB8Gwhhi6 for ; Tue, 11 May 2010 03:28:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 216413A6B87 for ; Tue, 11 May 2010 03:25:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="188102279" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 May 2010 06:25:48 -0400 X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="461497335" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 May 2010 06:25:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 12:25:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Errata Held for Document Update] RFC4740 (2246) Thread-Index: AcrwR5RQ1GeN2cZuQgOkGQybrqs7jgArK3qw From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: [Errata Held for Document Update] RFC4740 (2246) 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, 11 May 2010 10:28:03 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Monday, May 10, 2010 4:49 PM To: Miguel.A.Garcia@ericsson.com; miguel.an.garcia@nokia.com; maria.carmen.belinchon@ericsson.com; miguel-angel.pallares@ericsson.com; carolina.canales@ericsson.com; kalle.tammi@nokia.com Cc: Romascanu, Dan (Dan); iesg@iesg.org; rfc-editor@rfc-editor.org Subject: [Errata Held for Document Update] RFC4740 (2246) The following errata report has been held for document update for RFC4740, "Diameter Session Initiation Protocol (SIP) Application".=20 -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4740&eid=3D2246 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Miguel A. Garcia Date Reported: 2010-05-06 Held by: Dan Romascanu (IESG) Section: 9.12.1 Original Text ------------- The SIP-User-Data AVP (AVP Code 390) is of type UTF8String and contains a string that identifies the type of user data included in the SIP-User-Data AVP (Section 9.12). Corrected Text -------------- The SIP-User-Data-Type AVP (AVP Code 390) is of type UTF8String and ^^^^^ contains a string that identifies the type of user data included in the SIP-User-Data AVP (Section 9.12). Notes ----- -------------------------------------- RFC4740 (draft-ietf-aaa-diameter-sip-app-12) -------------------------------------- Title : Diameter Session Initiation Protocol (SIP) Application Publication Date : November 2006 Author(s) : M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG From dromasca@avaya.com Tue May 11 03:28: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 8A05928C171 for ; Tue, 11 May 2010 03:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.603, 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 9nNMfLCnQqfS for ; Tue, 11 May 2010 03:28:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id F07C23A6B8B for ; Tue, 11 May 2010 03:26:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="188102282" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 May 2010 06:25:49 -0400 X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="461497351" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 May 2010 06:25:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 12:25:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Errata Held for Document Update] RFC4072 (1956) Thread-Index: AcrwRlxGpdZL0Pu0R76leHHkSfMb1gAreqdQ From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: [Errata Held for Document Update] RFC4072 (1956) 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, 11 May 2010 10:28:04 -0000 =20 -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Monday, May 10, 2010 4:40 PM To: gwz@net-zen.net; pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com Cc: Romascanu, Dan (Dan); iesg@iesg.org; rfc-editor@rfc-editor.org Subject: [Errata Held for Document Update] RFC4072 (1956) The following errata report has been held for document update for RFC4072, "Diameter Extensible Authentication Protocol (EAP) Application".=20 -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4072&eid=3D1956 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Glen Zorn Date Reported: 2009-12-03 Held by: Dan Romascanu (IESG) Section: 4.1.4 Original Text ------------- In addition, the home Diameter server SHOULD include this AVP in=20 Diameter-EAP-Response only if an empty EAP-Key-Name AVP was present in=20 Diameter-EAP-Request. Corrected Text -------------- In addition, the home Diameter server SHOULD include this AVP in the=20 Diameter-EAP-Answer message only if an empty EAP-Key-Name AVP was present in the corresponding Diameter-EAP-Request. Notes ----- There's no such thing as a "Diameter-EAP-Response" message; the rephrasing is for purposes of clarification. -------------------------------------- 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 From dromasca@avaya.com Tue May 11 03:28: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 769E328C171 for ; Tue, 11 May 2010 03:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, 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 EoTIElDCH+aa for ; Tue, 11 May 2010 03:28:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 06C913A6C0D for ; Tue, 11 May 2010 03:26:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="188102285" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 May 2010 06:25:49 -0400 X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="461497363" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 May 2010 06:25:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 12:25:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Errata Held for Document Update] RFC4072 (1955) Thread-Index: AcrwRkrsqu+VpgCcQeWeBcFpCh4tYQArgErg From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: [Errata Held for Document Update] RFC4072 (1955) 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, 11 May 2010 10:28:05 -0000 =20 -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Monday, May 10, 2010 4:40 PM To: gwz@net-zen.net; pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com Cc: Romascanu, Dan (Dan); iesg@iesg.org; rfc-editor@rfc-editor.org Subject: [Errata Held for Document Update] RFC4072 (1955) The following errata report has been held for document update for RFC4072, "Diameter Extensible Authentication Protocol (EAP) Application".=20 -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4072&eid=3D1955 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Glen Zorn Date Reported: 2009-12-03 Held by: Dan Romascanu (IESG) Section: 4.1.4 Original Text ------------- Note that not all link layers use this name, and currently most EAP methods do not generate it. Since the NAS operates in pass-through mode, it cannot know the Key-Name before receiving it from the AAA server. As a result, a Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter server receiving a Diameter-EAP-Request with a Key-Name AVP with non-empty data MUST silently discard the AVP. =20 Corrected Text -------------- Note that not all link layers use this name, and currently most EAP methods do not generate it. Since the NAS operates in pass-through mode, it cannot know the name of the key before receiving it from the AAA server. As a result, an EAP-Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter server receiving a Diameter-EAP-Request containing an EAP-Key-Name AVP with non-empty data MUST silently ignore the AVP. =20 Notes ----- In the original text, the first occurrence of the string "Key-Name" apparently is meant to refer to the actual name of the key, rather than an AVP identifier, while the next two occurrences are obviously typos, since no Key-Name AVP is defined in the document. Also, the term "silently discard" is typically used in reference to messages; with reference to a single AVP, "silently ignore" seems more appropriate. -------------------------------------- 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 From dromasca@avaya.com Tue May 11 03:28: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 604A53A6C0D for ; Tue, 11 May 2010 03:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.593, 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 FjpbWp96HgxU for ; Tue, 11 May 2010 03:28:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 017EF28C14F for ; Tue, 11 May 2010 03:26:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="188102321" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 May 2010 06:26:13 -0400 X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="473775033" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 May 2010 06:26:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 12:25:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Errata Held for Document Update] RFC3588 (2101) Thread-Index: AcrwRcHL1+FSo1IGTlisnuKEjOK41wArpB4Q From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: [Errata Held for Document Update] RFC3588 (2101) 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, 11 May 2010 10:28:29 -0000 =20 -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Monday, May 10, 2010 4:36 PM To: dierbro@gmail.com; pcalhoun@airespace.com; john.Loughney@nokia.com; Jari.Arkko@ericsson.com; erik.guttman@sun.com Cc: Romascanu, Dan (Dan); iesg@iesg.org; rfc-editor@rfc-editor.org Subject: [Errata Held for Document Update] RFC3588 (2101) The following errata report has been held for document update for RFC3588, "Diameter Base Protocol".=20 -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D3588&eid=3D2101 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Diego Rosario Brogna Date Reported: 2010-03-31 Held by: Dan Romascanu (IESG) Section: 3.2 Original Text ------------- header =3D "<" Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] [application-id]">" Corrected Text -------------- header =3D "" Notes ----- -------------------------------------- RFC3588 (draft-ietf-aaa-diameter-17) -------------------------------------- Title : Diameter Base Protocol Publication Date : September 2003 Author(s) : P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG From dromasca@avaya.com Tue May 11 05:47:26 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 ADD433A680E for ; Tue, 11 May 2010 05:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.616, 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 8d1mG7GWyRrA for ; Tue, 11 May 2010 05:47:26 -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 684473A6BB3 for ; Tue, 11 May 2010 05:43:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="15342538" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 11 May 2010 06:15:45 -0400 X-IronPort-AV: E=Sophos;i="4.53,206,1272859200"; d="scan'208";a="473770304" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 May 2010 06:15:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 May 2010 12:15:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Errata #1946 Thread-Index: Acrw8uhy8rcMdyagS8Og3DnhFxsH2A== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] Errata #1946 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, 11 May 2010 12:47:26 -0000 DIME WG, Please issue a recommendation concerning errata #1946 (related to RFC 4005) Dan From gwz@net-zen.net Tue May 11 20:07: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 AB77F3A690A for ; Tue, 11 May 2010 20:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, 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 ihUebFYdvd4M for ; Tue, 11 May 2010 20:07:58 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id CE4683A68A4 for ; Tue, 11 May 2010 20:07:57 -0700 (PDT) Received: (qmail 4098 invoked from network); 12 May 2010 03:07:45 -0000 Received: from unknown (111.84.208.16) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 12 May 2010 03:07:43 -0000 From: "Glen Zorn" To: "'Qin Wu'" References: <010a01caf0e1$0961e980$23548a0a@china.huawei.com> In-Reply-To: <010a01caf0e1$0961e980$23548a0a@china.huawei.com> Date: Wed, 12 May 2010 10:07:24 +0700 Organization: Network Zen Message-ID: <01f301caf180$44c1a610$ce44f230$@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: Acrw4Q2aAh4EySyqRv26zbSM6NLGZAAnoQjw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Comments on draft-ietf-dime-local-keytran-03 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, 12 May 2010 03:07:58 -0000 Qin Wu [mailto:sunseawq@huawei.com] writes: > Hi, Glen: > Could you take care of the comments from Tom below? I have no idea what the purpose of the domain identifier might be; similarly, adding a table to section 5.2 would seem only to add verbiage, rather than utility, to the draft. > > Regards! > -Qin > ----- Original Message ----- > From: "Tom Taylor" > To: ; "wuqin" ; "Glen Zorn" > > Sent: Monday, May 10, 2010 7:55 AM > Subject: Comments on draft-ietf-dime-local-keytran-03 > > > >I have a couple of comments on draft-ietf-dime-local-keytran-03. > > > > 1) As suggested in my previous E-mail, the attributes contained in the > Key AVP > > should probably include an applicable domain identifier (in the > absence of which > > the key is not domain-specific), and an enumeration indicating usage. > The two > > usages I see are reauthentication root key and master session root > key. In a bow > > to RFC 5295, I suppose DSRK should be added to and stand at the head > of this > > list. Obviously the usage list has to be extensible -- another IANA > registry. > > > > 2) Minor comment: I would think section 5.2 itself would contain a > table listing > > the values to be registered. Of course, if my suggestion is adopted > the details > > of this will be different. > > > > Tom taylor > > > > From tom111.taylor@bell.net Wed May 12 05:55: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 8D2903A68AA for ; Wed, 12 May 2010 05:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.905 X-Spam-Level: X-Spam-Status: No, score=0.905 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 J0-wsCxnupaV for ; Wed, 12 May 2010 05:55:34 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id 9E2D63A6B4C for ; Wed, 12 May 2010 05:55:26 -0700 (PDT) Received: from BLU0-SMTP97 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:55:16 -0700 X-Originating-IP: [70.26.23.183] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP97.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 05:55:16 -0700 Date: Wed, 12 May 2010 08:55:13 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Glen Zorn References: <010a01caf0e1$0961e980$23548a0a@china.huawei.com> <01f301caf180$44c1a610$ce44f230$@net> In-Reply-To: <01f301caf180$44c1a610$ce44f230$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2010 12:55:16.0311 (UTC) FILETIME=[5E6D0670:01CAF1D2] Cc: dime@ietf.org Subject: Re: [Dime] Comments on draft-ietf-dime-local-keytran-03 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, 12 May 2010 12:55:35 -0000 The domain identifier would be needed if the receiving entity managed keys for multiple domains. Glen Zorn wrote: > Qin Wu [mailto:sunseawq@huawei.com] writes: > >> Hi, Glen: >> Could you take care of the comments from Tom below? > > I have no idea what the purpose of the domain identifier might be; > similarly, adding a table to section 5.2 would seem only to add verbiage, > rather than utility, to the draft. > >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Tom Taylor" >> To: ; "wuqin" ; "Glen Zorn" >> >> Sent: Monday, May 10, 2010 7:55 AM >> Subject: Comments on draft-ietf-dime-local-keytran-03 >> >> >>> I have a couple of comments on draft-ietf-dime-local-keytran-03. >>> >>> 1) As suggested in my previous E-mail, the attributes contained in the >> Key AVP >>> should probably include an applicable domain identifier (in the >> absence of which >>> the key is not domain-specific), and an enumeration indicating usage. >> The two >>> usages I see are reauthentication root key and master session root >> key. In a bow >>> to RFC 5295, I suppose DSRK should be added to and stand at the head >> of this >>> list. Obviously the usage list has to be extensible -- another IANA >> registry. >>> 2) Minor comment: I would think section 5.2 itself would contain a >> table listing >>> the values to be registered. Of course, if my suggestion is adopted >> the details >>> of this will be different. >>> >>> Tom taylor >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From jsalowey@cisco.com Wed May 12 15:47:09 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 D1FC23A682E for ; Wed, 12 May 2010 15:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.905 X-Spam-Level: X-Spam-Status: No, score=-8.905 tagged_above=-999 required=5 tests=[AWL=-0.906, 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 2byBe2-8AGBr for ; Wed, 12 May 2010 15:47:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0A8E33A6942 for ; Wed, 12 May 2010 15:46:55 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIfM6kurR7Ht/2dsb2JhbACeJ3GjYplThRIEg0A X-IronPort-AV: E=Sophos;i="4.53,217,1272844800"; d="scan'208";a="528847469" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 12 May 2010 22:46:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CMkjTT003946; Wed, 12 May 2010 22:46:45 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 15:46:45 -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: Wed, 12 May 2010 15:46:42 -0700 Message-ID: In-Reply-To: <00b701caedc5$92e4d150$b8ae73f0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-local-keytran-03 Thread-Index: Acrtl12sPac6N9K9TPSXykaaNEhQSwALJAvAAQtx3wA= References: <00b701caedc5$92e4d150$b8ae73f0$@net> From: "Joseph Salowey (jsalowey)" To: "Glen Zorn" X-OriginalArrivalTime: 12 May 2010 22:46:45.0233 (UTC) FILETIME=[FF78C610:01CAF224] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 12 May 2010 22:47:10 -0000 > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net] > Sent: Friday, May 07, 2010 2:13 AM > To: Joseph Salowey (jsalowey) > Cc: dime@ietf.org > Subject: RE: [Dime] Review of draft-ietf-dime-local-keytran-03 >=20 > Joseph Salowey [mailto://jsalowey@cisco.com] > writes: >=20 >=20 >=20 > I think this specification is useful. Here are some comments: >=20 >=20 >=20 > 1. Key types - The document lists USRK and DSUSRK as key types. > These are a class of keys and do not necessarily refer to a specific > application. How would one represent different USRKs for different > usages? Are rMSK and rRK examples of USRKs? >=20 > Any recommendations? [Joe] Right now key type is representing both a class of key (USRK,DSUSRK,etc) and a specific application and usage of key material (rMSK and rRK). For example an rRK may either be a USRK or a DSUSRK. There are several ways you could do this differently. a) Flatten out the space - get rid of USRK, DSUSRK - include rRK, rMSK, MSK, DSRK, IKEv2 PSK. Add a domain AVP that would be included if the key is a DSRK or an instance of a DSUSRK. This would contain the domain that was used in the key derivation (perhaps this is always know, but maybe a server can server more than one domain). =20 b) Keep the key type to indicate the class of the key and have a new attribute indicate the application and specific type. The class would indicate what other attributes would be required in the group. For example, IKE keys would have an SPI, DSUSRKs a domain etc. The classes might be USRK, DSUSRK, MSK, IKE-PSK,... Another attribute would indicate the specific application for the key.=20 I think b is too complex. I'd suggest modifying the key Type section as follows: "3.1.1. Key-Type AVP The Key-Type AVP (AVP Code ) is of type Enumerated and signifies the type of the key being sent. The following values are defined in this document: MSK (0) The EAP Master Session Key [RFC3748]. DSRK (1) A Domain-Specific Root Key [RFC5295]. If the domain of the key is not known through other means then the Key AVP MUST contain a Key-Domain AVP. =20 rRK (2) A reauthentication Root Key [RFC5296]. If the rRK is derive from a DSRK and the domain of the key is not known through other means then the Key AVP MUST contain a Key-Domain AVP. =20 rMSK (3) A reauthentication Master Session Key [RFC5296]. If the rMSK is derive from a DSRK and the domain of the key is not known through other means then the Key AVP MUST contain a Key-Domain AVP. =20 ikev2-psk(4) A pre-shared key for use in IKE-V2 key exchange [draft-ietf-dime-ikev2-psk-diameter] If additional values are needed, they are to be assigned by IANA according to the policy stated in Section 5.2" Also it may make sense to define a key-domain AVP assuming that it is possible that the domain of the key is ambiguous: " 3.1.6 Key-Domain The Key-Domain AVP (AVP Code ) is of type UTF8String and contains the domain name associated with the key. " >=20 > 2. IN 3.1.2 and 3.1.3 it mentions that this depends upon the link > layer. Could these keys be used for other purposes (say at the IP > layer)? If they could perhaps it would be better to say "usage" instead > of link layer. If not then the current text is fine. >=20 > Good idea, I can make that change (see below). >=20 > 3. The key lifetime is specified from when the key is first used. > In this case if there is a long period of time between when the key is > generated and used then the key life time may exceed the lifetime of the > root key. This indicates that the key generator can't determine when a > particular set of keys will expire. Is this what is desired? Why not > start the timer from when it is received? >=20 > OK >=20 > 4. Key-SPI - is there a particular example for a usage of this? > How does it differ from key ID? >=20 > Check https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ > . > In fact, this AVP was added in response to a request from the authors of > that draft, so that they remove the key-related stuff from that document > (which is, unfortunately, yet to be updated). >=20 [Joe] The draft should probably include reference to this work. > 5. Section 3.1 states certain attributes as optional it seems that > key name is also optional so it seems the text is a bit misleading. >=20 > Good point. How's this: >=20 > The Key AVP (AVP Code ) is of type Grouped [RFC3588] It contains > the type and >=20 > keying material and optionally an indication of the usable lifetime of > the key, the >=20 > name of the key and a SPI with which the key is associated. >=20 [Joe] Good > You might also mention that additional attributes can be defined to > pertain to a key (I think this is the case from the *[ AVP ] >=20 > OK >=20 > Joe From mark@azu.ca Wed May 12 18:58: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 415BF3A6908 for ; Wed, 12 May 2010 18:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 UmIk-npu3kHd for ; Wed, 12 May 2010 18:58:05 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id EBD433A67AF for ; Wed, 12 May 2010 18:58:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so1663439fge.13 for ; Wed, 12 May 2010 18:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.180.201 with SMTP id j9mr729622hbg.164.1273715870474; Wed, 12 May 2010 18:57:50 -0700 (PDT) Received: by 10.239.131.134 with HTTP; Wed, 12 May 2010 18:57:50 -0700 (PDT) In-Reply-To: <20100504184502.086A93A6A40@core3.amsl.com> References: <20100504184502.086A93A6A40@core3.amsl.com> Date: Thu, 13 May 2010 10:57:50 +0900 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] I-D Action:draft-ietf-dime-extended-naptr-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, 13 May 2010 01:58:06 -0000 This version of the draft incorporates the Application Service Tag format that I proposed at IETF77 and is aligned with 3588bis on S-NAPTR usage in Diameter. Comments appreciated. Regards Mark On Wed, May 5, 2010 at 3:45 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Diameter Maintenance and Extensions Work= ing Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Diameter Extended NAPTR > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Jones, J. Korhonen > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dime-extended-naptr-0= 1.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 9 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-05-04 > > This document describes an extended format for the S-NAPTR > Application Service Tag used in dynamic Diameter agent discovery. > The extended format allows NAPTR queries to contain Diameter > Application-Id information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-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. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From gwz@net-zen.net Wed May 12 21:35: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 B51B33A6A2B for ; Wed, 12 May 2010 21:35:50 -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 xBgAnU93Wf4c for ; Wed, 12 May 2010 21:35:49 -0700 (PDT) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 6B1193A69AC for ; Wed, 12 May 2010 21:35:49 -0700 (PDT) Received: (qmail 17929 invoked from network); 13 May 2010 04:35:38 -0000 Received: from unknown (111.84.45.212) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 13 May 2010 04:35:34 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: In-Reply-To: Date: Thu, 13 May 2010 11:35:05 +0700 Organization: Network Zen Message-ID: <000301caf255$b1e83e90$15b8bbb0$@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: Acrw8uhy8rcMdyagS8Og3DnhFxsH2AAkgq6g Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Errata #1946 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, 13 May 2010 04:35:50 -0000 Dan Romascanu [mailto://dromasca@avaya.com] writes: > DIME WG, > > Please issue a recommendation concerning errata #1946 (related to RFC > 4005) While the original text is certainly misleading at best, the new text is not a lot better since is leaves out the Accounting-Input-Packets and Accounting-Output-Packets AVPs. I think that a better correction would be something like this: If the Accounting-Input-Octets, Accounting-Input-Packets, Accounting-Output-Octets, or Accounting-Output-Packets AVPs are present, they SHOULD be translated to the corresponding RADIUS attributes. However, if the value of the Accounting-Input-Octets AVP or Accounting-Output-Octets AVP does not fit within a 32-bit RADIUS attribute, the RADIUS Acct-Input- Gigawords and Acct-Output-Gigawords Attributes must be used. > > Dan > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Wed May 12 22:34:01 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 4488B3A6A63 for ; Wed, 12 May 2010 22:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 vp57D7ru622A for ; Wed, 12 May 2010 22:33:59 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id A57963A6830 for ; Wed, 12 May 2010 22:30:25 -0700 (PDT) Received: (qmail 15754 invoked from network); 13 May 2010 05:29:56 -0000 Received: from unknown (111.84.45.212) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 13 May 2010 05:29:44 -0000 From: "Glen Zorn" To: "'Joseph Salowey \(jsalowey\)'" References: <00b701caedc5$92e4d150$b8ae73f0$@net> In-Reply-To: Date: Thu, 13 May 2010 12:29:19 +0700 Organization: Network Zen Message-ID: <000401caf25d$420b7d50$c62277f0$@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: Acrtl12sPac6N9K9TPSXykaaNEhQSwALJAvAAQtx3wAAGpQIAA== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 13 May 2010 05:34:02 -0000 Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] writes: > > 1. Key types - The document lists USRK and DSUSRK as key types. > > These are a class of keys and do not necessarily refer to a specific > > application. How would one represent different USRKs for different > > usages? Are rMSK and rRK examples of USRKs? > > > > Any recommendations? > > [Joe] Right now key type is representing both a class of key > (USRK,DSUSRK,etc) and a specific application and usage of key material > (rMSK and rRK). For example an rRK may either be a USRK or a DSUSRK. > There are several ways you could do this differently. > > a) Flatten out the space - get rid of USRK, DSUSRK - include rRK, rMSK, > MSK, DSRK, IKEv2 PSK. Add a domain AVP that would be included if the > key is a DSRK or an instance of a DSUSRK. This would contain the domain > that was used in the key derivation (perhaps this is always know, but > maybe a server can server more than one domain). Tom Taylor mentioned this as well but I am still puzzled by it: in what scenario could this occur? AFAIK all the keys are bound to a particular session which is itself bound to a particular access point. What am I missing? ... > > 4. Key-SPI - is there a particular example for a usage of this? > > How does it differ from key ID? > > > > Check > https://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ > > > . > > In fact, this AVP was added in response to a request from the authors > of > > that draft, so that they remove the key-related stuff from that > document > > (which is, unfortunately, yet to be updated). > > > [Joe] The draft should probably include reference to this work. OK. BTW, I apparently misspoke: draft-ietf-dime-ikev2-psk-diameter actually was updated to remove the key-related stuff & reference our draft some time ago. Sorry for any confusion! ... From dromasca@avaya.com Wed May 12 23:56:38 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 94CEC3A6A87 for ; Wed, 12 May 2010 23:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 6yhMVmkc4r+r for ; Wed, 12 May 2010 23:56:37 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B84CA3A6A8F for ; Wed, 12 May 2010 23:56:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,220,1272859200"; d="scan'208";a="217830957" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 May 2010 02:56:27 -0400 X-IronPort-AV: E=Sophos;i="4.53,220,1272859200"; d="scan'208";a="474576508" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 May 2010 02:56:26 -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, 13 May 2010 08:56:14 +0200 Message-ID: In-Reply-To: <000301caf255$b1e83e90$15b8bbb0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Errata #1946 Thread-Index: Acrw8uhy8rcMdyagS8Og3DnhFxsH2AAkgq6gADkYGWA= References: <000301caf255$b1e83e90$15b8bbb0$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] Errata #1946 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, 13 May 2010 06:56:38 -0000 This looks good to me.=20 Other opinions?=20 Dan =20 > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net]=20 > Sent: Thursday, May 13, 2010 7:35 AM > To: Romascanu, Dan (Dan) > Cc: dime@ietf.org > Subject: RE: [Dime] Errata #1946 >=20 > Dan Romascanu [mailto://dromasca@avaya.com] writes: >=20 > > DIME WG, > >=20 > > Please issue a recommendation concerning errata #1946=20 > (related to RFC > > 4005) >=20 > While the original text is certainly misleading at best, the=20 > new text is not a lot better since is leaves out the=20 > Accounting-Input-Packets and Accounting-Output-Packets AVPs. =20 > I think that a better correction would be something like this: >=20 > If the Accounting-Input-Octets, Accounting-Input-Packets, > Accounting-Output-Octets, or Accounting-Output-Packets AVPs are > present, they SHOULD be translated to the corresponding RADIUS > attributes. However, if the value of the=20 > Accounting-Input-Octets AVP > or Accounting-Output-Octets AVP does not fit > within a 32-bit RADIUS attribute, the RADIUS Acct-Input- > Gigawords and Acct-Output-Gigawords Attributes must be used. >=20 > >=20 > > Dan > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 From tom111.taylor@bell.net Thu May 13 06:01: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 015313A6892 for ; Thu, 13 May 2010 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] 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 XDSF69898zXC for ; Thu, 13 May 2010 06:01:41 -0700 (PDT) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by core3.amsl.com (Postfix) with ESMTP id 445E83A681E for ; Thu, 13 May 2010 06:01:37 -0700 (PDT) Received: from BLU0-SMTP13 ([65.55.116.72]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 06:01:27 -0700 X-Originating-IP: [70.26.23.183] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP13.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 06:01:27 -0700 Date: Thu, 13 May 2010 09:01:23 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Glen Zorn References: <00b701caedc5$92e4d150$b8ae73f0$@net> <000401caf25d$420b7d50$c62277f0$@net> In-Reply-To: <000401caf25d$420b7d50$c62277f0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 May 2010 13:01:27.0261 (UTC) FILETIME=[65F140D0:01CAF29C] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 13 May 2010 13:01:42 -0000 Below. Glen Zorn wrote: > Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] writes: > >>> 1. Key types - The document lists USRK and DSUSRK as key types. >>> These are a class of keys and do not necessarily refer to a specific >>> application. How would one represent different USRKs for different >>> usages? Are rMSK and rRK examples of USRKs? >>> >>> Any recommendations? >> [Joe] Right now key type is representing both a class of key >> (USRK,DSUSRK,etc) and a specific application and usage of key material >> (rMSK and rRK). For example an rRK may either be a USRK or a DSUSRK. >> There are several ways you could do this differently. >> >> a) Flatten out the space - get rid of USRK, DSUSRK - include rRK, rMSK, >> MSK, DSRK, IKEv2 PSK. Add a domain AVP that would be included if the >> key is a DSRK or an instance of a DSUSRK. This would contain the domain >> that was used in the key derivation (perhaps this is always know, but >> maybe a server can server more than one domain). > > Tom Taylor mentioned this as well but I am still puzzled by it: in what > scenario could this occur? AFAIK all the keys are bound to a particular > session which is itself bound to a particular access point. What am I > missing? > > ... [PTT] OK, this is one for the architecture to answer. I'll review the different interfaces to see if there is a case of anticipatory keying that isn't bound as tightly as you suggest. At the very least, I don't think the keys passed to a local ER server would be bound to a particular access point, but they may indeed be bound to a particular session, in some sense of session. From jsalowey@cisco.com Thu May 13 09:35: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 0DA733A691A for ; Thu, 13 May 2010 09:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, 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 JRXnR4tKgLxO for ; Thu, 13 May 2010 09:35:29 -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 DDB143A685A for ; Thu, 13 May 2010 09:35:15 -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: AvsEAIvH60urR7Ht/2dsb2JhbACeIHGkCZk6hRIEg0A X-IronPort-AV: E=Sophos;i="4.53,223,1272844800"; d="scan'208";a="129308358" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 13 May 2010 16:35:06 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4DGZ6JP028723; Thu, 13 May 2010 16:35:06 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); Thu, 13 May 2010 09:35:05 -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: Thu, 13 May 2010 09:35:04 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-local-keytran-03 Thread-Index: AcrynG3eS/86VoyNTOCVMDP0tA/98gAHZHpA References: <00b701caedc5$92e4d150$b8ae73f0$@net> <000401caf25d$420b7d50$c62277f0$@net> From: "Joseph Salowey (jsalowey)" To: "Tom Taylor" , "Glen Zorn" X-OriginalArrivalTime: 13 May 2010 16:35:05.0850 (UTC) FILETIME=[3E6AB5A0:01CAF2BA] Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 13 May 2010 16:35:30 -0000 > > > > Tom Taylor mentioned this as well but I am still puzzled by it: in what > > scenario could this occur? AFAIK all the keys are bound to a particular > > session which is itself bound to a particular access point. What am I > > missing? > > > > ... > [PTT] > OK, this is one for the architecture to answer. I'll review the different > interfaces to see if there is a case of anticipatory keying that isn't > bound as > tightly as you suggest. At the very least, I don't think the keys passed > to a > local ER server would be bound to a particular access point, but they may > indeed > be bound to a particular session, in some sense of session. [Joe] I can't think of a reason why the domain wouldn't already be known to the session. I'd be okay with leaving the domain out until there is a use-case for it. =20 From david@mitton.com Thu May 13 20:07:53 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 66C4F3A69F2 for ; Thu, 13 May 2010 20:07:53 -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 p1nr891NHO2C for ; Thu, 13 May 2010 20:07:52 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by core3.amsl.com (Postfix) with ESMTP id 119013A6852 for ; Thu, 13 May 2010 20:07:51 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay02.hostedemail.com (Postfix) with SMTP id 2CDD723B0F58; Fri, 14 May 2010 03:07:41 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 6461766964406D6974746F6E2E636F6D X-Filterd-Recvd-Size: 2958 Received: from CPQ-SEMPRON.mitton.com (c-24-147-31-235.hsd1.ma.comcast.net [24.147.31.235]) (Authenticated sender: david@mitton.com) by omf02.hostedemail.com (Postfix) with ESMTP; Fri, 14 May 2010 03:07:40 +0000 (UTC) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 May 2010 23:06:26 -0400 To: Sebastien Decugis , "Romascanu, Dan (Dan)" From: David Mitton In-Reply-To: <4BD0F81C.2020801@nict.go.jp> References: <4BCE85FE.1000401@nict.go.jp> <4BD0F81C.2020801@nict.go.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <20100514030741.2CDD723B0F58@smtprelay02.hostedemail.com> Cc: dime@ietf.org Subject: Re: [Dime] Termination-Cause IANA registry missing RFC4005 entries 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, 14 May 2010 03:07:53 -0000 Yes, this should be in the Dime=20 registry, particularly given every thing else that's in there now. Possibly the reason it's missing, is that there=20 is no mention in Section 11, IANA Considerations of this value mapping. Dave. Last RFC 4005 draft editor. On 4/22/2010 09:30 PM, Sebastien Decugis wrote: >Thank you Dan for your answer. >Since there has been no other comment, I will go forward and contact >IANA about this issue. > >Best regards, >Sebastien. > >Le 21/04/2010 17:14, Romascanu, Dan (Dan) a =E9crit : > > Unless a good reason is found or remembered by somebody - this should be > > reported to IANA. > > > > Dan > > > > > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > >> Behalf Of Sebastien Decugis > >> Sent: Wednesday, April 21, 2010 7:59 AM > >> To: dime@ietf.org > >> Subject: [Dime] Termination-Cause IANA registry missing > >> RFC4005 entries > >> > >> Hello, > >> > >> I just noticed that the IANA registry for Termination-Cause > >> AVP enumerated values [1] is missing the codes assigned from RFC4005 > >> (NASREQ) in section 9.3.5. This RFC reserves the values 11 to > >> 32 for mapping of RADIUS Acct-Terminate-Cause values. I am > >> not sure if this should be reported to IANA or here? Is there > >> a known reason why these values are not in the registry? > >> > >> Thank you! > >> Sebastien. > >> > >> [1] > >> http://www.iana.org/assignments/aaa-parameters/aaa-parameters. > >> xml#aaa-parameters-16 > >> > >> -- > >> Sebastien Decugis > >> Research fellow > >> Network Architecture Group > >> NICT (nict.go.jp) > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > >> > > > >-- >Sebastien Decugis >Research fellow >Network Architecture Group >NICT (nict.go.jp) > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime From david@mitton.com Thu May 13 20:35:16 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 782C33A69FA for ; Thu, 13 May 2010 20:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] 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 wSAo7kVQkvYg for ; Thu, 13 May 2010 20:35:14 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by core3.amsl.com (Postfix) with ESMTP id 38B733A69F2 for ; Thu, 13 May 2010 20:35:10 -0700 (PDT) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with SMTP id 88EE12578C3F; Fri, 14 May 2010 03:35:00 +0000 (UTC) X-Panda: scanned! X-Session-Marker: 6461766964406D6974746F6E2E636F6D X-Filterd-Recvd-Size: 2860 Received: from CPQ-SEMPRON.mitton.com (c-24-147-31-235.hsd1.ma.comcast.net [24.147.31.235]) (Authenticated sender: david@mitton.com) by omf06.hostedemail.com (Postfix) with ESMTP; Fri, 14 May 2010 03:34:59 +0000 (UTC) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 May 2010 23:35:04 -0400 To: "Glen Zorn" , "'Romascanu, Dan \(Dan\)'" From: David Mitton In-Reply-To: <000301caf255$b1e83e90$15b8bbb0$@net> References: <000301caf255$b1e83e90$15b8bbb0$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20100514033500.88EE12578C3F@smtprelay03.hostedemail.com> Cc: dime@ietf.org Subject: Re: [Dime] Errata #1946 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, 14 May 2010 03:35:16 -0000 I don't think the original text is misleading, just incomplete. There are two parts here. 1) All 4 Diameter AVPs must be translated into the corresponding 4 RADIUS attributes. 2) If the Diameter Octets attributes values are greater than 32-bits in magnitude, the higher order value must be mapped into the additional Gigaword attributes. What's not stated is, unfortunately there are only RADIUS Gigaword Attributes for Octets and not Packets. Avi's correction fixes the wrong problem, by leaving out the Packets translation. Glen's correction leaves that in, and makes the Gigaword translation cases explicit and for that reason is more complete. One could go a step further and point out that there is no RADIUS Acct attribute that can carry the full potential 64-bit value of Diameter AVPs Accounting-Input-Packets or Accounting-Input-Packets. Dave. On 5/13/2010 12:35 AM, Glen Zorn wrote: >Dan Romascanu [mailto://dromasca@avaya.com] writes: > > > DIME WG, > > > > Please issue a recommendation concerning errata #1946 (related to RFC > > 4005) > >While the original text is certainly misleading at best, the new text is not >a lot better since is leaves out the Accounting-Input-Packets and >Accounting-Output-Packets AVPs. I think that a better correction would be >something like this: > > If the Accounting-Input-Octets, Accounting-Input-Packets, > Accounting-Output-Octets, or Accounting-Output-Packets AVPs are > present, they SHOULD be translated to the corresponding RADIUS > attributes. However, if the value of the Accounting-Input-Octets AVP > or Accounting-Output-Octets AVP does not fit > within a 32-bit RADIUS attribute, the RADIUS Acct-Input- > Gigawords and Acct-Output-Gigawords Attributes must be used. > > > > > Dan > > _______________________________________________ > > 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 wwwrun@rfc-editor.org Fri May 14 16:08:14 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 DBCE528C132; Fri, 14 May 2010 16:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_05=-1.11, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 b2b0aQ3-6PoR; Fri, 14 May 2010 16:08:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 2591928C141; Fri, 14 May 2010 16:08:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77FE0E068F; Fri, 14 May 2010 16:08:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100514230805.77FE0E068F@rfc-editor.org> Date: Fri, 14 May 2010 16:08:05 -0700 (PDT) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 5866 on Diameter Quality-of-Service Application 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, 14 May 2010 23:08:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5866 Title: Diameter Quality-of-Service Application Author: D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed. Status: Standards Track Stream: IETF Date: May 2010 Mailbox: d.sun@alcatel-lucent.com, pete.mccann@motorola.com, Hannes.Tschofenig@gmx.net, tena@huawei.com, avri@ltu.se, gwz@net-zen.net Pages: 51 Characters: 122639 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-diameter-qos-15.txt URL: http://www.rfc-editor.org/rfc/rfc5866.txt This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. [STANDARDS TRACK] This document is a product of the Diameter Maintanence and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jouni.nospam@gmail.com Sat May 15 06:16:51 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 1A39E3A67EA for ; Sat, 15 May 2010 06:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, J_CHICKENPOX_93=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 KSXu1IpbiGom for ; Sat, 15 May 2010 06:16:50 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id CD32E3A682D for ; Sat, 15 May 2010 06:16:49 -0700 (PDT) Received: from a88-114-64-198.elisa-laajakaista.fi (a88-114-64-198.elisa-laajakaista.fi [88.114.64.198]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id C0A451394BA for ; Sat, 15 May 2010 16:16:37 +0300 (EEST) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 May 2010 16:16:36 +0300 References: <20100514230805.77FE0E068F@rfc-editor.org> To: dime@ietf.org Message-Id: <0B08F442-0E4B-4EAB-B41B-85C301EDB8C2@gmail.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Fwd: RFC 5866 on Diameter Quality-of-Service Application 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, 15 May 2010 13:16:51 -0000 We have yet again shipped a document that has spent some time in the = group. Congratulations to the authors for their persistent work! - chairs Begin forwarded message: > From: rfc-editor@rfc-editor.org > Date: May 15, 2010 2:08:05 AM GMT+03:00 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: dime@ietf.org, rfc-editor@rfc-editor.org > Subject: [Dime] RFC 5866 on Diameter Quality-of-Service Application >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 5866 >=20 > Title: Diameter Quality-of-Service Application=20 > Author: D. Sun, Ed., > P. McCann, H. Tschofenig, > T. Tsou, A. Doria, > G. Zorn, Ed. > Status: Standards Track > Stream: IETF > Date: May 2010 > Mailbox: d.sun@alcatel-lucent.com,=20 > pete.mccann@motorola.com,=20 > Hannes.Tschofenig@gmx.net, tena@huawei.com,=20 > avri@ltu.se, gwz@net-zen.net > Pages: 51 > Characters: 122639 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-dime-diameter-qos-15.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc5866.txt >=20 > This document describes the framework, messages, and procedures for > the Diameter Quality-of-Service (QoS) application. The Diameter QoS > application allows network elements to interact with Diameter servers > when allocating QoS resources in the network. In particular, two > modes of operation, namely "Pull" and "Push", are defined. [STANDARDS > TRACK] >=20 > This document is a product of the Diameter Maintanence and Extensions = Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Sun May 16 07:27: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 65D0D3A6971 for ; Sun, 16 May 2010 07:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_93=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 m81M+PdyLj7U for ; Sun, 16 May 2010 07:27:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 625CF3A67A7 for ; Sun, 16 May 2010 07:27:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,242,1272859200"; d="scan'208";a="218306049" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 May 2010 10:27:05 -0400 X-IronPort-AV: E=Sophos;i="4.53,242,1272859200"; d="scan'208";a="475422336" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 May 2010 10:27:04 -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: Sun, 16 May 2010 16:26:43 +0200 Message-ID: In-Reply-To: <0B08F442-0E4B-4EAB-B41B-85C301EDB8C2@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Fwd: RFC 5866 on Diameter Quality-of-Service Application Thread-Index: Acr0MOd6bJde7EpVTfehzdA0WUU9bAA0sn2w References: <20100514230805.77FE0E068F@rfc-editor.org> <0B08F442-0E4B-4EAB-B41B-85C301EDB8C2@gmail.com> From: "Romascanu, Dan (Dan)" To: "Jouni" , Subject: Re: [Dime] Fwd: RFC 5866 on Diameter Quality-of-Service Application 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, 16 May 2010 14:27:15 -0000 Indeed - congratulations to the WG, editors and chairs (present and past) for reaching this milestone.=20 Regards, Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Jouni > Sent: Saturday, May 15, 2010 4:17 PM > To: dime@ietf.org > Subject: [Dime] Fwd: RFC 5866 on Diameter Quality-of-Service=20 > Application >=20 > We have yet again shipped a document that has spent some time=20 > in the group. Congratulations to the authors for their=20 > persistent work! >=20 > - chairs >=20 > Begin forwarded message: >=20 > > From: rfc-editor@rfc-editor.org > > Date: May 15, 2010 2:08:05 AM GMT+03:00 > > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > > Cc: dime@ietf.org, rfc-editor@rfc-editor.org > > Subject: [Dime] RFC 5866 on Diameter Quality-of-Service Application > >=20 > >=20 > > A new Request for Comments is now available in online RFC libraries. > >=20 > >=20 > > RFC 5866 > >=20 > > Title: Diameter Quality-of-Service Application=20 > > Author: D. Sun, Ed., > > P. McCann, H. Tschofenig, > > T. Tsou, A. Doria, > > G. Zorn, Ed. > > Status: Standards Track > > Stream: IETF > > Date: May 2010 > > Mailbox: d.sun@alcatel-lucent.com,=20 > > pete.mccann@motorola.com,=20 > > Hannes.Tschofenig@gmx.net, tena@huawei.com,=20 > > avri@ltu.se, gwz@net-zen.net > > Pages: 51 > > Characters: 122639 > > Updates/Obsoletes/SeeAlso: None > >=20 > > I-D Tag: draft-ietf-dime-diameter-qos-15.txt > >=20 > > URL: http://www.rfc-editor.org/rfc/rfc5866.txt > >=20 > > This document describes the framework, messages, and procedures for=20 > > the Diameter Quality-of-Service (QoS) application. The=20 > Diameter QoS=20 > > application allows network elements to interact with=20 > Diameter servers=20 > > when allocating QoS resources in the network. In particular, two=20 > > modes of operation, namely "Pull" and "Push", are defined. =20 > [STANDARDS=20 > > TRACK] > >=20 > > This document is a product of the Diameter Maintanence and=20 > Extensions Working Group of the IETF. > >=20 > > This is now a Proposed Standard Protocol. > >=20 > > STANDARDS TRACK: This document specifies an Internet=20 > standards track=20 > > protocol for the Internet community,and requests discussion and=20 > > suggestions for improvements. Please refer to the current=20 > edition of=20 > > the Internet Official Protocol Standards (STD 1) for the=20 > > standardization state and status of this protocol. =20 > Distribution of this memo is unlimited. > >=20 > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > http://www.ietf.org/mailman/listinfo/ietf-announce > > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >=20 > > For searching the RFC series, see=20 > http://www.rfc-editor.org/rfcsearch.html. > > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > >=20 > > Requests for special distribution should be addressed to either the=20 > > author of the RFC in question, or to rfc-editor@rfc-editor.org. =20 > > Unless specifically noted otherwise on the RFC itself, all RFCs are=20 > > for unlimited distribution. > >=20 > >=20 > > The RFC Editor Team > > Association Management Solutions, LLC > >=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 >=20 From jouni.nospam@gmail.com Mon May 17 14:10:00 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 6D18528C156 for ; Mon, 17 May 2010 14:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 Rbb3doSzvqQ7 for ; Mon, 17 May 2010 14:09:59 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 5B67F28C154 for ; Mon, 17 May 2010 14:09:59 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so2322647fgb.13 for ; Mon, 17 May 2010 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mll0UwSAMw89AJX5A/CT5yllvcSeKmVgYfiXMckCmEU=; b=kPouBOrj/CNNnYq62iUWCRRSn/f7/PYu0YJXuwldFv2nR59YtTotIt2Xl8Mlppz8l2 VDPaTDgPRY+6zQDY2s624oxsRHdoqAl2x+l8lIS8aBcyi3cMrkX1SnnE9FVVN0WUszeo JaaAVKsxlHard4+K8K0gA9SwOYa/DJ/nsm8vQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=S0qDxn4INJQHUE394bp7NhqPlPgyX4d3RPxzFfM3ZTb3mfWbrB2V8E8aZDE9R1B/9H /IHBcW3X0T1SgC8QgLZ1oNqz3voOvah9PF84wcJLFOia9D2gj5RND+m8E7d226cCrjZm fEfGkxK4JOiioSMDAkxvUxMHNiSrPyJzgYMYo= Received: by 10.86.22.31 with SMTP id 31mr9454922fgv.24.1274130586620; Mon, 17 May 2010 14:09:46 -0700 (PDT) Received: from a88-114-68-184.elisa-laajakaista.fi (a88-114-68-184.elisa-laajakaista.fi [88.114.68.184]) by mx.google.com with ESMTPS id e20sm5902504fga.11.2010.05.17.14.09.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 May 2010 14:09:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 18 May 2010 00:09:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE3AA30-C1D6-41F1-9D6C-305DB8E1E867@gmail.com> References: <00b701caedc5$92e4d150$b8ae73f0$@net> <000401caf25d$420b7d50$c62277f0$@net> To: "Joseph Salowey (jsalowey)" , Tom Taylor , Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 17 May 2010 21:10:00 -0000 So, everybody happy with Joe's proposal of leaving the domain out? If = so, a new revision would be needed so that we can get this sorted out = and successfully conclude the WGLC. - Jouni On May 13, 2010, at 7:35 PM, Joseph Salowey (jsalowey) wrote: >>>=20 >>> Tom Taylor mentioned this as well but I am still puzzled by it: in > what >>> scenario could this occur? AFAIK all the keys are bound to a > particular >>> session which is itself bound to a particular access point. What am > I >>> missing? >>>=20 >>> ... >> [PTT] >> OK, this is one for the architecture to answer. I'll review the > different >> interfaces to see if there is a case of anticipatory keying that = isn't >> bound as >> tightly as you suggest. At the very least, I don't think the keys > passed >> to a >> local ER server would be bound to a particular access point, but they > may >> indeed >> be bound to a particular session, in some sense of session. >=20 >=20 > [Joe] I can't think of a reason why the domain wouldn't already be = known > to the session. I'd be okay with leaving the domain out until there = is > a use-case for it. =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Mon May 17 18:47:55 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 327183A6BBB for ; Mon, 17 May 2010 18:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_50=0.001, HELO_EQ_JP=1.244] 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 EVtL8L4IsZx9 for ; Mon, 17 May 2010 18:47:53 -0700 (PDT) Received: from ns1.nict.go.jp (unknown [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 13D7C3A6AF2 for ; Mon, 17 May 2010 18:47:52 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o4I1lfmK011007 for ; Tue, 18 May 2010 10:47:41 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o4I1lfJk015898 for ; Tue, 18 May 2010 10:47:41 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o4I1lfQN015893 for ; Tue, 18 May 2010 10:47:41 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 754842C2EA for ; Tue, 18 May 2010 10:47:41 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 703412C2DB for ; Tue, 18 May 2010 10:47:41 +0900 (JST) Message-ID: <4BF1F1B9.2050608@nict.go.jp> Date: Tue, 18 May 2010 10:47:37 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: dime@ietf.org References: <00b701caedc5$92e4d150$b8ae73f0$@net> <000401caf25d$420b7d50$c62277f0$@net> <2BE3AA30-C1D6-41F1-9D6C-305DB8E1E867@gmail.com> In-Reply-To: <2BE3AA30-C1D6-41F1-9D6C-305DB8E1E867@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 18 May 2010 01:47:55 -0000 Hi, Since the Key AVP's ABNF allows other AVPs anyway ( * [AVP ] ), it will be easy to add the domain, should one encounter a situation where it is not the same as the Orinigin-Realm of the message... So, I think is it not a problem to not include the domain here. My 2 cents, Sebastien. Le 18/05/2010 06:09, jouni korhonen a écrit : > > So, everybody happy with Joe's proposal of leaving the domain out? If so, a new revision would be needed so that we can get this sorted out and successfully conclude the WGLC. > > - Jouni > > > On May 13, 2010, at 7:35 PM, Joseph Salowey (jsalowey) wrote: > > >>>> Tom Taylor mentioned this as well but I am still puzzled by it: in >>>> >> what >> >>>> scenario could this occur? AFAIK all the keys are bound to a >>>> >> particular >> >>>> session which is itself bound to a particular access point. What am >>>> >> I >> >>>> missing? >>>> >>>> ... >>>> >>> [PTT] >>> OK, this is one for the architecture to answer. I'll review the >>> >> different >> >>> interfaces to see if there is a case of anticipatory keying that isn't >>> bound as >>> tightly as you suggest. At the very least, I don't think the keys >>> >> passed >> >>> to a >>> local ER server would be bound to a particular access point, but they >>> >> may >> >>> indeed >>> be bound to a particular session, in some sense of session. >>> >> >> [Joe] I can't think of a reason why the domain wouldn't already be known >> to the session. I'd be okay with leaving the domain out until there is >> a use-case for it. >> _______________________________________________ >> 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 > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon May 17 22:08: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 414903A68E4 for ; Mon, 17 May 2010 22:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[AWL=0.031, 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 hOnuwOirL+L8 for ; Mon, 17 May 2010 22:08:57 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 9A9513A6A03 for ; Mon, 17 May 2010 22:08:56 -0700 (PDT) Received: (qmail 23997 invoked from network); 18 May 2010 05:08:48 -0000 Received: from unknown (115.67.25.238) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 18 May 2010 05:08:45 -0000 From: "Glen Zorn" To: Date: Tue, 18 May 2010 12:08:21 +0700 Organization: Network Zen Message-ID: <00f501caf648$2e8e8210$8bab8630$@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: Acr2R2xALJWPLFKLQHKhYBGShk7SWw== Content-Language: en-us Subject: [Dime] a couple of comments on draft-ietf-dime-rfc3588bis 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, 18 May 2010 05:08:58 -0000 1) Section 4.3 is entitled "Derived AVP Data Formats" but the first paragraph states "An application that defines new AVP Derived Data Formats MUST include them in a section entitled "AVP Derived Data Formats"; it would be good to make the title and the text consistent. I suggest s/AVP Derived Data Formats/Derived AVP Data Formats/. 2) In the same section, I think that it would be cleaner to put the definitions of the derived data types (Address, Time, etc.) into separate sub-sections. 3) Again in Section 4.3, the formatting of the description of the IPFilterRule format seems kind of screwed-up (wanders across the page). From vf0213@gmail.com Tue May 18 13:51:52 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 565CB28C1ED for ; Tue, 18 May 2010 13:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_40=-0.185, 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 EQx5Rrue8vnc for ; Tue, 18 May 2010 13:51:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A8F8B28C1F3 for ; Tue, 18 May 2010 13:49:08 -0700 (PDT) Received: by wwb24 with SMTP id 24so135136wwb.31 for ; Tue, 18 May 2010 13:48:58 -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=KeUR+ydyi5+zbXJlGrdTA8NYY3QunX5KBP5jo/lPL90=; b=gTwlBZaK35v3vXn+KYa2oP56mkuw/vtEl074RRHENztniZxXLvdChqiiUqwkYEi/9w ho93WR3YfMhyH8rHpPkXp+rk+25yG+S7lcVYU8Vet0wE0ugia2DOS+x0wK1HXtXGEHnN upi47aPZDycvyg4qLpwzKDU47r55XkmwVBg9A= 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=OVzvgk+XuHIxclGqRm3l43ftbwy1M2c4nbFk14o36PEeOg+uxyV/dduH5sfW2SJ7fC 8TyoZds+300vb3fg9D6NTDjGIaGN8cTRQHvQDQWz0k8gMOqPn6H+zdjY4IlDqaAjvSqZ 7nIA6+XWyVnGLXpEKPCAxxm6VvWvQ6VcFtbPY= MIME-Version: 1.0 Received: by 10.216.163.204 with SMTP id a54mr2320192wel.2.1274215738122; Tue, 18 May 2010 13:48:58 -0700 (PDT) Received: by 10.216.156.209 with HTTP; Tue, 18 May 2010 13:48:57 -0700 (PDT) In-Reply-To: <00f501caf648$2e8e8210$8bab8630$@net> References: <00f501caf648$2e8e8210$8bab8630$@net> Date: Tue, 18 May 2010 16:48:57 -0400 Message-ID: From: Victor Fajardo To: Glen Zorn Content-Type: multipart/alternative; boundary=0016367f9f6e7022690486e47857 Cc: dime@ietf.org Subject: Re: [Dime] a couple of comments on draft-ietf-dime-rfc3588bis 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, 18 May 2010 20:51:52 -0000 --0016367f9f6e7022690486e47857 Content-Type: text/plain; charset=ISO-8859-1 Hi Glen, Thanks. Will add fixes for these comments .... regards, victor On Tue, May 18, 2010 at 1:08 AM, Glen Zorn wrote: > 1) Section 4.3 is entitled "Derived AVP Data Formats" but the first > paragraph states "An > application that defines new AVP Derived Data Formats MUST include them in > a > section > entitled "AVP Derived Data Formats"; it would be good to make the title and > the text consistent. I suggest s/AVP Derived Data Formats/Derived AVP Data > Formats/. > > 2) In the same section, I think that it would be cleaner to put the > definitions of the derived data types (Address, Time, etc.) into separate > sub-sections. > > 3) Again in Section 4.3, the formatting of the description of the > IPFilterRule format seems kind of screwed-up (wanders across the page). > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0016367f9f6e7022690486e47857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Glen,
=A0
Thanks. Will add fixes for these comments ....
=A0
regards,
victor

On Tue, May 18, 2010 at 1:08 AM, Glen Zorn <gwz@net-zen.net>= wrote:
1) Section 4.3 is entitled "= ;Derived AVP Data Formats" but the first
paragraph states "An<= br> application that defines new AVP Derived Data Formats MUST include them in = a
section
entitled "AVP Derived Data Formats"; it would be = good to make the title and
the text consistent. =A0I suggest s/AVP Deriv= ed Data Formats/Derived AVP Data
Formats/.

2) In the same section, I think that it would be cleaner t= o put the
definitions of the derived data types (Address, Time, etc.) in= to separate
sub-sections.

3) Again in Section 4.3, the formatting= of the description of the
IPFilterRule format seems kind of screwed-up (wanders across the page).
=
_______________________________________________
DiME mailing listDiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime

--0016367f9f6e7022690486e47857-- From gwz@net-zen.net Sun May 23 16:15: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 40A5E3A6820 for ; Sun, 23 May 2010 16:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=1.325, 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 o8IrQ1YKXH18 for ; Sun, 23 May 2010 16:15:21 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 1F38A3A68B7 for ; Sun, 23 May 2010 16:14:51 -0700 (PDT) Received: (qmail 12477 invoked from network); 23 May 2010 23:14:42 -0000 Received: from unknown (115.67.39.143) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 23 May 2010 23:14:40 -0000 From: "Glen Zorn" To: Date: Mon, 24 May 2010 06:13:57 +0700 Organization: Network Zen Message-ID: <003a01cafacd$a5061780$ef124680$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003B_01CAFB08.5164EF80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr6yQARBiQDGd5qTZOGEzMy5EJORwAAfQng Content-Language: en-us Cc: aaa-doctors@ietf.org Subject: [Dime] FW: I-D Action:draft-zorn-dime-rfc4005bis-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: Sun, 23 May 2010 23:15:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003B_01CAFB08.5164EF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A topic of discussion during the last couple of AAA Doctors meetings has been what to do about RFC 4005 in general and RADIUS-Diameter interoperability in particular. In Anaheim we decided to just try removing the RADIUS->Diameter translation stuff from 4005 (since it was unclear that it had ever actually been deployed) & see who screamed in pain ;-). I took the action item to revise the doc & this draft is the result. In addition to (I hope) carving out all the RADIUS-specific stuff (including all of section 9), I've also fixed a number of (small, IMHO) grammatical problems & some clumsy phrasing, reorganized the document to better (I hope) reflect the various groups of AVPs & reworked the AVP tables to remove redundant information. Comments are welcomed! -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Sunday, May 23, 2010 9:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-zorn-dime-rfc4005bis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Network Access Server Application Author(s) : G. Zorn Filename : draft-zorn-dime-rfc4005bis-01.txt Pages : 66 Date : 2010-05-23 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zorn-dime-rfc4005bis-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_000_003B_01CAFB08.5164EF80 Content-Type: Message/External-body; name="draft-zorn-dime-rfc4005bis-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-zorn-dime-rfc4005bis-01.txt" Content-Type: text/plain Content-ID: <2010-05-23071857.I-D@ietf.org> ------=_NextPart_000_003B_01CAFB08.5164EF80 Content-Type: text/plain; name="ATT00056.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00056.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_003B_01CAFB08.5164EF80-- From gwz@net-zen.net Sun May 23 18:18: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 CF38C3A6911 for ; Sun, 23 May 2010 18:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 zVuG0AkVZG8A for ; Sun, 23 May 2010 18:18:50 -0700 (PDT) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id E2F123A68FD for ; Sun, 23 May 2010 18:18:49 -0700 (PDT) Received: (qmail 15798 invoked from network); 24 May 2010 01:18:41 -0000 Received: from unknown (115.67.90.33) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 24 May 2010 01:18:39 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: <00b701caedc5$92e4d150$b8ae73f0$@net> <000401caf25d$420b7d50$c62277f0$@net> <2BE3AA30-C1D6-41F1-9D6C-305DB8E1E867@gmail.com> In-Reply-To: <2BE3AA30-C1D6-41F1-9D6C-305DB8E1E867@gmail.com> Date: Mon, 24 May 2010 08:17:55 +0700 Organization: Network Zen Message-ID: <005401cafade$f6c4b250$e44e16f0$@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: Acr2BUjK07MBxDdmQ02i2DxeTaxawgE2XD7Q Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 24 May 2010 01:18:50 -0000 jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > > So, everybody happy with Joe's proposal of leaving the domain out? If > so, a new revision would be needed so that we can get this sorted out > and successfully conclude the WGLC. Awaiting editing instructions from the Chairs... ... From root@core3.amsl.com Sun May 23 21:30:02 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 859853A69A6; Sun, 23 May 2010 21: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: <20100524043002.859853A69A6@core3.amsl.com> Date: Sun, 23 May 2010 21:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-capablities-update-04.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, 24 May 2010 04:30:03 -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-04.txt Pages : 7 Date : 2010-05-23 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-23212148.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Mon May 24 05:09:19 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 C86023A6BEA for ; Mon, 24 May 2010 05:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=2.400, 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 7E2U4iYQ17iq for ; Mon, 24 May 2010 05:09:18 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 218163A6BA3 for ; Mon, 24 May 2010 05:09:03 -0700 (PDT) Received: by wwb24 with SMTP id 24so2322336wwb.31 for ; Mon, 24 May 2010 05:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=xtKohI3r5EH1U83UHb1srGBJgArfJeUNetS4edi5X8Q=; b=sHCqkcDoSDGsviRw2pRFRSY42667E3H6UPj2YicEfAlvwmw+y528h1Qh1NLv9L2b+g xtkZzGRX/k0kBfGBwPCrqMtzbuKsC8UgsCwkJrBNZKJaSyhqMJadEYECBpesSxwtFJ1d 7D0h5oPtjYqcri1fOeLZTvDBfd4LmC9MLv57k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=e0ewLnp7duAlwE6+oNTeAwrNvKZxPfC5ATyAkM0geIDIuAEDRmJzqCGG+xHlALYMd/ CMODFzGXvOQ4K0NQhnxbeN6DCvMwY2zIeCtsDbaomlnRGBaRl/qWAjMdEciao8hygQY8 qrK/lmhjFeeNYiKWClkF3KSYh90cTcpji5qMo= Received: by 10.227.144.206 with SMTP id a14mr5426028wbv.212.1274702931248; Mon, 24 May 2010 05:08:51 -0700 (PDT) Received: from [10.254.1.146] ([192.100.123.77]) by mx.google.com with ESMTPS id f8sm31161206wbe.23.2010.05.24.05.08.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 05:08:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <005401cafade$f6c4b250$e44e16f0$@net> Date: Mon, 24 May 2010 15:08:45 +0300 Content-Transfer-Encoding: 7bit Message-Id: <02ABF09D-8B2B-43D6-92A8-883E1430A152@gmail.com> References: <00b701caedc5$92e4d150$b8ae73f0$@net> <000401caf25d$420b7d50$c62277f0$@net> <2BE3AA30-C1D6-41F1-9D6C-305DB8E1E867@gmail.com> <005401cafade$f6c4b250$e44e16f0$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03 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, 24 May 2010 12:09:19 -0000 We'll go for Joe's proposal and leave the domain out. - Jouni On May 24, 2010, at 4:17 AM, Glen Zorn wrote: > jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > >> >> So, everybody happy with Joe's proposal of leaving the domain out? If >> so, a new revision would be needed so that we can get this sorted out >> and successfully conclude the WGLC. > > > Awaiting editing instructions from the Chairs... > > ... > > From jouni.nospam@gmail.com Mon May 24 12:37:32 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 3AF383A6CB8 for ; Mon, 24 May 2010 12:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.573, 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 ZN0uQPpisYuR for ; Mon, 24 May 2010 12:37:31 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0A5C03A6B79 for ; Mon, 24 May 2010 12:37:30 -0700 (PDT) Received: by bwz6 with SMTP id 6so653751bwz.31 for ; Mon, 24 May 2010 12:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=JpPbV0Ngj42FIMkJVkwIbhUnSgeOYJzhUFlny56PbL0=; b=rOvyXVuj4A+JDQzoyx+42IgHZyoUectqO5rm7BwOaRDZLt2B6F6kTFdtzx8ZFYx7kw 4TxiWaDHQgY0xpiJuQ0U174H3VuSVVnZuGpW1kH+FmImK/7v1u491ZOylmQsmcPXcuvo BEbThK5o2i1KBhKgx4m8+4cbcOK6wQnbvkvVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TIIr8rqHWY382kH7/L3021LynCNCapIwyhUt1/x/nJpp9GN6jMOKuqvVvkRNjzChXP VoB0h+KEJDynXxiiyoLGBcFYPt/hnfVJZh6c5X3BLyq2L7Q05kq0uqMQJP7MKQmkH/mA B9MffXaAtcbUIMu/iy99FqW3otznSUb6qwams= Received: by 10.204.153.205 with SMTP id l13mr1885531bkw.95.1274729836870; Mon, 24 May 2010 12:37:16 -0700 (PDT) Received: from a88-114-66-199.elisa-laajakaista.fi (a88-114-66-199.elisa-laajakaista.fi [88.114.66.199]) by mx.google.com with ESMTPS id s17sm20460065bkd.16.2010.05.24.12.37.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 12:37:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> Date: Mon, 24 May 2010 22:37:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [Dime] Another round of WGLCs and WG status 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, 24 May 2010 19:37:32 -0000 Hi all, We can conclude from the WGLC that local-keytran and also pririty-avps = (though we got only 2 comments..) can move on. Authors, provide = revisions that addresses all comments on your documents and we'll move = them forward. Jouni & Lionel On Apr 26, 2010, at 2:29 PM, jouni korhonen wrote: > Hi all, >=20 > The following drafts have been in kind of a limbo for quite some time. >=20 > 1) draft-ietf-dime-priority-avps WGLC ended 16th Mar > 2) draft-ietf-dime-capablities-update WGLC ended 23rd Jan > 3) draft-ietf-dime-local-keytran WGLC ended 7th Mar > 4) draft-ietf-dime-rfc3588bis WGLC ended 5th July=20 > 5) draft-ietf-dime-app-design-guide >=20 > The WGLC for draft-ietf-dime-local-keytran-01 ended 7th Match. We = received only *one* review and a subsequent draft revision. Although, a = WGLC stands for the "last call", we decided to run one quick more due = the low number of reviews. Please, review the document and give any = indication whether you are fine with it or not. The WGLC#2 ends 10th = May. >=20 > The WGLC for draft-ietf-dime-priority-avps ended 16th March. We = received *one* comment and decided to run one more based on the same = reasons as above. Please, review the document and give any indication = whether you are fine with it or not. The WGLC#2 ends 10th May. >=20 > Although it may not look like it, we definitely intend to move above = two documents forward as soon as possible. I encourage respective = authors to work offline to get people to review their documents. >=20 > Lionel and I will have a look at draft-ietf-dime-app-design-guide, and = hopefully get the document move forward soon. >=20 > Jouni will write a proto write-up and shepherd the rfc3588bis (after I = actually have read latest revision). > Lionel will write a proto write-up and shepherd the = capablities-update. >=20 >=20 >=20 > Jouni & Lionel From gwz@net-zen.net Mon May 24 22:49: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 8B8303A68E7 for ; Mon, 24 May 2010 22:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 Nddx51ilS3+7 for ; Mon, 24 May 2010 22:49:42 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id B5F703A686E for ; Mon, 24 May 2010 22:49:42 -0700 (PDT) Received: (qmail 26186 invoked from network); 25 May 2010 05:49:34 -0000 Received: from unknown (111.84.163.145) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 25 May 2010 05:49:32 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> In-Reply-To: <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> Date: Tue, 25 May 2010 12:49:18 +0700 Organization: Network Zen Message-ID: <017301cafbce$09c10580$1d431080$@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: Acr7eIpkEx7hbbUzTcaVXhLMqpaAIAAVQyhg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 25 May 2010 05:49:43 -0000 jouni korhonen [mailto://jouni.nospam@gmail.com] writes: > Hi all, > > We can conclude from the WGLC that local-keytran and also pririty-avps > (though we got only 2 comments..) can move on. Authors, provide > revisions that addresses all comments on your documents and we'll move > them forward. It would be helpful if the chairs would provide a list of the accepted changes since (in the case of local-keytran, at least) not all comments were valid. ... From jouni.nospam@gmail.com Tue May 25 02:10: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 CDADA3A6AE0 for ; Tue, 25 May 2010 02:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 IsnzqjH-6OZL for ; Tue, 25 May 2010 02:10:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 343A33A6AA9 for ; Tue, 25 May 2010 02:10:37 -0700 (PDT) Received: by wwe15 with SMTP id 15so305892wwe.31 for ; Tue, 25 May 2010 02:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=L/q4W8+VPs61fbCZ0BS/ef43Xy/xhUhrUnQuNFNfruE=; b=d0W6QVOIJGw85SigN6cfD3pPrYVzjnVsOMCIld3p4fUrjilVES3s5rxNyN6aIl0qPx rcDvLgoGRX0oQ9PbWYa49NGwzlf1HOQJHncFf2Uq7giCsx4+NmRStpAlsEAA8mqHl8OR sQAT4zDUa/njpZfr5hIEmmOsW2TBRxeKvQ5gI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PObshjL7b1bK2k4WMuVICc7f5V8/DQv7nyK8/tYstSNs4xuDFW0SlHoz+LRmmDPO/A 7l0nurgNyg0zfAs+wdJwWsEYSQYf3gOK49PLQY7q/wgKmFdQ8M7bX8tGYQ3zykeQz9jd BlXkFd7kSLhYjFYFHzf5yrWhaMfB9DYv22mzo= Received: by 10.227.143.66 with SMTP id t2mr6579050wbu.116.1274778625553; Tue, 25 May 2010 02:10:25 -0700 (PDT) Received: from [10.254.1.146] ([192.100.123.77]) by mx.google.com with ESMTPS id u36sm38172803wbv.0.2010.05.25.02.10.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 02:10:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <017301cafbce$09c10580$1d431080$@net> Date: Tue, 25 May 2010 12:10:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> <017301cafbce$09c10580$1d431080$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 25 May 2010 09:10:39 -0000 On May 25, 2010, at 8:49 AM, Glen Zorn wrote: > jouni korhonen [mailto://jouni.nospam@gmail.com] writes: >=20 >> Hi all, >>=20 >> We can conclude from the WGLC that local-keytran and also = pririty-avps >> (though we got only 2 comments..) can move on. Authors, provide >> revisions that addresses all comments on your documents and we'll = move >> them forward. >=20 > It would be helpful if the chairs would provide a list of the accepted > changes since (in the case of local-keytran, at least) not all = comments were > valid. We could hold your hand as well ;) Anyway, seriously, I though to put = all stuff to tracker (just like RADEXT started to do) if folks would be = OK with that. It is a bit more spam on the list but would be rather = clear to follow each separate topic assuming folks would use it = systematically. Regarding the local-keytran case, which part of the comments you refer = here? Domains? - Jouni >=20 > ... >=20 >=20 From gwz@net-zen.net Tue May 25 02:40: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 C91263A68CE for ; Tue, 25 May 2010 02:40:40 -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 I-zyRkmlbKhX for ; Tue, 25 May 2010 02:40:40 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id BD9043A6CE7 for ; Tue, 25 May 2010 02:40:38 -0700 (PDT) Received: (qmail 1299 invoked from network); 25 May 2010 09:40:29 -0000 Received: from unknown (111.84.166.252) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 25 May 2010 09:40:27 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> <017301cafbce$09c10580$1d431080$@net> <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> In-Reply-To: <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> Date: Tue, 25 May 2010 16:40:13 +0700 Organization: Network Zen Message-ID: <018301cafbee$4b648eb0$e22dac10$@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: Acr76h2Khe3bmqJwTmO3lCrJv+A67wAAw9kg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 25 May 2010 09:40:40 -0000 jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > On May 25, 2010, at 8:49 AM, Glen Zorn wrote: > > > jouni korhonen [mailto://jouni.nospam@gmail.com] writes: > > > >> Hi all, > >> > >> We can conclude from the WGLC that local-keytran and also pririty- > avps > >> (though we got only 2 comments..) can move on. Authors, provide > >> revisions that addresses all comments on your documents and we'll > move > >> them forward. > > > > It would be helpful if the chairs would provide a list of the accepted > > changes since (in the case of local-keytran, at least) not all > comments were > > valid. > > We could hold your hand as well ;) The last time I checked, modifications to WG drafts were made by WG consensus _only_ & the responsibility for determining WG consensus was that of the WG Chairs, _not_ the document editor(s). > Anyway, seriously, I though to put > all stuff to tracker (just like RADEXT started to do) if folks would be > OK with that. It's a great idea, but only if you want to stop all progress (as the "tool" was used to great effect by the radext chairs). > It is a bit more spam on the list but would be rather > clear to follow each separate topic assuming folks would use it > systematically. This includes you, of course: you still have to make clear which changes are OK & which are not. Is it too much trouble to send an email stating the changes to be made? > > Regarding the local-keytran case, which part of the comments you refer > here? Domains? All of them: the only comments I've seen on any of Joe's or Tom's comments have been mine. > > - Jouni > > > > > ... > > > > > From root@core3.amsl.com Tue May 25 03:30:04 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 26A323A707F; Tue, 25 May 2010 03: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: <20100525103003.26A323A707F@core3.amsl.com> Date: Tue, 25 May 2010 03:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-lr-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, 25 May 2010 10:30:04 -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 Support for Proxy Mobile IPv6 Localized Routing Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-pmip6-lr-01.txt Pages : 12 Date : 2010-05-25 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly by the MAG without involving the LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of local routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-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-pmip6-lr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25032318.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Tue May 25 03:53:20 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 31BCE3A6B0E for ; Tue, 25 May 2010 03:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 6A+N7oPdotFg for ; Tue, 25 May 2010 03:53:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id F26513A6AF5 for ; Tue, 25 May 2010 03:53:18 -0700 (PDT) Received: by wwe15 with SMTP id 15so367337wwe.31 for ; Tue, 25 May 2010 03:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=YOpIkyu4CbeuRwjU2bVxZ6KoOmE8UnHg5SYaSAAVz4c=; b=k7uGrXWFiEJ23DgFgZKtl568a8bgrTcdaT1hRelsiKUYtun9BlI1REc8Uc4/18Cqyb CzaNQLcb5sHqvy46+5F2tZOegqywt76kMMZo/eXIFhIjipV/E9qCtKwfdweRLBCaeeYp nT9NzsKvdjtrd/DlBTOPbNn1rBAp6xeIWH+I4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=lkTYAjKyA7UrTl4On3QXO/mviJACaZpIrpSiTqhHEOH2FFg/vsFjOjIEGWR3loFVTu 5T6MF9YMkhV/ZXLg/2Iwan3fnLXofPBAtyyCiOzdkuP2T9tvtiQx1DJbc3X8oBhEOBbu QGu8r/nFyuT7cRJ/f7fde0rsAl3Kf1wDHrw1A= Received: by 10.227.141.135 with SMTP id m7mr6848360wbu.205.1274784786670; Tue, 25 May 2010 03:53:06 -0700 (PDT) Received: from [10.254.1.146] ([192.100.123.77]) by mx.google.com with ESMTPS id u36sm38674190wbv.12.2010.05.25.03.53.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 03:53:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <018301cafbee$4b648eb0$e22dac10$@net> Date: Tue, 25 May 2010 13:52:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4871F3F3-EBF2-4233-8EDF-A688413CF128@gmail.com> References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> <017301cafbce$09c10580$1d431080$@net> <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> <018301cafbee$4b648eb0$e22dac10$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 25 May 2010 10:53:20 -0000 On May 25, 2010, at 12:40 PM, Glen Zorn wrote: > jouni korhonen [mailto:jouni.nospam@gmail.com] writes: >=20 >> On May 25, 2010, at 8:49 AM, Glen Zorn wrote: >>=20 >>> jouni korhonen [mailto://jouni.nospam@gmail.com] writes: >>>=20 >>>> Hi all, >>>>=20 >>>> We can conclude from the WGLC that local-keytran and also pririty- >> avps >>>> (though we got only 2 comments..) can move on. Authors, provide >>>> revisions that addresses all comments on your documents and we'll >> move >>>> them forward. >>>=20 >>> It would be helpful if the chairs would provide a list of the = accepted >>> changes since (in the case of local-keytran, at least) not all >> comments were >>> valid. >>=20 >> We could hold your hand as well ;)=20 >=20 > The last time I checked, modifications to WG drafts were made by WG > consensus _only_ & the responsibility for determining WG consensus was = that > of the WG Chairs, _not_ the document editor(s). =20 Sure thing.. However, the only thing imho that really deviated from "how = about - ok" discussion was the domain stuff and that was then = specifically said to be left out. >=20 >> Anyway, seriously, I though to put >> all stuff to tracker (just like RADEXT started to do) if folks would = be >> OK with that.=20 >=20 > It's a great idea, but only if you want to stop all progress (as the = "tool" > was used to great effect by the radext chairs). Heh ;) That is what I am afraid off. Any other views?=20 >=20 >> It is a bit more spam on the list but would be rather >> clear to follow each separate topic assuming folks would use it >> systematically. >=20 > This includes you, of course: you still have to make clear which = changes are > OK & which are not. Is it too much trouble to send an email stating = the > changes to be made? Looking at the thread put into wiki.. o Frank Xia's review (1/3) and Glen's response -> ok * I don't have a problem with an AVP occurrence table. Though, I = would generalize the table to just Req & Rep 'general purpose commands' = that are not actually tied to a specific command. Though such general = purpose commands might need text saying they behave like DER/DEA etc.. o Joe Salowey's review (2/3) -- * for domain that was agreed to be left out (as no one came up with a good use case). * rest of for Key types Joe provided text. Did not see objections to = it. * Key-SPI stays. * others where text was proposed were acked as 'good' or 'ok' so those fly in. o Tom Taylor's comments (3/3) -- * comment 2 - up to the editor. I am ok with the current 5.2 content. >>=20 >> Regarding the local-keytran case, which part of the comments you = refer >> here? Domains? >=20 > All of them: the only comments I've seen on any of Joe's or Tom's = comments > have been mine. After all these weeks we can conclude that the silence means acceptance = for the comments/proposals above. Others seem to be fine with you three. - Jouni >=20 >>=20 >> - Jouni >>=20 >>>=20 >>> ... >>>=20 >>>=20 >>=20 >=20 >=20 From d.b.nelson@comcast.net Tue May 25 04:20: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 49C433A6AC0 for ; Tue, 25 May 2010 04:20:40 -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 1HulmX3nekkL for ; Tue, 25 May 2010 04:20:33 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 020333A6AFA for ; Tue, 25 May 2010 04:20:29 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Mmwh1e0020FhH24A1nLPZh; Tue, 25 May 2010 11:20:23 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta08.emeryville.ca.mail.comcast.net with comcast id MnLM1e0050yip6Y8UnLNZ6; Tue, 25 May 2010 11:20:23 +0000 From: "Dave Nelson" To: "'Glen Zorn'" , References: <003a01cafacd$a5061780$ef124680$@net> Date: Tue, 25 May 2010 07:20:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003a01cafacd$a5061780$ef124680$@net> thread-index: Acr6yQARBiQDGd5qTZOGEzMy5EJORwAAfQngAEwMWiA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: aaa-doctors@ietf.org Subject: Re: [Dime] [AAA-DOCTORS] FW: I-D Action:draft-zorn-dime-rfc4005bis-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, 25 May 2010 11:20:40 -0000 Glen Zorn writes... > A topic of discussion during the last couple of AAA Doctors meetings > has been what to do about RFC 4005 in general and RADIUS-Diameter > interoperability in particular. In Anaheim we decided to just try > removing the RADIUS->Diameter translation stuff from 4005 (since it > was unclear that it had ever actually been deployed) ... I don't personally know that it was ever implemented; I've never been involved with a Diameter implementation. One question that comes to mind is what we ought to do about the RADIUS RFCs that include a Diameter Compatibility section, based on the translation concepts that you are proposing to deprecate --- err, remove, actually? Technically, I suppose that rfc4005bis would need to Update those RFCs, indicating that the Diameter Compatibility section is to be ignored. That seems cumbersome, but I don't see any other way to formally tie up all those loose ends. From gwz@net-zen.net Tue May 25 06:44: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 2EBE13A6BF9 for ; Tue, 25 May 2010 06:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 U7ve+wed+6DH for ; Tue, 25 May 2010 06:44:58 -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 346C33A6B0C for ; Tue, 25 May 2010 06:44:58 -0700 (PDT) Received: (qmail 5893 invoked from network); 25 May 2010 13:44:49 -0000 Received: from unknown (111.84.148.117) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 25 May 2010 13:44:45 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> <017301cafbce$09c10580$1d431080$@net> <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> <018301cafbee$4b648eb0$e22dac10$@net> <4871F3F3-EBF2-4233-8EDF-A688413CF128@gmail.com> In-Reply-To: <4871F3F3-EBF2-4233-8EDF-A688413CF128@gmail.com> Date: Tue, 25 May 2010 20:44:28 +0700 Organization: Network Zen Message-ID: <01d301cafc10$6bc79a40$4356cec0$@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: Acr7+HXIMqduMe6MT72VjfgOkfoenAAF4KTQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 25 May 2010 13:44:59 -0000 jouni korhonen [mailto://jouni.nospam@gmail.com] writes: ... > o Frank Xia's review (1/3) and Glen's response -> ok > * I don't have a problem with an AVP occurrence table. Though, I > would > generalize the table to just Req & Rep 'general purpose commands' > that > are not actually tied to a specific command. Though such general > purpose > commands might need text saying they behave like DER/DEA etc.. Actually, the more I think about this idea, the less I like it: as you imply, AVP occurrence tables actually belong in application specs, which this is not. ... From root@core3.amsl.com Tue May 25 07: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 CC1473A7169; Tue, 25 May 2010 07: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: <20100525144501.CC1473A7169@core3.amsl.com> Date: Tue, 25 May 2010 07:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-04.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, 25 May 2010 14: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 Attribute-Value Pairs for Cryptographic Key Transport Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-local-keytran-04.txt Pages : 8 Date : 2010-05-25 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25073300.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue May 25 08:00:02 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 2AD313A69B2; Tue, 25 May 2010 08:00: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: <20100525150002.2AD313A69B2@core3.amsl.com> Date: Tue, 25 May 2010 08:00:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-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: Tue, 25 May 2010 15:00: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 Attribute-Value Pairs for Cryptographic Key Transport Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-local-keytran-05.txt Pages : 8 Date : 2010-05-25 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-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-local-keytran-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25075601.I-D@ietf.org> --NextPart-- From avi@bridgewatersystems.com Tue May 25 12:04: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 B749A3A69CC for ; Tue, 25 May 2010 12:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 kYnl1lKmEmgR for ; Tue, 25 May 2010 12:04:34 -0700 (PDT) Received: from mail37.messagelabs.com (mail37.messagelabs.com [216.82.241.83]) by core3.amsl.com (Postfix) with ESMTP id 10F643A67D7 for ; Tue, 25 May 2010 12:04:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-9.tower-37.messagelabs.com!1274814264!67683015!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 11568 invoked from network); 25 May 2010 19:04:25 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-9.tower-37.messagelabs.com with RC4-SHA encrypted SMTP; 25 May 2010 19:04:25 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 25 May 2010 15:04:23 -0400 From: Avi Lior To: David Mitton Date: Tue, 25 May 2010 15:04:23 -0400 Thread-Topic: [Dime] Errata #1946 Thread-Index: Acr8PRZ2qTF980OfTFaq31h1M+1YqQ== Message-ID: <83836E31-40C3-4800-8E15-4C4220DD5415@bridgewatersystems.com> References: <000301caf255$b1e83e90$15b8bbb0$@net> <20100514033500.88EE12578C3F@smtprelay03.hostedemail.com> In-Reply-To: <20100514033500.88EE12578C3F@smtprelay03.hostedemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Errata #1946 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, 25 May 2010 19:04:35 -0000 I agree. Glen's text does improve my text and makes a suggestion that need= s to be added as well.... >> If the Accounting-Input-Octets, Accounting-Input-Packets, >> Accounting-Output-Octets, or Accounting-Output-Packets AVPs are >> present, they SHOULD be translated to the corresponding RADIUS >> attributes. However, if the value of the Accounting-Input-Octets AVP >> or Accounting-Output-Octets AVP does not fit >> within a 32-bit RADIUS attribute, the RADIUS Acct-Input- >> Gigawords and Acct-Output-Gigawords Attributes must be used. Add the following: Care must be taken when interworking Diameter with RADIUS due to the fact t= hat there is no attribute available in RADIUS to record overflows in packet= counters. One remedy that can be used is to limit the session time such t= hat packet counter do not overflow. Another remedy would be to ignore the = packet counters altogether and just rely on the octet counters. End of change Limiting the session-timer will cause re-authentication. But re-authentica= tion does not necessarily mean a new accounting session right? Another possible change would be that the NAS starts another accounting ses= sion when it reaches packet counter limits but how do we do that. I think in reality packet counters are probably not used. On 13-05-2010, at 23:35 , David Mitton wrote: > I don't think the original text is misleading, just incomplete. >=20 > There are two parts here. > 1) All 4 Diameter AVPs must be translated into the corresponding 4=20 > RADIUS attributes. > 2) If the Diameter Octets attributes values are greater than 32-bits=20 > in magnitude, the higher order value must be mapped into the=20 > additional Gigaword attributes. What's not stated is, unfortunately=20 > there are only RADIUS Gigaword Attributes for Octets and not Packets. >=20 > Avi's correction fixes the wrong problem, by leaving out the Packets=20 > translation. > Glen's correction leaves that in, and makes the Gigaword translation=20 > cases explicit and for that reason is more complete. One could go a=20 > step further and point out that there is no RADIUS Acct attribute=20 > that can carry the full potential 64-bit value of Diameter AVPs=20 > Accounting-Input-Packets or Accounting-Input-Packets. >=20 > Dave. >=20 >=20 > On 5/13/2010 12:35 AM, Glen Zorn wrote: >> Dan Romascanu [mailto://dromasca@avaya.com] writes: >>=20 >>> DIME WG, >>>=20 >>> Please issue a recommendation concerning errata #1946 (related to RFC >>> 4005) >>=20 >> While the original text is certainly misleading at best, the new text is= not >> a lot better since is leaves out the Accounting-Input-Packets and >> Accounting-Output-Packets AVPs. I think that a better correction would = be >> something like this: >>=20 >> If the Accounting-Input-Octets, Accounting-Input-Packets, >> Accounting-Output-Octets, or Accounting-Output-Packets AVPs are >> present, they SHOULD be translated to the corresponding RADIUS >> attributes. However, if the value of the Accounting-Input-Octets AVP >> or Accounting-Output-Octets AVP does not fit >> within a 32-bit RADIUS attribute, the RADIUS Acct-Input- >> Gigawords and Acct-Output-Gigawords Attributes must be used. >>=20 >>>=20 >>> Dan >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=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 Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 From jouni.nospam@gmail.com Tue May 25 14:41: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 153B73A6DE6 for ; Tue, 25 May 2010 14:41:13 -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 cKtF6VqIkrf0 for ; Tue, 25 May 2010 14:41:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 303B43A7342 for ; Tue, 25 May 2010 13:57:52 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so414977fga.13 for ; Tue, 25 May 2010 13:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=V8dqzZZoXcJedxz66hHiygIzKB9IZpZmpIyRbMK/drw=; b=NkRRzkHctLJvC5jIelyOzx5WbaK0DsCiMFD5Yjgt5wtK2oQvc+OYdYW8jmYv0zHCV8 QGMBOxe+PM17+wBE+2tgZ2Soqm1HZZ9sQ5/otzijn0hzbxdiKeSyg1YvZbfHFZyZWa6t GVRxGOMYtJmZz5RBHV8HQ2BhU0TojdqkyJXAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nj7wyucX0S/G0CVfecG/Njd87FMhYgVG4ui7zbzdwMjvDboTx7iyEj1JDIDkXNfgEk rL2OYRPLJVmd8vm77ALzdNlJsSWfTCBGLjsYVg6xy1ZEjxhvUb8h6AvNiFkWd2GzIvCn h+VjPlGh4MtOPSjdQs1m755y9Er4ShJp21Y8U= Received: by 10.87.71.7 with SMTP id y7mr11264565fgk.63.1274821056722; Tue, 25 May 2010 13:57:36 -0700 (PDT) Received: from a88-114-168-249.elisa-laajakaista.fi (a88-114-168-249.elisa-laajakaista.fi [88.114.168.249]) by mx.google.com with ESMTPS id y15sm8087747fkd.38.2010.05.25.13.57.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 13:57:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <01d301cafc10$6bc79a40$4356cec0$@net> Date: Tue, 25 May 2010 23:57:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8CD1C413-0FC9-44BB-AC7C-76785F874DB7@gmail.com> References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> <017301cafbce$09c10580$1d431080$@net> <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> <018301cafbee$4b648eb0$e22dac10$@net> <4871F3F3-EBF2-4233-8EDF-A688413CF128@gmail.com> <01d301cafc10$6bc79a40$4356cec0$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 25 May 2010 21:41:13 -0000 On May 25, 2010, at 4:44 PM, Glen Zorn wrote: > jouni korhonen [mailto://jouni.nospam@gmail.com] writes: >=20 > ... >=20 >> o Frank Xia's review (1/3) and Glen's response -> ok >> * I don't have a problem with an AVP occurrence table. Though, I >> would >> generalize the table to just Req & Rep 'general purpose commands' >> that >> are not actually tied to a specific command. Though such general >> purpose >> commands might need text saying they behave like DER/DEA etc.. >=20 > Actually, the more I think about this idea, the less I like it: as you > imply, AVP occurrence tables actually belong in application specs, = which > this is not. Good point. In past we had few similar cases (general purpose AVPs) and = if we had some recommendations on the use of the AVPs, then we used e.g. = the Req & Rep approach. - JOuni >=20 > ... >=20 >=20 From gwz@net-zen.net Tue May 25 18:14: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 074663A683E for ; Tue, 25 May 2010 18:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 YEIOAghEm3J4 for ; Tue, 25 May 2010 18:14:47 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 986053A6819 for ; Tue, 25 May 2010 18:14:44 -0700 (PDT) Received: (qmail 10767 invoked from network); 26 May 2010 01:14:34 -0000 Received: from unknown (111.84.97.212) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 26 May 2010 01:14:32 -0000 From: "Glen Zorn" To: "'jouni korhonen'" References: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> <0F3F1973-63CA-41E1-903A-35D3894D507D@gmail.com> <017301cafbce$09c10580$1d431080$@net> <1033CE87-B78F-4765-9F50-29FEDE6D03CE@gmail.com> <018301cafbee$4b648eb0$e22dac10$@net> <4871F3F3-EBF2-4233-8EDF-A688413CF128@gmail.com> <01d301cafc10$6bc79a40$4356cec0$@net> <8CD1C413-0FC9-44BB-AC7C-76785F874DB7@gmail.com> In-Reply-To: <8CD1C413-0FC9-44BB-AC7C-76785F874DB7@gmail.com> Date: Wed, 26 May 2010 08:14:12 +0700 Organization: Network Zen Message-ID: <000001cafc70$c672cef0$53586cd0$@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: Acr8TOhjrqMYIUY4RzaGnG4zeT+newAI5Cog Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Another round of WGLCs and WG status 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, 26 May 2010 01:14:50 -0000 jouni korhonen [mailto:jouni.nospam@gmail.com] writes: > >> o Frank Xia's review (1/3) and Glen's response -> ok > >> * I don't have a problem with an AVP occurrence table. Though, I > >> would > >> generalize the table to just Req & Rep 'general purpose commands' > >> that > >> are not actually tied to a specific command. Though such general > >> purpose > >> commands might need text saying they behave like DER/DEA etc.. > > > > Actually, the more I think about this idea, the less I like it: as you > > imply, AVP occurrence tables actually belong in application specs, > which > > this is not. > > Good point. In past we had few similar cases (general purpose AVPs) and > if we had some recommendations on the use of the AVPs, then we used e.g. > the Req & Rep approach. OK, but it seems to me that only one (grouped) AVP is being defined here; a table seems to be overkill... > > - JOuni > > > > > > ... > > > > > From root@core3.amsl.com Tue May 25 19:15:19 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 EA29D3A67B6; Tue, 25 May 2010 19:15:06 -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: <20100526021513.EA29D3A67B6@core3.amsl.com> Date: Tue, 25 May 2010 19:15:06 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-06.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, 26 May 2010 02:15:20 -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-06.txt Pages : 8 Date : 2010-05-25 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25191022.I-D@ietf.org> --NextPart-- From gwz@net-zen.net Tue May 25 23:25: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 1B1563A6980 for ; Tue, 25 May 2010 23:25:07 -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 j+In6MnLpTb9 for ; Tue, 25 May 2010 23:25:06 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id 1ADEC3A6A8D for ; Tue, 25 May 2010 23:23:28 -0700 (PDT) Received: (qmail 20086 invoked from network); 26 May 2010 06:23:18 -0000 Received: from unknown (115.67.228.30) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 26 May 2010 06:23:16 -0000 From: "Glen Zorn" To: "'Dave Nelson'" , References: <003a01cafacd$a5061780$ef124680$@net> In-Reply-To: Date: Wed, 26 May 2010 13:22:57 +0700 Organization: Network Zen Message-ID: <002601cafc9b$e70a9000$b51fb000$@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: Acr6yQARBiQDGd5qTZOGEzMy5EJORwAAfQngAEwMWiAAJ40ssA== Content-Language: en-us Cc: aaa-doctors@ietf.org Subject: Re: [Dime] [AAA-DOCTORS] FW: I-D Action:draft-zorn-dime-rfc4005bis-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: Wed, 26 May 2010 06:25:07 -0000 Dave Nelson [mailto:d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > A topic of discussion during the last couple of AAA Doctors meetings > > has been what to do about RFC 4005 in general and RADIUS-Diameter > > interoperability in particular. In Anaheim we decided to just try > > removing the RADIUS->Diameter translation stuff from 4005 (since it > > was unclear that it had ever actually been deployed) ... > > I don't personally know that it was ever implemented; I've never been > involved with a Diameter implementation. > > One question that comes to mind is what we ought to do about the RADIUS > RFCs > that include a Diameter Compatibility section, based on the translation > concepts that you are proposing to deprecate --- err, remove, actually? > Technically, I suppose that rfc4005bis would need to Update those RFCs, > indicating that the Diameter Compatibility section is to be ignored. > That > seems cumbersome, but I don't see any other way to formally tie up all > those > loose ends. If & when the draft becomes an RFC, it might be easier (& less confusing) to publish very short notes updating the relevant RADIUS RFCs. > >