From avi@bridgewatersystems.com Sat Oct 2 13:47:49 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 60D423A6DAA for ; Sat, 2 Oct 2010 13:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 C5Jlv4CpH66E for ; Sat, 2 Oct 2010 13:47:48 -0700 (PDT) Received: from mail28.messagelabs.com (mail28.messagelabs.com [216.82.249.131]) by core3.amsl.com (Postfix) with ESMTP id D4B3C3A6D61 for ; Sat, 2 Oct 2010 13:47:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-13.tower-28.messagelabs.com!1286052517!78929427!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 21803 invoked from network); 2 Oct 2010 20:48:38 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-13.tower-28.messagelabs.com with RC4-SHA encrypted SMTP; 2 Oct 2010 20:48:38 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Sat, 2 Oct 2010 16:48:37 -0400 From: Avi Lior To: Mark Jones Date: Sat, 2 Oct 2010 16:48:35 -0400 Thread-Topic: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 Thread-Index: Acticy8xsoHreYOcQWyNQQSSJwxWmQ== Message-ID: <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> In-Reply-To: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 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, 02 Oct 2010 20:47:49 -0000 See inline On 29-09-2010, at 22:59 , Mark Jones wrote: > Hi Avi, >=20 > Thanks for the detailed review. Responses are inline. >=20 > On Tue, Sep 28, 2010 at 8:21 PM, Avi Lior wr= ote: >> I have reviewed draft-ietf-dime-extended-naptr-02. Here is my review: >>=20 >> Comment 1 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Improving understandability. >>=20 >> The introduction does not defines the problem statement that this docume= nt addresses. >>=20 >> Even the Abstract does not tell us what problem we are solving. >>=20 >> Why do we want the NAPTR queries to contain Diameter Application-Id info= rmation? >>=20 >> The answer is not reached until section 4 which presents a wonderful bac= kground to the problem. But still does not present the problem. >>=20 >> Suggestion move section 4 material to the introduction. Alternatively, = add a Problem Statement / Background section as part of 1.0 >>=20 >>=20 >=20 > Ok. I=92ll craft a problem statement. Something along the lines of: >=20 > =93Using dynamic peer discovery as described in RFC3588, a given realm > may advertise multiple Diameter nodes without revealing which > Diameter application each node supports. A peer outside the realm > would have to perform a CER/CEA exchange with every node in order to > find which one supports the desired application. This draft describes > an optimization using S-NAPTR entries that allows peer discovery > including supported applications without doing CER/CEA exchange > beforehand.=94 Works for me except: dont use This draft describes > use this RFC or this = document etc. >=20 >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Terminology >>=20 >> "The Diameter base protocol specification (Section 1.4 of RFC 3588) >> defines most of the terminology used in this document." >>=20 >> Where is the rest defined??? or does it not matter??? >>=20 >=20 > Ok. I=92ll add RFC3958 which introduces the S-NAPTR terms then remove =93= most of=94. Okay >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Section 3: >>=20 >> Question: Does NAPTR Service Field format always consists of Applicatio= n Service tag and Application Protocol tag? >>=20 >=20 > No. It is S-NAPTR (and not NAPTR) that defines the > appn-svc:appln-proto format which is what this section is covering. Okay. >=20 >> Check 3958 >>=20 >=20 > Checked. I believe we're good on this one. Okay >=20 >>=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D >> Editorial >>=20 >> Section 3 >>=20 >> supporting a specific Diameter application is show below. >>=20 >> s/show/shown >>=20 >=20 > Ok. >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> Section 3 editorial(s) >>=20 >> Break the last par in this section after the first sentence. >>=20 >> Also change: >> "The DNS administrator of some domain SHOULD also >> provision base RFC 3588 style NAPTR records [RFC2915] in order to >> guarantee backwards compatibility with legacy RFC 3588 compliant >> Diameter peers. " >>=20 >> To" >>=20 >> "DNS administrators SHOULD also >> provision base RFC 3588 style NAPTR records [RFC2915] in order to >> guarantee backwards compatibility with legacy RFC 3588 compliant >> Diameter peers." >>=20 >=20 > Ok. >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Editorial >>=20 >> Section 4 a: >>=20 >> s/The Diameter implementation performs/The Diameter peer performs/ >>=20 >> or client??? >>=20 >=20 > This text is consistent with Section 5.2 in RFC3588. Which is also > inconsistent between steps. ;) >=20 >> Align with terminology used in step b. >>=20 >> "If "X" contains the required Application Identifier and "Y" >> matches a transport protocol supported by the client," >>=20 >=20 > I believe the "client" here is not a Diameter client but a NAPTR > client, i.e. the Diameter peer performing the NAPTR query. Pretty > longwinded but I'll try to reword to clarify. Okay. >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Section 4 c: >>=20 >> "c: and d:" is existing behavior right? So why are we talking about it.= I would mention it first and get it out of the way. Just elaborate on th= e new stuff. >>=20 >=20 > I repeated step c for readability because I thought having the > S-NAPTR/NAPTR procedure steps would be more readable than having the > reader trying to figure out how to mesh it with the logic for dynamic > peer discovery in RFC3588. I believe I got the balance right here but > take a look at the full procedure in RFC3588 and let me know if you > disagree. Okay. I will check again...can you also check to see whether we should say= "As specifiend in3588" to make sure the reader understands this is not new= behavior. You may already have that - I just dont have the draft infront = of me. >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 5 Usage Guidelines >>=20 >> I am not getting this paragraph. >>=20 >> It is stating the problem (which we could do earlier). But i am not get= ting the last sentence. >>=20 >> Why do we care if its a client or a peer: can this be not used by one pe= er looking for a particular another peer supporting an application and prot= ocol >>=20 >=20 > Sure it could in a true peer-to-peer Diameter application there aren=92t > any (AFAIK). The usage guidelines in this section only apply for > Diameter applications that define client/server roles. >=20 >> why does it have to only apply to client server? What am I missing???? >>=20 >=20 > Let=92s say I=92m an MME (S6a client) looking for an HSS (S6a Server). > Since the S-NAPTR entry only identifies peers that support S6a then I > will discover all the other MME in the network in addition to the HSS. > Not very helpful. >=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> IANA Consideration >>=20 >>=20 >> 6.1 >>=20 >> Is this a new registry???? >>=20 >=20 > Nope. It reuses the S-NAPTR registry. >=20 >> Too bad we cant just say define a generic string/rule once and not requi= re IANA to create a new entry for each new application. >>=20 >=20 > Agreed but you can=92t do that without a new DDDS application and it is > tough to justify that effort for this optimization. >=20 >>=20 >> Comment >> =3D=3D=3D=3D=3D=3D=3D=3D >> 6.2 >>=20 >> Why are we doing this. We should make the usage consistent with first c= ome first served. >>=20 >> Why require an RFC???? >>=20 >=20 > Because we=92re using an existing IANA registry (S-NAPTR) and are bound > by an existing allocation policy. This was discussed at IETF77 and the > conclusion in the room was that this was the lesser of evils. Okay. >=20 >> Specifically if I have a vendor specific application id and I want to us= e this scheme now I have to write an RFC? >>=20 >=20 > Yes but the S-NAPTR allocation policy allows an RFC =93of any category=94 > (not standards track) so this should not present a major impediment to > vendors/SDOs that require this optimization. Okay. Doesnt scale well at all. =20 >=20 > --- >=20 > I'll make the above changes in the next rev along with any other > comments from WGLC. >=20 > Regards > Mark Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 From jouni.nospam@gmail.com Mon Oct 4 01:49: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 4047F3A6F55 for ; Mon, 4 Oct 2010 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 1zLT+L1xcy-a for ; Mon, 4 Oct 2010 01:49:47 -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 CA3213A6F62 for ; Mon, 4 Oct 2010 01:49:46 -0700 (PDT) Received: by fxm6 with SMTP id 6so3613074fxm.31 for ; Mon, 04 Oct 2010 01:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=YXbayYTHRD+nRKKqBeM0x5ezKEDrVjfw37TsxL5ySgs=; b=qyP6A8j4VBlqbmxi2iwqi+Um1Mf+aedLxrjBdFt4ikwhVuM9TVNaVXjJBfl3vfll/R J6X09sKJC3uWY1nE2GcEe9uQ6lsUXWeojXCh+suRugfttQncGu3bPgsNb4dXscrKwUUf ga2ZZXAPvbGJ3rLsAAw4Cn9Lkre+bUsTk9V40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=hprFwzaIvh3LS5NKoTjRDdUTrpbCwcsjd2N1ycZxnDmeQs/e3wLW7HnW+9O7H0D3az f977ABNQE++PombbkOftM//LTAFLXKN+bnhfPAU4BBcuTJ/WKxaOL07FuuUJoB2VdLyG oin+azRN5d6Z/zPh/pGw+Yu45JNYd32A4W4Yg= Received: by 10.223.99.137 with SMTP id u9mr8473788fan.45.1286182240910; Mon, 04 Oct 2010 01:50:40 -0700 (PDT) Received: from [10.254.0.129] ([192.100.123.77]) by mx.google.com with ESMTPS id f28sm2033312faa.24.2010.10.04.01.50.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Oct 2010 01:50:39 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Oct 2010 11:50:33 +0300 Message-Id: <37BB4CC4-8D86-4FC1-81D8-ECAB4EDD9DE7@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Agenda Items for Beijing IETF meeting 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, 04 Oct 2010 08:49:48 -0000 Folks, We got a two hours slot on Thursday 1520-1720 Afternoon Session II. If = you feel a need to present something outside existing WG drafts, please = send a mail to the chairs with a title, short abstract and time needed = for your presentation.=20 The authors of WG drafts should prepare for a status update of their = work in any case. - Jouni & Lionel= From mark@azu.ca Mon Oct 4 07:37: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 A6A683A6FCA for ; Mon, 4 Oct 2010 07:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.325, 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 41lGGXp1FK0J for ; Mon, 4 Oct 2010 07:37:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id AA9223A6FBD for ; Mon, 4 Oct 2010 07:37:29 -0700 (PDT) Received: by qwc9 with SMTP id 9so3637413qwc.31 for ; Mon, 04 Oct 2010 07:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.205 with SMTP id bz13mr7077338qcb.137.1286203104590; Mon, 04 Oct 2010 07:38:24 -0700 (PDT) Received: by 10.229.11.139 with HTTP; Mon, 4 Oct 2010 07:38:24 -0700 (PDT) In-Reply-To: <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> Date: Mon, 4 Oct 2010 10:38:24 -0400 Message-ID: From: Mark Jones To: Avi Lior Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dime@ietf.org" Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 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, 04 Oct 2010 14:37:30 -0000 See inline. On Sat, Oct 2, 2010 at 4:48 PM, Avi Lior wrote= : >>> Specifically if I have a vendor specific application id and I want to u= se this scheme now I have to write an RFC? >>> >> >> Yes but the S-NAPTR allocation policy allows an RFC =93of any category= =94 >> (not standards track) so this should not present a major impediment to >> vendors/SDOs that require this optimization. > > Okay. =A0Doesnt scale well at all. We presented the alternatives at IETF77 and this was the favoured approach despite the additional specification effort for a non-IETF SDO. It is the price to be paid for reusing an existing S-NAPTR registry that does not have a "First Come; First Served" allocation policy. A small consolation is that the IANA allocation policy for S-NATPR service tags is not as strict as that originally used for vendor-specific Diameter command codes ("Specification Required in form of an RFC" vs "IETF Consensus"). Regards Mark From avi@bridgewatersystems.com Mon Oct 4 09:40: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 50B1B3A7047 for ; Mon, 4 Oct 2010 09:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MCzcSeRupIaI for ; Mon, 4 Oct 2010 09:39:58 -0700 (PDT) Received: from mail28.messagelabs.com (mail28.messagelabs.com [216.82.249.131]) by core3.amsl.com (Postfix) with ESMTP id 8639E3A7021 for ; Mon, 4 Oct 2010 09:39:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-11.tower-28.messagelabs.com!1286210419!82739602!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 1855 invoked from network); 4 Oct 2010 16:40:20 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-11.tower-28.messagelabs.com with RC4-SHA encrypted SMTP; 4 Oct 2010 16:40:20 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 4 Oct 2010 12:40:19 -0400 From: Avi Lior To: Mark Jones Date: Mon, 4 Oct 2010 12:40:02 -0400 Thread-Topic: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 Thread-Index: Actj4sqgaaSGjgqfSsGDdSsw91zbdw== Message-ID: <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com> References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> In-Reply-To: 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 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, 04 Oct 2010 16:40:19 -0000 I realize that the issue I am raising is not really with your draft. Perha= ps Dime should liaise with DNS to change this matter. After all, Dime relaxed SDO requirements for their Diameter Applications an= d if NAPTR is going to be used by SDO they will have to write an RFC (sure= any old RFC but an RFC nevertheless). Seems to be that the IETF/IESG shou= ld address this issue. Unless of course we think that NAPTR will hardly ever be used. Perhaps you= can weigh in on how popular NAPTR will be. On 04-10-2010, at 10:38 , Mark Jones wrote: > See inline. >=20 > On Sat, Oct 2, 2010 at 4:48 PM, Avi Lior wro= te: > >>>> Specifically if I have a vendor specific application id and I want to = use this scheme now I have to write an RFC? >>>>=20 >>>=20 >>> Yes but the S-NAPTR allocation policy allows an RFC =93of any category= =94 >>> (not standards track) so this should not present a major impediment to >>> vendors/SDOs that require this optimization. >>=20 >> Okay. Doesnt scale well at all. >=20 > We presented the alternatives at IETF77 and this was the favoured > approach despite the additional specification effort for a non-IETF > SDO. It is the price to be paid for reusing an existing S-NAPTR > registry that does not have a "First Come; First Served" allocation > policy. A small consolation is that the IANA allocation policy for > S-NATPR service tags is not as strict as that originally used for > vendor-specific Diameter command codes ("Specification Required in > form of an RFC" vs "IETF Consensus"). >=20 > Regards > Mark Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 From victor.pascual.avila@gmail.com Mon Oct 4 14:04: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 40B853A6D94 for ; Mon, 4 Oct 2010 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, 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 C8qub+nkV0uX for ; Mon, 4 Oct 2010 14:04:42 -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 4382A3A6DB4 for ; Mon, 4 Oct 2010 14:04:41 -0700 (PDT) Received: by bwz9 with SMTP id 9so5251954bwz.31 for ; Mon, 04 Oct 2010 14:05:36 -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=XUwzFpSb074z8fD1sNhjc1rESNGTtU1A7Odr1p3SsYA=; b=YpsLJGiw4HjuH5AXKwneXJiYVKivilMm8bActylzdRIDHaTbeSSH+hLHWjvOFCOCho gxfmMuV1beW+bVhOA/Hh6Mkjca0dyBYpzv8giVt+hPp3tHmaCCAvVdjmA67gcSn3/NL8 k5HYl7OU6a2ZpnLssDhZYerYeHTosJzx8Z0IU= 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=U8yzeKQSuLESuB7/0wW0LUt0m1/MC70aMLEGOqhYaa3BlxeN3Ipml6fnHdYyTNiejD axtDAjrK3zD8/YjJAZryIZUAz/ljYydBIauc8/IzxDqPC9jDvCL6DHT6pdrfHXncsR7d 3xpEjmjpOB251bANzKO2QCQo13u5fM/Gi1pW8= MIME-Version: 1.0 Received: by 10.204.119.80 with SMTP id y16mr7538775bkq.113.1286226336750; Mon, 04 Oct 2010 14:05:36 -0700 (PDT) Received: by 10.204.78.144 with HTTP; Mon, 4 Oct 2010 14:05:36 -0700 (PDT) In-Reply-To: References: <4BDFB5CC.5080908@restena.lu> Date: Mon, 4 Oct 2010 17:05:36 -0400 Message-ID: From: Victor Pascual Avila To: vf0213@gmail.com Content-Type: multipart/alternative; boundary=0016e6d58fd6e71d7b0491d0e75d 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, 04 Oct 2010 21:04:45 -0000 --0016e6d58fd6e71d7b0491d0e75d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Victor, quick question: SCTP provides the "unordered delivery" feature, which means that the receiving side may receive unordered Diameter messages. Does Diameter provide any AVP indicating a sequence number or such that would enable message re-ordering? Many thanks in advance, -Victor On Tue, May 4, 2010 at 8:34 AM, Victor Fajardo wrote: > Hi, > > I see. Then I would propose that in the current state of this spec, we ca= n > simply state a minimum (as stefan has mentioned) that a peer MUST be read= y > to handle un-ordered messages. Then someone can volunteer a more proper > guideline for SCTP stream usage/assignment either in an errata or an anot= her > 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 implementatio= n >> >> > 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 co= me >> >> 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'Educa= tion 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 >> > >> > >> >> >> >> -- >> Victor Pascual =C3=81vila >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > --=20 Victor Pascual =C3=81vila --0016e6d58fd6e71d7b0491d0e75d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Victor,
=C2=A0
quick question: SCTP provides the "unordered delivery" featu= re, which means that the receiving side may receive unordered Diameter mess= ages. Does Diameter provide any AVP indicating a sequence number or such th= at would enable message re-ordering?
=C2=A0
Many thanks in advance,
-Victor=C2=A0

On Tue, May 4, 2010 at 8:34 AM, Victor Fajardo <= span dir=3D"ltr"><vf0213@gmail.com> wrote:
Hi,
=C2=A0
I see. Then I would propose that in the current state of this spec, we= can simply state=C2=A0a 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= another draft.
=C2=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=C2= =A0in the RFC=C2=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=C3=A9seau= T=C3=A9l=C3=A9informatique de l'Education Nationale et de
>> = la Recherche
>> 6, rue Richard Coudenhove-Kalergi
>> L-13= 59 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 =C3=81vila
=
_______________________________________________
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




--
Victor Pascual =C3=81vila
--0016e6d58fd6e71d7b0491d0e75d-- From sdecugis@nict.go.jp Mon Oct 4 18:39: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 785A53A6EBF for ; Mon, 4 Oct 2010 18:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVSAhYf4CxYd for ; Mon, 4 Oct 2010 18:39:25 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id AD32B3A6E7E for ; Mon, 4 Oct 2010 18:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id E32E49404E for ; Tue, 5 Oct 2010 03:39:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri0lMUFmMT1k for ; Tue, 5 Oct 2010 03:39:55 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 7AC2B9404D for ; Tue, 5 Oct 2010 03:39:54 +0200 (CEST) Message-ID: <4CAA81D7.6050605@nict.go.jp> Date: Tue, 05 Oct 2010 10:39:35 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dime@ietf.org References: <4BDFB5CC.5080908@restena.lu> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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, 05 Oct 2010 01:39:32 -0000 Hello, Sorry to jump in the discussion like this. I don't quite understand the issue discussed. Messages pertaining to one session come as Request/Answer sequence, there is no new request generated until the previous answer was received -- at least in the Diameter applications I know -- unless the ordering is not important such as in Accounting application (which contains account record number). The ordering in Diameter is provided at the application level, there is no need to be more specific at the transport level. The only exception that is worth clarification in my opinion is the interaction between applications and Base Protocol messages such as CER/CEA or STR/STA: for example if a new message is sent just after the CEA and received out of order by the other peer, it will be discarded. Also, if an STR is sent straight after a message and received before this message, the message will be dropped as well. This might be worth stating in the RFC. It is quite easy to work around these issues in the implementation, as long as they have been anticipated. My two cents, Sebastien. Le 05/10/2010 06:05, Victor Pascual Avila a écrit : > Hi Victor, > > quick question: SCTP provides the "unordered delivery" feature, which > means that the receiving side may receive unordered Diameter messages. > Does Diameter provide any AVP indicating a sequence number or such > that would enable message re-ordering? > > Many thanks in advance, > -Victor > > On Tue, May 4, 2010 at 8:34 AM, Victor Fajardo > wrote: > > 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 another draft. > > regards, > victor > > On Tue, May 4, 2010 at 6:40 AM, Victor Pascual Avila > > 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 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éseau Téléinformatique 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 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 Ávila > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > > -- > Victor Pascual Ávila > > > _______________________________________________ > 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 suckfish@ihug.co.nz Mon Oct 4 23:46: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 D83313A6E25 for ; Mon, 4 Oct 2010 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] 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 pjD5kGWZG3JR for ; Mon, 4 Oct 2010 23:46:04 -0700 (PDT) Received: from mailfilter67.ihug.co.nz (mailfilter67.ihug.co.nz [203.109.136.67]) by core3.amsl.com (Postfix) with ESMTP id B12123A6CC4 for ; Mon, 4 Oct 2010 23:46:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQMADtnqkx2XS7L/2dsb2JhbAChNYENcsQ6hUcEikCFaIFg X-IronPort-AV: E=Sophos;i="4.57,282,1283688000"; d="scan'208";a="99144960" Received: from 118-93-46-203.dsl.dyn.ihug.co.nz (HELO i.geek.nz) ([118.93.46.203]) by cust.filter3.content.vf.net.nz with SMTP; 05 Oct 2010 19:46:58 +1300 Date: Tue, 5 Oct 2010 19:46:58 +1300 From: Ralph Loader To: dime@ietf.org Message-Id: <20101005194658.2f21157e.suckfish@ihug.co.nz> In-Reply-To: <4CAA81D7.6050605@nict.go.jp> References: <4BDFB5CC.5080908@restena.lu> <4CAA81D7.6050605@nict.go.jp> X-Mailer: Sylpheed 3.1.0beta3 (GTK+ 2.22.0; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 05 Oct 2010 06:46:06 -0000 > The only exception that is worth clarification in my opinion is the > interaction between applications and Base Protocol messages such as > CER/CEA or STR/STA: for example if a new message is sent just after the > CEA and received out of order by the other peer, it will be discarded. > Also, if an STR is sent straight after a message and received before > this message, the message will be dropped as well. This might be worth > stating in the RFC. It is quite easy to work around these issues in the > implementation, as long as they have been anticipated. How is an end-point sending a CEA and then sending a request over separate = SCTP streams meant to work-around this issue? [I might be out of date, but= I thought that the Diameter RFCs required that an implementation using SCT= P MUST use multiple streams, which implies some out-of-order delivery.] Last time I asked on the list, I got a detailed explanation that it was imp= ossible. Cheers, Ralph. >=20 > My two cents, > Sebastien. >=20 > Le 05/10/2010 06:05, Victor Pascual Avila a =E9crit : > > Hi Victor, > > =20 > > quick question: SCTP provides the "unordered delivery" feature, which > > means that the receiving side may receive unordered Diameter messages. > > Does Diameter provide any AVP indicating a sequence number or such > > that would enable message re-ordering? > > =20 > > Many thanks in advance, > > -Victor=20 > > > > On Tue, May 4, 2010 at 8:34 AM, Victor Fajardo > > wrote: > > > > Hi, > > =20 > > 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 another draft. > > =20 > > regards, > > victor > > > > On Tue, May 4, 2010 at 6:40 AM, Victor Pascual Avila > > > > 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 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'Educa= tion > > 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 > > > > > > > > > > > > > > -- > > Victor Pascual =C1vila > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > --=20 > > Victor Pascual =C1vila > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > --=20 > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Tue Oct 5 00:44: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 E1E983A6D98 for ; Tue, 5 Oct 2010 00:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF---Bo-+Hwc for ; Tue, 5 Oct 2010 00:44:18 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id B711A3A6E41 for ; Tue, 5 Oct 2010 00:44:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 84CE59409D for ; Tue, 5 Oct 2010 09:45:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsQ-erZWhZoR for ; Tue, 5 Oct 2010 09:45:08 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 021299409B for ; Tue, 5 Oct 2010 09:45:07 +0200 (CEST) Message-ID: <4CAAD76C.6020904@nict.go.jp> Date: Tue, 05 Oct 2010 16:44:44 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dime@ietf.org References: <4BDFB5CC.5080908@restena.lu> <4CAA81D7.6050605@nict.go.jp> <20101005194658.2f21157e.suckfish@ihug.co.nz> In-Reply-To: <20101005194658.2f21157e.suckfish@ihug.co.nz> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 05 Oct 2010 07:44:20 -0000 Hi, > How is an end-point sending a CEA and then sending a request over separate SCTP streams meant to work-around this issue? Sorry if it was not clear, I meant it as "the only exception to out-of-order delivery *not* being an issue". So, what I was describing is an actual issue (in my opinion) with multi-stream use. It can be worked around in the implementation, for example by allowing messages to be sent over a different stream only after a new message has been received from the remote peer (confirming the remote peer moved the connection to OPEN state), or after a reasonable delay (for example a few seconds). If the first option is chosen, it can be a good practice to always send a DWR after the CEA is received (as it is done after a network failure recovery). I hope this clarifies my point ^^. Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Tue Oct 5 02:08:46 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 5E10C3A6EFF for ; Tue, 5 Oct 2010 02:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 1f6QdR02ahoa for ; Tue, 5 Oct 2010 02:08:45 -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 DBC3B3A6EF1 for ; Tue, 5 Oct 2010 02:08:44 -0700 (PDT) Received: by fxm6 with SMTP id 6so4197850fxm.31 for ; Tue, 05 Oct 2010 02:09:41 -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=qQ8nkmtVgIYbt3ZL/+/PDgKlGApNAH2G+dk0qlwRrD0=; b=i/W9yMGblIo7CTW3j3vPRu1uXsp1NvhTxqaOceXmKjhi+7Ad2/WAjjv5fb1H2nMSdc o33xzdEJUk/Ep6t7L52eloP78rp0L66dPbJ1DhqP7v+fY6VjwSFleo8kxJeF0bIyLet5 q49PBOCiF5HS3CpIBL93ZXzjSufTvZuT1TP6A= 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=TCzR/ijerODGjUYT99T647BxauvtI2LozZTkWtGHzKmdZSvx6/SR9O8m2bot/ukM/S +KFEc+cJ6QMRJM6AxxaWWq3LPIsFR1EUlSNLzLjugTEc4ProlQvNma2DUc/ugnl0kI88 ymUnDqYn2XHFeYkOZsv9kxCMjO/P184nzpeqo= Received: by 10.223.111.70 with SMTP id r6mr10125431fap.92.1286269781336; Tue, 05 Oct 2010 02:09:41 -0700 (PDT) Received: from [10.254.0.48] ([192.100.123.77]) by mx.google.com with ESMTPS id b36sm2744948faq.11.2010.10.05.02.09.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 02:09:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com> Date: Tue, 5 Oct 2010 12:09:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com> To: Avi Lior X-Mailer: Apple Mail (2.1078) Cc: "dime@ietf.org" Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 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, 05 Oct 2010 09:08:46 -0000 Hi Avi, First, thanks for thorough review comments. Some points below. On Oct 4, 2010, at 7:40 PM, Avi Lior wrote: > I realize that the issue I am raising is not really with your draft. = Perhaps Dime should liaise with DNS to change this matter. We did liaise to some extent already.. and that lead to this RFC3958 = stuff. But yes, I'll look into this (as in a Dime chair mode) >=20 > After all, Dime relaxed SDO requirements for their Diameter = Applications and if NAPTR is going to be used by SDO they will have to = write an RFC (sure any old RFC but an RFC nevertheless). Seems to be = that the IETF/IESG should address this issue. >=20 > Unless of course we think that NAPTR will hardly ever be used. = Perhaps you can weigh in on how popular NAPTR will be. That is a good question. As far as I know, at least one external body = has already put a reference to extended NAPTRs into their own = specifications. - Jouni >=20 >=20 > On 04-10-2010, at 10:38 , Mark Jones wrote: >=20 >> See inline. >>=20 >> On Sat, Oct 2, 2010 at 4:48 PM, Avi Lior = wrote: >> >>>>> Specifically if I have a vendor specific application id and I want = to use this scheme now I have to write an RFC? >>>>>=20 >>>>=20 >>>> Yes but the S-NAPTR allocation policy allows an RFC =93of any = category=94 >>>> (not standards track) so this should not present a major impediment = to >>>> vendors/SDOs that require this optimization. >>>=20 >>> Okay. Doesnt scale well at all. >>=20 >> We presented the alternatives at IETF77 and this was the favoured >> approach despite the additional specification effort for a non-IETF >> SDO. It is the price to be paid for reusing an existing S-NAPTR >> registry that does not have a "First Come; First Served" allocation >> policy. A small consolation is that the IANA allocation policy for >> S-NATPR service tags is not as strict as that originally used for >> vendor-specific Diameter command codes ("Specification Required in >> form of an RFC" vs "IETF Consensus"). >>=20 >> Regards >> Mark >=20 > Avi Lior > avi@bridgewatersystems.com > office: +1 613-591-9104x6417 > cell: +1 613-796-4183 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From avi@bridgewatersystems.com Tue Oct 5 06:11: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 191CE3A6F16 for ; Tue, 5 Oct 2010 06:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 6CsFCEHDYzZT for ; Tue, 5 Oct 2010 06:11:05 -0700 (PDT) Received: from mail29.messagelabs.com (mail29.messagelabs.com [216.82.249.147]) by core3.amsl.com (Postfix) with ESMTP id AA93C3A6F5E for ; Tue, 5 Oct 2010 06:10:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-8.tower-29.messagelabs.com!1286284251!77403967!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 27998 invoked from network); 5 Oct 2010 13:11:40 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-8.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 5 Oct 2010 13:11:40 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 5 Oct 2010 09:11:00 -0400 From: Avi Lior To: jouni korhonen Date: Tue, 5 Oct 2010 09:11:01 -0400 Thread-Topic: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 Thread-Index: ActkjsE44RMqzKYyRtmfahPuw//Xog== Message-ID: References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com> In-Reply-To: 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] Avi Lior Review of draft-ietf-dime-extended-naptr-02 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, 05 Oct 2010 13:11:07 -0000 On 05-10-2010, at 05:09 , jouni korhonen wrote: >> After all, Dime relaxed SDO requirements for their Diameter Applications= and if NAPTR is going to be used by SDO they will have to write an RFC (s= ure any old RFC but an RFC nevertheless). Seems to be that the IETF/IESG s= hould address this issue. >>=20 >> Unless of course we think that NAPTR will hardly ever be used. Perhaps = you can weigh in on how popular NAPTR will be. >=20 > That is a good question. As far as I know, at least one external body has= already put a reference to extended NAPTRs into their own specifications. >=20 My 2 cents: If that body is 3GPP then I suspect there will be many usages = to follow. Also, I think RADIUS folks are also using this. As well, as w= e start expanding beyond core services more and more will will start using = mechanisms such as this for discovery. We should get it right sooner. Avi Lior avi@bridgewatersystems.com office: +1 613-591-9104x6417 cell: +1 613-796-4183 From jouni.nospam@gmail.com Tue Oct 5 12:45: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 4A4643A6E62 for ; Tue, 5 Oct 2010 12:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 ZRz5iSHwqMLY for ; Tue, 5 Oct 2010 12:45:19 -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 2713D3A6DF6 for ; Tue, 5 Oct 2010 12:45:18 -0700 (PDT) Received: by fxm6 with SMTP id 6so4704645fxm.31 for ; Tue, 05 Oct 2010 12:46:16 -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=d1PtxkGtGIjzsFB9ZlfgriM8/mZBlvYLitvmyBwDIcA=; b=aqPCkOfUumkPqDPUwHRFPmFVVbmmzOXzXH2thWcwRUAhoGizntWsW5eWpdAN7zGYib 7kFYbCvWzUNwBvhXJvGmLYxXUA+D7hixWA7W0S7p70PMyMP69/XasoX0dkvKx8UVzVs2 pT0kFnRItG4DX7tHLk8IZb+XCIPWJFYibT7eU= 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=NqQy88spi+6we3FIMrTji/Xdo54LRM9I3iJjORKSbOUFPlV82xR9VsEhiJ0XqG/GfA qwteugIIv63q4TxrlxVo6oVl53Tl5o36ekB4GZWZEwcCn+RrjL9oipbNO2Ns3RDPk5dL hqlEHuxMJbAa2ku29AJSb7IJjGTVYBnTX63HM= Received: by 10.223.111.77 with SMTP id r13mr2276397fap.83.1286307976588; Tue, 05 Oct 2010 12:46:16 -0700 (PDT) Received: from a83-245-214-243.elisa-laajakaista.fi (a83-245-214-243.elisa-laajakaista.fi [83.245.214.243]) by mx.google.com with ESMTPS id b11sm3145441faq.30.2010.10.05.12.46.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 12:46:14 -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, 5 Oct 2010 22:46:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C7D7B22-E58D-4EA4-8B04-34FC52E0153C@gmail.com> References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> <4740121D-55DC-4D7F-AB5D-1D1DA7B8A86C@bridgewatersystems.com> <80E8ADA3-C07F-4F24-AE69-FDC4EEFC89A2@bridgewatersystems.com> To: Avi Lior X-Mailer: Apple Mail (2.1078) Cc: "dime@ietf.org" Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 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, 05 Oct 2010 19:45:20 -0000 On Oct 5, 2010, at 4:11 PM, Avi Lior wrote: >=20 > On 05-10-2010, at 05:09 , jouni korhonen wrote: >=20 >>> After all, Dime relaxed SDO requirements for their Diameter = Applications and if NAPTR is going to be used by SDO they will have to = write an RFC (sure any old RFC but an RFC nevertheless). Seems to be = that the IETF/IESG should address this issue. >>>=20 >>> Unless of course we think that NAPTR will hardly ever be used. = Perhaps you can weigh in on how popular NAPTR will be. >>=20 >> That is a good question. As far as I know, at least one external body = has already put a reference to extended NAPTRs into their own = specifications. >>=20 > My 2 cents: If that body is 3GPP then I suspect there will be many = usages to follow. Also, I think RADIUS folks are=20 ;) well.. no. I myself don't recall 3GPP being the suspect this time. > also using this. As well, as we start expanding beyond core services = more and more will will start using mechanisms such as this for = discovery. We should get it right sooner. Right. Agree. - Jouni >=20 > Avi Lior > avi@bridgewatersystems.com > office: +1 613-591-9104x6417 > cell: +1 613-796-4183 >=20 >=20 From trac@tools.ietf.org Tue Oct 5 21:00: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 A75EB3A6E0E for ; Tue, 5 Oct 2010 21:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP-fN+sobWpo for ; Tue, 5 Oct 2010 21:00:39 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C5F583A6D42 for ; Tue, 5 Oct 2010 21:00:39 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P3LCF-0002Rd-7O; Tue, 05 Oct 2010 21:01:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: tanakai@nttdocomo.co.jp X-Trac-Project: dime Date: Wed, 06 Oct 2010 04:01:39 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/14 Message-ID: <065.d4ac8b9b270749bdf0cf3633f1cc8047@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: tanakai@nttdocomo.co.jp, dime@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] extended-naptr #14 (new): Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 04:00:40 -0000 #14: Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02 -------------------------------------+-------------------------------------- Reporter: tanakai@… | Owner: tanakai@… Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: extended-naptr | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+-------------------------------------- I have reviewed draft-ietf-dime-extended-naptr-02. Let me provide some (mainly editorial) comments. [Comment 1] Introduction section should have a brief problem statement (i.e. what the problem this is trying to solve) so that the readability is improved. [Comment 2] Editorial in Section 3, "The DNS administrator of some domain SHOULD also provision base RFC 3588 style..." shouldn't this be "The DNS administrator of some domain SHOULD also provision *legacy* RFC 3588 style...".. ? My proposal is to replace 'base' with 'legacy', so that the consistent expression is used throughout the specification. [Comment 3] Editorial in Section 4, the first sentence. "The basic Diameter Peer Discover principles" should be "The basic Diameter Peer Discovery principles" -- Ticket URL: dime From victor.pascual.avila@gmail.com Wed Oct 6 09:09: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 5C2663A716D for ; Wed, 6 Oct 2010 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, 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 F3h-V5Hr8Ko7 for ; Wed, 6 Oct 2010 09:09:27 -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 EB6EE3A7151 for ; Wed, 6 Oct 2010 09:09:26 -0700 (PDT) Received: by bwz9 with SMTP id 9so6964073bwz.31 for ; Wed, 06 Oct 2010 09:10:26 -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=L4ynPHpF4wlIJGzwNcQymi5c7xSnW+ylHsE3ufJw5gc=; b=h5/R5y0HcIa37e6/XzN0uGn2KUWmKc8s311/2xkvNZqmHg74EcNitnIzuXe8mwF3fD 2CBPOXbjWW3KaK2RNzLV+mxvF5WwLAjP+bVR2/v2n6Rs/GaoaIp1vbVafF1rRDEQvW/j Pf52ATn64uUnRSSF8y0hyRnjI2j2CuvlQMPmo= 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=ZmrvShviMJgabzM+1UAH/dtfx0IvMvYY86/7QMNs0JbqJcxvlPkeVBovKfiOB4MrsI QgxC9OMFPreO93oAE2RsPkUVVj1Yp7T8T52iezymrOIi+dcxLgwW+dE4HoWf+8NLq43m MXxoYkOTyTSWT2HWUxoV/UWM2VBk9RErngieE= MIME-Version: 1.0 Received: by 10.204.112.136 with SMTP id w8mr5577751bkp.162.1286381426152; Wed, 06 Oct 2010 09:10:26 -0700 (PDT) Received: by 10.204.78.144 with HTTP; Wed, 6 Oct 2010 09:10:25 -0700 (PDT) In-Reply-To: <20101005194658.2f21157e.suckfish@ihug.co.nz> References: <4BDFB5CC.5080908@restena.lu> <4CAA81D7.6050605@nict.go.jp> <20101005194658.2f21157e.suckfish@ihug.co.nz> Date: Wed, 6 Oct 2010 12:10:25 -0400 Message-ID: From: Victor Pascual Avila To: Ralph Loader Content-Type: multipart/alternative; boundary=0016e6de16c4f3a1250491f50305 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: Wed, 06 Oct 2010 16:09:30 -0000 --0016e6de16c4f3a1250491f50305 Content-Type: text/plain; charset=UTF-8 Hi Ralph, please see my response below. On Tue, Oct 5, 2010 at 2:46 AM, Ralph Loader wrote: > > The only exception that is worth clarification in my opinion is the > > interaction between applications and Base Protocol messages such as > > CER/CEA or STR/STA: for example if a new message is sent just after the > > CEA and received out of order by the other peer, it will be discarded. > > Also, if an STR is sent straight after a message and received before > > this message, the message will be dropped as well. This might be worth > > stating in the RFC. It is quite easy to work around these issues in the > > implementation, as long as they have been anticipated. > > How is an end-point sending a CEA and then sending a request over separate > SCTP streams meant to work-around this issue? [I might be out of date, but > I thought that the Diameter RFCs required that an implementation using SCTP > MUST use multiple streams, which implies some out-of-order delivery.] > In order to prevent head-of-the-line-blocking, one could either send over multiple SCTP streams using ordered delivery (and map Diameter sessions intro SCTP streams) or send over a single stream using unordered delivery (this is actually how SIP over SCTP works). -Victor --0016e6de16c4f3a1250491f50305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ralph,
=C2=A0
please see my response below.

On Tue, Oct 5, 2010 at 2:46 AM, R= alph Loader <su= ckfish@ihug.co.nz> wrote:
> The only exception that is worth clarification in my= opinion is the
> interaction between applications and Base Protocol = messages such as
> CER/CEA or STR/STA: for example if a new message i= s sent just after the
> CEA and received out of order by the other peer, it will be discarded.=
> Also, if an STR is sent straight after a message and received befo= re
> this message, the message will be dropped as well. This might be= worth
> stating in the RFC. It is quite easy to work around these issues in th= e
> implementation, as long as they have been anticipated.

How is an end-point sending a CEA and then sending a request over separa= te SCTP streams meant to work-around this issue? =C2=A0[I might be out of d= ate, but I thought that the Diameter RFCs required that an implementation u= sing SCTP MUST use multiple streams, which implies some out-of-order delive= ry.]
In order to prevent head-of-the-line-blocking, one could either=C2=A0s= end over=C2=A0multiple SCTP streams using ordered delivery (and map Diamete= r sessions intro SCTP streams)=C2=A0or send over=C2=A0a single stream using= unordered delivery (this is actually how SIP over SCTP works).
=C2=A0
-Victor
--0016e6de16c4f3a1250491f50305-- From leig@tid.es Thu Oct 7 08:16: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 88EAA3A70D7 for ; Thu, 7 Oct 2010 08:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=3.300, BAYES_00=-2.599, 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 1nECPqgRGvQ7 for ; Thu, 7 Oct 2010 08:16:54 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by core3.amsl.com (Postfix) with ESMTP id D35493A6F85 for ; Thu, 7 Oct 2010 08:16:52 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9X0092EEHSZS@tid.hi.inet> for dime@ietf.org; Thu, 07 Oct 2010 17:17:54 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Brightmail Gateway) with SMTP id 0D.C7.02795.5A4EDAC4; Thu, 07 Oct 2010 17:17:57 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0L9X00BR7EHUMN@tid.hi.inet> for dime@ietf.org; Thu, 07 Oct 2010 17:17:54 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 07 Oct 2010 17:17:54 +0200 Date: Thu, 07 Oct 2010 17:17:52 +0200 From: LUIS ENRIQUE IZAGUIRRE GAMIR To: "dime@ietf.org" Message-id: <8EE61BA0CAEDBD4E9DA928D1206463D2660601B887@EXCLU2K7.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iNuR0wavRdU4i1zQFPtpjw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: draft-ietf-dime-nat-control pool usage clarification Thread-index: ActlcQNPPcQ2Z0x1TE66YpF2cK9KBQAeqivQABANIqA= acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7c15ae000000aeb-9f-4cade4a52d27 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: AAAAARZDfQk= Subject: [Dime] draft-ietf-dime-nat-control pool usage clarification 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, 07 Oct 2010 15:16:55 -0000 --Boundary_(ID_iNuR0wavRdU4i1zQFPtpjw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGVsbG8gYWxsLA0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbiBvbiDigJxkcmFmdC1p ZXRmLWRpbWUtbmF0LWNvbnRyb2zigJ06DQoNCg0KRENOQSBkZWZpbmVzIHRoZSBleHRlcm5hbCBh ZGRyZXNzIHBvb2wocykgdG8gYmUgdXNlZCBmb3IgYWxsb2NhdGluZyBhbiBleHRlcm5hbCBJUCBh ZGRyZXNzIHBlciBzdWJzY3JpYmVyL2VuZHBvaW50LCBlaXRoZXIgcHJlLWFzc2lnbmVkIHdpdGgg YSBOQVQtQ29udHJvbC1CaW5kaW5nLVJ1bGUgQVZQLCBvciBzcGVjaWZpZWQtd2l0aGluLWEtcmVx dWVzdCB3aXRoIGEgTkFULUNvbnRyb2wtRGVmaW5pdGlvbiBBVlAuIEhvd2V2ZXIsIHdlIGRvbuKA mXQgc2VlIGNsZWFyIGluIHRoZSBkcmFmdCB3aGV0aGVyIGl0IGlzIHBvc3NpYmxlIHRvIHByb3Zp ZGUgdGhlIHNhbWUgYWRkcmVzcyBwb29sIHdpdGhpbiBkaWZmZXJlbnQgcmVxdWVzdHMgZm9yIHNl dmVyYWwgc3Vic2NyaWJlcnMvZW5kcG9pbnRzOyB0aGlzIHBvb2wgd291bGQgYmUgdXNlZCBieSB0 aGUgTkFUIHdpdGhvdXQgb3ZlcmxhcHBpbmcgdGhlIHVzZSBvZiBJUC9wb3J0IGJldHdlZW4gdGhl c2UgdXNlcnMuDQoNCldoYXQgZG8geW91IHRoaW5rPyBXb3VsZCBpdCBiZSB3b3J0aCBhZGRpbmcg YW4gZXhwbGFuYXRpb24gaG93IHRoZSBOQVQgZGV2aWNlIG1hbmFnZXMgdGhpcyBzaXR1YXRpb24s IGluY2x1ZGluZyB0aGUgcG9zc2libGUgc2hvcnRhZ2Ugb2YgSVAvcG9ydCB0dXBsZXM/DQoNCk9u IHRoZSBvdGhlciBoYW5kLCBkb2VzIGFueWJvZHkga25vdyBpZiB0aGVyZSBpcyBhIHNpbWlsYXIg YXBwcm9hY2ggdG8gdGhpcyBkcmFmdCBiYXNlZCBvbiBSQURJVVM/DQoNClRoYW5rcyENCkVucmlx dWUgSXphZ3VpcnJlLg0KVGVsZWbDs25pY2EgSStELg0K --Boundary_(ID_iNuR0wavRdU4i1zQFPtpjw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KIC8q IFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBjb24gZm9ybWF0byBwcmV2aW8gQ2FyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MY29uZm9ybWF0b3ByZXZpb0Nh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBjb24gZm9ybWF0byBwcmV2aW8gQ2FyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgY29uIGZvcm1hdG8gcHJl dmlvIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRXN0aWxvQ29ycmVvMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRXN0aWxvQ29ycmVvMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uaDQxDQoJe21zby1zdHlsZS1uYW1lOmg0MTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgMy4wY20gNzAuODVwdCAzLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT4NCg0KPGRpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMxRjQ5N0QnPkhlbGxvIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz5JIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbiBvbiDigJxkcmFm dC1pZXRmLWRpbWUtbmF0LWNvbnRyb2zigJ06PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cHJlIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkRDTkEgZGVmaW5lcyB0 aGUgZXh0ZXJuYWwgYWRkcmVzcyBwb29sKHMpIHRvIGJlIHVzZWQgZm9yIGFsbG9jYXRpbmcgYW4g ZXh0ZXJuYWwgSVAgYWRkcmVzcyBwZXIgc3Vic2NyaWJlci9lbmRwb2ludCwgZWl0aGVyIHByZS1h c3NpZ25lZCB3aXRoIGEgTkFULUNvbnRyb2wtQmluZGluZy1SdWxlIEFWUCwgb3Igc3BlY2lmaWVk LXdpdGhpbi1hLXJlcXVlc3Qgd2l0aCBhIE5BVC1Db250cm9sLURlZmluaXRpb24gQVZQLiBIb3dl dmVyLCB3ZSBkb27igJl0IHNlZSBjbGVhciBpbiB0aGUgZHJhZnQgd2hldGhlciBpdCBpcyBwb3Nz aWJsZSB0byBwcm92aWRlIDwvc3Bhbj48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+dGhlIHNhbWU8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IGFk ZHJlc3MgcG9vbCB3aXRoaW4gPC9zcGFuPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz5kaWZmZXJlbnQ8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ IHJlcXVlc3Q8L3NwYW4+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPnMgZm9y PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6DQoiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiBzZXZlcmFsIHN1YnNj cmliZXJzL2VuZHBvaW50czsgdGhpcyBwb29sIHdvdWxkIGJlIHVzZWQgYnkgdGhlIE5BVCB3aXRo b3V0IG92ZXJsYXBwaW5nIHRoZSB1c2Ugb2YgSVAvcG9ydCBiZXR3ZWVuIHRoZXNlIHVzZXJzLjwv c3Bhbj48c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5XaGF0IGRvIHlvdSB0aGlu az8gPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldvdWxkIGl0IGJl IHdvcnRoDQphZGRpbmcgYW4gZXhwbGFuYXRpb24gaG93IHRoZSBOQVQgZGV2aWNlIG1hbmFnZXMg dGhpcyBzaXR1YXRpb24sIGluY2x1ZGluZyB0aGUgcG9zc2libGUNCnNob3J0YWdlIG9mIElQL3Bv cnQgdHVwbGVzPzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 Ow0KZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5PbiB0aGUg b3RoZXIgaGFuZCwgZG9lcyBhbnlib2R5IGtub3cgaWYgdGhlcmUgaXMgYSBzaW1pbGFyDQphcHBy b2FjaCB0byB0aGlzIGRyYWZ0IGJhc2VkIG9uIFJBRElVUz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGFua3MhPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFG NDk3RCc+RW5yaXF1ZTwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0Ow0KZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4g SXphZ3VpcnJlPC9zcGFuPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz4uPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+VGVsZWbDs25pY2EgSStELjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --Boundary_(ID_iNuR0wavRdU4i1zQFPtpjw)-- From pallavi.mishra.mnnit@gmail.com Sun Oct 10 11:45: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 AFFBE3A6830 for ; Sun, 10 Oct 2010 11:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm8k63kuQYMQ for ; Sun, 10 Oct 2010 11:45:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 9E6033A6820 for ; Sun, 10 Oct 2010 11:45:12 -0700 (PDT) Received: by gxk20 with SMTP id 20so987102gxk.31 for ; Sun, 10 Oct 2010 11:46: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=RGqyuQ+mKrLhOfM7osnu5ArjbCUlWy8xExVenSXHSYs=; b=dDBM6IOuR5/f6rxRqI8RiycX1/wwD3M/0rE0jf2VmDcBQyBsycbD+O3nEudPMMybef PYlXd6H4lJaLlLOkRAARU0aj8xwjQLojGVLLosEHedgjEJAjfhfCRlaoNNgRtkI0kYxq /5iDclKfBpXADAq/avHityjkPph8lNXHokK6Y= 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=nMxeybJTLvzCyfiBIbGa657IczNw+5ucd/ghPg7g2MV9Ka/IssqSQYMNqDNyMt4N9x PCKRHjnAPNsDX9A5aSK5FaOLiWsl/OWDm53Yq3K3RV/wE8j3zFoF0lAVlHilClK5QRcV aqOWgdTDcLVQg4oxbUH8bodjSA9EtDJQh6UMk= MIME-Version: 1.0 Received: by 10.100.173.12 with SMTP id v12mr2204132ane.74.1286736382072; Sun, 10 Oct 2010 11:46:22 -0700 (PDT) Received: by 10.100.108.12 with HTTP; Sun, 10 Oct 2010 11:46:22 -0700 (PDT) In-Reply-To: <04BD913C7AD1B84297D26D5614FBE13301ACE181@XMB-BGL-417.cisco.com> References: <04BD913C7AD1B84297D26D5614FBE13301ACE181@XMB-BGL-417.cisco.com> Date: Mon, 11 Oct 2010 00:16:22 +0530 Message-ID: From: Pallavi Mishra To: jouni.nospam@gmail.com, dime@ietf.org, draft-ietf-dime-nat-control@tools.ietf.org Content-Type: multipart/alternative; boundary=0016e645ada6f91952049247a82c X-Mailman-Approved-At: Sun, 10 Oct 2010 22:46:19 -0700 Cc: svikram@cisco.com, dime-chairs@tools.ietf.org Subject: Re: [Dime] WGLC starting for draft-ietf-dime-nat-control 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, 11 Oct 2010 05:12:05 -0000 --0016e645ada6f91952049247a82c Content-Type: text/plain; charset=ISO-8859-1 I have reviewed the draft and it looks good to me. thanks, Pallavi > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Monday, August 02, 2010 3:58 PM > To: dime@ietf.org; draft-ietf-dime-nat-control@tools.ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: WGLC starting for draft-ietf-dime-nat-control > > A two weeks WGLC for Diameter Network Address and Port Translation > Control Application (draft-ietf-dime-nat-control-03) starts as of > today 2-Aug-2010 and ends on Monday 16-Aug-2010 23:59 (CEST+1). > > We _require_ at least three reviews from people who are not authors of > the document. In case of an inadequate review success, we'll just keep > the document in the WG and go for another WGLC later (that will again > need a new set of three reviews ;). So lobby people to review! > > - Jouni & Lionel -- thanks, Pallavi --0016e645ada6f91952049247a82c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed the draft and it looks good to me.
thanks,
Pallavi


> -----Original Mes= sage-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com= ]
> Sent: Monday, August 02, 2010 3:58 PM
> To:=A0dime@ietf.org;=A0draft-ietf-d= ime-nat-control@tools.ietf.org
> Cc:=A0dime-chairs@tools.ietf.org
> Su= bject: WGLC starting for draft-ietf-dime-nat-control
>
> A two = weeks WGLC for Diameter Network Address and Port Translation
> Control Application (draft-ietf-dime-nat-control-03) starts as of
&= gt; today 2-Aug-2010 and ends on Monday 16-Aug-2010 23:59 (CEST+1).
>=
> We _require_ at least three reviews from people who are not author= s of

> the document. In case of an inadequate review success, we'll j= ust keep

> the document in the WG and go for another WGLC later (= that will again
> need a new set of three reviews ;). So lobby people= to review!
>
> - Jouni & Lionel

--
thanks= ,
Pallavi
--0016e645ada6f91952049247a82c-- From dromasca@avaya.com Mon Oct 11 07:00: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 840233A6A69 for ; Mon, 11 Oct 2010 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsycQXxhOSBm for ; Mon, 11 Oct 2010 07:00:09 -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 97D2E3A6A50 for ; Mon, 11 Oct 2010 07:00:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,314,1283745600"; d="scan'208";a="242141817" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Oct 2010 10:01:21 -0400 X-IronPort-AV: E=Sophos;i="4.57,314,1283745600"; d="scan'208";a="521557130" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Oct 2010 10:01:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 16:01:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-dime-rfc3588bis-25.txt Thread-Index: ActpTMct8R9Pe9VpTOaTe7t84CC1KQ== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 11 Oct 2010 14:00:10 -0000 Please find below the AD review for draft-ietf-dime-rfc3588bis-25.txt. I think that this document is stable and mature enough to go to IETF Last Call. Please deal with my comments together with the other IETF LC comments.=20 1. This document incorporates the changes made in the IANA Considerations for Diameter Command Code Allocations described in RFC 5719. I think that this document should obsolete RFC 5719, and this change should be described in Section 1.1.3 2. Same comment about the Diameter realm routing clarifications described in RFC 5729. 3. How is backwards compatibility ensured between RFC 3588 implementations which were mandating IPSec and this new version which mandates TLS and makes IPSec support optional, while disallowing usage of Diameter without any security mechanisms?=20 Thanks and Regards, Dan From wwwrun@core3.amsl.com Mon Oct 11 08:02:33 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 55B323A6B03; Mon, 11 Oct 2010 08:02:33 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20101011150233.55B323A6B03@core3.amsl.com> Date: Mon, 11 Oct 2010 08:02:33 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Base Protocol) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 15:02:33 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Base Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ From iesg-secretary@ietf.org Mon Oct 11 08:03:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8FD3A6B1A; Mon, 11 Oct 2010 08:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZmukh9J0Eod; Mon, 11 Oct 2010 08:03:36 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0883A6B03; Mon, 11 Oct 2010 08:03:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20101011150330.960.67372.idtracker@localhost> Date: Mon, 11 Oct 2010 08:03:30 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Base Protocol) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.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, 11 Oct 2010 15:03:37 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Base Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ No IPR declarations were found that appear related to this I-D. From mark@azu.ca Mon Oct 11 08:17:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD763A6AF5 for ; Mon, 11 Oct 2010 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.260, 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 NoC6pWNVZY-x for ; Mon, 11 Oct 2010 08:17:32 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 94FF33A6A98 for ; Mon, 11 Oct 2010 08:17:32 -0700 (PDT) Received: by qwc9 with SMTP id 9so1705136qwc.31 for ; Mon, 11 Oct 2010 08:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.241.137 with SMTP id le9mr5189742qcb.237.1286810324054; Mon, 11 Oct 2010 08:18:44 -0700 (PDT) Received: by 10.229.31.133 with HTTP; Mon, 11 Oct 2010 08:18:43 -0700 (PDT) In-Reply-To: <065.d4ac8b9b270749bdf0cf3633f1cc8047@tools.ietf.org> References: <065.d4ac8b9b270749bdf0cf3633f1cc8047@tools.ietf.org> Date: Mon, 11 Oct 2010 17:18:43 +0200 Message-ID: From: Mark Jones To: tanakai@nttdocomo.co.jp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] [dime] extended-naptr #14 (new): Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02 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, 11 Oct 2010 15:17:34 -0000 Hi Itsuma-san, Thank you for the review. Comments inline. On Wed, Oct 6, 2010 at 6:01 AM, dime issue tracker wr= ote: > #14: Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02 > -------------------------------------+-----------------------------------= --- > =A0Reporter: =A0tanakai@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = Owner: =A0tanakai@=85 > =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Stat= us: =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milest= one: =A0milestone1 > Component: =A0extended-naptr =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: =A01.= 0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 =A0Keywords: > -------------------------------------+-----------------------------------= --- > =A0I have reviewed draft-ietf-dime-extended-naptr-02. > =A0Let me provide some (mainly editorial) comments. > > =A0[Comment 1] > =A0Introduction section should have a brief problem statement (i.e. what = the > =A0problem this is trying to solve) so that the readability is improved. > Agreed. Here is my latest attempt at the problem statement based on feedback from Avi. Your comments are welcome. =93Using dynamic peer discovery as described in RFC3588, a given realm may advertise multiple Diameter nodes without revealing which Diameter application each node supports. A peer outside the realm would have to perform a CER/CEA exchange with every node in order to find which one supports the desired application. This document describes an optimization using S-NAPTR entries that allows peer discovery including supported applications without doing CER/CEA exchange beforehand.=94 > =A0[Comment 2] > =A0Editorial in Section 3, "The DNS administrator of some domain SHOULD a= lso > =A0provision base RFC 3588 style..." > > =A0shouldn't this be > > =A0"The DNS administrator of some domain SHOULD also provision *legacy* R= FC > =A03588 style...".. ? > > =A0My proposal is to replace 'base' with 'legacy', so that the consistent > =A0expression is used throughout the specification. > Makes sense. > =A0[Comment 3] > =A0Editorial in Section 4, the first sentence. > =A0"The basic Diameter Peer Discover principles" > =A0should be "The basic Diameter Peer Discovery principles" > Agreed. The word "basic" also seems redundant in this sentence. I'll incorporate these changes in the next revision. Thanks Mark From jouni.nospam@gmail.com Mon Oct 11 08:20:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653D23A6A86 for ; Mon, 11 Oct 2010 08:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S3fmHD2+wlL for ; Mon, 11 Oct 2010 08:20:32 -0700 (PDT) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by core3.amsl.com (Postfix) with ESMTP id E51D23A6927 for ; Mon, 11 Oct 2010 08:20:31 -0700 (PDT) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id A3E831A9079; Mon, 11 Oct 2010 18:21:42 +0300 (EEST) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A01CCDA1055; Mon, 11 Oct 2010 18:21:42 +0300 Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id 95D561A9079; Mon, 11 Oct 2010 18:21:42 +0300 (EEST) Received: from a83-245-209-228.elisa-laajakaista.fi (a83-245-209-228.elisa-laajakaista.fi [83.245.209.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 436B6139793; Mon, 11 Oct 2010 18:21:40 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Mon, 11 Oct 2010 18:21:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6F641D9B-7E25-405E-9060-CB86C1DB4E2A@gmail.com> References: To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1081) X-Antivirus: VAMS Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 11 Oct 2010 15:20:33 -0000 Hi Dan, I have one comment regarding RFC5729. We had a specific discussion = around this RFC (draft back then) whether we should somehow hook RFC5729 = with RFC3588bis or even incorporate into it. We decided to keep RFC5729 = and RFC3588bis separate, as we needed to get RFC5729 for RFC3588 based = deployments and not blocked by bis. Also, we decided back then not to = incorporate the RFC5729 clarifications to bis, as RFC5729 could be seen = as a companion document that would also complement bis. RFC3588bis has = still the same NAI routing principles as RFC3588, and therefore anything = in RFC5729 should also appliy to bis. - Jouni On Oct 11, 2010, at 5:01 PM, Romascanu, Dan (Dan) wrote: > Please find below the AD review for draft-ietf-dime-rfc3588bis-25.txt. = I > think that this document is stable and mature enough to go to IETF = Last > Call. Please deal with my comments together with the other IETF LC > comments.=20 >=20 > 1. This document incorporates the changes made in the IANA > Considerations for Diameter Command Code Allocations described in RFC > 5719. I think that this document should obsolete RFC 5719, and this > change should be described in Section 1.1.3 >=20 > 2. Same comment about the Diameter realm routing clarifications > described in RFC 5729. >=20 > 3. How is backwards compatibility ensured between RFC 3588 > implementations which were mandating IPSec and this new version which > mandates TLS and makes IPSec support optional, while disallowing usage > of Diameter without any security mechanisms?=20 >=20 > Thanks and Regards, >=20 > Dan >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Mon Oct 11 08:25:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67AEA3A6B03 for ; Mon, 11 Oct 2010 08:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-2n5m-db2LQ for ; Mon, 11 Oct 2010 08:25:36 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 05B3D3A6927 for ; Mon, 11 Oct 2010 08:25:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,314,1283745600"; d="scan'208";a="38542281" 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 Oct 2010 11:26:47 -0400 X-IronPort-AV: E=Sophos;i="4.57,314,1283745600"; d="scan'208";a="525388616" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Oct 2010 11:26:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 17:26:26 +0200 Message-ID: In-Reply-To: <6F641D9B-7E25-405E-9060-CB86C1DB4E2A@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt Thread-Index: ActpWAUfJkgo/cUjRWCpteE3wosNJwAABzqA References: <6F641D9B-7E25-405E-9060-CB86C1DB4E2A@gmail.com> From: "Romascanu, Dan (Dan)" To: "Jouni" Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.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, 11 Oct 2010 15:25:37 -0000 I am OK with your technical and editorial choice, but this needs to be reflected also in the text, because 5729 as it stands updates a document (3588) which will soon be obsolete. In 1.1.1. Description of the Document Set you need to mention also 5729 as part of the set.=20 Dan > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com]=20 > Sent: Monday, October 11, 2010 5:22 PM > To: Romascanu, Dan (Dan) > Cc: dime@ietf.org > Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt >=20 > Hi Dan, >=20 > I have one comment regarding RFC5729. We had a specific=20 > discussion around this RFC (draft back then) whether we=20 > should somehow hook RFC5729 with RFC3588bis or even=20 > incorporate into it. We decided to keep RFC5729 and=20 > RFC3588bis separate, as we needed to get RFC5729 for RFC3588=20 > based deployments and not blocked by bis. Also, we decided=20 > back then not to incorporate the RFC5729 clarifications to=20 > bis, as RFC5729 could be seen as a companion document that=20 > would also complement bis. RFC3588bis has still the same NAI=20 > routing principles as RFC3588, and therefore anything in=20 > RFC5729 should also appliy to bis. >=20 > - Jouni >=20 > On Oct 11, 2010, at 5:01 PM, Romascanu, Dan (Dan) wrote: >=20 > > Please find below the AD review for=20 > draft-ietf-dime-rfc3588bis-25.txt.=20 > > I think that this document is stable and mature enough to=20 > go to IETF=20 > > Last Call. Please deal with my comments together with the=20 > other IETF=20 > > LC comments. > >=20 > > 1. This document incorporates the changes made in the IANA=20 > > Considerations for Diameter Command Code Allocations=20 > described in RFC=20 > > 5719. I think that this document should obsolete RFC 5719, and this=20 > > change should be described in Section 1.1.3 > >=20 > > 2. Same comment about the Diameter realm routing clarifications=20 > > described in RFC 5729. > >=20 > > 3. How is backwards compatibility ensured between RFC 3588=20 > > implementations which were mandating IPSec and this new=20 > version which=20 > > mandates TLS and makes IPSec support optional, while=20 > disallowing usage=20 > > of Diameter without any security mechanisms? > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 From tanakai@nttdocomo.co.jp Mon Oct 11 09:28:49 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 868183A6B27 for ; Mon, 11 Oct 2010 09:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.834 X-Spam-Level: * X-Spam-Status: No, score=1.834 tagged_above=-999 required=5 tests=[AWL=2.925, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NI9zMapw7BW for ; Mon, 11 Oct 2010 09:28:48 -0700 (PDT) Received: from zcsg-mailro13.is.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by core3.amsl.com (Postfix) with ESMTP id 5A9B53A6822 for ; Mon, 11 Oct 2010 09:28:47 -0700 (PDT) Received: from zcsg-mailmt12.is.nttdocomo.co.jp (zcsg-mailmt10.is.nttdocomo.co.jp [10.160.86.41]) by zcsg-mailro13.is.nttdocomo.co.jp (Postfix) with ESMTP id 7053A34003 for ; Tue, 12 Oct 2010 01:29:59 +0900 (JST) Received: from zcsg-mailmi11.is.nttdocomo.co.jp (zcsg-mailmi10.is.nttdocomo.co.jp [10.160.86.49]) by zcsg-mailmt12.is.nttdocomo.co.jp (NTT DoCoMo Mail System) with SMTP id <0LA400MM6WHZDDE0@NTTDoCoMo.co.jp> for dime@ietf.org; Tue, 12 Oct 2010 01:29:59 +0900 (JST) Received: from unknown (HELO zcsg-mailvs12.is.nttdocomo.co.jp) (10.160.86.48) by 0 with SMTP; Tue, 12 Oct 2010 01:29:59 +0900 Received: from zcsg-mailvs12.is.nttdocomo.co.jp (localhost [127.0.0.1]) by localhost.nttdocomo.co.jp (Postfix) with ESMTP id 42CDB8003; Tue, 12 Oct 2010 01:29:59 +0900 (JST) Received: from zcsg-mailsa11.is.nttdocomo.co.jp (zcsg-mailsa10.is.nttdocomo.co.jp [10.160.86.46]) by zcsg-mailvs12.is.nttdocomo.co.jp (Postfix) with ESMTP id 371918002; Tue, 12 Oct 2010 01:29:59 +0900 (JST) Received: from [127.0.0.1] ([10.160.87.1]) by zcsg-mailsa11.is.nttdocomo.co.jp (NTT DoCoMo Mail System) with ESMTPA id <0LA4001Q2WHSK420@NTTDoCoMo.co.jp>; Tue, 12 Oct 2010 01:29:59 +0900 (JST) Date: Tue, 12 Oct 2010 01:29:41 +0900 From: Itsuma TANAKA In-reply-to: To: Mark Jones Message-id: <4CB33B75.5020701@nttdocomo.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit X-DoCoMo: ZCSG References: <065.d4ac8b9b270749bdf0cf3633f1cc8047@tools.ietf.org> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) Cc: dime@ietf.org Subject: Re: [Dime] [dime] extended-naptr #14 (new): Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02 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, 11 Oct 2010 16:28:49 -0000 Dear Mark, Thanks for the feedback. The new introduction text looks OK to me, but is this 'optimisation' or 'improvement' or 'functional enhancement'? I don't have strong opinion here though. BR, Itsuma Mark Jones wrote: > Hi Itsuma-san, > > Thank you for the review. Comments inline. > > On Wed, Oct 6, 2010 at 6:01 AM, dime issue tracker wrote: >> #14: Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02 >> -------------------------------------+-------------------------------------- >> Reporter: tanakai@$B!D(B | Owner: tanakai@$B!D(B >> Type: enhancement | Status: new >> Priority: minor | Milestone: milestone1 >> Component: extended-naptr | Version: 1.0 >> Severity: In WG Last Call | Keywords: >> -------------------------------------+-------------------------------------- >> I have reviewed draft-ietf-dime-extended-naptr-02. >> Let me provide some (mainly editorial) comments. >> >> [Comment 1] >> Introduction section should have a brief problem statement (i.e. what the >> problem this is trying to solve) so that the readability is improved. >> > > Agreed. Here is my latest attempt at the problem statement based on > feedback from Avi. Your comments are welcome. > > $B!H(BUsing dynamic peer discovery as described in RFC3588, a given realm > may advertise multiple Diameter nodes without revealing which Diameter > application each node supports. A peer outside the realm would have to > perform a CER/CEA exchange with every node in order to find which one > supports the desired application. This document describes an > optimization using S-NAPTR entries that allows peer discovery > including supported applications without doing CER/CEA exchange > beforehand.$B!I(B > >> [Comment 2] >> Editorial in Section 3, "The DNS administrator of some domain SHOULD also >> provision base RFC 3588 style..." >> >> shouldn't this be >> >> "The DNS administrator of some domain SHOULD also provision *legacy* RFC >> 3588 style...".. ? >> >> My proposal is to replace 'base' with 'legacy', so that the consistent >> expression is used throughout the specification. >> > > Makes sense. > >> [Comment 3] >> Editorial in Section 4, the first sentence. >> "The basic Diameter Peer Discover principles" >> should be "The basic Diameter Peer Discovery principles" >> > > Agreed. The word "basic" also seems redundant in this sentence. > > I'll incorporate these changes in the next revision. > > Thanks > Mark > > From root@core3.amsl.com Tue Oct 12 00:30:15 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 569FC3A682B; Tue, 12 Oct 2010 00: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: <20101012073011.569FC3A682B@core3.amsl.com> Date: Tue, 12 Oct 2010 00:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-capablities-update-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: Tue, 12 Oct 2010 07:30:16 -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-06.txt Pages : 7 Date : 2010-10-11 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-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-capablities-update-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12001536.I-D@ietf.org> --NextPart-- From shwethab@cisco.com Thu Oct 14 03:03: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 8F3A13A67A7 for ; Thu, 14 Oct 2010 03:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, 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 TR-xJA8bCORb for ; Thu, 14 Oct 2010 03:03:06 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 144203A68DC for ; Thu, 14 Oct 2010 03:03:06 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFALtxtkxAaMHG/2dsb2JhbACBQ59ecZ8cnF+FSASEUIh6 X-IronPort-AV: E=Sophos;i="4.57,329,1283731200"; d="scan'208,217";a="269349049" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2010 10:04:23 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9EA4GnS007665; Thu, 14 Oct 2010 10:04:23 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 15:34:19 +0530 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_01CB6B87.2AC48FFF" Date: Thu, 14 Oct 2010 15:35:00 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE13301BEE974@XMB-BGL-417.cisco.com> In-Reply-To: <8EE61BA0CAEDBD4E9DA928D1206463D2660601B887@EXCLU2K7.hi.inet> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-ietf-dime-nat-control pool usage clarification Thread-Index: ActlcQNPPcQ2Z0x1TE66YpF2cK9KBQAeqivQABANIqABVpW5cA== References: <8EE61BA0CAEDBD4E9DA928D1206463D2660601B887@EXCLU2K7.hi.inet> From: "Shwetha Bhandari (shwethab)" To: "LUIS ENRIQUE IZAGUIRRE GAMIR" , X-OriginalArrivalTime: 14 Oct 2010 10:04:19.0666 (UTC) FILETIME=[2B047320:01CB6B87] Subject: Re: [Dime] draft-ietf-dime-nat-control pool usage clarification 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, 14 Oct 2010 10:03:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6B87.2AC48FFF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Enrique, =20 Thanks for the comment. We will add a line to explicitly state reuse of = pool and external address for multiple subscribers. =20 We are not aware of a similar approach to this draft based on Radius.=20 You can look at = http://tools.ietf.org/html/draft-brockners-nat-control-protocols-review-0= 0 , where we tried to compare this with other approaches available. =20 Thanks, Shwetha ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = LUIS ENRIQUE IZAGUIRRE GAMIR Sent: Thursday, October 07, 2010 8:48 PM To: dime@ietf.org Subject: [Dime] draft-ietf-dime-nat-control pool usage clarification Hello all, =20 I have the following question on "draft-ietf-dime-nat-control": =20 DCNA defines the external address pool(s) to be used for allocating an = external IP address per subscriber/endpoint, either pre-assigned with a = NAT-Control-Binding-Rule AVP, or specified-within-a-request with a = NAT-Control-Definition AVP. However, we don't see clear in the draft = whether it is possible to provide the same address pool within different = requests for several subscribers/endpoints; this pool would be used by = the NAT without overlapping the use of IP/port between these users. =20 What do you think? Would it be worth adding an explanation how the NAT = device manages this situation, including the possible shortage of = IP/port tuples? =20 On the other hand, does anybody know if there is a similar approach to = this draft based on RADIUS? =20 Thanks! Enrique Izaguirre. Telef=F3nica I+D. ------_=_NextPart_001_01CB6B87.2AC48FFF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Enrique,
 
Thanks for the comment. We will add a line to = explicitly=20 state reuse of pool and external address for multiple=20 subscribers.
 
We are not aware of a similar approach to this = draft based=20 on Radius.
You can look at http://tools.ietf.org/html/draft-brockners-nat-control-protoco= ls-review-00 ,=20 where we tried to compare this with other approaches=20 available.
 
Thanks,
Shwetha

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of LUIS ENRIQUE = IZAGUIRRE=20 GAMIR
Sent: Thursday, October 07, 2010 8:48 PM
To:=20 dime@ietf.org
Subject: [Dime] draft-ietf-dime-nat-control pool = usage=20 clarification

Hello=20 all,

 

I=20 have the following question on=20 =93draft-ietf-dime-nat-control=94:

 

DCNA defines the external address pool(s) to be =
used for allocating an external IP address per subscriber/endpoint, =
either pre-assigned with a NAT-Control-Binding-Rule AVP, or =
specified-within-a-request with a NAT-Control-Definition AVP. However, =
we don=92t see clear in the draft whether it is possible to provide =
the same address pool within different requests for several subscribers/endpoints; this pool would =
be used by the NAT without overlapping the use of IP/port between these =
users.

 

What=20 do you think? Would=20 it be worth adding an explanation how the NAT device manages this = situation,=20 including the possible shortage of IP/port tuples?

 

On=20 the other hand, does anybody know if there is a similar approach to this = draft=20 based on RADIUS?

 

Thanks!

Enrique=20 Izaguirre.

Telef=F3nica=20 I+D.

------_=_NextPart_001_01CB6B87.2AC48FFF-- From gwz@net-zen.net Thu Oct 14 20:34: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 4ACAB3A6A79 for ; Thu, 14 Oct 2010 20:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.854 X-Spam-Level: X-Spam-Status: No, score=-101.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv3SmK3TTSgJ for ; Thu, 14 Oct 2010 20:34:37 -0700 (PDT) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id BC5FB3A6A11 for ; Thu, 14 Oct 2010 20:34:37 -0700 (PDT) Received: (qmail 1499 invoked from network); 15 Oct 2010 03:35:57 -0000 Received: from unknown (124.120.110.16) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 15 Oct 2010 03:35:56 -0000 From: "Glen Zorn" To: "'LIU Hans'" References: In-Reply-To: Date: Fri, 15 Oct 2010 10:35:24 +0700 Organization: Network Zen Message-ID: <003201cb6c1a$03035290$0909f7b0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CB6C54.AF622A90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActsE8MsfE1gZzIaQNCv/7QAATP8YAABdrwg Content-Language: en-us Cc: dime@ietf.org, draft-ietf-dime-rfc4005bis@tools.ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 03:34:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01CB6C54.AF622A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LIU Hans [mailto:Hans.Liu@alcatel-lucent.com] writes: Dear editor, There is a typo about route-record AVP occurrence in AAA of section 5.1, it should be 0 rather than 0+ according to AAA definition of section 3.2. Thanks! BTW, the same error exists in RFC 4005, so you might consider filing an erratum with the RFC Editor. Regards, Hans ------=_NextPart_000_0033_01CB6C54.AF622A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

LIU Hans [mailto:Hans.Liu@alcatel-lucent.com] = writes:

 <= /o:p>

Dear editor,

 

There is a typo about route-record AVP occurrence = in AAA of section 5.1, it should be 0 rather than 0+ according to AAA definition = of section 3.2.

Thanks!  BTW, the same error exists in RFC 4005, so = you might consider filing an erratum with the RFC = Editor.

Regards,

Hans

------=_NextPart_000_0033_01CB6C54.AF622A90-- From sdecugis@nict.go.jp Thu Oct 14 20:45: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 183213A6A11 for ; Thu, 14 Oct 2010 20:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Inpaf6JqXYbz for ; Thu, 14 Oct 2010 20:45:18 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id DC1923A67B8 for ; Thu, 14 Oct 2010 20:45:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id DF20E9408E for ; Fri, 15 Oct 2010 05:46:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PekmdLjwy67 for ; Fri, 15 Oct 2010 05:46:29 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 609749408C for ; Fri, 15 Oct 2010 05:46:28 +0200 (CEST) Message-ID: <4CB7CE73.2030800@nict.go.jp> Date: Fri, 15 Oct 2010 12:45:55 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: dime@ietf.org References: <003201cb6c1a$03035290$0909f7b0$@net> In-Reply-To: <003201cb6c1a$03035290$0909f7b0$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 03:45:22 -0000 Hello, > There is a typo about route-record AVP occurrence in AAA of section > 5.1, it should be 0 rather than 0+ according to AAA definition of > section 3.2. > > Thanks! BTW, the same error exists in RFC 4005, so you might consider > filing an erratum with the RFC Editor. > I respectfully disagree here. I think it makes sense to have Route-Record AVP in answers as a general rule in Diameter. Moreover, section 3.2 does not disallow it since the "*[AVP]" line appears in the ABNF. An, finally, I see no reason why AAA command only would be different from the other commands, with regard to an AVP that pertains to base protocol behavior. The typo fix, if needed, might be to add *[Route-Record] in the AAA ABNF? My 2 cents, Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Thu Oct 14 21:21: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 AEDBB3A6A6B for ; Thu, 14 Oct 2010 21:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od3CtfWPyY5S for ; Thu, 14 Oct 2010 21:21:00 -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 6B1543A68BA for ; Thu, 14 Oct 2010 21:21:00 -0700 (PDT) Received: (qmail 580 invoked from network); 15 Oct 2010 04:22:19 -0000 Received: from unknown (124.120.110.16) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 15 Oct 2010 04:22:18 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <003201cb6c1a$03035290$0909f7b0$@net> <4CB7CE73.2030800@nict.go.jp> In-Reply-To: <4CB7CE73.2030800@nict.go.jp> Date: Fri, 15 Oct 2010 11:21:46 +0700 Organization: Network Zen Message-ID: <005f01cb6c20$7cda36a0$768ea3e0$@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: ActsG5WZgf+ed0KCQPqGkH9t/zkirQAAn2aQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 04:21:02 -0000 Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello, > > > There is a typo about route-record AVP occurrence in AAA of section > > 5.1, it should be 0 rather than 0+ according to AAA definition of > > section 3.2. > > > > Thanks! BTW, the same error exists in RFC 4005, so you might consider > > filing an erratum with the RFC Editor. > > > > I respectfully disagree here. I think it makes sense to have > Route-Record AVP in answers as a general rule in Diameter. Moreover, > section 3.2 does not disallow it since the "*[AVP]" line appears in the > ABNF. An, finally, I see no reason why AAA command only would be > different from the other commands, with regard to an AVP that pertains > to base protocol behavior. > > The typo fix, if needed, might be to add *[Route-Record] in the AAA > ABNF? OK. The problem is that, AFAICT, Route-Record isn't specifically included in any other answer command. In fact, the AVP is specifically prohibited in all of the answer messages defined in RFC 3588, the statement in the final paragraph of Section 3 of that document notwithstanding. > > My 2 cents, > Best regards, > 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 gwz@net-zen.net Thu Oct 14 21:45: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 71DC63A6AA7 for ; Thu, 14 Oct 2010 21:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gPytYtlpfx9 for ; Thu, 14 Oct 2010 21:45:25 -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 438C33A6AA3 for ; Thu, 14 Oct 2010 21:45:25 -0700 (PDT) Received: (qmail 1471 invoked from network); 15 Oct 2010 04:40:05 -0000 Received: from unknown (124.120.110.16) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 15 Oct 2010 04:40:04 -0000 From: "Glen Zorn" To: "'IETF Discussion'" References: In-Reply-To: Date: Fri, 15 Oct 2010 11:39:28 +0700 Organization: Network Zen Message-ID: <006001cb6c22$f83c2450$e8b46cf0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CB6C5D.A49AFC50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActsFk4yOKHzGoYXSymgBgxw/SziGwADH3Jw Content-Language: en-us Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, 'LIU Hans' Subject: Re: [Dime] Mail regarding 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: Fri, 15 Oct 2010 04:45:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0061_01CB6C5D.A49AFC50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Including the IETF list because the draft in question is in IETF LC. Hope this helps. ~gwz From: LIU Hans [mailto:Hans.Liu@alcatel-lucent.com] Sent: Friday, October 15, 2010 10:09 AM To: draft-ietf-dime-rfc3588bis@tools.ietf.org Subject: Mail regarding draft-ietf-dime-rfc3588bis Dear editors, Seems the Route-Record AVP in figure 6 are shown with wrong values, I have correctness attached based on my understanding, appreciate your fixing it in future version. Regards, Hans ------=_NextPart_000_0061_01CB6C5D.A49AFC50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Including the IETF list because the draft in question is = in IETF LC.

 

Hope this helps.

 

 ~gwz

 

From:= LIU Hans [mailto:Hans.Liu@alcatel-lucent.com]
Sent: Friday, October 15, 2010 10:09 AM
To: draft-ietf-dime-rfc3588bis@tools.ietf.org
Subject: Mail regarding = draft-ietf-dime-rfc3588bis

 

Dear editors,

 

Seems the Route-Record AVP in figure 6 are shown = with wrong values, I have correctness attached based on my understanding, = appreciate your fixing it in future version.

 

Regards,

Hans

------=_NextPart_000_0061_01CB6C5D.A49AFC50-- From sdecugis@nict.go.jp Thu Oct 14 22:27: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 B755B3A6A65 for ; Thu, 14 Oct 2010 22:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dODEq+7Vi5tb for ; Thu, 14 Oct 2010 22:27:37 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 21B4E3A68B6 for ; Thu, 14 Oct 2010 22:27:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 102F59409D; Fri, 15 Oct 2010 07:28:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHwPDc5zWvFG; Fri, 15 Oct 2010 07:28:50 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 5DD2A9408E; Fri, 15 Oct 2010 07:28:49 +0200 (CEST) Message-ID: <4CB7E672.8090907@nict.go.jp> Date: Fri, 15 Oct 2010 14:28:18 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Glen Zorn References: <003201cb6c1a$03035290$0909f7b0$@net> <4CB7CE73.2030800@nict.go.jp> <005f01cb6c20$7cda36a0$768ea3e0$@net> In-Reply-To: <005f01cb6c20$7cda36a0$768ea3e0$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 05:27:40 -0000 Hi again, thank you for the fast answer. > OK. The problem is that, AFAICT, Route-Record isn't specifically included > in any other answer command. In fact, the AVP is specifically prohibited in > all of the answer messages defined in RFC 3588, the statement in the final > paragraph of Section 3 of that document notwithstanding. My apologies, I was mistakingly believing that the previous discussions on this topic had lead to the adoption of Route-Record AVPs in answers. Please disregard my previous comment... References: http://www.ietf.org/mail-archive/web/dime/current/msg01542.html http://www.ietf.org/mail-archive/web/dime/current/msg03402.html Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Thu Oct 14 22:42: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 789643A6C50 for ; Thu, 14 Oct 2010 22:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akrrfQRQdH9w for ; Thu, 14 Oct 2010 22:42:08 -0700 (PDT) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id 5AF903A6BD6 for ; Thu, 14 Oct 2010 22:37:21 -0700 (PDT) Received: (qmail 30173 invoked from network); 15 Oct 2010 05:36:46 -0000 Received: from unknown (124.120.110.16) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 15 Oct 2010 05:36:46 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <003201cb6c1a$03035290$0909f7b0$@net> <4CB7CE73.2030800@nict.go.jp> <005f01cb6c20$7cda36a0$768ea3e0$@net> <4CB7E672.8090907@nict.go.jp> In-Reply-To: <4CB7E672.8090907@nict.go.jp> Date: Fri, 15 Oct 2010 12:36:13 +0700 Organization: Network Zen Message-ID: <007701cb6c2a$e39cee50$aad6caf0$@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: ActsKd7xLI1MO7hbRVCj8e7HnaCEmQAAMx1w Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 05:42:19 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hi again, thank you for the fast answer. > > > OK. The problem is that, AFAICT, Route-Record isn't specifically > included > > in any other answer command. In fact, the AVP is specifically > prohibited in > > all of the answer messages defined in RFC 3588, the statement in the > final > > paragraph of Section 3 of that document notwithstanding. > My apologies, I was mistakingly believing that the previous discussions > on this topic had lead to the adoption of Route-Record AVPs in answers. I'm not at all sure that you were mistaken about that, but no such decision has been reflected in the draft. > Please disregard my previous comment... > > References: > http://www.ietf.org/mail-archive/web/dime/current/msg01542.html > http://www.ietf.org/mail-archive/web/dime/current/msg03402.html > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Thu Oct 14 22:43: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 AEA853A6A75 for ; Thu, 14 Oct 2010 22:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Y1TDdL42PK for ; Thu, 14 Oct 2010 22:43:57 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 2C8493A68B2 for ; Thu, 14 Oct 2010 22:43:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id D417B9409D; Fri, 15 Oct 2010 07:45:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaJwuHsOF9PL; Fri, 15 Oct 2010 07:45:00 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 4E9829404D; Fri, 15 Oct 2010 07:44:59 +0200 (CEST) Message-ID: <4CB7EA3C.2050705@nict.go.jp> Date: Fri, 15 Oct 2010 14:44:28 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Glen Zorn References: <003201cb6c1a$03035290$0909f7b0$@net> <4CB7CE73.2030800@nict.go.jp> <005f01cb6c20$7cda36a0$768ea3e0$@net> <4CB7E672.8090907@nict.go.jp> <007701cb6c2a$e39cee50$aad6caf0$@net> In-Reply-To: <007701cb6c2a$e39cee50$aad6caf0$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 05:43:58 -0000 > I'm not at all sure that you were mistaken about that, but no such decision > has been reflected in the draft. Sure. I was referring to older discussions (unrelated to this draft). BTW, there is the same typo on the AC-Answer: ABNF in 3.10, AVP occurence table in 5.2.1. Route-Record AVP has been removed from ACA in RFC3588bis, so you might want to reflect the same in 4005bis. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Thu Oct 14 23:08:25 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE44C3A6B91 for ; Thu, 14 Oct 2010 23:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TBUGDTjOF6Uf for ; Thu, 14 Oct 2010 23:08:22 -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 408823A68B6 for ; Thu, 14 Oct 2010 23:08:02 -0700 (PDT) Received: by bwz14 with SMTP id 14so1233013bwz.31 for ; Thu, 14 Oct 2010 23:08:56 -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=GevJ14yxX740rK7ln0uczfk9Xznl2O2vXSs167W5D2A=; b=phCvi/ec8d4DhjBpFZzqIiSbTZVjfKP8r+pJxlJwGq4IrhcongZln4x4DFXtFasdwy JSL95lShkrRY3WAS0Kwx9qpdSa1t8JrKXgc0wWJKbd5HyHXyWP1ZATuyA/ngigNtIVe4 u2iqizUhDmB6WoOLcVX53dRznuG1VBtVRQ4zI= 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=eAAGz+QL3WIsqzhSjCTfQYY1aSHY0OUNrkEqLGlWjWDVYdWH9lHOgLBkQ8kPEdEa1Z h4pZnfxhq4nwYy0Src+hK/YQwmnBs2wtZnIKrltU+feL3m+KU0Cv12P5kET/tsUSHTOS OJEUVG1+FuhR6OM0IiZoJ/cM7uS2IV3OV851Q= Received: by 10.204.55.211 with SMTP id v19mr317470bkg.153.1287122935249; Thu, 14 Oct 2010 23:08:55 -0700 (PDT) Received: from a88-114-66-22.elisa-laajakaista.fi (a88-114-66-22.elisa-laajakaista.fi [88.114.66.22]) by mx.google.com with ESMTPS id x13sm11873737bki.12.2010.10.14.23.08.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Oct 2010 23:08:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <005f01cb6c20$7cda36a0$768ea3e0$@net> Date: Fri, 15 Oct 2010 09:08:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE680CF-5729-4CFE-B6D2-1B37DFBC7746@gmail.com> References: <003201cb6c1a$03035290$0909f7b0$@net> <4CB7CE73.2030800@nict.go.jp> <005f01cb6c20$7cda36a0$768ea3e0$@net> To: Glen Zorn X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 06:08:26 -0000 Hi, On Oct 15, 2010, at 7:21 AM, Glen Zorn wrote: > Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: >=20 >> Hello, >>=20 >>> There is a typo about route-record AVP occurrence in AAA of section >>> 5.1, it should be 0 rather than 0+ according to AAA definition of >>> section 3.2. >>>=20 >>> Thanks! BTW, the same error exists in RFC 4005, so you might = consider >>> filing an erratum with the RFC Editor. >>>=20 >>=20 >> I respectfully disagree here. I think it makes sense to have >> Route-Record AVP in answers as a general rule in Diameter. Moreover, >> section 3.2 does not disallow it since the "*[AVP]" line appears in = the >> ABNF. An, finally, I see no reason why AAA command only would be >> different from the other commands, with regard to an AVP that = pertains >> to base protocol behavior. >>=20 >> The typo fix, if needed, might be to add *[Route-Record] in the AAA >> ABNF? >=20 > OK. The problem is that, AFAICT, Route-Record isn't specifically = included > in any other answer command. In fact, the AVP is specifically = prohibited in > all of the answer messages defined in RFC 3588, the statement in the = final > paragraph of Section 3 of that document notwithstanding. Yes.. the hop-by-hop identifier is used for the return path according to = the Section 3 of RFC3588 and this is OK. However, the confusing thing in = RFC3588 is that other sections have RFC2119 language regarding = Route-Record in answers, which is confusing in general (see Section 2.10 = last paragraph). This is now fixed in RFC3588bis but AFAIR some other = SDO folks in past have decided to follow Section 2.10 "requirement" = which means there are issues ahead with their specification & = implementations.. or then not depending on how their ABNF defines = Route-Record in answers. - Jouni >=20 >>=20 >> My 2 cents, >> Best regards, >> Sebastien. >>=20 >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >>=20 >> _______________________________________________ >> 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 From gwz@net-zen.net Thu Oct 14 23:18: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 9FAA23A6A6D for ; Thu, 14 Oct 2010 23:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeN-XndswBvC for ; Thu, 14 Oct 2010 23:18:07 -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 D479F3A6A75 for ; Thu, 14 Oct 2010 23:18:04 -0700 (PDT) Received: (qmail 12458 invoked from network); 15 Oct 2010 06:19:25 -0000 Received: from unknown (124.120.110.16) by p3plsmtpa01-04.prod.phx3.secureserver.net (72.167.82.84) with ESMTP; 15 Oct 2010 06:19:24 -0000 From: "Glen Zorn" To: "'Glen Zorn'" , "'Sebastien Decugis'" References: <003201cb6c1a$03035290$0909f7b0$@net> <4CB7CE73.2030800@nict.go.jp> <005f01cb6c20$7cda36a0$768ea3e0$@net> <4CB7E672.8090907@nict.go.jp> <007701cb6c2a$e39cee50$aad6caf0$@net> In-Reply-To: <007701cb6c2a$e39cee50$aad6caf0$@net> Date: Fri, 15 Oct 2010 13:18:50 +0700 Organization: Network Zen Message-ID: <008b01cb6c30$d86aa990$893ffcb0$@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: ActsKd7xLI1MO7hbRVCj8e7HnaCEmQAAMx1wAAF02RA= Content-Language: en-us Cc: dime@ietf.org, 'IETF Discussion' Subject: Re: [Dime] Mail regarding draft-ietf-dime-rfc4005bis 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, 15 Oct 2010 06:18:09 -0000 Glen Zorn [mailto://gwz@net-zen.net] writes: ... > > My apologies, I was mistakingly believing that the previous > discussions > > on this topic had lead to the adoption of Route-Record AVPs in > answers. > > I'm not at all sure that you were mistaken about that, but no such > decision > has been reflected in the draft. Sorry, I should have been more specific: what I _meant_ was "reflected in RFC3588bis". .. From root@core3.amsl.com Fri Oct 15 01:15: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 77E9C3A6860; Fri, 15 Oct 2010 01:15: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: <20101015081502.77E9C3A6860@core3.amsl.com> Date: Fri, 15 Oct 2010 01:15:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-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: Fri, 15 Oct 2010 08:15: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 Network Access Server Application Author(s) : G. Zorn Filename : draft-ietf-dime-rfc4005bis-01.txt Pages : 66 Date : 2010-10-15 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-ietf-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 Content-Type: Message/External-body; name="draft-ietf-dime-rfc4005bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-15010858.I-D@ietf.org> --NextPart-- From stefan.winter@restena.lu Fri Oct 15 05:27:56 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 03EFE3A6938 for ; Fri, 15 Oct 2010 05:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.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 BT+V2uU9n33S for ; Fri, 15 Oct 2010 05:27:54 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C8D33A68F3 for ; Fri, 15 Oct 2010 05:27:54 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2931410609 for ; Fri, 15 Oct 2010 14:29:15 +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 1632C10608 for ; Fri, 15 Oct 2010 14:29:15 +0200 (CEST) Message-ID: <4CB8491A.3070802@restena.lu> Date: Fri, 15 Oct 2010 14:29:14 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Subject: [Dime] Fwd: Re: Last Call: (Diameter Base, Protocol) to Proposed Standard 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, 15 Oct 2010 12:27:56 -0000 FYI, just in case my posting on ietf@ slipped through... -------- Original-Nachricht -------- Betreff: Re: Last Call: (Diameter Base, Protocol) to Proposed Standard Datum: Tue, 12 Oct 2010 13:49:45 +0200 Von: Stefan Winter An: 'IETF Discussion Mailing List' Hi, I was surprised to see the line "No IPR declarations were found that appear related to this I-D." in the message from ietf-announce. Its predecessor, RFC3588, has a filed IPR disclosure from Nokia, see https://datatracker.ietf.org/ipr/323/ A very long time ago, I looked into the patents in question, and they seemed to be related to the T-Bit (Diameter message command flag for "potentially re-transmitted message"). Page 35 in 3588bis still contains the T-Bit. As a naive non-legalese person, I would think that the same disclosure that applied to the T-Bit in 3588 also applies to the T-Bit in 3588bis then. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Rseau Tlinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From sunseawq@huawei.com Fri Oct 15 19:40: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 496A83A6992; Fri, 15 Oct 2010 19:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6DG5ZXB0Npb; Fri, 15 Oct 2010 19:40:50 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id EF64E3A63EB; Fri, 15 Oct 2010 19:40:49 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD00FFJ3GLP1@szxga02-in.huawei.com>; Sat, 16 Oct 2010 10:41:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAD00FGX3GLJG@szxga02-in.huawei.com>; Sat, 16 Oct 2010 10:41:09 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAD001SA3GKIL@szxml04-in.huawei.com>; Sat, 16 Oct 2010 10:41:09 +0800 (CST) Date: Sat, 16 Oct 2010 10:41:08 +0800 From: Qin Wu To: hokey@ietf.org, dime@ietf.org Message-id: <036801cb6cdb$96a42ad0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_JWAM9fDuRNDswJTk/pSrtQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] ERP with one ER server vs ERP with multiple ER servers 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, 16 Oct 2010 02:40:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JWAM9fDuRNDswJTk/pSrtQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, As described in RFC5296,ERP can be performed in two different ways: a) ERP with one ER server b) ERP with multiple ER servers As for a), RFC5296 allows three different use cases case 1: Peer -> ER authenticator -> Local ER server case 2: Peer -> ER authenticator -> home ER server case 3: Peer -> EAP authenticator/ER authenticator ->Local ER server -> Home EAP server case 3 also can be called as ER implicit bootstapping As for b), RFC5296 allows the following use case: case 4: Peer -> ER authenticator -> local ER server -> home ER server If the peer run ERP exchange with bootstapping flag on, case 4 calso can be called as ER explicit bootstapping. I was thinking why we SHOULD allow ERP with multiple ER servers? Since case 3 can be utilized to push DSRK to the local ER server and the peer can choose to run local ERP exchange with local ER server, why we need case 4. Why not restrict the ERP with only one ER server or the ERP with the local ER server in the domain as the peer? Also if you read the last paragraph of section 5.3.2.1 of RFC5296 " If the peer has already initiated an ERP exchange with the home ER server, it MAY choose to not start an ERP exchange with the local ER server. " You will find this paragph is contradict with the case 4 (Peer -> ER authenticator -> local ER server -> home ER server ) and description of section 5.1 of RFC5296. " it SHOULD initiate ERP bootstrap exchange (ERP exchange with the bootstrap flag turned on) with *the home ER server * to obtain the domain name. The *local ER server* behavior is the same as described above. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server. " In order to address this issue, we may have two choice to avoid overdesign for ERP a) restrict the ERP with only one ER server b) the ERP with the local ER server in the domain as the peer Personally I prefer the choice a), becos few changes are needed for RFC5296. Regards! -Qin --Boundary_(ID_JWAM9fDuRNDswJTk/pSrtQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
As described in RFC5296,ERP can be performed in two different ways:
a) ERP with one ER server
b) ERP with multiple ER servers
 
As for a), RFC5296 allows three different use cases
case 1: Peer -> ER authenticator -> Local ER server
case 2: Peer -> ER authenticator -> home ER server
case 3: Peer -> EAP authenticator/ER authenticator ->Local ER server -> Home EAP server
case 3 also can be called as ER implicit bootstapping
 
As for b), RFC5296 allows the following use case:
case 4: Peer -> ER authenticator -> local ER server -> home ER server
If the peer run ERP exchange with bootstapping flag on, case 4 calso can be called as ER explicit bootstapping.
I was thinking why we SHOULD allow ERP with multiple ER servers?
Since case 3 can be utilized to push DSRK to the local ER server and the peer can choose to run local ERP exchange
with local ER server, why we need case 4. Why not restrict the ERP with only one ER server or the ERP with the local ER server
in the domain as the peer?
 
Also if you read the last paragraph of section 5.3.2.1 of RFC5296
"
   If the peer has already
   initiated an ERP exchange with the home ER server, it MAY choose to
   not start an ERP exchange with the local ER server.
"
You will find this paragph is contradict with the case 4 (Peer -> ER authenticator -> local ER server -> home ER server ) and description of section 5.1 of RFC5296.
"
   it SHOULD initiate ERP bootstrap exchange (ERP exchange with
   the bootstrap flag turned on) with *the home ER server * to obtain the
   domain name.  The *local ER server* behavior is the same as described
   above.  The peer MAY also initiate bootstrapping to fetch information
   such as the rRK lifetime from the AAA server.
"
In order to address this issue, we may have two choice to avoid overdesign for ERP
a) restrict the ERP with only one ER server
b) the ERP with the local ER server in the domain as the peer
Personally I prefer the choice a), becos few changes are needed for RFC5296.
 
 
Regards!
-Qin
 
 
 
 
--Boundary_(ID_JWAM9fDuRNDswJTk/pSrtQ)-- From root@core3.amsl.com Sat Oct 16 04: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 0D36C3A6822; Sat, 16 Oct 2010 04: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: <20101016110002.0D36C3A6822@core3.amsl.com> Date: Sat, 16 Oct 2010 04:00:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nat-control-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: Sat, 16 Oct 2010 11: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 Network Address and Port Translation Control Application Author(s) : F. Brockners, et al. Filename : draft-ietf-dime-nat-control-04.txt Pages : 42 Date : 2010-10-16 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of large scale Network Address Translators and Network Address and Port Translators, which are added to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows large scale Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-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-nat-control-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-16034847.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Oct 16 23:30:15 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 4D3DF3A6956; Sat, 16 Oct 2010 23: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: <20101017063009.4D3DF3A6956@core3.amsl.com> Date: Sat, 16 Oct 2010 23:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-local-keytran-08.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, 17 Oct 2010 06:30:16 -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-08.txt Pages : 8 Date : 2010-10-16 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-08.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-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-16231604.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Mon Oct 18 08:40: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 C0F4F3A6A56; Mon, 18 Oct 2010 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzsufdFZ7Iul; Mon, 18 Oct 2010 08:40:14 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id ABC223A6B3E; Mon, 18 Oct 2010 08:40:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="39519846" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 18 Oct 2010 11:41:43 -0400 X-IronPort-AV: E=Sophos;i="4.57,345,1283745600"; d="scan'208";a="527550325" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Oct 2010 11:41:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2010 17:41:20 +0200 Message-ID: In-Reply-To: <4CB44B59.4000607@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Diameter Base, Protocol) to Proposed Standard Thread-Index: ActqA5yMcrw49Pd0Sw2b8gQ+S1pkFQE1kvhQ References: <4CB44B59.4000607@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , "IETF Discussion Mailing List" Cc: dime@ietf.org Subject: Re: [Dime] Last Call: (Diameter Base, Protocol) to Proposed Standard 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, 18 Oct 2010 15:40:15 -0000 Hi Stefan, Thank you for the comment and sorry for the taking a few days to answer = this, but your comment generated some discussions within the IESG, which = are still ongoing.=20 There was no IPR disclosure made directly on = draft-ietf-dime-rfc3588bis-25.txt, and this is why the IETF LC does not = mention any. This may be a miss in the case of 'bis' documents, and we = are discussing in the IETF whether our procedures need not be modified = to cover such cases. For the specific case I asked the IESG secretary to = contact the submitters of the IPR disclosure on RFC 3588 and check with = them whether they believe that the IPR also applies to = draft-ietf-dime-rfc3588bis-25.txt.=20 Regards, Dan > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Stefan Winter > Sent: Tuesday, October 12, 2010 1:50 PM > To: 'IETF Discussion Mailing List' > Subject: Re: Last Call: =20 > (Diameter Base,Protocol) to Proposed Standard >=20 >=20 > Hi, >=20 > I was surprised to see the line "No IPR declarations were=20 > found that appear related to this I-D." in the message from=20 > ietf-announce. Its predecessor, RFC3588, has a filed IPR=20 > disclosure from Nokia, see >=20 > https://datatracker.ietf.org/ipr/323/ >=20 > A very long time ago, I looked into the patents in question,=20 > and they seemed to be related to the T-Bit (Diameter message=20 > command flag for "potentially re-transmitted message"). >=20 > Page 35 in 3588bis still contains the T-Bit. As a naive=20 > non-legalese person, I would think that the same disclosure=20 > that applied to the T-Bit in 3588 also applies to the T-Bit=20 > in 3588bis then. >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20 > Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From ravikgvs@gmail.com Tue Oct 19 10:54: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 2B0FB3A68B2 for ; Tue, 19 Oct 2010 10:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbUU6s+w-CCk for ; Tue, 19 Oct 2010 10:54:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 09CB53A68B0 for ; Tue, 19 Oct 2010 10:54:38 -0700 (PDT) Received: by iwn10 with SMTP id 10so3051077iwn.31 for ; Tue, 19 Oct 2010 10:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=X+0kw3VP4oXqfFpR6FkNVPhAUX+8GVoDyMLPSDEdYvw=; b=Y4QYV3uf9YthDBUVD93bI1iDhmojKaDdQYn0F45tyfkwWzg458YQC09wzkxLMuM5zR wr9pMkKQrmEzcPq0r5NvsUUmkv5CNadVI28tHGhPnFzOT6gZPPE6I2DVx+rmH4+e8Kms I0UTkoD+o8tv/rjgkEb9kLmLYfs7GmFWvlzE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=dwFXdCL9XU3qLA7WTKR8JGpknAAi3b+w1xsiIFcFBvDU75NJrEweElwA4hMG2tm6xN ZPtPSvadtvp2Tg4MmeQkUXcP46ZZiiEvekiqSOSbMjCXkwQIpkNX7rVlRTHp92XPhfn9 LlJl7UALfiTtub2fA4difUhrovuAYnERKccPI= MIME-Version: 1.0 Received: by 10.231.19.3 with SMTP id y3mr5136372iba.156.1287510970133; Tue, 19 Oct 2010 10:56:10 -0700 (PDT) Received: by 10.231.167.202 with HTTP; Tue, 19 Oct 2010 10:56:09 -0700 (PDT) Date: Tue, 19 Oct 2010 10:56:09 -0700 Message-ID: From: Ravi Gunturu To: dime@ietf.org Content-Type: multipart/alternative; boundary=00221532cc5c04ede60492fc0290 X-Mailman-Approved-At: Tue, 19 Oct 2010 13:31:34 -0700 Cc: Ravi Gunturu Subject: [Dime] [DIME]diameter client failover and retransmission 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, 19 Oct 2010 17:58:14 -0000 --00221532cc5c04ede60492fc0290 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a question on the diameter client failover. Let us assume there are two nodes Active(C1, origin-host:H1) and Standby(C2, origin-host:H2) diameter clients and have successfully established connections with the diameter server S1. Client C1 also has active sessions with server S1 that were originally established from C1. My question is when C1 fails over to C2, Can C2 send CCR updates on these sessions with the origin-host of C2? If the answer to the above question is yes, How will the retransmission work from C2? According to RFC 3588, On the Server, the duplicate messages are detected by the combination of End-to-End identifier and Origin-Host(section 3, page 33). Is it OK for C2 to retransmit the message with the T-flag set, the same End-to-End identifier and a different origin-Host? What would be the server behavior in this case, Would it take it as a duplicate message? Please note that both the active and standby diameter nodes have connections always on from their respective origin-host IDs, when the failover happens the standby client would start right away working on the sessions without having to wait to reestablish the connection. Thanks in advance, Ravi --00221532cc5c04ede60492fc0290 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have a question on the diameter client failover. Let us assume= there are two nodes Active(C1, origin-host:H1) and Standby(C2, origin-host= :H2) diameter clients and have successfully established connections with th= e diameter server S1.=A0 Client C1 also has active sessions with server S1 = that were originally established from C1. My question is when C1 fails over= to C2, Can C2 send CCR updates on these sessions with the origin-host of C= 2?

If the answer to the above question is yes, How will the retransmission= work from C2?=A0=A0

According to RFC 3588, On the Server, the dupl= icate messages are detected by the combination of End-to-End identifier and= Origin-Host(section 3, page 33). Is it OK=A0 for C2 to retransmit the mess= age with the T-flag set, the same End-to-End identifier and a different ori= gin-Host? What would be the server behavior in this case, Would it take it = as a duplicate message?

Please note that both the active and standby diameter nodes have connec= tions always on from their respective origin-host IDs, when the failover ha= ppens the standby client would start right away working on the sessions wit= hout having to wait to reestablish the connection.

Thanks in advance,
Ravi
--00221532cc5c04ede60492fc0290-- From trac@tools.ietf.org Wed Oct 20 02:12: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 E6FA73A6820 for ; Wed, 20 Oct 2010 02:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2fmmsO2N6uA for ; Wed, 20 Oct 2010 02:12:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9BDF13A67DA for ; Wed, 20 Oct 2010 02:12:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P8UkJ-0002fZ-Ld; Wed, 20 Oct 2010 02:14:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: shwethab@cisco.com X-Trac-Project: dime Date: Wed, 20 Oct 2010 09:14:07 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/2#comment:1 Message-ID: <083.6a233f9a3efe6405284d00eddef4da6e@tools.ietf.org> References: <074.024b46fff52b5488900ccee06a808f5e@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <074.024b46fff52b5488900ccee06a808f5e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: shwethab@cisco.com, dime@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: Re: [Dime] [dime] nat-control #2 (closed): IPv4-only hosts in Fig 2, 3, 4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 09:12:36 -0000 #2: IPv4-only hosts in Fig 2, 3, 4 Changes (by shwethab@…): * status: new => closed * resolution: => fixed -- ----------------------------------------------+----------------------------- Reporter: lionel.morand@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: nat-control | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ----------------------------------------------+----------------------------- Ticket URL: dime From trac@tools.ietf.org Wed Oct 20 02:13: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 631303A6808 for ; Wed, 20 Oct 2010 02:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngx-vhzi3tub for ; Wed, 20 Oct 2010 02:13:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 241803A67DA for ; Wed, 20 Oct 2010 02:13:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P8Ulb-0003v6-9s; Wed, 20 Oct 2010 02:15:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: shwethab@cisco.com X-Trac-Project: dime Date: Wed, 20 Oct 2010 09:15:27 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/3#comment:1 Message-ID: <083.92972a769b380f51ca01bdfc8083c8d3@tools.ietf.org> References: <074.b69a11a3421642908b7bbc5d4a686704@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <074.b69a11a3421642908b7bbc5d4a686704@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: shwethab@cisco.com, dime@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: Re: [Dime] [dime] nat-control #3 (closed): Missing interface in figure 4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 09:13:58 -0000 #3: Missing interface in figure 4 Changes (by shwethab@…): * status: new => closed * resolution: => fixed -- ----------------------------------------------+----------------------------- Reporter: lionel.morand@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: nat-control | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ----------------------------------------------+----------------------------- Ticket URL: dime From trac@tools.ietf.org Wed Oct 20 02:14: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 EA1763A682E for ; Wed, 20 Oct 2010 02:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYsg2LuhRULW for ; Wed, 20 Oct 2010 02:14:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DB5143A6845 for ; Wed, 20 Oct 2010 02:14:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P8UmA-00053j-3P; Wed, 20 Oct 2010 02:16:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, shwethab@cisco.com X-Trac-Project: dime Date: Wed, 20 Oct 2010 09:16:02 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/8#comment:1 Message-ID: <073.fe22d400b3be8736dca93619d53584bd@tools.ietf.org> References: <064.8dc519dca77f5adff82cad892a62574a@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <064.8dc519dca77f5adff82cad892a62574a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, shwethab@cisco.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] [dime] nat-control #8 (closed): editorials for dime-nat-control-03 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 09:14:41 -0000 #8: editorials for dime-nat-control-03 Changes (by shwethab@…): * status: new => closed * resolution: => fixed Comment: Resolved in draft version 4 -- ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: nat-control | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dime From dromasca@avaya.com Wed Oct 20 08:17:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CF43A68D5 for ; Wed, 20 Oct 2010 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZiAadwCIi39 for ; Wed, 20 Oct 2010 08:17:28 -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 ADDE33A6847 for ; Wed, 20 Oct 2010 08:17:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,355,1283745600"; d="scan'208";a="243603022" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Oct 2010 11:19:01 -0400 X-IronPort-AV: E=Sophos;i="4.57,355,1283745600"; d="scan'208";a="528301752" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Oct 2010 11:19:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 17:18:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: Thread-Index: Actv2EE9VIHgCqUWSGePPpcZikDUJQAkdBkw From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: DISCUSS and COMMENT: 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, 20 Oct 2010 15:17:34 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Tuesday, October 19, 2010 11:53 PM To: iesg@ietf.org Cc: draft-ietf-dime-capablities-update@tools.ietf.org; dime-chairs@tools.ietf.org Subject: DISCUSS and COMMENT: Discuss: 1. Let me see if I understand this. The basic idea is that any two Diameter nodes can dynamically inform each other when their capabilities have changed, without forcing a reconnection. There are several kinds of capabilities that might change, such as (a) security mechanisms, (b) commands related to a particular application, and (c) the list of applications supported. It seems that several rules apply: (a) do not attempt to dynamically modify a security mechanism that is currently in use, because reconnection is required, (b) send updated commands related to a given application only to those peers which also support that application, and (c) send an updated list of supported applications to all peers [this seems to implicit]. Unfortunately, these rules are not explained very clearly, and certain matters are left unspecified: a. Is it OK to dynamically inform peers about capabilities security mechanisms that are *not* currently in use for that connection? b. When a node receives a Capabilities Update Request (CUR) from a peer, it needs to check if the two entities have any supported applications in common, and if not it SHOULD disconnect the transport connection. Why? Does this behavior protect against some unspecified threat? Does this behavior prevent two entities from exchanging a CUR that updates the list of supported applications (i.e., if they currently have no supported applications in common)? c. Is the Capabilities Update Application limited to informing peers about new/changed capabilities, or does it also assume that based on communication of those new/changed capabilities a peer MAY/SHOULD/MUST take action based on those modified capabilities (e.g., "modifying the security mechanism")? Comment: 1. In Section 4, there is a typo: "Attibute-Value" From root@core3.amsl.com Wed Oct 20 14:30:22 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6787E3A6864; Wed, 20 Oct 2010 14: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: <20101020213015.6787E3A6864@core3.amsl.com> Date: Wed, 20 Oct 2010 14:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-priority-avps-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: Wed, 20 Oct 2010 21:30:22 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Priority Attribute Value Pairs Author(s) : K. Carlberg, T. Taylor Filename : draft-ietf-dime-priority-avps-03.txt Pages : 7 Date : 2010-10-20 This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-priority-avps-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-priority-avps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-20142102.I-D@ietf.org> --NextPart-- From victor.pascual.avila@gmail.com Thu Oct 21 08:26:17 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 84A663A6910 for ; Thu, 21 Oct 2010 08:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 2exhxBIJts6q for ; Thu, 21 Oct 2010 08:26:15 -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 6EF7D3A67B7 for ; Thu, 21 Oct 2010 08:26:15 -0700 (PDT) Received: by bwz12 with SMTP id 12so465099bwz.31 for ; Thu, 21 Oct 2010 08:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Eu7opaxJ5CnYb0jYx5C+PevOMCVyWbZxJRT3SwQPxJI=; b=VBsDHKjpNPOwYfU+dTMhLlEThIEv+WIK/1/SVbnSfPdcxLXZmDw35PVpu+0ehvOybB KEse2ULEhc64no2CrwqKpFTcBrsosBYdU6bqB9h6tDHj5SDWU9RDDl/g3GDukTfcsCvJ vOIiFaiTOtpiXKKdr/HWrfvt7NuT6I3mLvc14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qgGN+fqor4TpVTnx2PAQv6xwVY0xk6I/w+NFaUNpjmljX3Ta6wjIYkva4FEdWvcPTj +EpyvNxmwjKadRvVLdfTvu9hX6kxMjMntVILc9GWJQtvwlx6sfdnVT+Kww1KHHv6W+gn 4cVEfvYuix+EaRnMpmcU6FwlrfPOW/8Z0JRis= MIME-Version: 1.0 Received: by 10.204.60.212 with SMTP id q20mr880042bkh.26.1287674870439; Thu, 21 Oct 2010 08:27:50 -0700 (PDT) Received: by 10.204.81.76 with HTTP; Thu, 21 Oct 2010 08:27:50 -0700 (PDT) Date: Thu, 21 Oct 2010 17:27:50 +0200 Message-ID: From: Victor Pascual Avila To: dime@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport 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, 21 Oct 2010 15:26:17 -0000 Hello, If you don't mind I have some comments on draft-ietf-dime-rfc3588bis and SCTP transport. Making the long story short, I believe RFC3588bis shall discuss the implications of using Diameter over SCTP transport and its associated security mechanisms. There are some aspects I'd like to discuss: -SCTP USAGE- 1) SCTP Payload Protocol Identifier for Diameter: IMO no SCTP identifier needs to be defined for Diameter messages. Therefore, the PPI in SCTP DATA chunks transporting Diameter messages MUST be set to zero. I think this should be documented 2) Mapping of Diameter messages into SCTP Streams: the current version of the draft states that "All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking". Well, mapping diameter messages into different SCTP streams could be one way to prevent HOL blocking but some increase of processing delay might be incurred. However, sending every Diameter message via the SCTP Stream ID zero with the =E2=80=9Cunordered=E2=80=9D fl= ag set may lead to improved performance and simplicity. I'd suggest something like: "Diameter messages need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking. Among the different ways of performing the mapping that fulfill this requirement, the simplest alternative is proposed; a Diameter entity SHOULD send every Diameter message (request or response) over stream zero with the unordered flag set. On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream. Although both sides of the SCTP association SHOULD use stream 0 for Diameter requests and responses if they follow this recommendation, if a Diameter request arrives over a particular stream, the server is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. This avoids undesirable collisions when seizing a particular stream". This is how SIP over SCTP works. -SECURITY MECHANISMS- 3) According to draft-ietf-dime-rfc3588bis, the use of a secured transport for exchanging Diameter messages is mandatory, being TLS the primary method and IPsec a secondary alternative. However, it is assumed that TLS is run on top of TCP when it is used, leaving IPsec as the only mechanism to secure Diameter messages. Is that the expected outcome? 4) TLS over SCTP usage: As exposed in draft-ietf-tsvwg-dtls-for-sctp, TLS over SCTP (RFC3436) has some serious limitations. In order to overcome these limitations, I believe Diameter over DTLS/SCTP shall be proposed as an alternative to TLS/SCTP. To my best knowledge, the IESG has recently approved DTLS over SCTP as a Proposed Standard and it will be published as a Standards Track RFC. However, I'd agree that until DTLS/SCTP gets widely adopted by the industry, we'll find IPsec as the common deployed mechanism to secure Diameter messages (please, see comment 6). 5) If draft-ietf-tsvwg-dtls-for-sctp gets adopted as a security mechanism for Diameter: 5.1) it should be documented somewhere that no SCTP identifier needs to be defined for Diameter messages over DTLS. Therefore, the Payload Protocol Identifier in SCTP DATA chunks transporting DTLS-based Diameter messages MUST be set to zero 5.2) a port number should be assigned 5.3) the S-NAPTR Application Protocol Tag for DTLS/SCTP (say, diameter.dtls.sctp) should be registered 6) Diameter over SCTP over IPsec usage: I believe some guidelines on this would be beneficial. Would it be ok to create an association and SPD selector for each SCTP IP Address and port involved in an association, treating SCTP as any other layer above IP, and thus potentially creating multiple entries for a single SCTP association? IMO implementations MUST at least support this mode (if they support Diameter over SCTP over IPsec). I believe RFC3554 (SCTP with IPsec) is unnecessary for Diameter applications, both because of the relatively low number of Diameter connections per system, and because one of the main advantages of SCTP is multi-homing across interfaces which makes RFC3554 potentially impossible to implement. I'm planning to put these ideas together in a short draft, but would like to hear your take on them. Many thanks in advance, Victor Pascual From dromasca@avaya.com Thu Oct 21 10:55:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926413A699A for ; Thu, 21 Oct 2010 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgkWOKpVYagR for ; Thu, 21 Oct 2010 10:55:32 -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 7CD1C3A68F3 for ; Thu, 21 Oct 2010 10:55:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="243916635" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2010 13:57:08 -0400 X-IronPort-AV: E=Sophos;i="4.58,218,1286164800"; d="scan'208";a="528803863" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2010 13:57:08 -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, 21 Oct 2010 19:56:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-capablities-update-06 in Revised ID Needed Thread-Index: ActxSVN1rgmupvJYQ5y7ZXk+02M2VA== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] draft-ietf-dime-capablities-update-06 in Revised ID Needed 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, 21 Oct 2010 17:55:33 -0000 The IESG discussed today draft-ietf-dime-capablities-update-06 and decided that more discussions between the editors (specifically Glen) and the ADs who entered the four currently pending DISCUSSes is necessary and a revised ID is needed to solve these DISCUSSes. Glen and the rest of the WG - please work on this.=20 Thanks and Regards, Dan From gwz@net-zen.net Thu Oct 21 16:25: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 B5D0C3A67E4 for ; Thu, 21 Oct 2010 16:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52be4Cn5o0U7 for ; Thu, 21 Oct 2010 16:25:04 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id AA4FE3A67F3 for ; Thu, 21 Oct 2010 16:24:43 -0700 (PDT) Received: (qmail 26662 invoked from network); 21 Oct 2010 23:26:19 -0000 Received: from unknown (124.120.175.221) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 21 Oct 2010 23:26:18 -0000 From: "Glen Zorn" To: Date: Fri, 22 Oct 2010 06:25:51 +0700 Organization: Network Zen Message-ID: <000301cb7177$4f20aee0$ed620ca0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: ActxVkKtYpsazGcRRoaHi3xtW2663gAIPyjg Subject: [Dime] FW: New Non-WG Mailing List: oud -- Operational Uses of Diameter 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, 21 Oct 2010 23:25:06 -0000 FYI -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] Sent: Friday, October 22, 2010 2:28 AM To: IETF Announcement list Cc: oud@ietf.org; gwz@net-zen.net Subject: New Non-WG Mailing List: oud -- Operational Uses of Diameter A new IETF non-working group email list has been created. List address: oud@ietf.org -- Operational Uses of Diameter Archive: http://www.ietf.org/mail-archive/web/oud/ To subscribe: https://www.ietf.org/mailman/listinfo/oud Description: Discussions of operational uses of Diameter (i.e., uses not directly related to user AAA). Examples might include Diameter database query and state synchronization between Diameter nodes. For additional information, please contact the list administrators. From root@core3.amsl.com Thu Oct 21 17: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 B849D3A67DB; Thu, 21 Oct 2010 17: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: <20101022004501.B849D3A67DB@core3.amsl.com> Date: Thu, 21 Oct 2010 17:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nat-control-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 00:45:01 -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 Network Address and Port Translation Control Application Author(s) : F. Brockners, et al. Filename : draft-ietf-dime-nat-control-05.txt Pages : 42 Date : 2010-10-21 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-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-nat-control-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-21173143.I-D@ietf.org> --NextPart-- From sdecugis@nict.go.jp Thu Oct 21 22:15: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 F3BCF3A67D3 for ; Thu, 21 Oct 2010 22:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHWz32kgr2A3 for ; Thu, 21 Oct 2010 22:15:26 -0700 (PDT) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id 3AC743A686B for ; Thu, 21 Oct 2010 22:15:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 624BD94375 for ; Fri, 22 Oct 2010 07:16:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgPSwHCwLz7f for ; Fri, 22 Oct 2010 07:16:54 +0200 (CEST) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id AD27694080 for ; Fri, 22 Oct 2010 07:16:53 +0200 (CEST) Message-ID: <4CC11E20.1030109@nict.go.jp> Date: Fri, 22 Oct 2010 14:16:16 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport 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, 22 Oct 2010 05:15:29 -0000 Hello Victor, I find your comments very useful. From an implementor point of view, the current draft leaves a lot of unclear aspects on how the SCTP transport should be implemented, and this will surely result in many un-interoperable choices. 2) IIUC, the unordered delivery is not compatible with TLS/SCTP. Therefore, if this recommendation is made, TLS/SCTP (which is clearly a resource-killer) should be deprecated at the same time (as you highlight in 4) ) 3) In addition to what you show, the document also recommends SCTP over TCP... This is quite contradictory... 5.2) I believe the same port as Diameter / TLS / TCP could be used, right? Or is this too confusing? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From victor.pascual.avila@gmail.com Thu Oct 21 23:51: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 CDDAC3A6782 for ; Thu, 21 Oct 2010 23:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 cuHRVrulULcp for ; Thu, 21 Oct 2010 23:51:15 -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 5BB3C3A6405 for ; Thu, 21 Oct 2010 23:51:15 -0700 (PDT) Received: by bwz12 with SMTP id 12so1099567bwz.31 for ; Thu, 21 Oct 2010 23:52:52 -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=t14SQFlBRLAS2u2thFQfkG52C/j0JAwzEdOdIOh0wMA=; b=uV8MbQR5V+80SlrC6x5n6P3feigtf+U2hnDA1s00Q3L4Tt7TnoNgptF3/s4cCmwZ/w V+VupXxe9+SIlyzsAlt2rGysZayDo8JVjIxbqsKjUB+7JIXHHNNtlnDG/sP40X+zMsAv lCRqJAWkzHA+JKSwygtQ8kDXZv6tbJC4gnORY= 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=P6s8vllZowN7raj98V22h9AWnmzZcWyFXzIMkU+UqXtSk1CJ86tv84d070bDPpHNKb Jcatc3AATwnZv0v+HTy7MuOW4o3XP0lzx9LJpvPxKvEt0TLf1YrYGX+JefBLSceeGsDW xov4PXh1ngzBqXflvyd1wPLdbkHOQzuTCTzWM= MIME-Version: 1.0 Received: by 10.204.112.207 with SMTP id x15mr1528400bkp.194.1287730372060; Thu, 21 Oct 2010 23:52:52 -0700 (PDT) Received: by 10.204.81.76 with HTTP; Thu, 21 Oct 2010 23:52:52 -0700 (PDT) In-Reply-To: <4CC11E20.1030109@nict.go.jp> References: <4CC11E20.1030109@nict.go.jp> Date: Fri, 22 Oct 2010 08:52:52 +0200 Message-ID: From: Victor Pascual Avila To: Sebastien Decugis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Comments on draft-ietf-dime-rfc3588bis and SCTP transport 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, 22 Oct 2010 06:51:16 -0000 Hi Sebastien, thanks for your feedback! Please find some notes inline. On Fri, Oct 22, 2010 at 7:16 AM, Sebastien Decugis wr= ote: (snip) > 2) IIUC, the unordered delivery is not compatible with TLS/SCTP. > Therefore, if this recommendation is made, TLS/SCTP (which is clearly a > resource-killer) should be deprecated at the same time (as you highlight > in 4) ) Lack of support for unordered delivery is just one of the limitations of TLS/SCTP. Some others are documented in draft-ietf-tsvwg-dtls-for-sctp-06 > > 3) In addition to what you show, the document also recommends SCTP over > TCP... This is quite contradictory... IIRC it is assumed that TLS is run on top of TCP when it is used Cheers, --=20 Victor Pascual =C3=81vila From root@core3.amsl.com Sun Oct 24 08: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 145FC3A68B5; Sun, 24 Oct 2010 08: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: <20101024153004.145FC3A68B5@core3.amsl.com> Date: Sun, 24 Oct 2010 08:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-capablities-update-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 15: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 : The Diameter Capabilities Update Application Author(s) : J. Kang, G. Zorn Filename : draft-ietf-dime-capablities-update-07.txt Pages : 7 Date : 2010-10-24 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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-capablities-update-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-24082500.I-D@ietf.org> --NextPart-- From ravikgvs@gmail.com Sun Oct 24 14:59: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 DC9603A6774 for ; Sun, 24 Oct 2010 14:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.429, 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 Ko0tYPd9axiz for ; Sun, 24 Oct 2010 14:59:32 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E7C193A6452 for ; Sun, 24 Oct 2010 14:59:31 -0700 (PDT) Received: by iwn40 with SMTP id 40so2931314iwn.31 for ; Sun, 24 Oct 2010 15:01: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=A+Wi6KOWANmTZXRPfj/aX3iwx6UL902iERY+nRv+ajU=; b=EGndjnXofmSLBLsxM3kGqxClHwaCrITa0qpZgbO5I/GIp7fhciKj4Dc1aXXxbgfenk IZE+Y+udm4axAU4b1YMuYDNr8VwxN4msRmFk8b65DDWP1l6IVz6GVHRaWBDJFzB3OELI HeJx0V/JWXH4RhxgVP5ByT7FDbbs8Voapk4co= 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=CxAFXqVUKg/CfRcCfXA+s8U4yQ27zmEQNpXmdCm+pnSrVOYnkN+87PS383669XrHj2 PubbB9WPRyqRxB9+gBkmeQQ34HxxfyjBIrYjTgpxB+0j1G3MnqNa2DBcF/tz+GphA1ou 17eVJiMjC+wYBbw/0cwWeUmS9dyd0NQmUdZ1g= MIME-Version: 1.0 Received: by 10.42.150.73 with SMTP id z9mr4270243icv.348.1287957675073; Sun, 24 Oct 2010 15:01:15 -0700 (PDT) Received: by 10.231.158.83 with HTTP; Sun, 24 Oct 2010 15:01:15 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Oct 2010 15:01:15 -0700 Message-ID: From: Ravi Gunturu To: dime@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e8eccb560da049364034f Subject: Re: [Dime] [DIME]diameter client failover and retransmission 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, 24 Oct 2010 21:59:33 -0000 --90e6ba6e8eccb560da049364034f Content-Type: text/plain; charset=ISO-8859-1 Could someone please respond to the question below? Thanks, Ravi On Tue, Oct 19, 2010 at 10:56 AM, Ravi Gunturu wrote: > Hi, > > I have a question on the diameter client failover. Let us assume there are > two nodes Active(C1, origin-host:H1) and Standby(C2, origin-host:H2) > diameter clients and have successfully established connections with the > diameter server S1. Client C1 also has active sessions with server S1 that > were originally established from C1. My question is when C1 fails over to > C2, Can C2 send CCR updates on these sessions with the origin-host of C2? > > If the answer to the above question is yes, How will the retransmission > work from C2? > > According to RFC 3588, On the Server, the duplicate messages are detected > by the combination of End-to-End identifier and Origin-Host(section 3, page > 33). Is it OK for C2 to retransmit the message with the T-flag set, the > same End-to-End identifier and a different origin-Host? What would be the > server behavior in this case, Would it take it as a duplicate message? > > Please note that both the active and standby diameter nodes have > connections always on from their respective origin-host IDs, when the > failover happens the standby client would start right away working on the > sessions without having to wait to reestablish the connection. > > Thanks in advance, > Ravi > --90e6ba6e8eccb560da049364034f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could someone please respond to the question below?

Thanks,
Ravi=

On Tue, Oct 19, 2010 at 10:56 AM, Ravi G= unturu <ravikgvs= @gmail.com> wrote:
Hi,

I have= a question on the diameter client failover. Let us assume there are two no= des Active(C1, origin-host:H1) and Standby(C2, origin-host:H2) diameter cli= ents and have successfully established connections with the diameter server= S1.=A0 Client C1 also has active sessions with server S1 that were origina= lly established from C1. My question is when C1 fails over to C2, Can C2 se= nd CCR updates on these sessions with the origin-host of C2?

If the answer to the above question is yes, How will the retransmission= work from C2?=A0=A0

According to RFC 3588, On the Server, the dupl= icate messages are detected by the combination of End-to-End identifier and= Origin-Host(section 3, page 33). Is it OK=A0 for C2 to retransmit the mess= age with the T-flag set, the same End-to-End identifier and a different ori= gin-Host? What would be the server behavior in this case, Would it take it = as a duplicate message?

Please note that both the active and standby diameter nodes have connec= tions always on from their respective origin-host IDs, when the failover ha= ppens the standby client would start right away working on the sessions wit= hout having to wait to reestablish the connection.

Thanks in advance,
Ravi

--90e6ba6e8eccb560da049364034f-- From root@core3.amsl.com Mon Oct 25 10:30:07 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 16F3F3A6B9E; Mon, 25 Oct 2010 10:30: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: <20101025173007.16F3F3A6B9E@core3.amsl.com> Date: Mon, 25 Oct 2010 10:30:07 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-erp-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: Mon, 25 Oct 2010 17:30:07 -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 the EAP Re-authentication Protocol (ERP) Author(s) : J. Bournelle, L. Morand, W. Wu, G. Zorn Filename : draft-ietf-dime-erp-05.txt Pages : 17 Date : 2010-10-25 The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-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-erp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25102845.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Mon Oct 25 22:35: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 6DBEB3A67F1 for ; Mon, 25 Oct 2010 22:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1Z2iSgbuBBdP for ; Mon, 25 Oct 2010 22:35:30 -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 93E6F3A67E4 for ; Mon, 25 Oct 2010 22:35:22 -0700 (PDT) Received: by fxm9 with SMTP id 9so3152631fxm.31 for ; Mon, 25 Oct 2010 22:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:x-priority:date:cc:content-transfer-encoding :message-id:to:x-mailer; bh=mJo+N7y5q+srSqwsW6QepCU89jYqNNRBkv8O4ng8kYg=; b=f5bP6dX+IdfPD14lKeiQFk+GkEK3bsZ8fSHKZoidhGsJ4SVlu12DkYJkCuNXgHBPdg KK4Aojydiye2G/cLe1DB42p8U9tXEfLOf4gvEFP9iIKZ7Qpw7QbFB6tsoImLVPOsyHq+ pLGDLoET5Rq3xUuPaFRIl0wUcjXvSrU65U42c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:x-priority:date:cc :content-transfer-encoding:message-id:to:x-mailer; b=ZfiF0/KA2eOWJAg6f9Ju7fDs2d1bD3z2nnLzPWsC/p0lIhd1WgJWNPlajEFHIc4U9k mR4QtmBk+G3iE134X+aciE8wTqxsIymFHYxWS4eZk51m0bxZoqzBRKw7ChV151UpNhTZ lUAtGGRs2zVQXWQT4eDVwfTmHgs9FMRbyHdxQ= Received: by 10.223.69.132 with SMTP id z4mr427165fai.31.1288071424668; Mon, 25 Oct 2010 22:37:04 -0700 (PDT) Received: from a88-112-141-166.elisa-laajakaista.fi (a88-112-141-166.elisa-laajakaista.fi [88.112.141.166]) by mx.google.com with ESMTPS id u8sm3331502fah.36.2010.10.25.22.37.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 22:37:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: jouni korhonen X-Priority: 1 Date: Tue, 26 Oct 2010 08:37:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4AB83D69-22A1-4259-B27B-2DD6408C34F1@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Dime Meeting and note takers, jabber scribes and such 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, 26 Oct 2010 05:35:32 -0000 Folks, We are meeting THURSDAY, November 11, 2010 between 1520-1720 Afternoon = Session II. To make the administrative part easier please volunteer in advance as a = note taker or jabber scribe! Just send a mail to chairs. - Jouni= From jouni.nospam@gmail.com Tue Oct 26 04:45:49 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 7A9C13A67A3 for ; Tue, 26 Oct 2010 04:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKKtTVjZoVRn for ; Tue, 26 Oct 2010 04:45:48 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 74F863A67DB for ; Tue, 26 Oct 2010 04:45:48 -0700 (PDT) Received: by ewy27 with SMTP id 27so2209378ewy.31 for ; Tue, 26 Oct 2010 04:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=2X3MsoxFm5NQDgpcm3V0MkmUz654TEO7b4ioqmkJLzQ=; b=aC7IXqHxZH47Z/zMHj87XdnkgHvAyDUk+C0QF+f9fy74Py2Gt2agjpyG2V+W2Uk80R uMq6RP6BWe9d3LCi3VAeEQGaWbnohjaTGaN9egX+QJaDOaOB0WHwIo87GXKgV2mW9by0 OJTsjr1EN6nEPBAM4+sWSSX3ERCj4VPPnS1PU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=dIVMTNM/PSSXxWJCCgegV4YztJg3jBDA+rZ/GYhW4VjXBBZKgXkpgAZC5Z/2CeeV3c tX8Np4rmnCyBLA5DuiF2C9VJBMyxSp+ouhVLmd/6SmtAuuijTT35q+cNNu6JWHR9EE/9 p1WLKIR7kHtOwk3MwP6E+3iJ/njuaIybKQ9EQ= Received: by 10.102.244.15 with SMTP id r15mr4814426muh.130.1288093654351; Tue, 26 Oct 2010 04:47:34 -0700 (PDT) Received: from a88-112-141-166.elisa-laajakaista.fi (a88-112-141-166.elisa-laajakaista.fi [88.112.141.166]) by mx.google.com with ESMTPS id r22sm3468135fax.45.2010.10.26.04.47.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 Oct 2010 04:47:32 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Oct 2010 14:47:30 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Dime draft agenda uploaded 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, 26 Oct 2010 11:45:49 -0000 Folks, See the draft agenda: http://www.ietf.org/proceedings/79/agenda/dime.txt And we are going to have webex this time.. so let us know if you want to = join the meeting via webex. - Jouni & Lionel= From dromasca@avaya.com Thu Oct 28 06:42: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 1AC223A683C for ; Thu, 28 Oct 2010 06:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ves8xaLxu8aL for ; Thu, 28 Oct 2010 06:42:24 -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 90B5A3A67E3 for ; Thu, 28 Oct 2010 06:42:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,252,1286164800"; d="scan'208";a="246904632" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Oct 2010 09:44:16 -0400 X-IronPort-AV: E=Sophos;i="4.58,252,1286164800"; d="scan'208";a="533766212" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2010 09:44:16 -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, 28 Oct 2010 15:43:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (full) review of draft-ietf-dime-rfc3588bis-25.txt Thread-Index: Act2pc+x3jLkwSVJRdmVYp8Q/s5J/QAAFOZQ From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: (full) review of draft-ietf-dime-rfc3588bis-25.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, 28 Oct 2010 13:42:27 -0000 =20 -----Original Message----- From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Sent: Thursday, October 28, 2010 3:40 PM To: gen-art@ietf.org Cc: draft-ietf-dime-rfc3588bis.all@tools.ietf.org Subject: (full) review of draft-ietf-dime-rfc3588bis-25.txt I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-rfc3588bis-25.txt Reviewer: Francis Dupont Review Date: 2010-10-27 IETF LC End Date: 2010-10-25 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: Technical: - 13 page 147: I have a concern about 'TLS or IPsec handshake' because there is no such thing like 'IPsec handshake'. I suggest to ask IPsec people to check if this must be changed and if yes to get a better wording. Large scope editial: - Acknowledgements -> Acknowledgments (ToC page 6, A. page 152 and in the text itself, for instance 1 page 7 in Failover) - i.e. -> i.e., (for instance 2.1 page 23, 5.6 page 69) Editorial: - 1.1.3 page 12: please expand CER ad CEA at their first use. - 5.2 page 60: 'diameter.tls' -> 'diameter.tls.tcp' (cf 11.6 page 145) - 5.6 page 70: both ends moves -> both ends move - 6.6 page 84: a non-routable messages. -> a non-routable message. - 6.7.2 page 84: local state information of Diameter node -> local state information of the Diameter node - 6.7.4 page 85: by entities other Diameter entities. -> by other Diameter entities. - 6.11 page 86: a CER or CEA messages. -> a CER or CEA message. - 7 page 91: A command is received that is missing AVP(s) that (bad wording) -> A received command which is ... - 7.1.5 page 96: (bad wording) The Failed-AVP AVPs MUST be present which contains - 7.1.5 page 97: avp -> AVP (in code 5014 description) - 8 page 102: the applications itself -> the application itself - 8.1 page 103: sessions maintains -> sessions maintain - 8.1 pages 103 and 104: if it is possible I prefer: Result-Code =3D ... to Result-Code =3D ... - 9.3 page 128 (Split): maybe -> may be - 9.6 page 131: [Acct-]Multi-Session- Id -> [Acct-]Multi-Session-Id - Authors' page 158: ITU TS E.123 mandates a '+' before country code (i.e., +33 for France, +1 for USA and Canada, etc) Spelling: reauthentication -> re-authentication Regards Francis.Dupont@fdupont.fr PS: I heavily used the IETF diff tool so bad wordings could be inherited from RFC 3588. From simon.mizikovsky@alcatel-lucent.com Thu Oct 28 12:51:17 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 1244E3A6774 for ; Thu, 28 Oct 2010 12:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJsiC6Hm2TKh for ; Thu, 28 Oct 2010 12:51:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 168843A68DA for ; Thu, 28 Oct 2010 12:51:16 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o9SJr8Yr015820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Oct 2010 14:53:08 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9SJr76o030415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Oct 2010 14:53:07 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 28 Oct 2010 14:53:07 -0500 From: "Mizikovsky, Semyon B (Simon)" To: "dime@ietf.org" Date: Thu, 28 Oct 2010 14:53:07 -0500 Thread-Topic: Comments on draft-ietf-dime-ikev2-psk-diameter-03.txt Thread-Index: Act2CJUiMrD465+GSN+L519yo/QNdQAEQTOwACDeaxAAC8sR8A== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [Dime] Comments on draft-ietf-dime-ikev2-psk-diameter-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: Thu, 28 Oct 2010 19:51:17 -0000 1. In Sec.4.2 first paragraph "The HAAA may maintain state or may be statel= ess. This is indicated by presence or absence of the Auth-Session-State AV= P." This behavior is already defined in RFC3588. In fact, absence of the Au= th-Session-State AVP in a Request would indicate the default that the state= is requested to be maintained by the HAAA, and absence of this AVP in an A= nswer - that the HAAA will in fact maintain the state. Suggest to remove th= ese two sentences, leaving only the main requirement of this Draft, listed = in the third sentence: "The IKEv2 Server MUST support the Authorization Ses= sion State Machine defined in [RFC3588]." 2. The Auth-Session-State AVP is absent in the IKEv2-PSK-Answer (IKEPSKA) C= ommand, sec. 5.2, even though it is shown [optional] in IKEv2-PSK-Request (= IKEPSKR) Command, sec.5.1. Suggest to add it to IKEv2-PSK-Answer (IKEPSKA)= Command for completeness. 3. Sec.10 "Security Considerations", second paragraph "In this case, the HA= to the Diameter server AAA communication relies on the security properties= of the intermediating AAA inter-connection networks, AAA brokers, and Diam= eter agents." Suggest replacing the HA with IKEv2 Server. With these changes, suggest to approve the draft for publication. Semyon Mizikovsky Alcatel Lucent Wireless Security & Fraud Prevention Wireless Standards Department 600/700 Mountain Avenue, 3C-506L Murray Hill, NJ 07974, USA (O) 1+908-582-0729 (M) 1+732-239-7533 (F) 1+908-743-4361 From wwwrun@core3.amsl.com Fri Oct 29 10:14:14 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2767F3A686A; Fri, 29 Oct 2010 10:14:13 -0700 (PDT) To: gwz@net-zen.net, jari.arkko@piuha.net, john.loughney@nokia.com, vf0213@gmail.com From: IETF Secretariat Message-Id: <20101029171414.2767F3A686A@core3.amsl.com> Date: Fri, 29 Oct 2010 10:14:14 -0700 (PDT) X-Mailman-Approved-At: Sat, 30 Oct 2010 10:51:03 -0700 Cc: jouni.korhonen@nsn.com, housley@vigilsec.com, dime@ietf.org, rbonica@juniper.net, ipr-announce@ietf.org Subject: [Dime] IPR Disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25 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, 29 Oct 2010 17:14:14 -0000 Dear Glen Zorn, Jari Arkko, John Loughney, Victor Fajardo: An IPR disclosure that pertains to your Internet-Draft entitled "Diameter Base Protocol" (draft-ietf-dime-rfc3588bis) was submitted to the IETF Secretariat on 2010-10-29 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1437/). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to draft-ietf-dime-rfc3588bis-25." The IETF Secretariat