From jouni.nospam@gmail.com Sun Apr 1 12:13:01 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AEA21F8748 for ; Sun, 1 Apr 2012 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewS-ED-c9LEp for ; Sun, 1 Apr 2012 12:13:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 890D721F873B for ; Sun, 1 Apr 2012 12:12:59 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1840940bku.31 for ; Sun, 01 Apr 2012 12:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vRvQ0HTwEay9eSLhrlfOQ8v99g3yV2v9iBjCTmHlFgg=; b=kGpZHwc+fqIMVFVSKpgGgOKt8zvDD7RLT3eZKi/n9ZhwEmzCHW8kf32IPMuVtipyK9 Sjs1CjTkWjTWUEX1quRcOmOxMi+OE5k492n6iswuzardTG/leJlcHZzmRfYoTLgCFL9F cyUpzvqN1sM5M+LlL0NUHb0ck8iV1sMqmehYiGFD49ipvg0jB10DkA/kkqJQQtwND8FY 5CekBvZFCABYGCo/JAk7KWel7xjhDcwDyoNNmPIpPKUwFFIZpYvMgu9Y7IZbXSPIiTDc 7DSXyl1A9QJZD9v1rJNd5PCGgN+GyS6fjg66F4SabDvc4SxMZQm4b11bHXYp/lk1tITR 9aQg== Received: by 10.204.128.152 with SMTP id k24mr2214786bks.127.1333307578546; Sun, 01 Apr 2012 12:12:58 -0700 (PDT) Received: from a88-114-1-77.elisa-laajakaista.fi (a88-114-1-77.elisa-laajakaista.fi. [88.114.1.77]) by mx.google.com with ESMTPS id cy11sm7388899bkb.7.2012.04.01.12.12.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 12:12:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> Date: Sun, 1 Apr 2012 22:12:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com> <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 19:13:01 -0000 Folks, As per the discussion during the Dime WG meeting in Paris, the = RFC3588bis text in Section 5.2 on existing IETF standards. The first option (manual configuration) MUST be supported by all Diameter nodes, while the latter option (DNS) MAY be supported. will be clarified so that the DNS-based discovery is MUST to implement and MAY be supported. A note about this will also be added to RFC3588bis Section 1.1.3. "Changes from RFC3588". - Jouni & Lionel On Mar 12, 2012, at 10:20 PM, Ben Campbell wrote: >=20 > On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote: >=20 >> Ben, >>=20 >> Normal "Dime lag" added to the response ;) See inline. >=20 > Thanks, also see inline: >=20 >>=20 >> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote: >>=20 >>> Hi All, >>>=20 >>> I'm digesting the Peer Discovery section of 3588bis-29 (Section = 5.2), and have some questions. I apologize in advance if these have been = covered in past discussion. >>>=20 >>> 1) paragraph 1 says that "=85 the later option (DNS) MAY be = supported: >>>=20 >>> Does that mean supported "by the software implementation", or = supported "by the network deployment"? That is, is the intent to say = that DNS based peer discovery MAY be implemented, vs MAY be used? >>=20 >> This is currently under a debate.. as you probably have seen. >=20 > Yes, thanks. Put me in the "prefer MUST implement" camp. I've seen = too many situations where management is harder than it needs to be = because people are pre-provisioning every possible peer, often by IP = address. While you can't make them stop doing that if they _want_ to, it = would be nice if vendors gave them the option to not. >=20 >>=20 >>> 2) Paragraph 2 talks about peer discovery by a client to find a next = hop agent, or an agent to find another (next hop) agent. Is peer = discovery limited to finding Diameter Agents? That is, can a Diameter = client discover a Diameter server? (Perhaps the word "node" was intended = rather than "agent"?) >>=20 >> It entirely depends what the domain owner populates into its DNS. If = he/she puts there RRs for a relay, then the DNS-based discovery = discovers it. If he/she puts there RRs for a server, then server gets = discovered. There is no strict rule about that. >=20 > That's what I hoped the answer was--but the text is confusing on that = point. >=20 >=20 >>=20 >>> 3) The 4th paragraph from the end says that, when using a site = certificate, _both_ the domain name in the initial query and the name in = the replacement field must match the site certificate. Is that just the = for initial query and the final result, or does it cover any = intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does = the SRV step also need to match?) Is there an expectation that the = client will actually validate against both the queried name and the = resulting name, or is the point merely that the cert should include them = because different clients may start their initial query at different = places in the DDDS sequence? >>=20 >> As far as I understand it, all domain names used for the query: the = one for querying NAPTR, possible A/AAAA replacement from NAPTR, or = replacement to query a SRV and finally the A/AAAAs in the SRV; must be = in the cert. The client can check any of those.. it does not need to = check whole chain but it probably should. The reason is stated in the = same paragraph: >>=20 >> MUST both be valid based on the same site certificate. Otherwise, = an >> attacker could modify the DNS records to contain replacement values >> in a different domain, and the client could not validate that this >> was the desired behavior, or the result of an attack. >=20 > It's not clear to me what the attack is where a cert that contains the = initial name but not the derived names but not where the cert also = contains all the derived names. Unless I'm reading it wrong, the = security considerations for DDDS (RFC3958) only require the server to = supply a certificate that matches the _original_ name. >=20 >>=20 >> - Jouni >>=20 >>=20 >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From jouni.nospam@gmail.com Sun Apr 1 12:20:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158B611E8081 for ; Sun, 1 Apr 2012 12:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqANuV11nmD8 for ; Sun, 1 Apr 2012 12:20:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75D11E807F for ; Sun, 1 Apr 2012 12:20:31 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1843661bku.31 for ; Sun, 01 Apr 2012 12:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=3Pk5CU1Bz/9of/t+5IORN/65nwJOkHT5jmrba5rKglU=; b=L3lLkQzzS800bOR7mZ/FgFyv85ZtisJGspdm1hdVCK7WJkF5omhYNoygTmF1hUdqkM v3sTIL6/omNIFjROHsNT0tc/kib+fUG2Zb0EIQa8SenaZZRcnJjtkrYSDkNqxFB0nfQQ NvfRxt/fRHx6tjPZuCkR6IWCQjMwX/53lsJwyu8jqhNbZddq+pexRPusmii8ud1lgogt KA3dmh3r39AZlmyYvFayUUZ8iIvA54VLr+wsJ7HUqVbg6DC3UplRqfHz46uyG8pEae7H MxohgtThl8dKWDJhG0Dhb/JNbAnPhMGJHHIbsuQCLpQP2xoVdR4YOozFrxjOrb58R8cw EZow== Received: by 10.205.122.2 with SMTP id ge2mr2399381bkc.113.1333308030508; Sun, 01 Apr 2012 12:20:30 -0700 (PDT) Received: from a88-114-1-77.elisa-laajakaista.fi (a88-114-1-77.elisa-laajakaista.fi. [88.114.1.77]) by mx.google.com with ESMTPS id f5sm33337153bke.9.2012.04.01.12.20.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 12:20:29 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Apr 2012 22:20:27 +0300 Message-Id: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 19:20:32 -0000 Folks, During the Dime WG meeting in Paris we decided to adopt = draft-jones-diameter-group-signaling-01 "Diameter Group Signaling" as a working group I-D. The I-D is an input = for the charter mile stone 'Protocol extension for bulk and group signaling'. This mail starts a one week verification for the adoption. If you have = strong concerns that the=20 draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ = for the solution, then express your concerns on the mailing list by 8th April. - Jouni & Lionel From jouni.nospam@gmail.com Sun Apr 1 12:28:33 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4319221F88D8 for ; Sun, 1 Apr 2012 12:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsAyi4tqRhHL for ; Sun, 1 Apr 2012 12:28:32 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A23121F88D5 for ; Sun, 1 Apr 2012 12:28:32 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1846479bku.31 for ; Sun, 01 Apr 2012 12:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=ryxkFv9GlY71mbcq5IEs/9ko6oOOOr1FnXodFYNLQso=; b=yX7t1ENHmwkrrK88i5BpFGiYBtwvJWFN0V9gzjRG1Z/SOWfo2XP3a8ANQEJQ+t3Yft evXZedg5nn4l3yBLb7jZq+N7pXGQdh9H6CIABKDInGdXqi8aeZ3lU2CfdgYrI7sAbKM9 OToElYR/9Ygp/uj2PzJ2k47hXIJkugPvKEvnrDH4wJ0+kDcbikrleKCRmY6CEfVrZ4gC /XYcYgDGbpL1M2XGjpyWv4O9Qno/fJcbmJA5oiNWoSEPbIL3dScL8i+CXQg75r4fF5Bg wgc5rbYowXi14IxyY60FpNGycZsP0LB5YhG3Dj+wE7XsUQjS64pT6wdgzwHQqJE+Lr0V /Bqw== Received: by 10.204.154.209 with SMTP id p17mr2495447bkw.6.1333308511690; Sun, 01 Apr 2012 12:28:31 -0700 (PDT) Received: from a88-114-1-77.elisa-laajakaista.fi (a88-114-1-77.elisa-laajakaista.fi. [88.114.1.77]) by mx.google.com with ESMTPS id p19sm33443203bka.1.2012.04.01.12.28.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 12:28:30 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 1 Apr 2012 22:28:28 +0300 Message-Id: <298E9AF5-09A8-4BE9-B6EE-5CF7E9DCF453@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] Removing Diameter MIB documents from the charter.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 19:28:33 -0000 Folks, As discussed in Dime WG meeting in Paris there seems to be no energy to get both MIB documents draft-ietf-dime-diameter-base-protocol-mib draft-ietf-dime-diameter-cc-appl-mib completed. Unless someone steps ahead now by 8th April and really manages to progress these documents in few weeks time, we will abandon both and remove them from Dime charter's milestones.. - Jouni & Lionel From internet-drafts@ietf.org Sun Apr 1 15:52:18 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C9721F86CA; Sun, 1 Apr 2012 15:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KSd+F8A0c+E; Sun, 1 Apr 2012 15:52:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5B21F86C3; Sun, 1 Apr 2012 15:52:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120401225217.14365.16591.idtracker@ietfa.amsl.com> Date: Sun, 01 Apr 2012 15:52:17 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-14.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 22:52:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-14.txt Pages : 26 Date : 2012-04-01 The Diameter Base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend the Diameter Base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-14.txt From ben@nostrum.com Sun Apr 1 18:14:55 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B711E8085 for ; Sun, 1 Apr 2012 18:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3JkQpU9Y6lD for ; Sun, 1 Apr 2012 18:14:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D65021F86F7 for ; Sun, 1 Apr 2012 18:14:54 -0700 (PDT) Received: from [10.0.1.33] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q321Elrm097999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Apr 2012 20:14:48 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Ben Campbell In-Reply-To: Date: Sun, 1 Apr 2012 20:14:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com> <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> To: jouni korhonen X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 01:14:55 -0000 Hi Jouni, I concur in principle, but have one comment inline: On Apr 1, 2012, at 2:12 PM, jouni korhonen wrote: > Folks, >=20 > As per the discussion during the Dime WG meeting in Paris, the = RFC3588bis > text in Section 5.2 >=20 > on existing IETF standards. The first option (manual configuration) > MUST be supported by all Diameter nodes, while the latter option > (DNS) MAY be supported. >=20 > will be clarified so that the DNS-based discovery is MUST to implement > and MAY be supported. A note about this will also be added to = RFC3588bis > Section 1.1.3. "Changes from RFC3588". I think the term "supported" was part of the original confusion, as it's = not clear whether that means "implemented" or "used". I think the = takeaway from the discussion in Paris is that DNS-based discovery "MUST = be implemented and MAY be _used_", or something to that effect. Thanks! Ben. >=20 > - Jouni & Lionel >=20 >=20 >=20 >=20 > On Mar 12, 2012, at 10:20 PM, Ben Campbell wrote: >=20 >>=20 >> On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote: >>=20 >>> Ben, >>>=20 >>> Normal "Dime lag" added to the response ;) See inline. >>=20 >> Thanks, also see inline: >>=20 >>>=20 >>> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote: >>>=20 >>>> Hi All, >>>>=20 >>>> I'm digesting the Peer Discovery section of 3588bis-29 (Section = 5.2), and have some questions. I apologize in advance if these have been = covered in past discussion. >>>>=20 >>>> 1) paragraph 1 says that "=85 the later option (DNS) MAY be = supported: >>>>=20 >>>> Does that mean supported "by the software implementation", or = supported "by the network deployment"? That is, is the intent to say = that DNS based peer discovery MAY be implemented, vs MAY be used? >>>=20 >>> This is currently under a debate.. as you probably have seen. >>=20 >> Yes, thanks. Put me in the "prefer MUST implement" camp. I've seen = too many situations where management is harder than it needs to be = because people are pre-provisioning every possible peer, often by IP = address. While you can't make them stop doing that if they _want_ to, it = would be nice if vendors gave them the option to not. >>=20 >>>=20 >>>> 2) Paragraph 2 talks about peer discovery by a client to find a = next hop agent, or an agent to find another (next hop) agent. Is peer = discovery limited to finding Diameter Agents? That is, can a Diameter = client discover a Diameter server? (Perhaps the word "node" was intended = rather than "agent"?) >>>=20 >>> It entirely depends what the domain owner populates into its DNS. If = he/she puts there RRs for a relay, then the DNS-based discovery = discovers it. If he/she puts there RRs for a server, then server gets = discovered. There is no strict rule about that. >>=20 >> That's what I hoped the answer was--but the text is confusing on that = point. >>=20 >>=20 >>>=20 >>>> 3) The 4th paragraph from the end says that, when using a site = certificate, _both_ the domain name in the initial query and the name in = the replacement field must match the site certificate. Is that just the = for initial query and the final result, or does it cover any = intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does = the SRV step also need to match?) Is there an expectation that the = client will actually validate against both the queried name and the = resulting name, or is the point merely that the cert should include them = because different clients may start their initial query at different = places in the DDDS sequence? >>>=20 >>> As far as I understand it, all domain names used for the query: the = one for querying NAPTR, possible A/AAAA replacement from NAPTR, or = replacement to query a SRV and finally the A/AAAAs in the SRV; must be = in the cert. The client can check any of those.. it does not need to = check whole chain but it probably should. The reason is stated in the = same paragraph: >>>=20 >>> MUST both be valid based on the same site certificate. Otherwise, = an >>> attacker could modify the DNS records to contain replacement values >>> in a different domain, and the client could not validate that this >>> was the desired behavior, or the result of an attack. >>=20 >> It's not clear to me what the attack is where a cert that contains = the initial name but not the derived names but not where the cert also = contains all the derived names. Unless I'm reading it wrong, the = security considerations for DDDS (RFC3958) only require the server to = supply a certificate that matches the _original_ name. >>=20 >>>=20 >>> - Jouni >>>=20 >>>=20 >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >=20 From jouni.nospam@gmail.com Sun Apr 1 23:34:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C2311E8074 for ; Sun, 1 Apr 2012 23:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtJ35yJ--A3P for ; Sun, 1 Apr 2012 23:34:52 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2511E8073 for ; Sun, 1 Apr 2012 23:34:51 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2071407bku.31 for ; Sun, 01 Apr 2012 23:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OdKDqboU5LkFGJHjEl06QkwZNsPUmhVA+I2K6ztlW78=; b=xMM+fYsHHmTISK5d/gJn67VFjony7qVlw3Omk7jyoUbEE3AGdM6008TXJxB2gCGLQs +YwED4Z7djenP6dELNym3LNfTyamHzR4stPofFKzSXtqfh2s6Z0TKueCbjV36Ip4NJtG 5To6Tm70e7lLBO33E6YaUfGPrCOV/BSd7S98DOuXVXIyXVLZJYQ77jEPtJqMSY4MNkFd lIhdV7G0Xs3qQu1uAUrC5wxt8gmLZWi/wjLhaM9AyoLS+pGq+ed0pmtaoFe83JOEG59i BiXHvj8KtwjchABDC0PtLhibzOLvp3pqZMq+n9ESQHzj+JzA9Bx7bHg+doGqUKLIA7Zh cPvg== Received: by 10.205.122.2 with SMTP id ge2mr2999026bkc.113.1333348490800; Sun, 01 Apr 2012 23:34:50 -0700 (PDT) Received: from a88-114-1-77.elisa-laajakaista.fi (a88-114-1-77.elisa-laajakaista.fi. [88.114.1.77]) by mx.google.com with ESMTPS id f5sm35826028bke.9.2012.04.01.23.34.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Apr 2012 23:34:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> Date: Mon, 2 Apr 2012 09:34:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9E8A06E5-0B53-40FD-9DA3-2CE32C8CDA10@gmail.com> References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com> <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:34:53 -0000 Ben, On Apr 2, 2012, at 4:14 AM, Ben Campbell wrote: > Hi Jouni, >=20 > I concur in principle, but have one comment inline: >=20 > On Apr 1, 2012, at 2:12 PM, jouni korhonen wrote: >=20 >> Folks, >>=20 >> As per the discussion during the Dime WG meeting in Paris, the = RFC3588bis >> text in Section 5.2 >>=20 >> on existing IETF standards. The first option (manual configuration) >> MUST be supported by all Diameter nodes, while the latter option >> (DNS) MAY be supported. >>=20 >> will be clarified so that the DNS-based discovery is MUST to = implement >> and MAY be supported. A note about this will also be added to = RFC3588bis >> Section 1.1.3. "Changes from RFC3588". >=20 > I think the term "supported" was part of the original confusion, as = it's not clear whether that means "implemented" or "used". I think the = takeaway from the discussion in Paris is that DNS-based discovery "MUST = be implemented and MAY be _used_", or something to that effect. Sorry for my badly placed words. "MAY be used" is exactly what I had in mind. Sometimes the lines from the head muscle to fingers are long and experience some corruption of information ;) - Jouni >=20 > Thanks! >=20 > Ben. >=20 >>=20 >> - Jouni & Lionel >>=20 >>=20 >>=20 >>=20 >> On Mar 12, 2012, at 10:20 PM, Ben Campbell wrote: >>=20 >>>=20 >>> On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote: >>>=20 >>>> Ben, >>>>=20 >>>> Normal "Dime lag" added to the response ;) See inline. >>>=20 >>> Thanks, also see inline: >>>=20 >>>>=20 >>>> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote: >>>>=20 >>>>> Hi All, >>>>>=20 >>>>> I'm digesting the Peer Discovery section of 3588bis-29 (Section = 5.2), and have some questions. I apologize in advance if these have been = covered in past discussion. >>>>>=20 >>>>> 1) paragraph 1 says that "=85 the later option (DNS) MAY be = supported: >>>>>=20 >>>>> Does that mean supported "by the software implementation", or = supported "by the network deployment"? That is, is the intent to say = that DNS based peer discovery MAY be implemented, vs MAY be used? >>>>=20 >>>> This is currently under a debate.. as you probably have seen. >>>=20 >>> Yes, thanks. Put me in the "prefer MUST implement" camp. I've seen = too many situations where management is harder than it needs to be = because people are pre-provisioning every possible peer, often by IP = address. While you can't make them stop doing that if they _want_ to, it = would be nice if vendors gave them the option to not. >>>=20 >>>>=20 >>>>> 2) Paragraph 2 talks about peer discovery by a client to find a = next hop agent, or an agent to find another (next hop) agent. Is peer = discovery limited to finding Diameter Agents? That is, can a Diameter = client discover a Diameter server? (Perhaps the word "node" was intended = rather than "agent"?) >>>>=20 >>>> It entirely depends what the domain owner populates into its DNS. = If he/she puts there RRs for a relay, then the DNS-based discovery = discovers it. If he/she puts there RRs for a server, then server gets = discovered. There is no strict rule about that. >>>=20 >>> That's what I hoped the answer was--but the text is confusing on = that point. >>>=20 >>>=20 >>>>=20 >>>>> 3) The 4th paragraph from the end says that, when using a site = certificate, _both_ the domain name in the initial query and the name in = the replacement field must match the site certificate. Is that just the = for initial query and the final result, or does it cover any = intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does = the SRV step also need to match?) Is there an expectation that the = client will actually validate against both the queried name and the = resulting name, or is the point merely that the cert should include them = because different clients may start their initial query at different = places in the DDDS sequence? >>>>=20 >>>> As far as I understand it, all domain names used for the query: the = one for querying NAPTR, possible A/AAAA replacement from NAPTR, or = replacement to query a SRV and finally the A/AAAAs in the SRV; must be = in the cert. The client can check any of those.. it does not need to = check whole chain but it probably should. The reason is stated in the = same paragraph: >>>>=20 >>>> MUST both be valid based on the same site certificate. Otherwise, = an >>>> attacker could modify the DNS records to contain replacement values >>>> in a different domain, and the client could not validate that this >>>> was the desired behavior, or the result of an attack. >>>=20 >>> It's not clear to me what the attack is where a cert that contains = the initial name but not the derived names but not where the cert also = contains all the derived names. Unless I'm reading it wrong, the = security considerations for DDDS (RFC3958) only require the server to = supply a certificate that matches the _original_ name. >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>=20 >>=20 >=20 From glenzorn@gmail.com Mon Apr 2 20:10:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5187221F876E for ; Mon, 2 Apr 2012 20:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiWQ2EYlGPkX for ; Mon, 2 Apr 2012 20:10:35 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3CBF21F876C for ; Mon, 2 Apr 2012 20:10:34 -0700 (PDT) Received: by lagj5 with SMTP id j5so4642318lag.31 for ; Mon, 02 Apr 2012 20:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OMFK+0U61oPji1/WcNkfbPcsD/Oft7Uvbq375z4uOOc=; b=Ztihgcw464//xG8+jKlSDgRlXPe0jL+0lYPEgEduPHao5Pigjb51LS9Z+sJYvXCE1K pL1zYL4ht1JBhuVirSOMYSQF6ch/NKiEIkahXCBiiD9cYkAYOTkZvAsPolaM61l0Ki4y HRfUb5BWAEGwh8HKRvkhSMhWeb6TTPW5YbYcxPUu95nVlz7TJjfakR7eDLicTw7A7GD3 Q//jUTx3cVlUel9lgzqdkTtQZCIEx8v3g8RccqftfMuuXBgfJgnV2+Sr3y9kfCCFOIfY 2SSzqzR7XQ1MpWdaiaXLino2nCrjSCZK/J8fCdqnj/S6DmEjDXFnMm/tlig4e+5HKKqK 4Bww== MIME-Version: 1.0 Received: by 10.152.131.66 with SMTP id ok2mr12259418lab.10.1333422633629; Mon, 02 Apr 2012 20:10:33 -0700 (PDT) Received: by 10.152.9.37 with HTTP; Mon, 2 Apr 2012 20:10:33 -0700 (PDT) Received: by 10.152.9.37 with HTTP; Mon, 2 Apr 2012 20:10:33 -0700 (PDT) In-Reply-To: <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com> <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> Date: Tue, 3 Apr 2012 10:10:33 +0700 Message-ID: From: Glen Zorn To: Ben Campbell Content-Type: multipart/alternative; boundary=f46d042c6b8369b90b04bcbda648 Cc: dime@ietf.org Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 03:10:39 -0000 --f46d042c6b8369b90b04bcbda648 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Apr 2, 2012 8:14 AM, "Ben Campbell" wrote: > > Hi Jouni, > > I concur in principle, but have one comment inline: > > On Apr 1, 2012, at 2:12 PM, jouni korhonen wrote: > > > Folks, > > > > As per the discussion during the Dime WG meeting in Paris, the RFC3588bis > > text in Section 5.2 > > > > on existing IETF standards. The first option (manual configuration) > > MUST be supported by all Diameter nodes, while the latter option > > (DNS) MAY be supported. > > > > will be clarified so that the DNS-based discovery is MUST to implement > > and MAY be supported. A note about this will also be added to RFC3588bi= s > > Section 1.1.3. "Changes from RFC3588". > > I think the term "supported" was part of the original confusion, as it's not clear whether that means "implemented" or "used". I think the takeaway from the discussion in Paris is that DNS-based discovery "MUST be implemented and MAY be _used_", or something to that effect. > I really don't think that it's any of our business _what_ people use, only what is implemented, so I would just leave out anything about that. > Thanks! > > Ben. > > > > > - Jouni & Lionel > > > > > > > > > > On Mar 12, 2012, at 10:20 PM, Ben Campbell wrote: > > > >> > >> On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote: > >> > >>> Ben, > >>> > >>> Normal "Dime lag" added to the response ;) See inline. > >> > >> Thanks, also see inline: > >> > >>> > >>> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote: > >>> > >>>> Hi All, > >>>> > >>>> I'm digesting the Peer Discovery section of 3588bis-29 (Section 5.2), and have some questions. I apologize in advance if these have been covered in past discussion. > >>>> > >>>> 1) paragraph 1 says that "=85 the later option (DNS) MAY be supporte= d: > >>>> > >>>> Does that mean supported "by the software implementation", or supported "by the network deployment"? That is, is the intent to say that DNS based peer discovery MAY be implemented, vs MAY be used? > >>> > >>> This is currently under a debate.. as you probably have seen. > >> > >> Yes, thanks. Put me in the "prefer MUST implement" camp. I've seen too many situations where management is harder than it needs to be because people are pre-provisioning every possible peer, often by IP address. While you can't make them stop doing that if they _want_ to, it would be nice if vendors gave them the option to not. > >> > >>> > >>>> 2) Paragraph 2 talks about peer discovery by a client to find a next hop agent, or an agent to find another (next hop) agent. Is peer discovery limited to finding Diameter Agents? That is, can a Diameter client discover a Diameter server? (Perhaps the word "node" was intended rather than "agent"?) > >>> > >>> It entirely depends what the domain owner populates into its DNS. If he/she puts there RRs for a relay, then the DNS-based discovery discovers it. If he/she puts there RRs for a server, then server gets discovered. There is no strict rule about that. > >> > >> That's what I hoped the answer was--but the text is confusing on that point. > >> > >> > >>> > >>>> 3) The 4th paragraph from the end says that, when using a site certificate, _both_ the domain name in the initial query and the name in the replacement field must match the site certificate. Is that just the for initial query and the final result, or does it cover any intermediate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does the SRV step also need to match?) Is there an expectation that the client will actually validate against both the queried name and the resulting name, or is the point merely that the cert should include them because different clients may start their initial query at different places in the DDDS sequence? > >>> > >>> As far as I understand it, all domain names used for the query: the one for querying NAPTR, possible A/AAAA replacement from NAPTR, or replacement to query a SRV and finally the A/AAAAs in the SRV; must be in the cert. The client can check any of those.. it does not need to check whole chain but it probably should. The reason is stated in the same paragraph: > >>> > >>> MUST both be valid based on the same site certificate. Otherwise, an > >>> attacker could modify the DNS records to contain replacement values > >>> in a different domain, and the client could not validate that this > >>> was the desired behavior, or the result of an attack. > >> > >> It's not clear to me what the attack is where a cert that contains the initial name but not the derived names but not where the cert also contains all the derived names. Unless I'm reading it wrong, the security considerations for DDDS (RFC3958) only require the server to supply a certificate that matches the _original_ name. > >> > >>> > >>> - Jouni > >>> > >>> > >>>> > >>>> Thanks! > >>>> > >>>> Ben. > >>>> _______________________________________________ > >>>> DiME mailing list > >>>> DiME@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dime > >>> > >> > > > --f46d042c6b8369b90b04bcbda648 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2012 8:14 AM, "Ben Campbell" <ben@nostrum.com> wrote:
>
> Hi Jouni,
>
> I concur in principle, but have one comment inline:
>
> On Apr 1, 2012, at 2:12 PM, jouni korhonen wrote:
>
> > Folks,
> >
> > As per the discussion during the Dime WG meeting in Paris, the RF= C3588bis
> > text in Section 5.2
> >
> > =A0 on existing IETF standards. =A0The first option (manual confi= guration)
> > =A0 MUST be supported by all Diameter nodes, while the latter opt= ion
> > =A0 (DNS) MAY be supported.
> >
> > will be clarified so that the DNS-based discovery is MUST to impl= ement
> > and MAY be supported. A note about this will also be added to RFC= 3588bis
> > Section 1.1.3. =A0"Changes from RFC3588".
>
> I think the term "supported" was part of the original confus= ion, as it's not clear whether that means "implemented" or &q= uot;used". I think the takeaway from the discussion in Paris is that D= NS-based discovery "MUST be implemented and MAY be _used_", or so= mething to that effect.
>

I really don't think that it's any of our business _what_ people= use, only what is implemented, so I would just leave out anything about th= at.

> Thanks!
>
> Ben.
>
> >
> > - Jouni & Lionel
> >
> >
> >
> >
> > On Mar 12, 2012, at 10:20 PM, Ben Campbell wrote:
> >
> >>
> >> On Mar 12, 2012, at 2:50 PM, jouni korhonen wrote:
> >>
> >>> Ben,
> >>>
> >>> Normal "Dime lag" added to the response ;) See = inline.
> >>
> >> Thanks, also see inline:
> >>
> >>>
> >>> On Feb 4, 2012, at 12:36 AM, Ben Campbell wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> I'm digesting the Peer Discovery section of 3588b= is-29 (Section 5.2), and have some questions. I apologize in advance if the= se have been covered in past discussion.
> >>>>
> >>>> 1) paragraph 1 says that "=85 the later option (= DNS) MAY be supported:
> >>>>
> >>>> Does that mean supported "by the software implem= entation", or supported "by the network deployment"? That is= , is the intent to say that DNS based peer discovery MAY be implemented, vs= MAY be used?
> >>>
> >>> This is currently under a debate.. as you probably have s= een.
> >>
> >> Yes, thanks. =A0Put me in the "prefer MUST implement&quo= t; camp. I've seen too many situations where management is harder than = it needs to be because people are pre-provisioning every possible peer, oft= en by IP address. While you can't make them stop doing that if they _wa= nt_ to, it would be nice if vendors gave them the option to not.
> >>
> >>>
> >>>> 2) Paragraph 2 talks about peer discovery by a client= to find a next hop agent, or an agent to find another (next hop) agent. Is= peer discovery limited to finding Diameter Agents? That is, can a Diameter= client discover a Diameter server? (Perhaps the word "node" was = intended rather than "agent"?)
> >>>
> >>> It entirely depends what the domain owner populates into = its DNS. If he/she puts there RRs for a relay, then the DNS-based discovery= discovers it. If he/she puts there RRs for a server, then server gets disc= overed. There is no strict rule about that.
> >>
> >> That's what I hoped the answer was--but the text is confu= sing on that point.
> >>
> >>
> >>>
> >>>> 3) The 4th paragraph from the end says that, when usi= ng a site certificate, _both_ the domain name in the initial query and the = name in the replacement field must match the site certificate. Is that just= the for initial query and the final result, or does it cover any intermedi= ate steps? (e.g. if your query flow is NAPTR-->SRV-->AAAA, does the S= RV step also need to match?) Is there an expectation that the client will a= ctually validate against both the queried name and the resulting name, or i= s the point merely that the cert should include them because different clie= nts may start their initial query at different places in the DDDS sequence?=
> >>>
> >>> As far as I understand it, all domain names used for the = query: the one for querying NAPTR, possible A/AAAA replacement from NAPTR, = or replacement to query a SRV and finally the A/AAAAs in the SRV; must be i= n the cert. The client can check any of those.. it does not need to check w= hole chain but it probably should. The reason is stated in the same paragra= ph:
> >>>
> >>> MUST both be valid based on the same site certificate. = =A0Otherwise, an
> >>> attacker could modify the DNS records to contain replacem= ent values
> >>> in a different domain, and the client could not validate = that this
> >>> was the desired behavior, or the result of an attack.
> >>
> >> It's not clear to me what the attack is where a cert that= contains the initial name but not the derived names but not where the cert= also contains all the derived names. Unless I'm reading it wrong, the = security considerations for DDDS (RFC3958) only require the server to suppl= y a certificate that matches the _original_ name.
> >>
> >>>
> >>> - Jouni
> >>>
> >>>
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Ben.
> >>>> _______________________________________________
> >>>> DiME mailing list
> >>>> DiME@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dime
> >>>
> >>
> >
>

--f46d042c6b8369b90b04bcbda648-- From adam@nostrum.com Mon Apr 2 20:45:24 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04EC21F8589 for ; Mon, 2 Apr 2012 20:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf6f5L6s7Y6d for ; Mon, 2 Apr 2012 20:45:24 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42B21F852A for ; Mon, 2 Apr 2012 20:45:23 -0700 (PDT) Received: from [192.168.0.227] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q333jKMC059723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 22:45:21 -0500 (CDT) (envelope-from adam@nostrum.com) References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com> <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B176) From: Adam Roach Date: Mon, 2 Apr 2012 22:45:21 -0500 To: Glen Zorn Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 03:45:24 -0000 On Apr 2, 2012, at 22:10, Glen Zorn wrote: > I really don't think that it's any of our business _what_ people use, only= what is implemented, so I would just leave out anything about that. Given that "MAY" is non-constraining, I don't see the harm in including a st= atement to the effect that the mechanism "MAY be used". In fact, I think it c= larifies that the implementation would be well served by allowing the mechan= ism to be turned off. Without the phrase, you're likely to find implementors= who interpret the statement to mean that the mechanism is mandatory all the= time, and will provide no means to configure it to be off.=20 /a= From lionel.morand@orange.com Tue Apr 3 00:24:41 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DCE21F848A for ; Tue, 3 Apr 2012 00:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rnsvcmb429t for ; Tue, 3 Apr 2012 00:24:41 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD6221F8484 for ; Tue, 3 Apr 2012 00:24:41 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40F0AE3028B; Tue, 3 Apr 2012 09:26:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 25418E30283; Tue, 3 Apr 2012 09:26:16 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 09:24:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 09:24:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis Peer Discovery Questions Thread-Index: Ac0RTDUdwaWVkJYyQASAd5L2Fn2cxwAHQHIA References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com><1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com><58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> From: To: , X-OriginalArrivalTime: 03 Apr 2012 07:24:38.0063 (UTC) FILETIME=[D3C39BF0:01CD116A] Cc: dime@ietf.org Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:24:42 -0000 I think that this reflects the conclusion of our discussion during the = dime session. So, even if not deemed required, the statement "MUST_be_implemented, = MAY_be_used" is correct and removes some ambiguity of the current text = in RFC 3588. Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Adam Roach Envoy=E9=A0: mardi 3 avril 2012 05:45 =C0=A0: Glen Zorn Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] 3588bis Peer Discovery Questions On Apr 2, 2012, at 22:10, Glen Zorn wrote: > I really don't think that it's any of our business _what_ people use, = only what is implemented, so I would just leave out anything about that. Given that "MAY" is non-constraining, I don't see the harm in including = a statement to the effect that the mechanism "MAY be used". In fact, I = think it clarifies that the implementation would be well served by = allowing the mechanism to be turned off. Without the phrase, you're = likely to find implementors who interpret the statement to mean that the = mechanism is mandatory all the time, and will provide no means to = configure it to be off.=20 /a _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Apr 3 00:28:22 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B421F8569 for ; Tue, 3 Apr 2012 00:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoscbCxaVC0i for ; Tue, 3 Apr 2012 00:28:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2021F8568 for ; Tue, 3 Apr 2012 00:28:13 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3170373obb.31 for ; Tue, 03 Apr 2012 00:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8sm7+7uqQ7/B+5HKjzvdZSrNx8wwgt9Dol1cS1iE1U8=; b=Rllo2Pe9ZCT+THzbKBeJonu7VIWPo6ZPmPBwj0izzg0omVy+dScpqM9WlqQSfkPkbv lPxdx+6RHeoV+cx9iJTv5zwPEGIam55dlEJsKVCU7mCAN+IfRjQXc7IPo0N5mS0Bd+Y7 6w2VjAQuu8H7FxENjTGbKtsMlsv7QpHYWyoZNvf8A8o42PpbomUJ1Bt3vj83S7ebZzhz 88VYLS4RdqRJCL3uLNTxOlr1m0YjTRJ80t2dVmd++UUqdFnLP/Wj2hCYPz6p24svkB2H T39d9XoGQpBbTY3XqD9YS+Yb82CQ540Zv7PQBeEkL/a+cekY/atHSGIptIFOfeitf8B+ LpWA== Received: by 10.182.74.8 with SMTP id p8mr16794431obv.41.1333438093363; Tue, 03 Apr 2012 00:28:13 -0700 (PDT) Received: from [10.255.135.226] ([192.100.123.77]) by mx.google.com with ESMTPS id h5sm16353193oea.1.2012.04.03.00.28.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 00:28:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen Date: Tue, 3 Apr 2012 10:28:06 +0300 Content-Transfer-Encoding: 7bit Message-Id: <44D8FE0F-328D-4A6E-9857-117A00E76DAE@gmail.com> References: To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org, draft-ietf-dime-erp@tools.ietf.org Subject: [Dime] Fwd: WGLC for draft-ietf-dime-erp-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:28:22 -0000 Resending.. it seems this never made it to the mailing list. - Jouni Begin forwarded message: > From: jouni korhonen > Date: April 1, 2012 10:02:53 PM GMT+03:00 > To: dime@ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: WGLC for draft-ietf-dime-erp-09 > > > This mail starts a two week WGCL for "Diameter Support for the EAP > Re-authentication Protocol (ERP)" draft-ietf-dime-erp-09. The WGLC > ends 15th April. Provide your comments to the mailing list and you > can also enter them into the Issue Tracker. > > - Jouni & Lionel From Tina.Tsou.Zouting@huawei.com Wed Apr 4 16:46:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9849411E811C for ; Wed, 4 Apr 2012 16:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZDjrjFeEC5J for ; Wed, 4 Apr 2012 16:46:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F366111E80FE for ; Wed, 4 Apr 2012 16:46:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER00443; Wed, 04 Apr 2012 19:46:53 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 16:41:33 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Apr 2012 16:41:31 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 07:41:27 +0800 From: Tina TSOU To: jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 Thread-Index: AQHNEDyF4CFv35exeUKXaSyq14pyOpaLVqMg Date: Wed, 4 Apr 2012 23:41:26 +0000 Message-ID: References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> In-Reply-To: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 23:46:54 -0000 Hi Jouni and Mark, The problem statement is valid and the solution can work in basic scenarios= .=20 =20 However the solution may have some limit in roaming scenario. =20 Consider a network having a WLAN AN (hosting a Diameter Client) requesting = some 3G internet resources, visited network proxies and home network server= as below: =20 Client -------------- ---------- {Home network server= } -------------- ----------{Home network serve= r} The session path can be established through either of the visited n/w proxi= es. For all the messages of same session, client can ensure that the sessio= n path through stateful nodes is maintained. The visited n/w proxies would = require that the session path be maintained for offline charging etc. In this scenario, if client uses group signalling method to terminate all s= essions in a group using GSTR, only the proxy in the GSTR-GSTA path will be= aware of session termination. Since there are no follow-up messages, there= is no mechanism to let the other proxy know that the sessions are terminat= ed. This problem can be avoided in Server initiated group signalling cases (GRA= R & GASR) as the PER_SESSION mode can be used for follow up exchanges. Thus the current solution has a limit if client uses group signalling metho= d for session termination in roaming cases. I volunteer to work together with Mark to find a solution for this case. I'm NOT aware of any IPR in this area. Tina > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > jouni korhonen > Sent: Sunday, April 01, 2012 12:20 PM > To: dime@ietf.org > Cc: dime-chairs@tools.ietf.org > Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- > signaling-01 >=20 >=20 > Folks, >=20 > During the Dime WG meeting in Paris we decided to adopt draft-jones- > diameter-group-signaling-01 > "Diameter Group Signaling" as a working group I-D. The I-D is an input fo= r > the charter mile stone 'Protocol extension for bulk and group signaling'. >=20 > This mail starts a one week verification for the adoption. If you have > strong concerns that the > draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ > for the solution, then express your concerns on the mailing list by 8th > April. >=20 > - Jouni & Lionel >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Apr 10 02:53:02 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C168B21F8807 for ; Tue, 10 Apr 2012 02:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rNZbsdwVxq6 for ; Tue, 10 Apr 2012 02:53:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A53421F86DE for ; Tue, 10 Apr 2012 02:53:02 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7948925obb.31 for ; Tue, 10 Apr 2012 02:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=Ijd3P6A8ww1I4j7poD36RDxu0PX6LGk2hg6fTiuIoXg=; b=sVSDBrocYjbmkSYLEvCINPdJ6FBX/15sHVY27WJzZWd9nx3l2YhK4lIjMBAUra1EI8 8d+UjVOXET5dQNSqkeH33eNSdWDhi/Nckvxy67U+OLcCRa0BMpWY0vINPEOkBEWIbW1a Ha+JYm7VcGqDJgqdtWLMaNJUG9PPA0oeLOiHstEbyjRpu3Z3KfCrVPMM+2XEkYM8j2P9 KsJl3ZG/rB+E2aNMaIGRjzPeW/rfbPTnWFbM5lKbLd1ZObN2EsjHB9rLeU43v2X98GPZ +iXdPyoJoTxkOd3+KYvjg0RZRFuI5jangWczYWSUlajzHe9WFRj+CCj6jUrR/HQlaZpe aWKA== Received: by 10.60.19.106 with SMTP id d10mr14686007oee.40.1334051581908; Tue, 10 Apr 2012 02:53:01 -0700 (PDT) Received: from [10.255.128.21] ([192.100.123.77]) by mx.google.com with ESMTPS id xb7sm19280839obb.10.2012.04.10.02.53.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 02:53:01 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 12:53:00 +0300 Message-Id: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:53:02 -0000 Folks, They are up now for public review. Thanks to Shwetha for taking = excellent minutes. - Jouni= From Marco.Liebsch@neclab.eu Tue Apr 10 07:07:07 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0421F8644 for ; Tue, 10 Apr 2012 07:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGy5IGZ3Ng2S for ; Tue, 10 Apr 2012 07:07:06 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6237A21F8643 for ; Tue, 10 Apr 2012 07:07:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BC560100C19; Tue, 10 Apr 2012 16:06:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VYCifc0Y-Cq; Tue, 10 Apr 2012 16:06:15 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A42D2100C1C; Tue, 10 Apr 2012 16:06:05 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.36]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 16:06:55 +0200 From: Marco Liebsch To: jouni korhonen , "dime@ietf.org" Thread-Topic: discuss encoding of bulk commands /RE: [Dime] very drafty IETF#83 meeting minutes uploaded Thread-Index: Ac0XIvgjWikHGYgeT82w7wee0wt8Vw== Date: Tue, 10 Apr 2012 14:06:54 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:07:07 -0000 Thanks for the meeting minutes.=20 As the notes refer to a discussion about different means to signal bulk ope= ration, let's go through this exercise and evaluate the three candidates to signal bulk commands. Just to summarize the three alternatives according to Mark's presentation: (a) New group commands (b) Re-use existing commands and command codes, indicate group operation on the attached context (AVPs) within the message, e.g. by adding group identifier, flags, .. (c) Single new bulk command (1 new command code), indicate Diameter command= , to which the group operation applies, within the message Whereas I see (a) as straight forward method, a counterargument could be th= e need of additional command codes for each command, which should be enabled for group operation. Other SDOs, which specify new command codes, need to follow the same rules and request new command codes for all existing com= mands which should be bulk-operation enabled. With (b), all existing messages could be re-used and potentially bulk opera= tion enabled by using a different application ID and adding an additional label to the m= essage, e.g. flags, Group session AVP, etc. Such approach allows much flexibil8ity, but = we need to ensure compatibility with proxies etc, which are not bulk-operation ena= bled. Possibly using a new application ID solves that issue already. With (c), the DIME WG could specify a single dedicated command for bulk ope= rations, and the actual payload carries the command code of the Diameter message to = be executed as bulk operation (e.g. RAR, STR, ..) as well as the associated co= mmand's AVP, plus a group identifier. Any existing and new command, which is so far= used for single session operations, can be bulk operation enabled. Formatting of= such bulk operation message is still open, maybe it has impact to existing appli= cations' command parser. If we find a suitable encoding scheme for such container me= ssage, it's a concept that can be easily adopted by any Diameter command and appli= cation. We'd be interested in more opinions about the different approaches and I ho= pe that this eMail can trigger such discussion. marco > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > jouni korhonen > Sent: Dienstag, 10. April 2012 11:53 > To: dime@ietf.org > Subject: [Dime] very drafty IETF#83 meeting minutes uploaded >=20 > Folks, >=20 > They are up now for public review. Thanks to Shwetha for taking excellent > minutes. >=20 > - Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From bill.wu@huawei.com Tue Apr 10 22:08:15 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52F21F86E0 for ; Tue, 10 Apr 2012 22:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADbRi6OuhhsB for ; Tue, 10 Apr 2012 22:08:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB821F86DF for ; Tue, 10 Apr 2012 22:08:14 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU89191; Wed, 11 Apr 2012 01:08:14 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 22:06:35 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Apr 2012 22:06:38 -0700 Received: from w53375 (10.138.41.149) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 13:06:31 +0800 Message-ID: From: Qin Wu To: Marco Liebsch , jouni korhonen , References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> Date: Wed, 11 Apr 2012 13:06:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 05:08:15 -0000 SGksIE1hcmNvOg0KSSB0aGluayB0aGUgY3JpdGVyaWEgd2UgbmVlZCB0byBjb25zaWRlciBhcmU6 DQpob3cgbXVjaCBwcm90b2NvbCBleHRlbnNpb24gaXMgcmVhbGx5IHJlcXVpcmVkPw0KaG93IG11 Y2ggc3VjaCBwcm90b2NvbCBhZmZlY3RzIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhaW9uPw0KSG93 IG1hbnkgY29tbWFuZCBleGNoYW5nZXMgY2FuIHdlIHJlZHVjZT8NCnBsZWFzZSBzZWUgbXkgY29t bWVudHMgaW5saW5lLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJNYXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+DQpU bzogImpvdW5pIGtvcmhvbmVuIiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT47IDxkaW1lQGlldGYu b3JnPg0KU2VudDogVHVlc2RheSwgQXByaWwgMTAsIDIwMTIgMTA6MDYgUE0NClN1YmplY3Q6IFtE aW1lXSBkaXNjdXNzIGVuY29kaW5nIG9mIGJ1bGsgY29tbWFuZHMgL1JFOiB2ZXJ5IGRyYWZ0eSBJ RVRGIzgzIG1lZXRpbmcgbWludXRlcyB1cGxvYWRlZA0KDQoNCj4gVGhhbmtzIGZvciB0aGUgbWVl dGluZyBtaW51dGVzLiANCj4gDQo+IEFzIHRoZSBub3RlcyByZWZlciB0byBhIGRpc2N1c3Npb24g YWJvdXQgZGlmZmVyZW50IG1lYW5zIHRvIHNpZ25hbCBidWxrIG9wZXJhdGlvbiwNCj4gbGV0J3Mg Z28gdGhyb3VnaCB0aGlzIGV4ZXJjaXNlIGFuZCBldmFsdWF0ZSB0aGUgdGhyZWUgY2FuZGlkYXRl cyB0byBzaWduYWwNCj4gYnVsayBjb21tYW5kcy4NCj4gDQo+IEp1c3QgdG8gc3VtbWFyaXplIHRo ZSB0aHJlZSBhbHRlcm5hdGl2ZXMgYWNjb3JkaW5nIHRvIE1hcmsncyBwcmVzZW50YXRpb246DQo+ IChhKSBOZXcgZ3JvdXAgY29tbWFuZHMNCj4gKGIpIFJlLXVzZSBleGlzdGluZyBjb21tYW5kcyBh bmQgY29tbWFuZCBjb2RlcywgaW5kaWNhdGUgZ3JvdXAgb3BlcmF0aW9uDQo+IG9uIHRoZSBhdHRh Y2hlZCBjb250ZXh0IChBVlBzKSB3aXRoaW4gdGhlIG1lc3NhZ2UsIGUuZy4gYnkgYWRkaW5nIGdy b3VwDQo+IGlkZW50aWZpZXIsIGZsYWdzLCAuLg0KPiAoYykgU2luZ2xlIG5ldyBidWxrIGNvbW1h bmQgKDEgbmV3IGNvbW1hbmQgY29kZSksIGluZGljYXRlIERpYW1ldGVyIGNvbW1hbmQsDQo+IHRv IHdoaWNoIHRoZSBncm91cCBvcGVyYXRpb24gYXBwbGllcywgd2l0aGluIHRoZSBtZXNzYWdlDQo+ IA0KPiBXaGVyZWFzIEkgc2VlIChhKSBhcyBzdHJhaWdodCBmb3J3YXJkIG1ldGhvZCwgYSBjb3Vu dGVyYXJndW1lbnQgY291bGQgYmUgdGhlDQo+IG5lZWQgb2YgYWRkaXRpb25hbCBjb21tYW5kIGNv ZGVzIGZvciBlYWNoIGNvbW1hbmQsIHdoaWNoIHNob3VsZCBiZSBlbmFibGVkDQo+IGZvciBncm91 cCBvcGVyYXRpb24uIE90aGVyIFNET3MsIHdoaWNoIHNwZWNpZnkgbmV3IGNvbW1hbmQgY29kZXMs IG5lZWQNCj4gdG8gZm9sbG93IHRoZSBzYW1lIHJ1bGVzIGFuZCByZXF1ZXN0IG5ldyBjb21tYW5k IGNvZGVzIGZvciBhbGwgZXhpc3RpbmcgY29tbWFuZHMNCj4gd2hpY2ggc2hvdWxkIGJlIGJ1bGst b3BlcmF0aW9uIGVuYWJsZWQuDQoNCltRaW5dOiBBZ3JlZS4gT25lIG1vcmUgdGhpbmcgSSBhbSB0 aGlua2luZyBpcyBob3cgdG8gdXNlIGV4aXN0aW5nIENvbW1hbmQgQ29kZSBjYW4gaGFuZGxlDQpn cm91cCBhc3NpZ21lbnQuIEl0IGxvb2tzIHRvIG1lIGFkZGl0aW9uYWwgc2VtYW50aWNzIGluIHRo ZXNlIGV4aXN0aW5nIENvbW1hbmQgIGFyZSBuZWVkZWQgdG8gDQpkaXN0aW5ndWlzaCBhZGRpbmcg YSBzZXNzaW9uIGludG8gZ3JvdXAgZnJvbSByZW1vdmluZyBhIHNlc2lvbiBpbnRvIGdyb3VwIG9y IGRpc3Rpbmd1aXNoIGdyb3VwDQogYXNzaWdubWVudCBmcm9tIGJ1bGsgc2lnbmFsaW5nIG9wZXJh dGlvbi4gDQpOZXcgQ29tbWFuZCBmbGFncyBtYXkgYmUgZXhhbXBsZSBvZiBzdWNoIGFkZGl0aW9u YWwgc2VtYW50aWNzIGJ1dCBzZWVtcyBub3QgY29tcGVsbGluZy46LSkNCg0KPiBXaXRoIChiKSwg YWxsIGV4aXN0aW5nIG1lc3NhZ2VzIGNvdWxkIGJlIHJlLXVzZWQgYW5kIHBvdGVudGlhbGx5IGJ1 bGsgb3BlcmF0aW9uIGVuYWJsZWQNCj4gYnkgdXNpbmcgYSBkaWZmZXJlbnQgYXBwbGljYXRpb24g SUQgYW5kIGFkZGluZyBhbiBhZGRpdGlvbmFsIGxhYmVsIHRvIHRoZSBtZXNzYWdlLCBlLmcuDQo+ IGZsYWdzLCBHcm91cCBzZXNzaW9uIEFWUCwgZXRjLiBTdWNoIGFwcHJvYWNoIGFsbG93cyBtdWNo IGZsZXhpYmlsOGl0eSwgYnV0IHdlIG5lZWQNCj4gdG8gZW5zdXJlICBjb21wYXRpYmlsaXR5IHdp dGggcHJveGllcyBldGMsIHdoaWNoIGFyZSBub3QgYnVsay1vcGVyYXRpb24gZW5hYmxlZC4NCj4g UG9zc2libHkgdXNpbmcgYSBuZXcgYXBwbGljYXRpb24gSUQgc29sdmVzIHRoYXQgaXNzdWUgYWxy ZWFkeS4NCg0KW1Fpbl06IEkgYW0gbm90IHN1cmUgcHJveHkgaW4gYmV0d2VlbiBuZWVkcyB0byBi ZSBidWxrLW9wZXJhdGlvbiBlbmFibGVkLg0KSXQgbG9va3MgdG8gbWUgYnVsayBvcGVyYXRpb24g b25seSBoYXBwZW5zIG9uIHRoZSBzb3VyY2UgYW5kIGZpbmFsIGRlc3RpbmF0aW9uIA0Kb2YgdGhl IERpYW1ldGVyIG1lc3NhZ2UuDQoNCj4gV2l0aCAoYyksIHRoZSBESU1FIFdHIGNvdWxkIHNwZWNp ZnkgYSBzaW5nbGUgZGVkaWNhdGVkIGNvbW1hbmQgZm9yIGJ1bGsgb3BlcmF0aW9ucywNCj4gYW5k IHRoZSBhY3R1YWwgcGF5bG9hZCBjYXJyaWVzIHRoZSBjb21tYW5kIGNvZGUgb2YgdGhlIERpYW1l dGVyIG1lc3NhZ2UgdG8gYmUNCj4gZXhlY3V0ZWQgYXMgYnVsayBvcGVyYXRpb24gKGUuZy4gUkFS LCBTVFIsIC4uKSBhcyB3ZWxsIGFzIHRoZSBhc3NvY2lhdGVkIGNvbW1hbmQncw0KPiBBVlAsIHBs dXMgYSBncm91cCBpZGVudGlmaWVyLiBBbnkgZXhpc3RpbmcgYW5kIG5ldyBjb21tYW5kLCB3aGlj aCBpcyBzbyBmYXIgdXNlZA0KPiBmb3Igc2luZ2xlIHNlc3Npb24gb3BlcmF0aW9ucywgY2FuIGJl IGJ1bGsgb3BlcmF0aW9uIGVuYWJsZWQuIEZvcm1hdHRpbmcgb2Ygc3VjaA0KPiBidWxrIG9wZXJh dGlvbiBtZXNzYWdlIGlzIHN0aWxsIG9wZW4sIG1heWJlIGl0IGhhcyBpbXBhY3QgdG8gZXhpc3Rp bmcgYXBwbGljYXRpb25zJw0KPiBjb21tYW5kIHBhcnNlci4gSWYgd2UgZmluZCBhIHN1aXRhYmxl IGVuY29kaW5nIHNjaGVtZSBmb3Igc3VjaCBjb250YWluZXIgbWVzc2FnZSwNCj4gaXQncyBhIGNv bmNlcHQgdGhhdCBjYW4gYmUgZWFzaWx5IGFkb3B0ZWQgYnkgYW55IERpYW1ldGVyIGNvbW1hbmQg YW5kIGFwcGxpY2F0aW9uLg0KDQpbUWluXTogV2l0aCB0aGUgYXBwcm9hY2ggKGMpLCBpcyB0aGUg cHJvcG9zYWwgaGVyZSB1c2luZyBuZXN0ZWQgQ29tbWFuZCBDb2RlcywgaS5lLiwgZW5jYXBzdWxh dGUgDQpvciBncm91cCBleGlzdGluZyBjb21tYW5kIGNvZGVzIGludG8gb25lIGxvZ2ljYWwgY29u dGFpbmVyLiBUaGUgbG9naWNhbCBjb250YWluZXIgaXMgc3RpbGwgYSBjb21tYW5kIGNvZGUuIA0K SWYgdGhlIGFuc3dlciBpcyB5ZXMsIEkgYW0gdGhpbmtpbmcgd2h5IHdlIHNob3VsZCBjYXJyeSB0 aGUgZXhpc3RpbmcgY29tbWFuZCBjb2RlcyBiZWxvbmdpbmcgdG8gZGlmZmVyZW50IHVzZXIgIG9y IHRoZSBzYW1lIHVzZXIgdGhhdCBuZWVkcyBidWxrIG9wZXJhdGlvbg0KaW50byBvbmUgZGVkaWNh dGVkIGNvbW1hbmQgY29kZT8gSXMgaXQgZm9yIGEgZ3JvdXAgb2YgdXNlciBvciBhIHNpbmdsZSB1 c2VyPw0KDQo+IFdlJ2QgYmUgaW50ZXJlc3RlZCBpbiBtb3JlIG9waW5pb25zIGFib3V0IHRoZSBk aWZmZXJlbnQgYXBwcm9hY2hlcyBhbmQgSSBob3BlIHRoYXQNCj4gdGhpcyBlTWFpbCBjYW4gdHJp Z2dlciBzdWNoIGRpc2N1c3Npb24uDQo+IA0KPiBtYXJjbw0KPiANCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaW1l LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4gam91bmkga29yaG9uZW4NCj4+IFNl bnQ6IERpZW5zdGFnLCAxMC4gQXByaWwgMjAxMiAxMTo1Mw0KPj4gVG86IGRpbWVAaWV0Zi5vcmcN Cj4+IFN1YmplY3Q6IFtEaW1lXSB2ZXJ5IGRyYWZ0eSBJRVRGIzgzIG1lZXRpbmcgbWludXRlcyB1 cGxvYWRlZA0KPj4gDQo+PiBGb2xrcywNCj4+IA0KPj4gVGhleSBhcmUgdXAgbm93IGZvciBwdWJs aWMgcmV2aWV3LiBUaGFua3MgdG8gU2h3ZXRoYSBmb3IgdGFraW5nIGV4Y2VsbGVudA0KPj4gbWlu dXRlcy4NCj4+IA0KPj4gLSBKb3VuaQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IERpTUUgbWFpbGluZyBsaXN0DQo+PiBEaU1FQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5n IGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RpbWU= From glenzorn@gmail.com Wed Apr 11 01:39:12 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACEB11E814A for ; Wed, 11 Apr 2012 01:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6IdEtdm7N2G for ; Wed, 11 Apr 2012 01:39:12 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD64411E814C for ; Wed, 11 Apr 2012 01:39:11 -0700 (PDT) Received: by iazz13 with SMTP id z13so1149262iaz.31 for ; Wed, 11 Apr 2012 01:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zhspfNo/vLq3uPCPlAXEHRcYFUo09yu0bXRARgJZN0M=; b=NhuGrh4+fWksB0IDqsnBUIu2lI2Sp9i/mW1pnOexKrxIV0fCcKbYRgkdU32J4yMoGv XB0/nHFqiOM1IzKoYGYrGj0dyknjCAUg+WMzHrNKgTBefyqwVC4pYDvsuF/NTCTy9Dwh ZdalCkLB6aasMU5ms7/tf6Mm9zgi26j+a08ozFUM2MC3TDDvv5g55g+ndGmxpUksdXx7 xhDqgjYtkeLh+3rzB0vrc1NETBQEESpgC7rI2PL26b/ih7+NwlKNHv8VooCpaj5rB8AB orG0UixNqpmIERhj7WcksSSEqyn6GJQ5g49Ylx22SSV/WeXlu8Dr2UAbYcS7kJmNgxLd zUtg== Received: by 10.50.185.193 with SMTP id fe1mr4914221igc.9.1334133551595; Wed, 11 Apr 2012 01:39:11 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-57-104.revip2.asianet.co.th. [124.120.57.104]) by mx.google.com with ESMTPS id xf6sm5824975igb.13.2012.04.11.01.39.08 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 01:39:10 -0700 (PDT) Message-ID: <4F85432A.9080109@gmail.com> Date: Wed, 11 Apr 2012 15:39:06 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: jouni korhonen References: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> In-Reply-To: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:39:12 -0000 On 04/10/2012 04:53 PM, jouni korhonen wrote: > Folks, > > They are up now for public review. The URL is http://www.ietf.org/proceedings/83/minutes/minutes-83-dime.txt. > Thanks to Shwetha for taking excellent minutes. > > - Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Wed Apr 11 01:44:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5221F86D5 for ; Wed, 11 Apr 2012 01:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3yCLoVJDSlh for ; Wed, 11 Apr 2012 01:44:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 817D421F86D3 for ; Wed, 11 Apr 2012 01:44:08 -0700 (PDT) Received: by iazz13 with SMTP id z13so1156405iaz.31 for ; Wed, 11 Apr 2012 01:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K5o/iZTLIn4/AKT09XuEav7k3j0R1mwzpOrUkyw4Xug=; b=RbfTO5ZfD7pQ0BBGIe1yv43h25zD5Ctizf7G8Q3EFTjr+xBWAWEWrlWXSMevLm1hwc sk3JkSEqu+vTgk34pBnEkNv5HMiqm7vId/q71bqrFOcS0rVFES1giHOpguUGdEGYIiiF 012QlqC3TXsj5UI+1LcjCA+t1pKWPxldwLw2uLfeOZ5vCG9mRdlQnizXPYYWR4LawLql h/ygEib4+1mi9n8XlGMtFpBs0TQ65NYa/6s9dA2stzWJYnopr/OAidgacFYpiSjreEZU 3dRhNlYT/aaXveqq5jmA7h2OQo+0SDyd8QsCEocJLAxcwzGzV6OR7eE+Gyeg8BBGKyEj PRLg== Received: by 10.50.212.97 with SMTP id nj1mr1217689igc.65.1334133848081; Wed, 11 Apr 2012 01:44:08 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-57-104.revip2.asianet.co.th. [124.120.57.104]) by mx.google.com with ESMTPS id hq3sm55574172igc.0.2012.04.11.01.44.05 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 01:44:07 -0700 (PDT) Message-ID: <4F854453.90702@gmail.com> Date: Wed, 11 Apr 2012 15:44:03 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: jouni korhonen References: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> In-Reply-To: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:44:09 -0000 On 04/10/2012 04:53 PM, jouni korhonen wrote: > Folks, > > They are up now for public review. Thanks to Shwetha for taking excellent minutes. The minutes say: Glen Zorn: draft-ietf-dmer-rfc4005bis - issue tracker updated Jouni K: Next step is WGLC. At what point in time might we expect the next step to take place? > > - Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Wed Apr 11 01:47:33 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91D021F86DF for ; Wed, 11 Apr 2012 01:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 318kaGmTrWAw for ; Wed, 11 Apr 2012 01:47:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F521F86DB for ; Wed, 11 Apr 2012 01:47:33 -0700 (PDT) Received: by iazz13 with SMTP id z13so1161712iaz.31 for ; Wed, 11 Apr 2012 01:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=M0NF25CsZiCdgScvyH4QMyLoSQzF5yNvp1kggKwY1A0=; b=As9v6jRduewQJEpbHlNcInQvBK0fCkwu5lqTHwYRpVwzcUc8Dkv/doFhgK6AKDL56F AXj3bMJAJnGc8HFTl/+owHqznGL12mfO1Zs4aI5CYsQS93UQyhxLYTE5oyH51JIPKqZN jQZ1pnfX10GYIOEWlalkxuM2fJDXwb5dLayB4OAdvM4oa+h/P8f/2hJoMh1NFCTPlG2U muur0aRpYFoLN8Znb0iaghQHSPXJcbHMzD33xswSqnz8G7yc/WvHU3gLsbKDZJ6Ov2S8 3bM54Jt9NWiQrqcGpfWMkupgmFFwMzjQK/wax1oMUfvMXAa85v/nikWPPmVqEpt+gH1n 7Ggg== Received: by 10.42.137.67 with SMTP id x3mr8810105ict.52.1334134052820; Wed, 11 Apr 2012 01:47:32 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-57-104.revip2.asianet.co.th. [124.120.57.104]) by mx.google.com with ESMTPS id hq3sm55600027igc.0.2012.04.11.01.47.29 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 01:47:31 -0700 (PDT) Message-ID: <4F85451F.8030800@gmail.com> Date: Wed, 11 Apr 2012 15:47:27 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Glen Zorn References: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> <4F854453.90702@gmail.com> In-Reply-To: <4F854453.90702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:47:33 -0000 On 04/11/2012 03:44 PM, Glen Zorn wrote: > On 04/10/2012 04:53 PM, jouni korhonen wrote: >> Folks, >> >> They are up now for public review. Thanks to Shwetha for taking >> excellent minutes. > > The minutes say: > > Glen Zorn: draft-ietf-dmer-rfc4005bis - issue tracker updated > Jouni K: Next step is WGLC. > > At what point in time might we expect the next step to take place? Actually, the tracker issues were _from_ WGLC, I believe; shouldn't the next step be request for publication? From Marco.Liebsch@neclab.eu Wed Apr 11 06:09:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33811E8091 for ; Wed, 11 Apr 2012 06:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVg-S1w0X2zQ for ; Wed, 11 Apr 2012 06:09:38 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E826611E80FB for ; Wed, 11 Apr 2012 06:09:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 71DE8100C3F; Wed, 11 Apr 2012 15:08:40 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUdMazPl0tdA; Wed, 11 Apr 2012 15:08:40 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4FBDF100C30; Wed, 11 Apr 2012 15:08:25 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 11 Apr 2012 15:09:22 +0200 From: Marco Liebsch To: Qin Wu , jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded Thread-Index: AQHNF6EP6KvMuGZY/0iFk+anXwwzMpaVlBew Date: Wed, 11 Apr 2012 13:09:21 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:09:39 -0000 Hi Qin, please see inline. > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Mittwoch, 11. April 2012 07:06 > To: Marco Liebsch; jouni korhonen; dime@ietf.org > Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty > IETF#83 meeting minutes uploaded >=20 > Hi, Marco: > I think the criteria we need to consider are: > how much protocol extension is really required? > how much such protocol affects the existing implementaion? > How many command exchanges can we reduce? > please see my comments inline. The list of criteria sounds reasonable to me. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "jouni korhonen" ; > Sent: Tuesday, April 10, 2012 10:06 PM > Subject: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#8= 3 > meeting minutes uploaded >=20 >=20 > > Thanks for the meeting minutes. > > > > As the notes refer to a discussion about different means to signal bulk > operation, > > let's go through this exercise and evaluate the three candidates to sig= nal > > bulk commands. > > > > Just to summarize the three alternatives according to Mark's presentati= on: > > (a) New group commands > > (b) Re-use existing commands and command codes, indicate group > operation > > on the attached context (AVPs) within the message, e.g. by adding group > > identifier, flags, .. > > (c) Single new bulk command (1 new command code), indicate Diameter > command, > > to which the group operation applies, within the message > > > > Whereas I see (a) as straight forward method, a counterargument could b= e > the > > need of additional command codes for each command, which should be > enabled > > for group operation. Other SDOs, which specify new command codes, need > > to follow the same rules and request new command codes for all existing > commands > > which should be bulk-operation enabled. >=20 > [Qin]: Agree. One more thing I am thinking is how to use existing Command > Code can handle > group assigment. It looks to me additional semantics in these existing > Command are needed to > distinguish adding a session into group from removing a sesion into group= or > distinguish group > assignment from bulk signaling operation. > New Command flags may be example of such additional semantics but > seems not compelling.:-) IMO, join/leave of a session to/from one or multiple groups should be treat= ed separately from bulk commands.=20 >=20 > > With (b), all existing messages could be re-used and potentially bulk > operation enabled > > by using a different application ID and adding an additional label to t= he > message, e.g. > > flags, Group session AVP, etc. Such approach allows much flexibil8ity, = but > we need > > to ensure compatibility with proxies etc, which are not bulk-operation > enabled. > > Possibly using a new application ID solves that issue already. >=20 > [Qin]: I am not sure proxy in between needs to be bulk-operation enabled. > It looks to me bulk operation only happens on the source and final > destination > of the Diameter message. What if a proxy receives a bulk command, which carries a new application ID= ?=20 >From operation it should not bother, I agree, as per-session and group oper= ations are end-to-end. If implementations process the command code or application = ID, then compatibility may depend on how proxies or relay agents treat such mes= sages. >=20 > > With (c), the DIME WG could specify a single dedicated command for bulk > operations, > > and the actual payload carries the command code of the Diameter message > to be > > executed as bulk operation (e.g. RAR, STR, ..) as well as the associate= d > command's > > AVP, plus a group identifier. Any existing and new command, which is so= far > used > > for single session operations, can be bulk operation enabled. Formattin= g of > such > > bulk operation message is still open, maybe it has impact to existing > applications' > > command parser. If we find a suitable encoding scheme for such containe= r > message, > > it's a concept that can be easily adopted by any Diameter command and > application. >=20 > [Qin]: With the approach (c), is the proposal here using nested Command > Codes, i.e., encapsulate > or group existing command codes into one logical container. The logical > container is still a command code. > If the answer is yes, I am thinking why we should carry the existing comm= and > codes belonging to different user or the same user that needs bulk > operation > into one dedicated command code? Is it for a group of user or a single us= er? The idea was to have a single command code for bulk operations, which is referred to in the Diameter header. I did 'not' consider having the complet= e Diameter header twice, for the bulk command and for the Diameter command, which is to be executed as bulk operation. So we may keep one Diameter head= er, which carries the bulk command code, a single new AVP, which carries the Di= ameter command (RAR, STR, ..), and the required attributes for group identificatio= n and the AVPs, that apply to the group. So, I did not have nesting in mind. marco >=20 > > We'd be interested in more opinions about the different approaches and = I > hope that > > this eMail can trigger such discussion. > > > > marco > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of > >> jouni korhonen > >> Sent: Dienstag, 10. April 2012 11:53 > >> To: dime@ietf.org > >> Subject: [Dime] very drafty IETF#83 meeting minutes uploaded > >> > >> Folks, > >> > >> They are up now for public review. Thanks to Shwetha for taking excell= ent > >> minutes. > >> > >> - Jouni > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Wed Apr 11 08:01:06 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3311E80C6 for ; Wed, 11 Apr 2012 08:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01220qMfETuz for ; Wed, 11 Apr 2012 08:01:05 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B948E11E80AA for ; Wed, 11 Apr 2012 08:01:04 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C2EAADE400A; Wed, 11 Apr 2012 17:02:35 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B5ADADE4005; Wed, 11 Apr 2012 17:02:35 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 17:01:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2012 17:01:02 +0200 Message-ID: In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded Thread-Index: AQHNF6EP6KvMuGZY/0iFk+anXwwzMpaVlBewgAAi2qA= References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> From: To: , , , X-OriginalArrivalTime: 11 Apr 2012 15:01:03.0366 (UTC) FILETIME=[E9FB3A60:01CD17F3] Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:01:06 -0000 > > > With (b), all existing messages could be re-used and potentially = bulk > > operation enabled > > > by using a different application ID and adding an additional label = to the > > > message, e.g. > > > flags, Group session AVP, etc. Such approach allows much = flexibil8ity, but > > > we need > > > to ensure compatibility with proxies etc, which are not = bulk-operation > > > enabled. > > > Possibly using a new application ID solves that issue already. > > =20 > > [Qin]: I am not sure proxy in between needs to be bulk-operation = enabled. > > It looks to me bulk operation only happens on the source and final > > destination > > of the Diameter message. > What if a proxy receives a bulk command, which carries a new = application ID?=20 > From operation it should not bother, I agree, as per-session and group = operations > are end-to-end. If implementations process the command code or = application ID, > then compatibility may depend on how proxies or relay agents treat = such messages. [LM] I think that the point is that the solution could be transparent to = proxy if you can reuse existing applications without major impacts and = not updating the application-Id. Of course, if you have to use a new = application-id, any proxy will have to advertize the new application, as = per definition of a proxy, even if the proxy is transparent to bulk = operations. Regards, Lionel=20 -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Marco Liebsch Envoy=E9=A0: mercredi 11 avril 2012 15:09 =C0=A0: Qin Wu; jouni korhonen; dime@ietf.org Objet=A0: Re: [Dime] discuss encoding of bulk commands /RE: very drafty = IETF#83 meeting minutes uploaded Hi Qin, please see inline. > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Mittwoch, 11. April 2012 07:06 > To: Marco Liebsch; jouni korhonen; dime@ietf.org > Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty > IETF#83 meeting minutes uploaded >=20 > Hi, Marco: > I think the criteria we need to consider are: > how much protocol extension is really required? > how much such protocol affects the existing implementaion? > How many command exchanges can we reduce? > please see my comments inline. The list of criteria sounds reasonable to me. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "jouni korhonen" ; > Sent: Tuesday, April 10, 2012 10:06 PM > Subject: [Dime] discuss encoding of bulk commands /RE: very drafty = IETF#83 > meeting minutes uploaded >=20 >=20 > > Thanks for the meeting minutes. > > > > As the notes refer to a discussion about different means to signal = bulk > operation, > > let's go through this exercise and evaluate the three candidates to = signal > > bulk commands. > > > > Just to summarize the three alternatives according to Mark's = presentation: > > (a) New group commands > > (b) Re-use existing commands and command codes, indicate group > operation > > on the attached context (AVPs) within the message, e.g. by adding = group > > identifier, flags, .. > > (c) Single new bulk command (1 new command code), indicate Diameter > command, > > to which the group operation applies, within the message > > > > Whereas I see (a) as straight forward method, a counterargument = could be > the > > need of additional command codes for each command, which should be > enabled > > for group operation. Other SDOs, which specify new command codes, = need > > to follow the same rules and request new command codes for all = existing > commands > > which should be bulk-operation enabled. >=20 > [Qin]: Agree. One more thing I am thinking is how to use existing = Command > Code can handle > group assigment. It looks to me additional semantics in these existing > Command are needed to > distinguish adding a session into group from removing a sesion into = group or > distinguish group > assignment from bulk signaling operation. > New Command flags may be example of such additional semantics but > seems not compelling.:-) IMO, join/leave of a session to/from one or multiple groups should be = treated separately from bulk commands.=20 >=20 > > With (b), all existing messages could be re-used and potentially = bulk > operation enabled > > by using a different application ID and adding an additional label = to the > message, e.g. > > flags, Group session AVP, etc. Such approach allows much = flexibil8ity, but > we need > > to ensure compatibility with proxies etc, which are not = bulk-operation > enabled. > > Possibly using a new application ID solves that issue already. >=20 > [Qin]: I am not sure proxy in between needs to be bulk-operation = enabled. > It looks to me bulk operation only happens on the source and final > destination > of the Diameter message. What if a proxy receives a bulk command, which carries a new application = ID?=20 >From operation it should not bother, I agree, as per-session and group = operations are end-to-end. If implementations process the command code or = application ID, then compatibility may depend on how proxies or relay agents treat such = messages. >=20 > > With (c), the DIME WG could specify a single dedicated command for = bulk > operations, > > and the actual payload carries the command code of the Diameter = message > to be > > executed as bulk operation (e.g. RAR, STR, ..) as well as the = associated > command's > > AVP, plus a group identifier. Any existing and new command, which is = so far > used > > for single session operations, can be bulk operation enabled. = Formatting of > such > > bulk operation message is still open, maybe it has impact to = existing > applications' > > command parser. If we find a suitable encoding scheme for such = container > message, > > it's a concept that can be easily adopted by any Diameter command = and > application. >=20 > [Qin]: With the approach (c), is the proposal here using nested = Command > Codes, i.e., encapsulate > or group existing command codes into one logical container. The = logical > container is still a command code. > If the answer is yes, I am thinking why we should carry the existing = command > codes belonging to different user or the same user that needs bulk > operation > into one dedicated command code? Is it for a group of user or a single = user? The idea was to have a single command code for bulk operations, which is referred to in the Diameter header. I did 'not' consider having the = complete Diameter header twice, for the bulk command and for the Diameter = command, which is to be executed as bulk operation. So we may keep one Diameter = header, which carries the bulk command code, a single new AVP, which carries the = Diameter command (RAR, STR, ..), and the required attributes for group = identification and the AVPs, that apply to the group. So, I did not have nesting in = mind. marco >=20 > > We'd be interested in more opinions about the different approaches = and I > hope that > > this eMail can trigger such discussion. > > > > marco > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = Behalf > Of > >> jouni korhonen > >> Sent: Dienstag, 10. April 2012 11:53 > >> To: dime@ietf.org > >> Subject: [Dime] very drafty IETF#83 meeting minutes uploaded > >> > >> Folks, > >> > >> They are up now for public review. Thanks to Shwetha for taking = excellent > >> minutes. > >> > >> - Jouni > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From mark@azu.ca Wed Apr 11 08:09:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF211E8163 for ; Wed, 11 Apr 2012 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhG9moVrW7VU for ; Wed, 11 Apr 2012 08:09:50 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE41411E815A for ; Wed, 11 Apr 2012 08:09:49 -0700 (PDT) Received: by qcsq13 with SMTP id q13so741791qcs.31 for ; Wed, 11 Apr 2012 08:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Ey89JLH3A4yMFW3mzR/S2CRrM47Mch5/6ehB3EL6BxY=; b=dLFzSKtmUJWXWIbTUQB67ClbOp+c29sbR+qTb1vFwwEphggRUu+LegUrWr3Qm9wdM4 AO2l77y5tToYjq20n1HYYawGRr5CwwnVUCgxnf/SfCjUzsBS28ReC/y0BIXLrSopTNwk 9yhHvGptJrXNdxZzfpUdBvPm7LlOaEC2Pol+Q5Lie3p094rkH22V92S1xyk/YHblpDXr WiCsZGDmnlDylaRPWwflR1CQzQuH0cYtcBDsbNZjclo1xlu2H2DdPJE6Rv+BBTRq6pZl FWw+3KKRSrM+TJv9GLhKwuaSXGkb6CNtOzy47bV0QVctkAnBrfpJrYmHK+49dlA+utE4 EFig== MIME-Version: 1.0 Received: by 10.224.31.197 with SMTP id z5mr252017qac.26.1334156989211; Wed, 11 Apr 2012 08:09:49 -0700 (PDT) Received: by 10.229.182.76 with HTTP; Wed, 11 Apr 2012 08:09:49 -0700 (PDT) In-Reply-To: References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> Date: Wed, 11 Apr 2012 11:09:49 -0400 Message-ID: From: Mark Jones To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmp3vnVfoQ59WkIUXCaBChff9EIR0EwCmPB6WsyIy0hTuplxBae0AAfPP6wxW6ztSnGRPXj Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:09:50 -0000 Hi Tina, I agree that the role of a proxy in group signalling has not been explored in the current draft and appreciate your offer to work on this aspect. Further comments inline. On Wed, Apr 4, 2012 at 7:41 PM, Tina TSOU wr= ote: > Hi Jouni and Mark, > The problem statement is valid and the solution can work in basic scenari= os. > > However the solution may have some limit in roaming scenario. > > Consider a network having a WLAN AN (hosting a Diameter Client) requestin= g some 3G internet resources, visited network proxies and home network serv= er as below: > > Client -------------- ---------- {Home network serv= er} > =A0 =A0 =A0 =A0 -------------- ----------{Home netw= ork server} > > The session path can be established through either of the visited n/w pro= xies. For all the messages of same session, client can ensure that the sess= ion path through stateful nodes is maintained. The visited n/w proxies woul= d require that the session path be maintained for offline charging etc. In your example, I understand from "session path" that you're assuming the client will ensure that the STR traverses the same visited n/w proxy so that state is cleaned up in the appropriate proxy, right? > In this scenario, if client uses group signalling method to terminate all= sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will = be aware of session termination. Since there are no follow-up messages, the= re is no mechanism to let the other proxy know that the sessions are termin= ated. If the client knows the session path for each session then it knows that both visited n/w proxies need to receive the GSTR. However, if the client sends the GSTR to both proxies then the home n/w server is going to get two GSTR for the same group from the same origin host. Yuck! Since groups assignments are arbitrary, the client could create a subgroup per session path and send the subgroup GSTR to the appropriate proxy. Path failures would make the error handling very complex though. > This problem can be avoided in Server initiated group signalling cases (G= RAR & GASR) as the PER_SESSION mode can be used for follow up exchanges. It could also be avoided in the GSTR case. If the client knows that the group termination will impact sessions that have session paths split across multiple proxies then it MUST revert to per-session STR signaling. However, I'd much prefer to solve this if we can. > Thus the current solution has a limit if client uses group signalling met= hod for session termination in roaming cases. > Agreed. > I volunteer to work together with Mark to find a solution for this case. > Great! > I'm NOT aware of any IPR in this area. > Me neither. > > Tina > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >> jouni korhonen >> Sent: Sunday, April 01, 2012 12:20 PM >> To: dime@ietf.org >> Cc: dime-chairs@tools.ietf.org >> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >> signaling-01 >> >> >> Folks, >> >> During the Dime WG meeting in Paris we decided to adopt draft-jones- >> diameter-group-signaling-01 >> "Diameter Group Signaling" as a working group I-D. The I-D is an input f= or >> the charter mile stone 'Protocol extension for bulk and group signaling'= . >> >> This mail starts a one week verification for the adoption. If you have >> strong concerns that the >> draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ >> for the solution, then express your concerns on the mailing list by 8th >> April. >> >> - Jouni & Lionel >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From mark@azu.ca Wed Apr 11 09:10:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8F21F853A for ; Wed, 11 Apr 2012 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZnS+wDOwP6y for ; Wed, 11 Apr 2012 09:10:30 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB9521F853E for ; Wed, 11 Apr 2012 09:10:29 -0700 (PDT) Received: by qaea16 with SMTP id a16so858318qae.10 for ; Wed, 11 Apr 2012 09:10:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=6eLrOwu2uufTGoM9zRWmsPWIh171hBG6pUDY338wv60=; b=WT4imCPBmTljfD8WmrFlgwi0SUPVrsblxS5I644C9pnY1aMOEo/BaRAIdHHf0sXcYx PPj7wc+34JeIvvB6LXsn6fddEtAUP0jELiMYJr53bJSwcxfd2Cn4eXOAQt5vSiaa2Squ aGCJA3wR6qXGTW7MYez7jtXsrdeoIjS1DV+QMEf6Ap7QYG9QJtj0Sy+sgrTXkDDWGTws UsbkHrm4BX+JE7Kzr1Ikye2NK6NEpbXs5pe2r1/gqqQdnaZ+XYTwuGtw/A1kEBalCJM7 GkjJKZg6nYq0N7ILbczxvHJLbd2jXb1gMFAu49hP3CH9E7LT7IOMMRroj0Rl2xbZfGfk EKyw== MIME-Version: 1.0 Received: by 10.229.137.3 with SMTP id u3mr6670161qct.20.1334160628877; Wed, 11 Apr 2012 09:10:28 -0700 (PDT) Received: by 10.229.182.76 with HTTP; Wed, 11 Apr 2012 09:10:28 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> Date: Wed, 11 Apr 2012 12:10:28 -0400 Message-ID: From: Mark Jones To: Marco Liebsch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlTrIKoNxFxlY0jnA1NMVneB60IjqZr2s9O5cX0bBPLq1HWtlN/BBydBB/EolzFfAhueSk8 Cc: "dime@ietf.org" Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:10:31 -0000 Hi Marco, Thanks for kicking off this thread. Some comments inline. On Tue, Apr 10, 2012 at 10:06 AM, Marco Liebsch w= rote: > Thanks for the meeting minutes. > > As the notes refer to a discussion about different means to signal bulk o= peration, > let's go through this exercise and evaluate the three candidates to signa= l > bulk commands. > > Just to summarize the three alternatives according to Mark's presentation= : > (a) New group commands > (b) Re-use existing commands and command codes, indicate group operation > on the attached context (AVPs) within the message, e.g. by adding group > identifier, flags, .. > (c) Single new bulk command (1 new command code), indicate Diameter comma= nd, > to which the group operation applies, within the message > > Whereas I see (a) as straight forward method, a counterargument could be = the > need of additional command codes for each command, which should be enable= d > for group operation. Other SDOs, which specify new command codes, need > to follow the same rules and request new command codes for all existing c= ommands > which should be bulk-operation enabled. > Agreed but I don't think this is particularly onerous. SDOs no longer need to write an RFC to get new command codes. A simple request to IANA gets a vendor-specific command code. > With (b), all existing messages could be re-used and potentially bulk ope= ration enabled > by using a different application ID and adding an additional label to the= message, e.g. > flags, Group session AVP, etc. Such approach allows much flexibil8ity, bu= t we need > to ensure =A0compatibility with proxies etc, which are not bulk-operation= enabled. > Possibly using a new application ID solves that issue already. > I understood this proposal as defining a new command flag in the Diameter header to indicate that it was a grouped command. I think a new application id is required regardless. I think a new command flag will have more impact on existing Diameter stacks than (a) or (c) where the grouped semantics are handled at the application layer. > With (c), the DIME WG could specify a single dedicated command for bulk o= perations, > and the actual payload carries the command code of the Diameter message t= o be > executed as bulk operation (e.g. RAR, STR, ..) as well as the associated = command's > AVP, plus a group identifier. Any existing and new command, which is so f= ar used > for single session operations, can be bulk operation enabled. Formatting = of such > bulk operation message is still open, maybe it has impact to existing app= lications' > command parser. If we find a suitable encoding scheme for such container = message, > it's a concept that can be easily adopted by any Diameter command and app= lication. > This proposal definitely economizes command codes but they are not a scarce resource nor difficult to obtain. Can you elaborate on why this can be more "easily adopted" because I do not see a reduction in specification or implementation effort? If existing commands are simply re-packaged as a grouped AVP, what does one do with those required AVPs that are per-session, e.g. User-Name, Session-Id? Specification text will be required to describe how these surplus AVPs are to be treated. With proposal (a), these surplus AVPs are simply omitted and the ABNF describes the new command structure. I also have doubts that all commands can be re-packaged as a grouped command so specification text will still be required to describe which commands can be grouped and their associated semantics. > We'd be interested in more opinions about the different approaches and I = hope that > this eMail can trigger such discussion. > Agreed. It would be good to hear some new voices on the list. We discussed these three options in Paris but this is certainly not a closed list. New proposals are also welcome. > marco > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >> jouni korhonen >> Sent: Dienstag, 10. April 2012 11:53 >> To: dime@ietf.org >> Subject: [Dime] very drafty IETF#83 meeting minutes uploaded >> >> Folks, >> >> They are up now for public review. Thanks to Shwetha for taking excellen= t >> minutes. >> >> - Jouni >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Tina.Tsou.Zouting@huawei.com Wed Apr 11 22:38:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B1421F8527 for ; Wed, 11 Apr 2012 22:38:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrJ87x0Y3234 for ; Wed, 11 Apr 2012 22:38:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0308321F851D for ; Wed, 11 Apr 2012 22:38:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD71084; Thu, 12 Apr 2012 01:38:02 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 22:34:30 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Apr 2012 22:34:01 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 12 Apr 2012 13:34:29 +0800 From: Tina TSOU To: Mark Jones Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 Thread-Index: AQHNEDyF4CFv35exeUKXaSyq14pyOpaLVqMggAntDoCAAXbdEA== Date: Thu, 12 Apr 2012 05:34:29 +0000 Message-ID: References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.215] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 05:38:04 -0000 > -----Original Message----- > From: Mark Jones [mailto:mark@azu.ca] > Sent: Wednesday, April 11, 2012 8:10 AM > To: Tina TSOU > Cc: jouni korhonen; dime@ietf.org; dime-chairs@tools.ietf.org > Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group- > signaling-01 >=20 > Hi Tina, >=20 > I agree that the role of a proxy in group signalling has not been > explored in the current draft and appreciate your offer to work on > this aspect. Further comments inline. >=20 > On Wed, Apr 4, 2012 at 7:41 PM, Tina TSOU > wrote: > > Hi Jouni and Mark, > > The problem statement is valid and the solution can work in basic > scenarios. > > > > However the solution may have some limit in roaming scenario. > > > > Consider a network having a WLAN AN (hosting a Diameter Client) > requesting some 3G internet resources, visited network proxies and home > network server as below: > > > > Client -------------- ---------- {Home network > server} > > =A0 =A0 =A0 =A0 -------------- ----------{Home ne= twork > server} > > > > The session path can be established through either of the visited n/w > proxies. For all the messages of same session, client can ensure that > the session path through stateful nodes is maintained. The visited n/w > proxies would require that the session path be maintained for offline > charging etc. >=20 > In your example, I understand from "session path" that you're assuming > the client will ensure that the STR traverses the same visited n/w > proxy so that state is cleaned up in the appropriate proxy, right? Right. >=20 > > In this scenario, if client uses group signalling method to terminate > all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path > will be aware of session termination. Since there are no follow-up > messages, there is no mechanism to let the other proxy know that the > sessions are terminated. >=20 > If the client knows the session path for each session then it knows > that both visited n/w proxies need to receive the GSTR. However, if > the client sends the GSTR to both proxies then the home n/w server is > going to get two GSTR for the same group from the same origin host. > Yuck! Yuck indeed! >=20 > Since groups assignments are arbitrary, the client could create a > subgroup per session path and send the subgroup GSTR to the > appropriate proxy. Path failures would make the error handling very > complex though. It is a problem of scale. If there is only 1 visited n/w involved, this app= roach is OK. If there are more than one, (for eg. a HK CSL user in roaming = in India may need to connect to their home network through more than one vi= sited networks in the session path) client may not have enough information = to create sub groups appropriately. >=20 > > This problem can be avoided in Server initiated group signalling cases > (GRAR & GASR) as the PER_SESSION mode can be used for follow up > exchanges. >=20 > It could also be avoided in the GSTR case. If the client knows that > the group termination will impact sessions that have session paths > split across multiple proxies then it MUST revert to per-session STR > signaling. However, I'd much prefer to solve this if we can. Since it is not possible for the client to have complete information about = the roaming topology, this would limit the client to always revert to per-s= ession STR in all roaming cases. >=20 > > Thus the current solution has a limit if client uses group signalling > method for session termination in roaming cases. > > >=20 > Agreed. >=20 > > I volunteer to work together with Mark to find a solution for this > case. > > >=20 > Great! >=20 > > I'm NOT aware of any IPR in this area. > > >=20 > Me neither. >=20 > > > > Tina > > > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of > >> jouni korhonen > >> Sent: Sunday, April 01, 2012 12:20 PM > >> To: dime@ietf.org > >> Cc: dime-chairs@tools.ietf.org > >> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- > >> signaling-01 > >> > >> > >> Folks, > >> > >> During the Dime WG meeting in Paris we decided to adopt draft-jones- > >> diameter-group-signaling-01 > >> "Diameter Group Signaling" as a working group I-D. The I-D is an > input for > >> the charter mile stone 'Protocol extension for bulk and group > signaling'. > >> > >> This mail starts a one week verification for the adoption. If you > have > >> strong concerns that the > >> draft-jones-diameter-group-signaling-01 is not appropriate as a > _basis_ > >> for the solution, then express your concerns on the mailing list by > 8th > >> April. > >> > >> - Jouni & Lionel > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime From bill.wu@huawei.com Thu Apr 12 01:32:20 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EFA21F85D4 for ; Thu, 12 Apr 2012 01:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD8rsO1lmuA1 for ; Thu, 12 Apr 2012 01:32:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBFF21F85D0 for ; Thu, 12 Apr 2012 01:32:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEV78265; Thu, 12 Apr 2012 04:32:19 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 01:29:09 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 01:29:14 -0700 Received: from w53375 (10.138.41.149) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 16:29:11 +0800 Message-ID: From: Qin Wu To: Marco Liebsch , jouni korhonen , References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> Date: Thu, 12 Apr 2012 16:29:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:32:20 -0000 SGksIE1hcmNvLA0KSSBoYXZlIGEgZmV3IGZvbGxvd3VwIGNvbW1lbnRzLg0KDQpSZWdhcmRzIQ0K LVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYXJjbyBMaWVic2No IiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+DQpUbzogIlFpbiBXdSIgPGJpbGwud3VAaHVhd2Vp LmNvbT47ICJqb3VuaSBrb3Job25lbiIgPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+OyA8ZGltZUBp ZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTIgOTowOSBQTQ0KU3ViamVj dDogUkU6IFtEaW1lXSBkaXNjdXNzIGVuY29kaW5nIG9mIGJ1bGsgY29tbWFuZHMgL1JFOiB2ZXJ5 IGRyYWZ0eSBJRVRGIzgzIG1lZXRpbmcgbWludXRlcyB1cGxvYWRlZA0KDQoNCkhpIFFpbiwNCnBs ZWFzZSBzZWUgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NCj4gU2VudDogTWl0dHdvY2gsIDEx LiBBcHJpbCAyMDEyIDA3OjA2DQo+IFRvOiBNYXJjbyBMaWVic2NoOyBqb3VuaSBrb3Job25lbjsg ZGltZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RpbWVdIGRpc2N1c3MgZW5jb2Rpbmcgb2Yg YnVsayBjb21tYW5kcyAvUkU6IHZlcnkgZHJhZnR5DQo+IElFVEYjODMgbWVldGluZyBtaW51dGVz IHVwbG9hZGVkDQo+IA0KPiBIaSwgTWFyY286DQo+IEkgdGhpbmsgdGhlIGNyaXRlcmlhIHdlIG5l ZWQgdG8gY29uc2lkZXIgYXJlOg0KPiBob3cgbXVjaCBwcm90b2NvbCBleHRlbnNpb24gaXMgcmVh bGx5IHJlcXVpcmVkPw0KPiBob3cgbXVjaCBzdWNoIHByb3RvY29sIGFmZmVjdHMgdGhlIGV4aXN0 aW5nIGltcGxlbWVudGFpb24/DQo+IEhvdyBtYW55IGNvbW1hbmQgZXhjaGFuZ2VzIGNhbiB3ZSBy ZWR1Y2U/DQo+IHBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KDQpUaGUgbGlzdCBvZiBj cml0ZXJpYSBzb3VuZHMgcmVhc29uYWJsZSB0byBtZS4NCg0KPiANCj4gUmVnYXJkcyENCj4gLVFp bg0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJNYXJjbyBMaWVic2No IiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+DQo+IFRvOiAiam91bmkga29yaG9uZW4iIDxqb3Vu aS5ub3NwYW1AZ21haWwuY29tPjsgPGRpbWVAaWV0Zi5vcmc+DQo+IFNlbnQ6IFR1ZXNkYXksIEFw cmlsIDEwLCAyMDEyIDEwOjA2IFBNDQo+IFN1YmplY3Q6IFtEaW1lXSBkaXNjdXNzIGVuY29kaW5n IG9mIGJ1bGsgY29tbWFuZHMgL1JFOiB2ZXJ5IGRyYWZ0eSBJRVRGIzgzDQo+IG1lZXRpbmcgbWlu dXRlcyB1cGxvYWRlZA0KPiANCj4gDQo+ID4gVGhhbmtzIGZvciB0aGUgbWVldGluZyBtaW51dGVz Lg0KPiA+DQo+ID4gQXMgdGhlIG5vdGVzIHJlZmVyIHRvIGEgZGlzY3Vzc2lvbiBhYm91dCBkaWZm ZXJlbnQgbWVhbnMgdG8gc2lnbmFsIGJ1bGsNCj4gb3BlcmF0aW9uLA0KPiA+IGxldCdzIGdvIHRo cm91Z2ggdGhpcyBleGVyY2lzZSBhbmQgZXZhbHVhdGUgdGhlIHRocmVlIGNhbmRpZGF0ZXMgdG8g c2lnbmFsDQo+ID4gYnVsayBjb21tYW5kcy4NCj4gPg0KPiA+IEp1c3QgdG8gc3VtbWFyaXplIHRo ZSB0aHJlZSBhbHRlcm5hdGl2ZXMgYWNjb3JkaW5nIHRvIE1hcmsncyBwcmVzZW50YXRpb246DQo+ ID4gKGEpIE5ldyBncm91cCBjb21tYW5kcw0KPiA+IChiKSBSZS11c2UgZXhpc3RpbmcgY29tbWFu ZHMgYW5kIGNvbW1hbmQgY29kZXMsIGluZGljYXRlIGdyb3VwDQo+IG9wZXJhdGlvbg0KPiA+IG9u IHRoZSBhdHRhY2hlZCBjb250ZXh0IChBVlBzKSB3aXRoaW4gdGhlIG1lc3NhZ2UsIGUuZy4gYnkg YWRkaW5nIGdyb3VwDQo+ID4gaWRlbnRpZmllciwgZmxhZ3MsIC4uDQo+ID4gKGMpIFNpbmdsZSBu ZXcgYnVsayBjb21tYW5kICgxIG5ldyBjb21tYW5kIGNvZGUpLCBpbmRpY2F0ZSBEaWFtZXRlcg0K PiBjb21tYW5kLA0KPiA+IHRvIHdoaWNoIHRoZSBncm91cCBvcGVyYXRpb24gYXBwbGllcywgd2l0 aGluIHRoZSBtZXNzYWdlDQo+ID4NCj4gPiBXaGVyZWFzIEkgc2VlIChhKSBhcyBzdHJhaWdodCBm b3J3YXJkIG1ldGhvZCwgYSBjb3VudGVyYXJndW1lbnQgY291bGQgYmUNCj4gdGhlDQo+ID4gbmVl ZCBvZiBhZGRpdGlvbmFsIGNvbW1hbmQgY29kZXMgZm9yIGVhY2ggY29tbWFuZCwgd2hpY2ggc2hv dWxkIGJlDQo+IGVuYWJsZWQNCj4gPiBmb3IgZ3JvdXAgb3BlcmF0aW9uLiBPdGhlciBTRE9zLCB3 aGljaCBzcGVjaWZ5IG5ldyBjb21tYW5kIGNvZGVzLCBuZWVkDQo+ID4gdG8gZm9sbG93IHRoZSBz YW1lIHJ1bGVzIGFuZCByZXF1ZXN0IG5ldyBjb21tYW5kIGNvZGVzIGZvciBhbGwgZXhpc3RpbmcN Cj4gY29tbWFuZHMNCj4gPiB3aGljaCBzaG91bGQgYmUgYnVsay1vcGVyYXRpb24gZW5hYmxlZC4N Cj4gDQo+IFtRaW5dOiBBZ3JlZS4gT25lIG1vcmUgdGhpbmcgSSBhbSB0aGlua2luZyBpcyBob3cg dG8gdXNlIGV4aXN0aW5nIENvbW1hbmQNCj4gQ29kZSBjYW4gaGFuZGxlDQo+IGdyb3VwIGFzc2ln bWVudC4gSXQgbG9va3MgdG8gbWUgYWRkaXRpb25hbCBzZW1hbnRpY3MgaW4gdGhlc2UgZXhpc3Rp bmcNCj4gQ29tbWFuZCAgYXJlIG5lZWRlZCB0bw0KPiBkaXN0aW5ndWlzaCBhZGRpbmcgYSBzZXNz aW9uIGludG8gZ3JvdXAgZnJvbSByZW1vdmluZyBhIHNlc2lvbiBpbnRvIGdyb3VwIG9yDQo+IGRp c3Rpbmd1aXNoIGdyb3VwDQo+ICBhc3NpZ25tZW50IGZyb20gYnVsayBzaWduYWxpbmcgb3BlcmF0 aW9uLg0KPiBOZXcgQ29tbWFuZCBmbGFncyBtYXkgYmUgZXhhbXBsZSBvZiBzdWNoIGFkZGl0aW9u YWwgc2VtYW50aWNzIGJ1dA0KPiBzZWVtcyBub3QgY29tcGVsbGluZy46LSkNCg0KSU1PLCBqb2lu L2xlYXZlIG9mIGEgc2Vzc2lvbiB0by9mcm9tIG9uZSBvciBtdWx0aXBsZSBncm91cHMgc2hvdWxk IGJlIHRyZWF0ZWQNCnNlcGFyYXRlbHkgZnJvbSBidWxrIGNvbW1hbmRzLiANCg0KW1Fpbl06WWVz Lg0KDQo+IA0KPiA+IFdpdGggKGIpLCBhbGwgZXhpc3RpbmcgbWVzc2FnZXMgY291bGQgYmUgcmUt dXNlZCBhbmQgcG90ZW50aWFsbHkgYnVsaw0KPiBvcGVyYXRpb24gZW5hYmxlZA0KPiA+IGJ5IHVz aW5nIGEgZGlmZmVyZW50IGFwcGxpY2F0aW9uIElEIGFuZCBhZGRpbmcgYW4gYWRkaXRpb25hbCBs YWJlbCB0byB0aGUNCj4gbWVzc2FnZSwgZS5nLg0KPiA+IGZsYWdzLCBHcm91cCBzZXNzaW9uIEFW UCwgZXRjLiBTdWNoIGFwcHJvYWNoIGFsbG93cyBtdWNoIGZsZXhpYmlsOGl0eSwgYnV0DQo+IHdl IG5lZWQNCj4gPiB0byBlbnN1cmUgIGNvbXBhdGliaWxpdHkgd2l0aCBwcm94aWVzIGV0Yywgd2hp Y2ggYXJlIG5vdCBidWxrLW9wZXJhdGlvbg0KPiBlbmFibGVkLg0KPiA+IFBvc3NpYmx5IHVzaW5n IGEgbmV3IGFwcGxpY2F0aW9uIElEIHNvbHZlcyB0aGF0IGlzc3VlIGFscmVhZHkuDQo+IA0KPiBb UWluXTogSSBhbSBub3Qgc3VyZSBwcm94eSBpbiBiZXR3ZWVuIG5lZWRzIHRvIGJlIGJ1bGstb3Bl cmF0aW9uIGVuYWJsZWQuDQo+IEl0IGxvb2tzIHRvIG1lIGJ1bGsgb3BlcmF0aW9uIG9ubHkgaGFw cGVucyBvbiB0aGUgc291cmNlIGFuZCBmaW5hbA0KPiBkZXN0aW5hdGlvbg0KPiBvZiB0aGUgRGlh bWV0ZXIgbWVzc2FnZS4NCg0KV2hhdCBpZiBhIHByb3h5IHJlY2VpdmVzIGEgYnVsayBjb21tYW5k LCB3aGljaCBjYXJyaWVzIGEgbmV3IGFwcGxpY2F0aW9uIElEPyANCkZyb20gb3BlcmF0aW9uIGl0 IHNob3VsZCBub3QgYm90aGVyLCBJIGFncmVlLCBhcyBwZXItc2Vzc2lvbiBhbmQgZ3JvdXAgb3Bl cmF0aW9ucw0KYXJlIGVuZC10by1lbmQuIElmIGltcGxlbWVudGF0aW9ucyBwcm9jZXNzIHRoZSBj b21tYW5kIGNvZGUgb3IgYXBwbGljYXRpb24gSUQsDQp0aGVuIGNvbXBhdGliaWxpdHkgbWF5IGRl cGVuZCBvbiBob3cgcHJveGllcyBvciByZWxheSBhZ2VudHMgdHJlYXQgc3VjaCBtZXNzYWdlcy4N Cg0KW1Fpbl06IFllcywgcHJveGllcyBhbmQgcmVsYXkgYWdlbnRzIHNob3VsZCB1bmRlcnN0YW5k IHRoZSBtZXNzYWdlIGlmIGFueSBuZXcgY29tbWFuZCBjb2RlIA0Kb3IgYW55IG5ldyBhcHBsaWNh dGlvbiBJRCBpcyBkZWZpbmVkLiBUaGlzIGNhbiBiZSBkb25lIGJ5IENhcGFiaWxpdHkgRXhjaGFu Z2UuDQoNCkFub3RoZXIgcG9pbnQgaXMgcHJveGllcyBtYXkgbm90IG5lZWQgdG8gbG9vayBpbnRv IG1lc3NhZ2UgYW5kDQpkZWVwIHBhcnNlIHRoZSBwYXlsb2FkIG9mIHRoZSBtZXNzYWdlLg0KZS5n LiwgaWYgd2UgaGF2ZSBuZXcgQVZQLCBkbyB5b3UgdGhpbmsgcHJveHkgYWxzbyBuZWVkIHRvIHBh cnNlIHRoaXMgQVZQPw0KDQo+IA0KPiA+IFdpdGggKGMpLCB0aGUgRElNRSBXRyBjb3VsZCBzcGVj aWZ5IGEgc2luZ2xlIGRlZGljYXRlZCBjb21tYW5kIGZvciBidWxrDQo+IG9wZXJhdGlvbnMsDQo+ ID4gYW5kIHRoZSBhY3R1YWwgcGF5bG9hZCBjYXJyaWVzIHRoZSBjb21tYW5kIGNvZGUgb2YgdGhl IERpYW1ldGVyIG1lc3NhZ2UNCj4gdG8gYmUNCj4gPiBleGVjdXRlZCBhcyBidWxrIG9wZXJhdGlv biAoZS5nLiBSQVIsIFNUUiwgLi4pIGFzIHdlbGwgYXMgdGhlIGFzc29jaWF0ZWQNCj4gY29tbWFu ZCdzDQo+ID4gQVZQLCBwbHVzIGEgZ3JvdXAgaWRlbnRpZmllci4gQW55IGV4aXN0aW5nIGFuZCBu ZXcgY29tbWFuZCwgd2hpY2ggaXMgc28gZmFyDQo+IHVzZWQNCj4gPiBmb3Igc2luZ2xlIHNlc3Np b24gb3BlcmF0aW9ucywgY2FuIGJlIGJ1bGsgb3BlcmF0aW9uIGVuYWJsZWQuIEZvcm1hdHRpbmcg b2YNCj4gc3VjaA0KPiA+IGJ1bGsgb3BlcmF0aW9uIG1lc3NhZ2UgaXMgc3RpbGwgb3BlbiwgbWF5 YmUgaXQgaGFzIGltcGFjdCB0byBleGlzdGluZw0KPiBhcHBsaWNhdGlvbnMnDQo+ID4gY29tbWFu ZCBwYXJzZXIuIElmIHdlIGZpbmQgYSBzdWl0YWJsZSBlbmNvZGluZyBzY2hlbWUgZm9yIHN1Y2gg Y29udGFpbmVyDQo+IG1lc3NhZ2UsDQo+ID4gaXQncyBhIGNvbmNlcHQgdGhhdCBjYW4gYmUgZWFz aWx5IGFkb3B0ZWQgYnkgYW55IERpYW1ldGVyIGNvbW1hbmQgYW5kDQo+IGFwcGxpY2F0aW9uLg0K PiANCj4gW1Fpbl06IFdpdGggdGhlIGFwcHJvYWNoIChjKSwgaXMgdGhlIHByb3Bvc2FsIGhlcmUg dXNpbmcgbmVzdGVkIENvbW1hbmQNCj4gQ29kZXMsIGkuZS4sIGVuY2Fwc3VsYXRlDQo+IG9yIGdy b3VwIGV4aXN0aW5nIGNvbW1hbmQgY29kZXMgaW50byBvbmUgbG9naWNhbCBjb250YWluZXIuIFRo ZSBsb2dpY2FsDQo+IGNvbnRhaW5lciBpcyBzdGlsbCBhIGNvbW1hbmQgY29kZS4NCj4gSWYgdGhl IGFuc3dlciBpcyB5ZXMsIEkgYW0gdGhpbmtpbmcgd2h5IHdlIHNob3VsZCBjYXJyeSB0aGUgZXhp c3RpbmcgY29tbWFuZA0KPiBjb2RlcyBiZWxvbmdpbmcgdG8gZGlmZmVyZW50IHVzZXIgIG9yIHRo ZSBzYW1lIHVzZXIgdGhhdCBuZWVkcyBidWxrDQo+IG9wZXJhdGlvbg0KPiBpbnRvIG9uZSBkZWRp Y2F0ZWQgY29tbWFuZCBjb2RlPyBJcyBpdCBmb3IgYSBncm91cCBvZiB1c2VyIG9yIGEgc2luZ2xl IHVzZXI/DQoNClRoZSBpZGVhIHdhcyB0byBoYXZlIGEgc2luZ2xlIGNvbW1hbmQgY29kZSBmb3Ig YnVsayBvcGVyYXRpb25zLCB3aGljaCBpcw0KcmVmZXJyZWQgdG8gaW4gdGhlIERpYW1ldGVyIGhl YWRlci4gSSBkaWQgJ25vdCcgY29uc2lkZXIgaGF2aW5nIHRoZSBjb21wbGV0ZQ0KRGlhbWV0ZXIg aGVhZGVyIHR3aWNlLCBmb3IgdGhlIGJ1bGsgY29tbWFuZCBhbmQgZm9yIHRoZSBEaWFtZXRlciBj b21tYW5kLA0Kd2hpY2ggaXMgdG8gYmUgZXhlY3V0ZWQgYXMgYnVsayBvcGVyYXRpb24uIFNvIHdl IG1heSBrZWVwIG9uZSBEaWFtZXRlciBoZWFkZXIsDQp3aGljaCBjYXJyaWVzIHRoZSBidWxrIGNv bW1hbmQgY29kZSwgYSBzaW5nbGUgbmV3IEFWUCwgd2hpY2ggY2FycmllcyB0aGUgRGlhbWV0ZXIN CmNvbW1hbmQgKFJBUiwgU1RSLCAuLiksIGFuZCB0aGUgcmVxdWlyZWQgYXR0cmlidXRlcyBmb3Ig Z3JvdXAgaWRlbnRpZmljYXRpb24NCmFuZCB0aGUgQVZQcywgdGhhdCBhcHBseSB0byB0aGUgZ3Jv dXAuIFNvLCBJIGRpZCBub3QgaGF2ZSBuZXN0aW5nIGluIG1pbmQuDQoNCltRaW5dOiAgU28geW91 ciBwcm9wb3NhbCBpcyBkZWZpbmUgb25lIG5ldyBjb250YWluZXIgQVZQIHRvIENhcnJ5IGFsbCB0 aGUgY29kZSBvZiAgY29tbWFuZHMgdGhhdCBuZWVkDQpidWxrIG9wZXJhdGlvbi4gVGhpcyBBVlAg Y2FuIGJlIHVzZWQgdG8gaW5mb3JtIHRoZSByZWNlaXZlciBvZiB0aGUgbWVzc2FnZSB0aGF0IHRo ZXNlIGNvbW1hbmRzIGNvZGVzDQpuZWVkIGJ1bGsgb3BlcmF0aW9uLiBhbSBJIHJpZ2h0Pw0KSW4g dGhhdCBjYXNlLCBpdCBsb29rcyB0byBtZSBidWxrIGNvbW1hbmQgY29kZSBpcyBub3QgcmVkdW5k YW50IHNpbmNlIHlvdSBjYW4gdXNlIGFub3RoZXIgbmV3IEFWUCB0aGF0DQpjYXJyaWVzIGdyb3Vw IGlkZW50aWZpZXIgdG8gaW5kaWNhdGUgdGhpcyBpcyBmb3IgYnVsayBvcGVyYXRpb24uIHdoYXQg YW0gSSBtaXNzaW5nPw0KDQoNCm1hcmNvDQoNCj4gDQo+ID4gV2UnZCBiZSBpbnRlcmVzdGVkIGlu IG1vcmUgb3BpbmlvbnMgYWJvdXQgdGhlIGRpZmZlcmVudCBhcHByb2FjaGVzIGFuZCBJDQo+IGhv cGUgdGhhdA0KPiA+IHRoaXMgZU1haWwgY2FuIHRyaWdnZXIgc3VjaCBkaXNjdXNzaW9uLg0KPiA+ DQo+ID4gbWFyY28NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBG cm9tOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZg0KPiA+PiBqb3VuaSBrb3Job25lbg0KPiA+PiBTZW50OiBEaWVuc3Rh ZywgMTAuIEFwcmlsIDIwMTIgMTE6NTMNCj4gPj4gVG86IGRpbWVAaWV0Zi5vcmcNCj4gPj4gU3Vi amVjdDogW0RpbWVdIHZlcnkgZHJhZnR5IElFVEYjODMgbWVldGluZyBtaW51dGVzIHVwbG9hZGVk DQo+ID4+DQo+ID4+IEZvbGtzLA0KPiA+Pg0KPiA+PiBUaGV5IGFyZSB1cCBub3cgZm9yIHB1Ymxp YyByZXZpZXcuIFRoYW5rcyB0byBTaHdldGhhIGZvciB0YWtpbmcgZXhjZWxsZW50DQo+ID4+IG1p bnV0ZXMuDQo+ID4+DQo+ID4+IC0gSm91bmkNCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPj4gRGlN RUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp bWUNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IERpTUUgbWFpbGluZyBsaXN0DQo+ID4gRGlNRUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ== From bill.wu@huawei.com Thu Apr 12 01:32:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63021F8609 for ; Thu, 12 Apr 2012 01:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6EklhkEVN89 for ; Thu, 12 Apr 2012 01:32:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 246C221F8607 for ; Thu, 12 Apr 2012 01:32:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEV78297; Thu, 12 Apr 2012 04:32:51 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 01:29:58 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 01:30:03 -0700 Received: from w53375 (10.138.41.149) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 16:29:55 +0800 Message-ID: <3A7A525371BD448C87C4F9AC33203B09@china.huawei.com> From: Qin Wu To: , , , References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> Date: Thu, 12 Apr 2012 16:29:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:32:53 -0000 QWdyZWUuDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPGxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbT4NClRvOiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+OyA8YmlsbC53dUBo dWF3ZWkuY29tPjsgPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+OyA8ZGltZUBpZXRmLm9yZz4NClNl bnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMTIgMTE6MDEgUE0NClN1YmplY3Q6IFJFOiBbRGlt ZV0gZGlzY3VzcyBlbmNvZGluZyBvZiBidWxrIGNvbW1hbmRzIC9SRTogdmVyeSBkcmFmdHkgSUVU RiM4MyBtZWV0aW5nIG1pbnV0ZXMgdXBsb2FkZWQNCg0KDQo+ID4gPiBXaXRoIChiKSwgYWxsIGV4 aXN0aW5nIG1lc3NhZ2VzIGNvdWxkIGJlIHJlLXVzZWQgYW5kIHBvdGVudGlhbGx5IGJ1bGsNCj4g PiBvcGVyYXRpb24gZW5hYmxlZA0KPiA+ID4gYnkgdXNpbmcgYSBkaWZmZXJlbnQgYXBwbGljYXRp b24gSUQgYW5kIGFkZGluZyBhbiBhZGRpdGlvbmFsIGxhYmVsIHRvIHRoZQ0KPiA+ID4gbWVzc2Fn ZSwgZS5nLg0KPiA+ID4gZmxhZ3MsIEdyb3VwIHNlc3Npb24gQVZQLCBldGMuIFN1Y2ggYXBwcm9h Y2ggYWxsb3dzIG11Y2ggZmxleGliaWw4aXR5LCBidXQNCj4gPiA+IHdlIG5lZWQNCj4gPiA+IHRv IGVuc3VyZSAgY29tcGF0aWJpbGl0eSB3aXRoIHByb3hpZXMgZXRjLCB3aGljaCBhcmUgbm90IGJ1 bGstb3BlcmF0aW9uDQo+ID4gPiBlbmFibGVkLg0KPiA+ID4gUG9zc2libHkgdXNpbmcgYSBuZXcg YXBwbGljYXRpb24gSUQgc29sdmVzIHRoYXQgaXNzdWUgYWxyZWFkeS4NCj4gPiAgDQo+ID4gW1Fp bl06IEkgYW0gbm90IHN1cmUgcHJveHkgaW4gYmV0d2VlbiBuZWVkcyB0byBiZSBidWxrLW9wZXJh dGlvbiBlbmFibGVkLg0KPiA+IEl0IGxvb2tzIHRvIG1lIGJ1bGsgb3BlcmF0aW9uIG9ubHkgaGFw cGVucyBvbiB0aGUgc291cmNlIGFuZCBmaW5hbA0KPiA+IGRlc3RpbmF0aW9uDQo+ID4gb2YgdGhl IERpYW1ldGVyIG1lc3NhZ2UuDQoNCj4gV2hhdCBpZiBhIHByb3h5IHJlY2VpdmVzIGEgYnVsayBj b21tYW5kLCB3aGljaCBjYXJyaWVzIGEgbmV3IGFwcGxpY2F0aW9uIElEPyANCj4gRnJvbSBvcGVy YXRpb24gaXQgc2hvdWxkIG5vdCBib3RoZXIsIEkgYWdyZWUsIGFzIHBlci1zZXNzaW9uIGFuZCBn cm91cCBvcGVyYXRpb25zDQo+IGFyZSBlbmQtdG8tZW5kLiBJZiBpbXBsZW1lbnRhdGlvbnMgcHJv Y2VzcyB0aGUgY29tbWFuZCBjb2RlIG9yIGFwcGxpY2F0aW9uIElELA0KPiB0aGVuIGNvbXBhdGli aWxpdHkgbWF5IGRlcGVuZCBvbiBob3cgcHJveGllcyBvciByZWxheSBhZ2VudHMgdHJlYXQgc3Vj aCBtZXNzYWdlcy4NCg0KW0xNXSBJIHRoaW5rIHRoYXQgdGhlIHBvaW50IGlzIHRoYXQgdGhlIHNv bHV0aW9uIGNvdWxkIGJlIHRyYW5zcGFyZW50IHRvIHByb3h5IGlmIHlvdSBjYW4gcmV1c2UgZXhp c3RpbmcgYXBwbGljYXRpb25zIHdpdGhvdXQgbWFqb3IgaW1wYWN0cyBhbmQgbm90IHVwZGF0aW5n IHRoZSBhcHBsaWNhdGlvbi1JZC4gT2YgY291cnNlLCBpZiB5b3UgaGF2ZSB0byB1c2UgYSBuZXcg YXBwbGljYXRpb24taWQsIGFueSBwcm94eSB3aWxsIGhhdmUgdG8gYWR2ZXJ0aXplIHRoZSBuZXcg YXBwbGljYXRpb24sIGFzIHBlciBkZWZpbml0aW9uIG9mIGEgcHJveHksIGV2ZW4gaWYgdGhlIHBy b3h5IGlzIHRyYW5zcGFyZW50IHRvIGJ1bGsgb3BlcmF0aW9ucy4NCg0KUmVnYXJkcywNCg0KTGlv bmVsIA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogZGltZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmNv IExpZWJzY2gNCkVudm956SA6IG1lcmNyZWRpIDExIGF2cmlsIDIwMTIgMTU6MDkNCsAgOiBRaW4g V3U7IGpvdW5pIGtvcmhvbmVuOyBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJlOiBbRGltZV0gZGlz Y3VzcyBlbmNvZGluZyBvZiBidWxrIGNvbW1hbmRzIC9SRTogdmVyeSBkcmFmdHkgSUVURiM4MyBt ZWV0aW5nIG1pbnV0ZXMgdXBsb2FkZWQNCg0KSGkgUWluLA0KcGxlYXNlIHNlZSBpbmxpbmUuDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUWluIFd1IFttYWlsdG86Ymls bC53dUBodWF3ZWkuY29tXQ0KPiBTZW50OiBNaXR0d29jaCwgMTEuIEFwcmlsIDIwMTIgMDc6MDYN Cj4gVG86IE1hcmNvIExpZWJzY2g7IGpvdW5pIGtvcmhvbmVuOyBkaW1lQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbRGltZV0gZGlzY3VzcyBlbmNvZGluZyBvZiBidWxrIGNvbW1hbmRzIC9SRTog dmVyeSBkcmFmdHkNCj4gSUVURiM4MyBtZWV0aW5nIG1pbnV0ZXMgdXBsb2FkZWQNCj4gDQo+IEhp LCBNYXJjbzoNCj4gSSB0aGluayB0aGUgY3JpdGVyaWEgd2UgbmVlZCB0byBjb25zaWRlciBhcmU6 DQo+IGhvdyBtdWNoIHByb3RvY29sIGV4dGVuc2lvbiBpcyByZWFsbHkgcmVxdWlyZWQ/DQo+IGhv dyBtdWNoIHN1Y2ggcHJvdG9jb2wgYWZmZWN0cyB0aGUgZXhpc3RpbmcgaW1wbGVtZW50YWlvbj8N Cj4gSG93IG1hbnkgY29tbWFuZCBleGNoYW5nZXMgY2FuIHdlIHJlZHVjZT8NCj4gcGxlYXNlIHNl ZSBteSBjb21tZW50cyBpbmxpbmUuDQoNClRoZSBsaXN0IG9mIGNyaXRlcmlhIHNvdW5kcyByZWFz b25hYmxlIHRvIG1lLg0KDQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5l Y2xhYi5ldT4NCj4gVG86ICJqb3VuaSBrb3Job25lbiIgPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+ OyA8ZGltZUBpZXRmLm9yZz4NCj4gU2VudDogVHVlc2RheSwgQXByaWwgMTAsIDIwMTIgMTA6MDYg UE0NCj4gU3ViamVjdDogW0RpbWVdIGRpc2N1c3MgZW5jb2Rpbmcgb2YgYnVsayBjb21tYW5kcyAv UkU6IHZlcnkgZHJhZnR5IElFVEYjODMNCj4gbWVldGluZyBtaW51dGVzIHVwbG9hZGVkDQo+IA0K PiANCj4gPiBUaGFua3MgZm9yIHRoZSBtZWV0aW5nIG1pbnV0ZXMuDQo+ID4NCj4gPiBBcyB0aGUg bm90ZXMgcmVmZXIgdG8gYSBkaXNjdXNzaW9uIGFib3V0IGRpZmZlcmVudCBtZWFucyB0byBzaWdu YWwgYnVsaw0KPiBvcGVyYXRpb24sDQo+ID4gbGV0J3MgZ28gdGhyb3VnaCB0aGlzIGV4ZXJjaXNl IGFuZCBldmFsdWF0ZSB0aGUgdGhyZWUgY2FuZGlkYXRlcyB0byBzaWduYWwNCj4gPiBidWxrIGNv bW1hbmRzLg0KPiA+DQo+ID4gSnVzdCB0byBzdW1tYXJpemUgdGhlIHRocmVlIGFsdGVybmF0aXZl cyBhY2NvcmRpbmcgdG8gTWFyaydzIHByZXNlbnRhdGlvbjoNCj4gPiAoYSkgTmV3IGdyb3VwIGNv bW1hbmRzDQo+ID4gKGIpIFJlLXVzZSBleGlzdGluZyBjb21tYW5kcyBhbmQgY29tbWFuZCBjb2Rl cywgaW5kaWNhdGUgZ3JvdXANCj4gb3BlcmF0aW9uDQo+ID4gb24gdGhlIGF0dGFjaGVkIGNvbnRl eHQgKEFWUHMpIHdpdGhpbiB0aGUgbWVzc2FnZSwgZS5nLiBieSBhZGRpbmcgZ3JvdXANCj4gPiBp ZGVudGlmaWVyLCBmbGFncywgLi4NCj4gPiAoYykgU2luZ2xlIG5ldyBidWxrIGNvbW1hbmQgKDEg bmV3IGNvbW1hbmQgY29kZSksIGluZGljYXRlIERpYW1ldGVyDQo+IGNvbW1hbmQsDQo+ID4gdG8g d2hpY2ggdGhlIGdyb3VwIG9wZXJhdGlvbiBhcHBsaWVzLCB3aXRoaW4gdGhlIG1lc3NhZ2UNCj4g Pg0KPiA+IFdoZXJlYXMgSSBzZWUgKGEpIGFzIHN0cmFpZ2h0IGZvcndhcmQgbWV0aG9kLCBhIGNv dW50ZXJhcmd1bWVudCBjb3VsZCBiZQ0KPiB0aGUNCj4gPiBuZWVkIG9mIGFkZGl0aW9uYWwgY29t bWFuZCBjb2RlcyBmb3IgZWFjaCBjb21tYW5kLCB3aGljaCBzaG91bGQgYmUNCj4gZW5hYmxlZA0K PiA+IGZvciBncm91cCBvcGVyYXRpb24uIE90aGVyIFNET3MsIHdoaWNoIHNwZWNpZnkgbmV3IGNv bW1hbmQgY29kZXMsIG5lZWQNCj4gPiB0byBmb2xsb3cgdGhlIHNhbWUgcnVsZXMgYW5kIHJlcXVl c3QgbmV3IGNvbW1hbmQgY29kZXMgZm9yIGFsbCBleGlzdGluZw0KPiBjb21tYW5kcw0KPiA+IHdo aWNoIHNob3VsZCBiZSBidWxrLW9wZXJhdGlvbiBlbmFibGVkLg0KPiANCj4gW1Fpbl06IEFncmVl LiBPbmUgbW9yZSB0aGluZyBJIGFtIHRoaW5raW5nIGlzIGhvdyB0byB1c2UgZXhpc3RpbmcgQ29t bWFuZA0KPiBDb2RlIGNhbiBoYW5kbGUNCj4gZ3JvdXAgYXNzaWdtZW50LiBJdCBsb29rcyB0byBt ZSBhZGRpdGlvbmFsIHNlbWFudGljcyBpbiB0aGVzZSBleGlzdGluZw0KPiBDb21tYW5kICBhcmUg bmVlZGVkIHRvDQo+IGRpc3Rpbmd1aXNoIGFkZGluZyBhIHNlc3Npb24gaW50byBncm91cCBmcm9t IHJlbW92aW5nIGEgc2VzaW9uIGludG8gZ3JvdXAgb3INCj4gZGlzdGluZ3Vpc2ggZ3JvdXANCj4g IGFzc2lnbm1lbnQgZnJvbSBidWxrIHNpZ25hbGluZyBvcGVyYXRpb24uDQo+IE5ldyBDb21tYW5k IGZsYWdzIG1heSBiZSBleGFtcGxlIG9mIHN1Y2ggYWRkaXRpb25hbCBzZW1hbnRpY3MgYnV0DQo+ IHNlZW1zIG5vdCBjb21wZWxsaW5nLjotKQ0KDQpJTU8sIGpvaW4vbGVhdmUgb2YgYSBzZXNzaW9u IHRvL2Zyb20gb25lIG9yIG11bHRpcGxlIGdyb3VwcyBzaG91bGQgYmUgdHJlYXRlZA0Kc2VwYXJh dGVseSBmcm9tIGJ1bGsgY29tbWFuZHMuIA0KDQo+IA0KPiA+IFdpdGggKGIpLCBhbGwgZXhpc3Rp bmcgbWVzc2FnZXMgY291bGQgYmUgcmUtdXNlZCBhbmQgcG90ZW50aWFsbHkgYnVsaw0KPiBvcGVy YXRpb24gZW5hYmxlZA0KPiA+IGJ5IHVzaW5nIGEgZGlmZmVyZW50IGFwcGxpY2F0aW9uIElEIGFu ZCBhZGRpbmcgYW4gYWRkaXRpb25hbCBsYWJlbCB0byB0aGUNCj4gbWVzc2FnZSwgZS5nLg0KPiA+ IGZsYWdzLCBHcm91cCBzZXNzaW9uIEFWUCwgZXRjLiBTdWNoIGFwcHJvYWNoIGFsbG93cyBtdWNo IGZsZXhpYmlsOGl0eSwgYnV0DQo+IHdlIG5lZWQNCj4gPiB0byBlbnN1cmUgIGNvbXBhdGliaWxp dHkgd2l0aCBwcm94aWVzIGV0Yywgd2hpY2ggYXJlIG5vdCBidWxrLW9wZXJhdGlvbg0KPiBlbmFi bGVkLg0KPiA+IFBvc3NpYmx5IHVzaW5nIGEgbmV3IGFwcGxpY2F0aW9uIElEIHNvbHZlcyB0aGF0 IGlzc3VlIGFscmVhZHkuDQo+IA0KPiBbUWluXTogSSBhbSBub3Qgc3VyZSBwcm94eSBpbiBiZXR3 ZWVuIG5lZWRzIHRvIGJlIGJ1bGstb3BlcmF0aW9uIGVuYWJsZWQuDQo+IEl0IGxvb2tzIHRvIG1l IGJ1bGsgb3BlcmF0aW9uIG9ubHkgaGFwcGVucyBvbiB0aGUgc291cmNlIGFuZCBmaW5hbA0KPiBk ZXN0aW5hdGlvbg0KPiBvZiB0aGUgRGlhbWV0ZXIgbWVzc2FnZS4NCg0KV2hhdCBpZiBhIHByb3h5 IHJlY2VpdmVzIGEgYnVsayBjb21tYW5kLCB3aGljaCBjYXJyaWVzIGEgbmV3IGFwcGxpY2F0aW9u IElEPyANCkZyb20gb3BlcmF0aW9uIGl0IHNob3VsZCBub3QgYm90aGVyLCBJIGFncmVlLCBhcyBw ZXItc2Vzc2lvbiBhbmQgZ3JvdXAgb3BlcmF0aW9ucw0KYXJlIGVuZC10by1lbmQuIElmIGltcGxl bWVudGF0aW9ucyBwcm9jZXNzIHRoZSBjb21tYW5kIGNvZGUgb3IgYXBwbGljYXRpb24gSUQsDQp0 aGVuIGNvbXBhdGliaWxpdHkgbWF5IGRlcGVuZCBvbiBob3cgcHJveGllcyBvciByZWxheSBhZ2Vu dHMgdHJlYXQgc3VjaCBtZXNzYWdlcy4NCg0KDQo+IA0KPiA+IFdpdGggKGMpLCB0aGUgRElNRSBX RyBjb3VsZCBzcGVjaWZ5IGEgc2luZ2xlIGRlZGljYXRlZCBjb21tYW5kIGZvciBidWxrDQo+IG9w ZXJhdGlvbnMsDQo+ID4gYW5kIHRoZSBhY3R1YWwgcGF5bG9hZCBjYXJyaWVzIHRoZSBjb21tYW5k IGNvZGUgb2YgdGhlIERpYW1ldGVyIG1lc3NhZ2UNCj4gdG8gYmUNCj4gPiBleGVjdXRlZCBhcyBi dWxrIG9wZXJhdGlvbiAoZS5nLiBSQVIsIFNUUiwgLi4pIGFzIHdlbGwgYXMgdGhlIGFzc29jaWF0 ZWQNCj4gY29tbWFuZCdzDQo+ID4gQVZQLCBwbHVzIGEgZ3JvdXAgaWRlbnRpZmllci4gQW55IGV4 aXN0aW5nIGFuZCBuZXcgY29tbWFuZCwgd2hpY2ggaXMgc28gZmFyDQo+IHVzZWQNCj4gPiBmb3Ig c2luZ2xlIHNlc3Npb24gb3BlcmF0aW9ucywgY2FuIGJlIGJ1bGsgb3BlcmF0aW9uIGVuYWJsZWQu IEZvcm1hdHRpbmcgb2YNCj4gc3VjaA0KPiA+IGJ1bGsgb3BlcmF0aW9uIG1lc3NhZ2UgaXMgc3Rp bGwgb3BlbiwgbWF5YmUgaXQgaGFzIGltcGFjdCB0byBleGlzdGluZw0KPiBhcHBsaWNhdGlvbnMn DQo+ID4gY29tbWFuZCBwYXJzZXIuIElmIHdlIGZpbmQgYSBzdWl0YWJsZSBlbmNvZGluZyBzY2hl bWUgZm9yIHN1Y2ggY29udGFpbmVyDQo+IG1lc3NhZ2UsDQo+ID4gaXQncyBhIGNvbmNlcHQgdGhh dCBjYW4gYmUgZWFzaWx5IGFkb3B0ZWQgYnkgYW55IERpYW1ldGVyIGNvbW1hbmQgYW5kDQo+IGFw cGxpY2F0aW9uLg0KPiANCj4gW1Fpbl06IFdpdGggdGhlIGFwcHJvYWNoIChjKSwgaXMgdGhlIHBy b3Bvc2FsIGhlcmUgdXNpbmcgbmVzdGVkIENvbW1hbmQNCj4gQ29kZXMsIGkuZS4sIGVuY2Fwc3Vs YXRlDQo+IG9yIGdyb3VwIGV4aXN0aW5nIGNvbW1hbmQgY29kZXMgaW50byBvbmUgbG9naWNhbCBj b250YWluZXIuIFRoZSBsb2dpY2FsDQo+IGNvbnRhaW5lciBpcyBzdGlsbCBhIGNvbW1hbmQgY29k ZS4NCj4gSWYgdGhlIGFuc3dlciBpcyB5ZXMsIEkgYW0gdGhpbmtpbmcgd2h5IHdlIHNob3VsZCBj YXJyeSB0aGUgZXhpc3RpbmcgY29tbWFuZA0KPiBjb2RlcyBiZWxvbmdpbmcgdG8gZGlmZmVyZW50 IHVzZXIgIG9yIHRoZSBzYW1lIHVzZXIgdGhhdCBuZWVkcyBidWxrDQo+IG9wZXJhdGlvbg0KPiBp bnRvIG9uZSBkZWRpY2F0ZWQgY29tbWFuZCBjb2RlPyBJcyBpdCBmb3IgYSBncm91cCBvZiB1c2Vy IG9yIGEgc2luZ2xlIHVzZXI/DQoNClRoZSBpZGVhIHdhcyB0byBoYXZlIGEgc2luZ2xlIGNvbW1h bmQgY29kZSBmb3IgYnVsayBvcGVyYXRpb25zLCB3aGljaCBpcw0KcmVmZXJyZWQgdG8gaW4gdGhl IERpYW1ldGVyIGhlYWRlci4gSSBkaWQgJ25vdCcgY29uc2lkZXIgaGF2aW5nIHRoZSBjb21wbGV0 ZQ0KRGlhbWV0ZXIgaGVhZGVyIHR3aWNlLCBmb3IgdGhlIGJ1bGsgY29tbWFuZCBhbmQgZm9yIHRo ZSBEaWFtZXRlciBjb21tYW5kLA0Kd2hpY2ggaXMgdG8gYmUgZXhlY3V0ZWQgYXMgYnVsayBvcGVy YXRpb24uIFNvIHdlIG1heSBrZWVwIG9uZSBEaWFtZXRlciBoZWFkZXIsDQp3aGljaCBjYXJyaWVz IHRoZSBidWxrIGNvbW1hbmQgY29kZSwgYSBzaW5nbGUgbmV3IEFWUCwgd2hpY2ggY2FycmllcyB0 aGUgRGlhbWV0ZXINCmNvbW1hbmQgKFJBUiwgU1RSLCAuLiksIGFuZCB0aGUgcmVxdWlyZWQgYXR0 cmlidXRlcyBmb3IgZ3JvdXAgaWRlbnRpZmljYXRpb24NCmFuZCB0aGUgQVZQcywgdGhhdCBhcHBs eSB0byB0aGUgZ3JvdXAuIFNvLCBJIGRpZCBub3QgaGF2ZSBuZXN0aW5nIGluIG1pbmQuDQoNCm1h cmNvDQoNCj4gDQo+ID4gV2UnZCBiZSBpbnRlcmVzdGVkIGluIG1vcmUgb3BpbmlvbnMgYWJvdXQg dGhlIGRpZmZlcmVudCBhcHByb2FjaGVzIGFuZCBJDQo+IGhvcGUgdGhhdA0KPiA+IHRoaXMgZU1h aWwgY2FuIHRyaWdnZXIgc3VjaCBkaXNjdXNzaW9uLg0KPiA+DQo+ID4gbWFyY28NCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBkaW1lLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+ PiBqb3VuaSBrb3Job25lbg0KPiA+PiBTZW50OiBEaWVuc3RhZywgMTAuIEFwcmlsIDIwMTIgMTE6 NTMNCj4gPj4gVG86IGRpbWVAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW0RpbWVdIHZlcnkgZHJh ZnR5IElFVEYjODMgbWVldGluZyBtaW51dGVzIHVwbG9hZGVkDQo+ID4+DQo+ID4+IEZvbGtzLA0K PiA+Pg0KPiA+PiBUaGV5IGFyZSB1cCBub3cgZm9yIHB1YmxpYyByZXZpZXcuIFRoYW5rcyB0byBT aHdldGhhIGZvciB0YWtpbmcgZXhjZWxsZW50DQo+ID4+IG1pbnV0ZXMuDQo+ID4+DQo+ID4+IC0g Sm91bmkNCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPj4gRGlNRUBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERpTUUgbWFpbGluZyBsaXN0 DQo+ID4gRGlNRUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU= From jouni.nospam@gmail.com Thu Apr 12 02:02:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3A21F8698 for ; Thu, 12 Apr 2012 02:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3Px5DatTzKU for ; Thu, 12 Apr 2012 02:02:53 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD8C21F8697 for ; Thu, 12 Apr 2012 02:02:50 -0700 (PDT) Received: by werb10 with SMTP id b10so1337376wer.31 for ; Thu, 12 Apr 2012 02:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TGG7l9NkvPNej52Xiaeegq4ypypx4x9AEBEFBg6I27w=; b=QuajCtNCWPrj9s38SPWGLkD2gub6LlP7vKCILBKXJfhe1vm1qXqLsvnRSdVj7EaWSa se68HIysXYb2l+39oBrJaJ9UbuUbH+uOsGSlPWL2CKeNttGte5d4i9ug4qnQOoKB6eas wWV/Nh7SS87iawvx0fnbncF6cF0Y/DnVeI20YINAA+Jy/FdeMuf43FhCB0orholMrB6+ 1ZtZubh03MoZBECnBDzBpBeg39mjjjFC5ljF9pb1NgaCUEuAVEotBVTvtTglv6B75blb OGlb2FaskMWwL6QcyiADYe75xqgWpeE/l4/ItpCIO4fH5AciwaE4DrVkTzslP+iixdoi H6ug== Received: by 10.180.81.166 with SMTP id b6mr13940022wiy.0.1334221369729; Thu, 12 Apr 2012 02:02:49 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id u9sm50896981wix.0.2012.04.12.02.02.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 02:02:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 12 Apr 2012 12:02:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:02:54 -0000 Tina, On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote: > Hi Jouni and Mark, > The problem statement is valid and the solution can work in basic = scenarios.=20 >=20 > However the solution may have some limit in roaming scenario. >=20 > Consider a network having a WLAN AN (hosting a Diameter Client) = requesting some 3G internet resources, visited network proxies and home = network server as below: >=20 > Client -------------- ---------- {Home network = server} > -------------- ----------{Home network = server} >=20 > The session path can be established through either of the visited n/w = proxies. For all the messages of same session, client can ensure that = the session path through stateful nodes is maintained. The visited n/w = proxies would require that the session path be maintained for offline = charging etc. > In this scenario, if client uses group signalling method to terminate = all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path = will be aware of session termination. Since there are no follow-up = messages, there is no mechanism to let the other proxy know that the = sessions are terminated. How this differentiates from a generic issue where someone puts a proxy on path that is supposed to stay on path and at the same time allows by deployment options an alternative path to take place? Like asking for trouble.. > This problem can be avoided in Server initiated group signalling cases = (GRAR & GASR) as the PER_SESSION mode can be used for follow up = exchanges. > Thus the current solution has a limit if client uses group signalling = method for session termination in roaming cases. The problem could also be avoided by not doing such deployment where this can happen. - Jouni >=20 > I volunteer to work together with Mark to find a solution for this = case. >=20 > I'm NOT aware of any IPR in this area. >=20 >=20 > Tina >=20 >=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of >> jouni korhonen >> Sent: Sunday, April 01, 2012 12:20 PM >> To: dime@ietf.org >> Cc: dime-chairs@tools.ietf.org >> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >> signaling-01 >>=20 >>=20 >> Folks, >>=20 >> During the Dime WG meeting in Paris we decided to adopt draft-jones- >> diameter-group-signaling-01 >> "Diameter Group Signaling" as a working group I-D. The I-D is an = input for >> the charter mile stone 'Protocol extension for bulk and group = signaling'. >>=20 >> This mail starts a one week verification for the adoption. If you = have >> strong concerns that the >> draft-jones-diameter-group-signaling-01 is not appropriate as a = _basis_ >> for the solution, then express your concerns on the mailing list by = 8th >> April. >>=20 >> - Jouni & Lionel >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Apr 12 02:13:46 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B854E21F866A for ; Thu, 12 Apr 2012 02:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olAsLQkk-3S8 for ; Thu, 12 Apr 2012 02:13:45 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8521F8667 for ; Thu, 12 Apr 2012 02:13:45 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so4745122wgb.1 for ; Thu, 12 Apr 2012 02:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=vCJofMTCq3Rvdw7wqdTrLjrCMVFNpqYoot06UV+eFTk=; b=y6fG2xm1uOJ7oAPjpqF8y+Qhs6bNp3i4U47MOhKOVwKN8GgfxGHErIK+aYOABZPKsh XV2PKW8JCqSZY2gso6TzP2ejEzvzTVPxzq9Dnw3Xgp/voRY9DphdOmfnAiMPKVAbZW4P d4FewcKkJYMOc3clVzifWsKK4dvelD3WGVhZ8RFmM+bKZEoxdkhdX9Kt4BtGnyr1XnKm 7PMViEm4TdGnvWSqV/Fxa5Tx1sU53cUrH+8/iZcipmBaOCpY4ggIHGuv4ZkcHuBDP++q jGs0RK3WjdDYZTB494f8UkpJJVVnf6SGA0MrEaA1dffyMyxM0GUy2PEXKiY8pVR3fSyX Xasg== Received: by 10.180.102.100 with SMTP id fn4mr4086901wib.1.1334222024682; Thu, 12 Apr 2012 02:13:44 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id ff9sm50954716wib.2.2012.04.12.02.13.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 02:13:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: <4F854453.90702@gmail.com> Date: Thu, 12 Apr 2012 12:13:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3644B3A1-7938-42BE-A4A5-6CC2590813C7@gmail.com> References: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> <4F854453.90702@gmail.com> To: Glen Zorn , dime@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Dime] very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:13:46 -0000 On Apr 11, 2012, at 11:44 AM, Glen Zorn wrote: > On 04/10/2012 04:53 PM, jouni korhonen wrote: >> Folks, >>=20 >> They are up now for public review. Thanks to Shwetha for taking = excellent minutes. >=20 > The minutes say: >=20 > Glen Zorn: draft-ietf-dmer-rfc4005bis - issue tracker updated > Jouni K: Next step is WGLC. >=20 > At what point in time might we expect the next step to take place? Actually the I-D is past WGLC already. So the next step would be requesting for publication. That is in queue now (no preset date). - Jouni >>=20 >> - Jouni >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From bill.wu@huawei.com Thu Apr 12 02:14:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7936B21F8671 for ; Thu, 12 Apr 2012 02:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I95LTMqSm9uB for ; Thu, 12 Apr 2012 02:14:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8729721F866A for ; Thu, 12 Apr 2012 02:14:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFD83080; Thu, 12 Apr 2012 05:14:50 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 02:12:11 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 02:12:16 -0700 Received: from w53375 (10.138.41.149) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 17:12:08 +0800 Message-ID: From: Qin Wu To: Marco Liebsch , jouni korhonen , References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd><69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> Date: Thu, 12 Apr 2012 17:12:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [Dime] discuss encoding of bulk commands /RE: very draftyIETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:14:53 -0000 cy9idWxrIGNvbW1hbmQgY29kZSBpcyBub3QgcmVkdW5kYW50IC9idWxrIGNvbW1hbmQgY29kZSBp cyAgcmVkdW5kYW50DQo6LSkNCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiUWluIFd1IiA8YmlsbC53dUBodWF3ZWkuY29tPg0KVG86ICJNYXJj byBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+OyAiam91bmkga29yaG9uZW4iIDxq b3VuaS5ub3NwYW1AZ21haWwuY29tPjsgPGRpbWVAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwg QXByaWwgMTIsIDIwMTIgNDoyOSBQTQ0KU3ViamVjdDogUmU6IFtEaW1lXSBkaXNjdXNzIGVuY29k aW5nIG9mIGJ1bGsgY29tbWFuZHMgL1JFOiB2ZXJ5IGRyYWZ0eUlFVEYjODMgbWVldGluZyBtaW51 dGVzIHVwbG9hZGVkDQoNCg0KPiBIaSwgTWFyY28sDQo+IEkgaGF2ZSBhIGZldyBmb2xsb3d1cCBj b21tZW50cy4NCj4gDQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCj4gRnJvbTogIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5l dT4NCj4gVG86ICJRaW4gV3UiIDxiaWxsLnd1QGh1YXdlaS5jb20+OyAiam91bmkga29yaG9uZW4i IDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPjsgPGRpbWVAaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMTEsIDIwMTIgOTowOSBQTQ0KPiBTdWJqZWN0OiBSRTogW0RpbWVdIGRpc2N1 c3MgZW5jb2Rpbmcgb2YgYnVsayBjb21tYW5kcyAvUkU6IHZlcnkgZHJhZnR5IElFVEYjODMgbWVl dGluZyBtaW51dGVzIHVwbG9hZGVkDQo+IA0KPiANCj4gSGkgUWluLA0KPiBwbGVhc2Ugc2VlIGlu bGluZS4NCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUWluIFd1 IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KPj4gU2VudDogTWl0dHdvY2gsIDExLiBBcHJp bCAyMDEyIDA3OjA2DQo+PiBUbzogTWFyY28gTGllYnNjaDsgam91bmkga29yaG9uZW47IGRpbWVA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbRGltZV0gZGlzY3VzcyBlbmNvZGluZyBvZiBidWxr IGNvbW1hbmRzIC9SRTogdmVyeSBkcmFmdHkNCj4+IElFVEYjODMgbWVldGluZyBtaW51dGVzIHVw bG9hZGVkDQo+PiANCj4+IEhpLCBNYXJjbzoNCj4+IEkgdGhpbmsgdGhlIGNyaXRlcmlhIHdlIG5l ZWQgdG8gY29uc2lkZXIgYXJlOg0KPj4gaG93IG11Y2ggcHJvdG9jb2wgZXh0ZW5zaW9uIGlzIHJl YWxseSByZXF1aXJlZD8NCj4+IGhvdyBtdWNoIHN1Y2ggcHJvdG9jb2wgYWZmZWN0cyB0aGUgZXhp c3RpbmcgaW1wbGVtZW50YWlvbj8NCj4+IEhvdyBtYW55IGNvbW1hbmQgZXhjaGFuZ2VzIGNhbiB3 ZSByZWR1Y2U/DQo+PiBwbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCj4gDQo+IFRoZSBs aXN0IG9mIGNyaXRlcmlhIHNvdW5kcyByZWFzb25hYmxlIHRvIG1lLg0KPiANCj4+IA0KPj4gUmVn YXJkcyENCj4+IC1RaW4NCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+IEZyb206 ICJNYXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+DQo+PiBUbzogImpvdW5p IGtvcmhvbmVuIiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT47IDxkaW1lQGlldGYub3JnPg0KPj4g U2VudDogVHVlc2RheSwgQXByaWwgMTAsIDIwMTIgMTA6MDYgUE0NCj4+IFN1YmplY3Q6IFtEaW1l XSBkaXNjdXNzIGVuY29kaW5nIG9mIGJ1bGsgY29tbWFuZHMgL1JFOiB2ZXJ5IGRyYWZ0eSBJRVRG IzgzDQo+PiBtZWV0aW5nIG1pbnV0ZXMgdXBsb2FkZWQNCj4+IA0KPj4gDQo+PiA+IFRoYW5rcyBm b3IgdGhlIG1lZXRpbmcgbWludXRlcy4NCj4+ID4NCj4+ID4gQXMgdGhlIG5vdGVzIHJlZmVyIHRv IGEgZGlzY3Vzc2lvbiBhYm91dCBkaWZmZXJlbnQgbWVhbnMgdG8gc2lnbmFsIGJ1bGsNCj4+IG9w ZXJhdGlvbiwNCj4+ID4gbGV0J3MgZ28gdGhyb3VnaCB0aGlzIGV4ZXJjaXNlIGFuZCBldmFsdWF0 ZSB0aGUgdGhyZWUgY2FuZGlkYXRlcyB0byBzaWduYWwNCj4+ID4gYnVsayBjb21tYW5kcy4NCj4+ ID4NCj4+ID4gSnVzdCB0byBzdW1tYXJpemUgdGhlIHRocmVlIGFsdGVybmF0aXZlcyBhY2NvcmRp bmcgdG8gTWFyaydzIHByZXNlbnRhdGlvbjoNCj4+ID4gKGEpIE5ldyBncm91cCBjb21tYW5kcw0K Pj4gPiAoYikgUmUtdXNlIGV4aXN0aW5nIGNvbW1hbmRzIGFuZCBjb21tYW5kIGNvZGVzLCBpbmRp Y2F0ZSBncm91cA0KPj4gb3BlcmF0aW9uDQo+PiA+IG9uIHRoZSBhdHRhY2hlZCBjb250ZXh0IChB VlBzKSB3aXRoaW4gdGhlIG1lc3NhZ2UsIGUuZy4gYnkgYWRkaW5nIGdyb3VwDQo+PiA+IGlkZW50 aWZpZXIsIGZsYWdzLCAuLg0KPj4gPiAoYykgU2luZ2xlIG5ldyBidWxrIGNvbW1hbmQgKDEgbmV3 IGNvbW1hbmQgY29kZSksIGluZGljYXRlIERpYW1ldGVyDQo+PiBjb21tYW5kLA0KPj4gPiB0byB3 aGljaCB0aGUgZ3JvdXAgb3BlcmF0aW9uIGFwcGxpZXMsIHdpdGhpbiB0aGUgbWVzc2FnZQ0KPj4g Pg0KPj4gPiBXaGVyZWFzIEkgc2VlIChhKSBhcyBzdHJhaWdodCBmb3J3YXJkIG1ldGhvZCwgYSBj b3VudGVyYXJndW1lbnQgY291bGQgYmUNCj4+IHRoZQ0KPj4gPiBuZWVkIG9mIGFkZGl0aW9uYWwg Y29tbWFuZCBjb2RlcyBmb3IgZWFjaCBjb21tYW5kLCB3aGljaCBzaG91bGQgYmUNCj4+IGVuYWJs ZWQNCj4+ID4gZm9yIGdyb3VwIG9wZXJhdGlvbi4gT3RoZXIgU0RPcywgd2hpY2ggc3BlY2lmeSBu ZXcgY29tbWFuZCBjb2RlcywgbmVlZA0KPj4gPiB0byBmb2xsb3cgdGhlIHNhbWUgcnVsZXMgYW5k IHJlcXVlc3QgbmV3IGNvbW1hbmQgY29kZXMgZm9yIGFsbCBleGlzdGluZw0KPj4gY29tbWFuZHMN Cj4+ID4gd2hpY2ggc2hvdWxkIGJlIGJ1bGstb3BlcmF0aW9uIGVuYWJsZWQuDQo+PiANCj4+IFtR aW5dOiBBZ3JlZS4gT25lIG1vcmUgdGhpbmcgSSBhbSB0aGlua2luZyBpcyBob3cgdG8gdXNlIGV4 aXN0aW5nIENvbW1hbmQNCj4+IENvZGUgY2FuIGhhbmRsZQ0KPj4gZ3JvdXAgYXNzaWdtZW50LiBJ dCBsb29rcyB0byBtZSBhZGRpdGlvbmFsIHNlbWFudGljcyBpbiB0aGVzZSBleGlzdGluZw0KPj4g Q29tbWFuZCAgYXJlIG5lZWRlZCB0bw0KPj4gZGlzdGluZ3Vpc2ggYWRkaW5nIGEgc2Vzc2lvbiBp bnRvIGdyb3VwIGZyb20gcmVtb3ZpbmcgYSBzZXNpb24gaW50byBncm91cCBvcg0KPj4gZGlzdGlu Z3Vpc2ggZ3JvdXANCj4+ICBhc3NpZ25tZW50IGZyb20gYnVsayBzaWduYWxpbmcgb3BlcmF0aW9u Lg0KPj4gTmV3IENvbW1hbmQgZmxhZ3MgbWF5IGJlIGV4YW1wbGUgb2Ygc3VjaCBhZGRpdGlvbmFs IHNlbWFudGljcyBidXQNCj4+IHNlZW1zIG5vdCBjb21wZWxsaW5nLjotKQ0KPiANCj4gSU1PLCBq b2luL2xlYXZlIG9mIGEgc2Vzc2lvbiB0by9mcm9tIG9uZSBvciBtdWx0aXBsZSBncm91cHMgc2hv dWxkIGJlIHRyZWF0ZWQNCj4gc2VwYXJhdGVseSBmcm9tIGJ1bGsgY29tbWFuZHMuIA0KPiANCj4g W1Fpbl06WWVzLg0KPiANCj4+IA0KPj4gPiBXaXRoIChiKSwgYWxsIGV4aXN0aW5nIG1lc3NhZ2Vz IGNvdWxkIGJlIHJlLXVzZWQgYW5kIHBvdGVudGlhbGx5IGJ1bGsNCj4+IG9wZXJhdGlvbiBlbmFi bGVkDQo+PiA+IGJ5IHVzaW5nIGEgZGlmZmVyZW50IGFwcGxpY2F0aW9uIElEIGFuZCBhZGRpbmcg YW4gYWRkaXRpb25hbCBsYWJlbCB0byB0aGUNCj4+IG1lc3NhZ2UsIGUuZy4NCj4+ID4gZmxhZ3Ms IEdyb3VwIHNlc3Npb24gQVZQLCBldGMuIFN1Y2ggYXBwcm9hY2ggYWxsb3dzIG11Y2ggZmxleGli aWw4aXR5LCBidXQNCj4+IHdlIG5lZWQNCj4+ID4gdG8gZW5zdXJlICBjb21wYXRpYmlsaXR5IHdp dGggcHJveGllcyBldGMsIHdoaWNoIGFyZSBub3QgYnVsay1vcGVyYXRpb24NCj4+IGVuYWJsZWQu DQo+PiA+IFBvc3NpYmx5IHVzaW5nIGEgbmV3IGFwcGxpY2F0aW9uIElEIHNvbHZlcyB0aGF0IGlz c3VlIGFscmVhZHkuDQo+PiANCj4+IFtRaW5dOiBJIGFtIG5vdCBzdXJlIHByb3h5IGluIGJldHdl ZW4gbmVlZHMgdG8gYmUgYnVsay1vcGVyYXRpb24gZW5hYmxlZC4NCj4+IEl0IGxvb2tzIHRvIG1l IGJ1bGsgb3BlcmF0aW9uIG9ubHkgaGFwcGVucyBvbiB0aGUgc291cmNlIGFuZCBmaW5hbA0KPj4g ZGVzdGluYXRpb24NCj4+IG9mIHRoZSBEaWFtZXRlciBtZXNzYWdlLg0KPiANCj4gV2hhdCBpZiBh IHByb3h5IHJlY2VpdmVzIGEgYnVsayBjb21tYW5kLCB3aGljaCBjYXJyaWVzIGEgbmV3IGFwcGxp Y2F0aW9uIElEPyANCj4gRnJvbSBvcGVyYXRpb24gaXQgc2hvdWxkIG5vdCBib3RoZXIsIEkgYWdy ZWUsIGFzIHBlci1zZXNzaW9uIGFuZCBncm91cCBvcGVyYXRpb25zDQo+IGFyZSBlbmQtdG8tZW5k LiBJZiBpbXBsZW1lbnRhdGlvbnMgcHJvY2VzcyB0aGUgY29tbWFuZCBjb2RlIG9yIGFwcGxpY2F0 aW9uIElELA0KPiB0aGVuIGNvbXBhdGliaWxpdHkgbWF5IGRlcGVuZCBvbiBob3cgcHJveGllcyBv ciByZWxheSBhZ2VudHMgdHJlYXQgc3VjaCBtZXNzYWdlcy4NCj4gDQo+IFtRaW5dOiBZZXMsIHBy b3hpZXMgYW5kIHJlbGF5IGFnZW50cyBzaG91bGQgdW5kZXJzdGFuZCB0aGUgbWVzc2FnZSBpZiBh bnkgbmV3IGNvbW1hbmQgY29kZSANCj4gb3IgYW55IG5ldyBhcHBsaWNhdGlvbiBJRCBpcyBkZWZp bmVkLiBUaGlzIGNhbiBiZSBkb25lIGJ5IENhcGFiaWxpdHkgRXhjaGFuZ2UuDQo+IA0KPiBBbm90 aGVyIHBvaW50IGlzIHByb3hpZXMgbWF5IG5vdCBuZWVkIHRvIGxvb2sgaW50byBtZXNzYWdlIGFu ZA0KPiBkZWVwIHBhcnNlIHRoZSBwYXlsb2FkIG9mIHRoZSBtZXNzYWdlLg0KPiBlLmcuLCBpZiB3 ZSBoYXZlIG5ldyBBVlAsIGRvIHlvdSB0aGluayBwcm94eSBhbHNvIG5lZWQgdG8gcGFyc2UgdGhp cyBBVlA/DQo+IA0KPj4gDQo+PiA+IFdpdGggKGMpLCB0aGUgRElNRSBXRyBjb3VsZCBzcGVjaWZ5 IGEgc2luZ2xlIGRlZGljYXRlZCBjb21tYW5kIGZvciBidWxrDQo+PiBvcGVyYXRpb25zLA0KPj4g PiBhbmQgdGhlIGFjdHVhbCBwYXlsb2FkIGNhcnJpZXMgdGhlIGNvbW1hbmQgY29kZSBvZiB0aGUg RGlhbWV0ZXIgbWVzc2FnZQ0KPj4gdG8gYmUNCj4+ID4gZXhlY3V0ZWQgYXMgYnVsayBvcGVyYXRp b24gKGUuZy4gUkFSLCBTVFIsIC4uKSBhcyB3ZWxsIGFzIHRoZSBhc3NvY2lhdGVkDQo+PiBjb21t YW5kJ3MNCj4+ID4gQVZQLCBwbHVzIGEgZ3JvdXAgaWRlbnRpZmllci4gQW55IGV4aXN0aW5nIGFu ZCBuZXcgY29tbWFuZCwgd2hpY2ggaXMgc28gZmFyDQo+PiB1c2VkDQo+PiA+IGZvciBzaW5nbGUg c2Vzc2lvbiBvcGVyYXRpb25zLCBjYW4gYmUgYnVsayBvcGVyYXRpb24gZW5hYmxlZC4gRm9ybWF0 dGluZyBvZg0KPj4gc3VjaA0KPj4gPiBidWxrIG9wZXJhdGlvbiBtZXNzYWdlIGlzIHN0aWxsIG9w ZW4sIG1heWJlIGl0IGhhcyBpbXBhY3QgdG8gZXhpc3RpbmcNCj4+IGFwcGxpY2F0aW9ucycNCj4+ ID4gY29tbWFuZCBwYXJzZXIuIElmIHdlIGZpbmQgYSBzdWl0YWJsZSBlbmNvZGluZyBzY2hlbWUg Zm9yIHN1Y2ggY29udGFpbmVyDQo+PiBtZXNzYWdlLA0KPj4gPiBpdCdzIGEgY29uY2VwdCB0aGF0 IGNhbiBiZSBlYXNpbHkgYWRvcHRlZCBieSBhbnkgRGlhbWV0ZXIgY29tbWFuZCBhbmQNCj4+IGFw cGxpY2F0aW9uLg0KPj4gDQo+PiBbUWluXTogV2l0aCB0aGUgYXBwcm9hY2ggKGMpLCBpcyB0aGUg cHJvcG9zYWwgaGVyZSB1c2luZyBuZXN0ZWQgQ29tbWFuZA0KPj4gQ29kZXMsIGkuZS4sIGVuY2Fw c3VsYXRlDQo+PiBvciBncm91cCBleGlzdGluZyBjb21tYW5kIGNvZGVzIGludG8gb25lIGxvZ2lj YWwgY29udGFpbmVyLiBUaGUgbG9naWNhbA0KPj4gY29udGFpbmVyIGlzIHN0aWxsIGEgY29tbWFu ZCBjb2RlLg0KPj4gSWYgdGhlIGFuc3dlciBpcyB5ZXMsIEkgYW0gdGhpbmtpbmcgd2h5IHdlIHNo b3VsZCBjYXJyeSB0aGUgZXhpc3RpbmcgY29tbWFuZA0KPj4gY29kZXMgYmVsb25naW5nIHRvIGRp ZmZlcmVudCB1c2VyICBvciB0aGUgc2FtZSB1c2VyIHRoYXQgbmVlZHMgYnVsaw0KPj4gb3BlcmF0 aW9uDQo+PiBpbnRvIG9uZSBkZWRpY2F0ZWQgY29tbWFuZCBjb2RlPyBJcyBpdCBmb3IgYSBncm91 cCBvZiB1c2VyIG9yIGEgc2luZ2xlIHVzZXI/DQo+IA0KPiBUaGUgaWRlYSB3YXMgdG8gaGF2ZSBh IHNpbmdsZSBjb21tYW5kIGNvZGUgZm9yIGJ1bGsgb3BlcmF0aW9ucywgd2hpY2ggaXMNCj4gcmVm ZXJyZWQgdG8gaW4gdGhlIERpYW1ldGVyIGhlYWRlci4gSSBkaWQgJ25vdCcgY29uc2lkZXIgaGF2 aW5nIHRoZSBjb21wbGV0ZQ0KPiBEaWFtZXRlciBoZWFkZXIgdHdpY2UsIGZvciB0aGUgYnVsayBj b21tYW5kIGFuZCBmb3IgdGhlIERpYW1ldGVyIGNvbW1hbmQsDQo+IHdoaWNoIGlzIHRvIGJlIGV4 ZWN1dGVkIGFzIGJ1bGsgb3BlcmF0aW9uLiBTbyB3ZSBtYXkga2VlcCBvbmUgRGlhbWV0ZXIgaGVh ZGVyLA0KPiB3aGljaCBjYXJyaWVzIHRoZSBidWxrIGNvbW1hbmQgY29kZSwgYSBzaW5nbGUgbmV3 IEFWUCwgd2hpY2ggY2FycmllcyB0aGUgRGlhbWV0ZXINCj4gY29tbWFuZCAoUkFSLCBTVFIsIC4u KSwgYW5kIHRoZSByZXF1aXJlZCBhdHRyaWJ1dGVzIGZvciBncm91cCBpZGVudGlmaWNhdGlvbg0K PiBhbmQgdGhlIEFWUHMsIHRoYXQgYXBwbHkgdG8gdGhlIGdyb3VwLiBTbywgSSBkaWQgbm90IGhh dmUgbmVzdGluZyBpbiBtaW5kLg0KPiANCj4gW1Fpbl06ICBTbyB5b3VyIHByb3Bvc2FsIGlzIGRl ZmluZSBvbmUgbmV3IGNvbnRhaW5lciBBVlAgdG8gQ2FycnkgYWxsIHRoZSBjb2RlIG9mICBjb21t YW5kcyB0aGF0IG5lZWQNCj4gYnVsayBvcGVyYXRpb24uIFRoaXMgQVZQIGNhbiBiZSB1c2VkIHRv IGluZm9ybSB0aGUgcmVjZWl2ZXIgb2YgdGhlIG1lc3NhZ2UgdGhhdCB0aGVzZSBjb21tYW5kcyBj b2Rlcw0KPiBuZWVkIGJ1bGsgb3BlcmF0aW9uLiBhbSBJIHJpZ2h0Pw0KPiBJbiB0aGF0IGNhc2Us IGl0IGxvb2tzIHRvIG1lIGJ1bGsgY29tbWFuZCBjb2RlIGlzIG5vdCByZWR1bmRhbnQgc2luY2Ug eW91IGNhbiB1c2UgYW5vdGhlciBuZXcgQVZQIHRoYXQNCj4gY2FycmllcyBncm91cCBpZGVudGlm aWVyIHRvIGluZGljYXRlIHRoaXMgaXMgZm9yIGJ1bGsgb3BlcmF0aW9uLiB3aGF0IGFtIEkgbWlz c2luZz8NCj4gDQo+IA0KPiBtYXJjbw0KPiANCj4+IA0KPj4gPiBXZSdkIGJlIGludGVyZXN0ZWQg aW4gbW9yZSBvcGluaW9ucyBhYm91dCB0aGUgZGlmZmVyZW50IGFwcHJvYWNoZXMgYW5kIEkNCj4+ IGhvcGUgdGhhdA0KPj4gPiB0aGlzIGVNYWlsIGNhbiB0cmlnZ2VyIHN1Y2ggZGlzY3Vzc2lvbi4N Cj4+ID4NCj4+ID4gbWFyY28NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiA+PiBGcm9tOiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4gT2YNCj4+ID4+IGpvdW5pIGtvcmhvbmVuDQo+PiA+PiBT ZW50OiBEaWVuc3RhZywgMTAuIEFwcmlsIDIwMTIgMTE6NTMNCj4+ID4+IFRvOiBkaW1lQGlldGYu b3JnDQo+PiA+PiBTdWJqZWN0OiBbRGltZV0gdmVyeSBkcmFmdHkgSUVURiM4MyBtZWV0aW5nIG1p bnV0ZXMgdXBsb2FkZWQNCj4+ID4+DQo+PiA+PiBGb2xrcywNCj4+ID4+DQo+PiA+PiBUaGV5IGFy ZSB1cCBub3cgZm9yIHB1YmxpYyByZXZpZXcuIFRoYW5rcyB0byBTaHdldGhhIGZvciB0YWtpbmcg ZXhjZWxsZW50DQo+PiA+PiBtaW51dGVzLg0KPj4gPj4NCj4+ID4+IC0gSm91bmkNCj4+ID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBEaU1F IG1haWxpbmcgbGlzdA0KPj4gPj4gRGlNRUBpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IERpTUUgbWFpbGluZyBsaXN0DQo+PiA+IERp TUVAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aW1lDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ From jouni.nospam@gmail.com Thu Apr 12 02:19:35 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6843921F867F for ; Thu, 12 Apr 2012 02:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64iuC+5gTe2K for ; Thu, 12 Apr 2012 02:19:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A386421F8671 for ; Thu, 12 Apr 2012 02:19:34 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4551380wib.13 for ; Thu, 12 Apr 2012 02:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8RR9Iam4Ew0MlLzdL0E0HjPg2LRelYEGmEvHu2BpDkY=; b=r89Be1zRxSSEqfloQt0JX2gZ5oo1dN9BEJSjd5hWAPdaLoykoYtQGuE31uqpr73IVu yyYsY/mKMAJE/MBX88lO5zz9qCIFrzqXRiNAt/BaLP4EJ9/ySNn6hdh9bpLMlsrPO8gF MML+3eShP/+4FCC4hxYUgwZdG6oudJReTIDv8EO3DkkNH7+AjqgoDN5kfT2wfjMyIy45 ZZ8AHq8ZLWamEAi5zBjk6cZ2YpsNxExLTfkmGlPgUWLMw5rholEDnL43oyBELzZIOURQ WfB2YziSJBKMT6W+xEf135LmPlJ7CnJo5K8/lxUZxZYy7KFRduyV7WbiNnOPXsiRmutf fNxA== Received: by 10.216.132.229 with SMTP id o79mr1010611wei.64.1334222369403; Thu, 12 Apr 2012 02:19:29 -0700 (PDT) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id n8sm19538056wix.10.2012.04.12.02.19.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 02:19:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <298E9AF5-09A8-4BE9-B6EE-5CF7E9DCF453@gmail.com> Date: Thu, 12 Apr 2012 12:19:25 +0300 Content-Transfer-Encoding: 7bit Message-Id: <64368E2D-A0BC-405A-8159-4D0FEAFBFC0B@gmail.com> References: <298E9AF5-09A8-4BE9-B6EE-5CF7E9DCF453@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] Removing Diameter MIB documents from the charter.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:19:35 -0000 Folks, No one volunteered, thus we are going to remove these two documents from the charter milestones. The ADs can the also declare these documents are dead/withdrawn. - Jouni & Lionel On Apr 1, 2012, at 10:28 PM, jouni korhonen wrote: > Folks, > > As discussed in Dime WG meeting in Paris there seems to be no > energy to get both MIB documents > > draft-ietf-dime-diameter-base-protocol-mib > draft-ietf-dime-diameter-cc-appl-mib > > completed. Unless someone steps ahead now by 8th April and > really manages to progress these documents in few weeks time, > we will abandon both and remove them from Dime charter's > milestones.. > > - Jouni & Lionel From lionel.morand@orange.com Thu Apr 12 02:35:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE29B21F867F for ; Thu, 12 Apr 2012 02:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Runct7ufhseq for ; Thu, 12 Apr 2012 02:35:39 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id DF7E221F866C for ; Thu, 12 Apr 2012 02:35:38 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CED8D7D4004; Thu, 12 Apr 2012 11:35:37 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id C3BF07D4003; Thu, 12 Apr 2012 11:35:37 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 11:35:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 11:35:36 +0200 Message-ID: In-Reply-To: <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 Thread-Index: Ac0YixBVeQUOZ0CSRkSfUT+kHpdB2wAA2TcA References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> From: To: , X-OriginalArrivalTime: 12 Apr 2012 09:35:37.0666 (UTC) FILETIME=[9E2B9A20:01CD188F] Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 09:35:39 -0000 Hi Jouni, Tina and Mark, I share the Jouni's point of view. If stateful proxies are required in = the path, all messages related to the same sessions have to go through = the same proxy. If an implementation allows relying on multiple stateful proxies to = manage the same sessions, this implementation needs also to support a = mechanism ensuring a consistent management of the session data contexts = between proxies. But IMHO, this kind of implementation is and should = remain out of scope of any Diameter protocol spec. Regards, Lionel -----Message d'origine----- De=A0: jouni korhonen [mailto:jouni.nospam@gmail.com]=20 Envoy=E9=A0: jeudi 12 avril 2012 11:03 =C0=A0: Tina TSOU Cc=A0: dime@ietf.org; dime-chairs@tools.ietf.org; mark@azu.ca Objet=A0: Re: [Dime] Call for WG adoption: = draft-jones-diameter-group-signaling-01 Tina, On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote: > Hi Jouni and Mark, > The problem statement is valid and the solution can work in basic = scenarios.=20 >=20 > However the solution may have some limit in roaming scenario. >=20 > Consider a network having a WLAN AN (hosting a Diameter Client) = requesting some 3G internet resources, visited network proxies and home = network server as below: >=20 > Client -------------- ---------- {Home network = server} > -------------- ----------{Home network = server} >=20 > The session path can be established through either of the visited n/w = proxies. For all the messages of same session, client can ensure that = the session path through stateful nodes is maintained. The visited n/w = proxies would require that the session path be maintained for offline = charging etc. > In this scenario, if client uses group signalling method to terminate = all sessions in a group using GSTR, only the proxy in the GSTR-GSTA path = will be aware of session termination. Since there are no follow-up = messages, there is no mechanism to let the other proxy know that the = sessions are terminated. How this differentiates from a generic issue where someone puts a proxy on path that is supposed to stay on path and at the same time allows by deployment options an alternative path to take place? Like asking for trouble.. > This problem can be avoided in Server initiated group signalling cases = (GRAR & GASR) as the PER_SESSION mode can be used for follow up = exchanges. > Thus the current solution has a limit if client uses group signalling = method for session termination in roaming cases. The problem could also be avoided by not doing such deployment where this can happen. - Jouni >=20 > I volunteer to work together with Mark to find a solution for this = case. >=20 > I'm NOT aware of any IPR in this area. >=20 >=20 > Tina >=20 >=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of >> jouni korhonen >> Sent: Sunday, April 01, 2012 12:20 PM >> To: dime@ietf.org >> Cc: dime-chairs@tools.ietf.org >> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >> signaling-01 >>=20 >>=20 >> Folks, >>=20 >> During the Dime WG meeting in Paris we decided to adopt draft-jones- >> diameter-group-signaling-01 >> "Diameter Group Signaling" as a working group I-D. The I-D is an = input for >> the charter mile stone 'Protocol extension for bulk and group = signaling'. >>=20 >> This mail starts a one week verification for the adoption. If you = have >> strong concerns that the >> draft-jones-diameter-group-signaling-01 is not appropriate as a = _basis_ >> for the solution, then express your concerns on the mailing list by = 8th >> April. >>=20 >> - Jouni & Lionel >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From Tina.Tsou.Zouting@huawei.com Fri Apr 13 10:31:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C711E8096 for ; Fri, 13 Apr 2012 10:31:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMWKVirTLGWH for ; Fri, 13 Apr 2012 10:31:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 28FA411E8072 for ; Fri, 13 Apr 2012 10:31:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW85692; Fri, 13 Apr 2012 13:31:49 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 10:29:47 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 10:29:45 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Sat, 14 Apr 2012 01:29:42 +0800 From: Tina TSOU To: jouni korhonen Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 Thread-Index: AQHNEDyF4CFv35exeUKXaSyq14pyOpaLVqMggAsY1QCAAqYUPA== Date: Fri, 13 Apr 2012 17:29:42 +0000 Message-ID: <97D84A0B-C8EF-4200-AABA-8D2259EE2CCE@huawei.com> References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> , <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> In-Reply-To: <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:31:51 -0000 Sent from my iPad On Apr 12, 2012, at 2:04 AM, "jouni korhonen" wrot= e: > Tina, Thank u, Jouni. Comments are in line. >=20 >=20 > On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote: >=20 >> Hi Jouni and Mark, >> The problem statement is valid and the solution can work in basic scenar= ios.=20 >>=20 >> However the solution may have some limit in roaming scenario. >>=20 >> Consider a network having a WLAN AN (hosting a Diameter Client) requesti= ng some 3G internet resources, visited network proxies and home network ser= ver as below: >>=20 >> Client -------------- ---------- {Home network ser= ver} >> -------------- ----------{Home network serve= r} >>=20 >> The session path can be established through either of the visited n/w pr= oxies. For all the messages of same session, client can ensure that the ses= sion path through stateful nodes is maintained. The visited n/w proxies wou= ld require that the session path be maintained for offline charging etc. >> In this scenario, if client uses group signalling method to terminate al= l sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will= be aware of session termination. Since there are no follow-up messages, th= ere is no mechanism to let the other proxy know that the sessions are termi= nated. >=20 > How this differentiates from a generic issue where someone > puts a proxy on path that is supposed to stay on path and > at the same time allows by deployment options an alternative > path to take place? Like asking for trouble.. The problem I am trying to put forth is one where the sessions between a cl= ient and server can take more than one path, but the group session terminat= ion signalling (GSTR) can take only one of such path. This is different fro= m other group signalling exchanges suggested where there is a followup (GRA= R, GASR etc.) which can be done at PER_SESSION level. >=20 >=20 >> This problem can be avoided in Server initiated group signalling cases (= GRAR & GASR) as the PER_SESSION mode can be used for follow up exchanges. >> Thus the current solution has a limit if client uses group signalling me= thod for session termination in roaming cases. >=20 > The problem could also be avoided by not doing such deployment > where this can happen. >=20 > - Jouni >=20 >>=20 >> I volunteer to work together with Mark to find a solution for this case. >>=20 >> I'm NOT aware of any IPR in this area. >>=20 >>=20 >> Tina >>=20 >>=20 >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >>> jouni korhonen >>> Sent: Sunday, April 01, 2012 12:20 PM >>> To: dime@ietf.org >>> Cc: dime-chairs@tools.ietf.org >>> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >>> signaling-01 >>>=20 >>>=20 >>> Folks, >>>=20 >>> During the Dime WG meeting in Paris we decided to adopt draft-jones- >>> diameter-group-signaling-01 >>> "Diameter Group Signaling" as a working group I-D. The I-D is an input = for >>> the charter mile stone 'Protocol extension for bulk and group signaling= '. >>>=20 >>> This mail starts a one week verification for the adoption. If you have >>> strong concerns that the >>> draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ >>> for the solution, then express your concerns on the mailing list by 8th >>> April. >>>=20 >>> - Jouni & Lionel >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 From Tina.Tsou.Zouting@huawei.com Fri Apr 13 10:35:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BFC11E809F for ; Fri, 13 Apr 2012 10:35:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dsz3EJ8ANZu for ; Fri, 13 Apr 2012 10:35:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6691111E809D for ; Fri, 13 Apr 2012 10:35:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFE86515; Fri, 13 Apr 2012 13:35:03 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 10:33:42 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 10:33:49 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 14 Apr 2012 01:33:41 +0800 From: Tina TSOU To: "lionel.morand@orange.com" Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 Thread-Index: AQHNEDyF4CFv35exeUKXaSyq14pyOpaLVqMggAsY1QCAAAktAIACngRg Date: Fri, 13 Apr 2012 17:33:41 +0000 Message-ID: <62751006-3C94-4279-B962-382E27E4D49D@huawei.com> References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:35:04 -0000 Sent from my iPad On Apr 12, 2012, at 2:35 AM, "lionel.morand@orange.com" wrote: > Hi Jouni, Tina and Mark, Merci, Lionel. Comments r in line. >=20 > I share the Jouni's point of view. If stateful proxies are required in th= e path, all messages related to the same sessions have to go through the sa= me proxy. You are right. Implementations should ensure this. However in group signall= ing only one (req-resp pair) group signalling message is exchanged between = the client and the server. It can only take one of the session path between= the client and the server. For server-initiated group signaling, implement= ations can still ensure "maintaining" the session path by indicating the fo= llow up to happen at PER_SESSION level. The client initiated group signalli= ng has no such provision in the current solution. >=20 > If an implementation allows relying on multiple stateful proxies to manag= e the same sessions, this implementation needs also to support a mechanism = ensuring a consistent management of the session data contexts between proxi= es. But IMHO, this kind of implementation is and should remain out of scope= of any Diameter protocol spec. >=20 > Regards, >=20 > Lionel >=20 >=20 >=20 > -----Message d'origine----- > De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 > Envoy=E9 : jeudi 12 avril 2012 11:03 > =C0 : Tina TSOU > Cc : dime@ietf.org; dime-chairs@tools.ietf.org; mark@azu.ca > Objet : Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signa= ling-01 >=20 > Tina, >=20 >=20 > On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote: >=20 >> Hi Jouni and Mark, >> The problem statement is valid and the solution can work in basic scenar= ios.=20 >>=20 >> However the solution may have some limit in roaming scenario. >>=20 >> Consider a network having a WLAN AN (hosting a Diameter Client) requesti= ng some 3G internet resources, visited network proxies and home network ser= ver as below: >>=20 >> Client -------------- ---------- {Home network ser= ver} >> -------------- ----------{Home network serv= er} >>=20 >> The session path can be established through either of the visited n/w pr= oxies. For all the messages of same session, client can ensure that the ses= sion path through stateful nodes is maintained. The visited n/w proxies wou= ld require that the session path be maintained for offline charging etc. >> In this scenario, if client uses group signalling method to terminate al= l sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will= be aware of session termination. Since there are no follow-up messages, th= ere is no mechanism to let the other proxy know that the sessions are termi= nated. >=20 > How this differentiates from a generic issue where someone > puts a proxy on path that is supposed to stay on path and > at the same time allows by deployment options an alternative > path to take place? Like asking for trouble.. >=20 >=20 >> This problem can be avoided in Server initiated group signalling cases (= GRAR & GASR) as the PER_SESSION mode can be used for follow up exchanges. >> Thus the current solution has a limit if client uses group signalling me= thod for session termination in roaming cases. >=20 > The problem could also be avoided by not doing such deployment > where this can happen. >=20 > - Jouni >=20 >>=20 >> I volunteer to work together with Mark to find a solution for this case. >>=20 >> I'm NOT aware of any IPR in this area. >>=20 >>=20 >> Tina >>=20 >>=20 >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >>> jouni korhonen >>> Sent: Sunday, April 01, 2012 12:20 PM >>> To: dime@ietf.org >>> Cc: dime-chairs@tools.ietf.org >>> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >>> signaling-01 >>>=20 >>>=20 >>> Folks, >>>=20 >>> During the Dime WG meeting in Paris we decided to adopt draft-jones- >>> diameter-group-signaling-01 >>> "Diameter Group Signaling" as a working group I-D. The I-D is an input = for >>> the charter mile stone 'Protocol extension for bulk and group signaling= '. >>>=20 >>> This mail starts a one week verification for the adoption. If you have >>> strong concerns that the >>> draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ >>> for the solution, then express your concerns on the mailing list by 8th >>> April. >>>=20 >>> - Jouni & Lionel >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Fri Apr 13 12:35:45 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408BE11E80DB for ; Fri, 13 Apr 2012 12:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSjSH8bsMV-t for ; Fri, 13 Apr 2012 12:35:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C516A11E80E0 for ; Fri, 13 Apr 2012 12:35:43 -0700 (PDT) Received: by lagj5 with SMTP id j5so2866747lag.31 for ; Fri, 13 Apr 2012 12:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dcC7Wt42hYhtufaTApSVHPYLVk4fy/SAii7FB8l3RZ0=; b=U2I98KT+MjL/iDV/lprOcIOJI+sfYbLIQD6x52mp5ZDAxKP86rfY/6IWgkF3zSniew UGWjMtNGoafb9X9KC0JFRkRl38kwe4wTdHQG6pSF2rUOUsJaJ1lIJXoS9Rg/hGbTP5Qm SdkBbyDmdsDxV7117VaiA8Kvs722ZX3a6HVq8RPNCYsYg4Tpckmw/LW6aaTrRKNGMjSA PMf0Mf/jmlsp+aBa3lL9bRs4UUgANLkm1mkfEr9FmyY38sc2e9IgLGhZX2Zn6mygXvUT w60UzxeG/gtbwNM/JtlIfCmqzoJuBvaEvbunF9bMHcj4qaXnrBbXRBLhqTM9SuVeTRGm MBKQ== Received: by 10.112.51.229 with SMTP id n5mr1295113lbo.36.1334345742652; Fri, 13 Apr 2012 12:35:42 -0700 (PDT) Received: from a88-114-171-246.elisa-laajakaista.fi (a88-114-171-246.elisa-laajakaista.fi. [88.114.171.246]) by mx.google.com with ESMTPS id oy17sm10422058lab.7.2012.04.13.12.35.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 12:35:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <62751006-3C94-4279-B962-382E27E4D49D@huawei.com> Date: Fri, 13 Apr 2012 22:35:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5F24BC23-1507-41A4-8FF9-B62411E83B64@gmail.com> References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> <62751006-3C94-4279-B962-382E27E4D49D@huawei.com> To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:35:45 -0000 Tina, On Apr 13, 2012, at 8:33 PM, Tina TSOU wrote: >=20 >=20 > Sent from my iPad >=20 > On Apr 12, 2012, at 2:35 AM, "lionel.morand@orange.com" = wrote: >=20 >> Hi Jouni, Tina and Mark, > Merci, Lionel. Comments r in line. >>=20 >> I share the Jouni's point of view. If stateful proxies are required = in the path, all messages related to the same sessions have to go = through the same proxy. > You are right. Implementations should ensure this. However in group = signalling only one (req-resp pair) group signalling I would still day.. "deployments should ensure this". This is a generic issue. > message is exchanged between the client and the server. It can only = take one of the session path between the client and the server. For = server-initiated group signaling, implementations can still ensure = "maintaining" the session path by=20 If a specific deployment requires that a specific node is always on path that must not be different then from whether the message exchange is=20 initiated by the client or the server. - Jouni > indicating the follow up to happen at PER_SESSION level. The client = initiated group signalling has no such provision in the current = solution. >>=20 >> If an implementation allows relying on multiple stateful proxies to = manage the same sessions, this implementation needs also to support a = mechanism ensuring a consistent management of the session data contexts = between proxies. But IMHO, this kind of implementation is and should = remain out of scope of any Diameter protocol spec. >>=20 >> Regards, >>=20 >> Lionel >>=20 >>=20 >>=20 >> -----Message d'origine----- >> De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >> Envoy=E9 : jeudi 12 avril 2012 11:03 >> =C0 : Tina TSOU >> Cc : dime@ietf.org; dime-chairs@tools.ietf.org; mark@azu.ca >> Objet : Re: [Dime] Call for WG adoption: = draft-jones-diameter-group-signaling-01 >>=20 >> Tina, >>=20 >>=20 >> On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote: >>=20 >>> Hi Jouni and Mark, >>> The problem statement is valid and the solution can work in basic = scenarios.=20 >>>=20 >>> However the solution may have some limit in roaming scenario. >>>=20 >>> Consider a network having a WLAN AN (hosting a Diameter Client) = requesting some 3G internet resources, visited network proxies and home = network server as below: >>>=20 >>> Client -------------- ---------- {Home network = server} >>> -------------- ----------{Home network = server} >>>=20 >>> The session path can be established through either of the visited = n/w proxies. For all the messages of same session, client can ensure = that the session path through stateful nodes is maintained. The visited = n/w proxies would require that the session path be maintained for = offline charging etc. >>> In this scenario, if client uses group signalling method to = terminate all sessions in a group using GSTR, only the proxy in the = GSTR-GSTA path will be aware of session termination. Since there are no = follow-up messages, there is no mechanism to let the other proxy know = that the sessions are terminated. >>=20 >> How this differentiates from a generic issue where someone >> puts a proxy on path that is supposed to stay on path and >> at the same time allows by deployment options an alternative >> path to take place? Like asking for trouble.. >>=20 >>=20 >>> This problem can be avoided in Server initiated group signalling = cases (GRAR & GASR) as the PER_SESSION mode can be used for follow up = exchanges. >>> Thus the current solution has a limit if client uses group = signalling method for session termination in roaming cases. >>=20 >> The problem could also be avoided by not doing such deployment >> where this can happen. >>=20 >> - Jouni >>=20 >>>=20 >>> I volunteer to work together with Mark to find a solution for this = case. >>>=20 >>> I'm NOT aware of any IPR in this area. >>>=20 >>>=20 >>> Tina >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = Behalf Of >>>> jouni korhonen >>>> Sent: Sunday, April 01, 2012 12:20 PM >>>> To: dime@ietf.org >>>> Cc: dime-chairs@tools.ietf.org >>>> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >>>> signaling-01 >>>>=20 >>>>=20 >>>> Folks, >>>>=20 >>>> During the Dime WG meeting in Paris we decided to adopt = draft-jones- >>>> diameter-group-signaling-01 >>>> "Diameter Group Signaling" as a working group I-D. The I-D is an = input for >>>> the charter mile stone 'Protocol extension for bulk and group = signaling'. >>>>=20 >>>> This mail starts a one week verification for the adoption. If you = have >>>> strong concerns that the >>>> draft-jones-diameter-group-signaling-01 is not appropriate as a = _basis_ >>>> for the solution, then express your concerns on the mailing list by = 8th >>>> April. >>>>=20 >>>> - Jouni & Lionel >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>=20 From Tina.Tsou.Zouting@huawei.com Fri Apr 13 15:56:19 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB9911E814A for ; Fri, 13 Apr 2012 15:56:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1ESXQlHhVuC for ; Fri, 13 Apr 2012 15:56:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E9E1611E8142 for ; Fri, 13 Apr 2012 15:56:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEX03130; Fri, 13 Apr 2012 18:56:08 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 15:55:05 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Apr 2012 15:54:22 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 14 Apr 2012 06:54:59 +0800 From: Tina TSOU To: jouni korhonen Thread-Topic: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 Thread-Index: AQHNEDyF4CFv35exeUKXaSyq14pyOpaLVqMggAsY1QCAAwD2EQ== Date: Fri, 13 Apr 2012 22:54:59 +0000 Message-ID: <6466E06A-BDEC-4CF4-9E2F-29731640D70C@huawei.com> References: <4C639074-1D3C-44E8-B2EB-D602681818A4@gmail.com> , <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> In-Reply-To: <41608FF6-EAFA-49B1-9BCF-92C6A8D2D411@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dime@ietf.org" , "dime-chairs@tools.ietf.org" Subject: Re: [Dime] Call for WG adoption: draft-jones-diameter-group-signaling-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:56:19 -0000 Sent from my iPad On Apr 12, 2012, at 2:04 AM, "jouni korhonen" wrot= e: > Tina, Thank u Jouni. >=20 >=20 > On Apr 5, 2012, at 2:41 AM, Tina TSOU wrote: >=20 >> Hi Jouni and Mark, >> The problem statement is valid and the solution can work in basic scenar= ios.=20 >>=20 >> However the solution may have some limit in roaming scenario. >>=20 >> Consider a network having a WLAN AN (hosting a Diameter Client) requesti= ng some 3G internet resources, visited network proxies and home network ser= ver as below: >>=20 >> Client -------------- ---------- {Home network ser= ver} >> -------------- ----------{Home network serve= r} >>=20 >> The session path can be established through either of the visited n/w pr= oxies. For all the messages of same session, client can ensure that the ses= sion path through stateful nodes is maintained. The visited n/w proxies wou= ld require that the session path be maintained for offline charging etc. >> In this scenario, if client uses group signalling method to terminate al= l sessions in a group using GSTR, only the proxy in the GSTR-GSTA path will= be aware of session termination. Since there are no follow-up messages, th= ere is no mechanism to let the other proxy know that the sessions are termi= nated. >=20 > How this differentiates from a generic issue where someone > puts a proxy on path that is supposed to stay on path and > at the same time allows by deployment options an alternative > path to take place? Like asking for trouble.. The problem I am trying to put forth is one where the sessions between a cl= ient and server can take more than one path, but the group session terminat= ion signalling (GSTR) can take only one of such path. This is different fro= m other group signalling exchanges suggested where there is a followup (GRA= R, GASR etc.) which can be done at PER_SESSION level. >=20 >=20 >> This problem can be avoided in Server initiated group signalling cases (= GRAR & GASR) as the PER_SESSION mode can be used for follow up exchanges. >> Thus the current solution has a limit if client uses group signalling me= thod for session termination in roaming cases. >=20 > The problem could also be avoided by not doing such deployment > where this can happen. >=20 > - Jouni >=20 >>=20 >> I volunteer to work together with Mark to find a solution for this case. >>=20 >> I'm NOT aware of any IPR in this area. >>=20 >>=20 >> Tina >>=20 >>=20 >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >>> jouni korhonen >>> Sent: Sunday, April 01, 2012 12:20 PM >>> To: dime@ietf.org >>> Cc: dime-chairs@tools.ietf.org >>> Subject: [Dime] Call for WG adoption: draft-jones-diameter-group- >>> signaling-01 >>>=20 >>>=20 >>> Folks, >>>=20 >>> During the Dime WG meeting in Paris we decided to adopt draft-jones- >>> diameter-group-signaling-01 >>> "Diameter Group Signaling" as a working group I-D. The I-D is an input = for >>> the charter mile stone 'Protocol extension for bulk and group signaling= '. >>>=20 >>> This mail starts a one week verification for the adoption. If you have >>> strong concerns that the >>> draft-jones-diameter-group-signaling-01 is not appropriate as a _basis_ >>> for the solution, then express your concerns on the mailing list by 8th >>> April. >>>=20 >>> - Jouni & Lionel >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 From glenzorn@gmail.com Sun Apr 15 21:36:05 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01621F869E for ; Sun, 15 Apr 2012 21:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP3gV8AGwE6v for ; Sun, 15 Apr 2012 21:36:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C69F921F869D for ; Sun, 15 Apr 2012 21:36:02 -0700 (PDT) Received: by iazz13 with SMTP id z13so8372771iaz.31 for ; Sun, 15 Apr 2012 21:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YzHyEmRiXP7DtHOoa7fjh/PAf3gfhDOYgz1RKCJv2CU=; b=eaBVwKU2XVI+RWuwMJo3SaEqdXlcmlkRJer4yQY2l+j8Tkse7DinoTLdnUeSZW6zmi Nq0/FxTPTpmX1deZwO2chX0QgpNmIT7qmBZ5sN5yYhag9xc7AdjzzcA19m1valyQR+/B Olu8FJSBIhBJzxmVNydIzNFLro9/D+bEaXa37OQRDYqyudaLj/d97p66P7r63A+mXOiG HxDzAFlMcBlGJcxorFZgwPNEqgvnovo8F+6laPFkJTAOVfwyXFASiCRrG/DSbfTtyyib OjmriTys8pHWxjq04dFAhWy8mS20IWfssjJTxt0OD9zX9vLvVer88ewkdiC85vfhe9VZ 4f7Q== Received: by 10.50.182.133 with SMTP id ee5mr4329531igc.63.1334550962395; Sun, 15 Apr 2012 21:36:02 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-4-101.revip2.asianet.co.th. [124.120.4.101]) by mx.google.com with ESMTPS id wh8sm21763168igb.11.2012.04.15.21.35.58 (version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 21:36:00 -0700 (PDT) Message-ID: <4F8BA1AC.80604@gmail.com> Date: Mon, 16 Apr 2012 11:35:56 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: jouni korhonen References: <11F80A48-5782-4FED-955A-1B49F8438B3A@gmail.com> <4F854453.90702@gmail.com> <3644B3A1-7938-42BE-A4A5-6CC2590813C7@gmail.com> In-Reply-To: <3644B3A1-7938-42BE-A4A5-6CC2590813C7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 04:36:05 -0000 On 04/12/2012 04:13 PM, jouni korhonen wrote: ... > The minutes say: > > Glen Zorn: draft-ietf-dmer-rfc4005bis - issue tracker updated > Jouni K: Next step is WGLC. > > At what point in time might we expect the next step to take place? > Actually the I-D is past WGLC already. So the next step would be > requesting for publication. That is in queue now (no preset date). Perhaps you could set a date (or at least share the contents of the queue)? ... From bclaise@cisco.com Mon Apr 16 02:12:13 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D674221F865B for ; Mon, 16 Apr 2012 02:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei0d-CXWQiUy for ; Mon, 16 Apr 2012 02:12:13 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E27FA21F8657 for ; Mon, 16 Apr 2012 02:12:12 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3G9CBkY026772; Mon, 16 Apr 2012 11:12:11 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3G9CAr5018885; Mon, 16 Apr 2012 11:12:10 +0200 (CEST) Message-ID: <4F8BE269.4090209@cisco.com> Date: Mon, 16 Apr 2012 11:12:09 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: jouni korhonen References: <298E9AF5-09A8-4BE9-B6EE-5CF7E9DCF453@gmail.com> <64368E2D-A0BC-405A-8159-4D0FEAFBFC0B@gmail.com> In-Reply-To: <64368E2D-A0BC-405A-8159-4D0FEAFBFC0B@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] Removing Diameter MIB documents from the charter.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:12:14 -0000 Dear all, Those two documents are now marked "dead". Regards, Benoit > Folks, > > No one volunteered, thus we are going to remove these two > documents from the charter milestones. The ADs can the also > declare these documents are dead/withdrawn. > > - Jouni& Lionel > > On Apr 1, 2012, at 10:28 PM, jouni korhonen wrote: > >> Folks, >> >> As discussed in Dime WG meeting in Paris there seems to be no >> energy to get both MIB documents >> >> draft-ietf-dime-diameter-base-protocol-mib >> draft-ietf-dime-diameter-cc-appl-mib >> >> completed. Unless someone steps ahead now by 8th April and >> really manages to progress these documents in few weeks time, >> we will abandon both and remove them from Dime charter's >> milestones.. >> >> - Jouni& Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From glenzorn@gmail.com Thu Apr 19 07:55:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1221F85C3 for ; Thu, 19 Apr 2012 07:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhxUc+s3YW55 for ; Thu, 19 Apr 2012 07:55:00 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 521EF21F8596 for ; Thu, 19 Apr 2012 07:55:00 -0700 (PDT) Received: by dady13 with SMTP id y13so15755685dad.27 for ; Thu, 19 Apr 2012 07:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HM9+o4hKPb5kzm5DYsqwjI2eB3lD/Lx3gNpz6+yE2ME=; b=WoxEb4DwKK5fSDGKRY53gbfUA/zTUp26s4SFocgxTf34alZ/P42KY+OT9BGLeV4mTQ QcCq9tTSa4NBx2QLkIqKRQmns7WPtu61OfvoE4dxbKtrDHBIeSeHOOSBPdaoHWHUMjKU iPEvlwRYA1CIt68DgRJLqfRj3iPG1d2iY3bWCWvF6Eo7Rp04M+/6nSQ4QNlx13hIMA8k 3HV5MPUUQFKabj87dbq9NdEgBiVc91uMNS4O+W7BbSR7e/NggE+rhzq1oJw9TgqrmL0A 1ItJeH1rvbJy2vERbQxYBToDbj1z0wnp4HXcnwbXurR2JnnP95NvNt++4RwZIuI6v/82 1pAQ== Received: by 10.68.191.35 with SMTP id gv3mr4967852pbc.160.1334847299982; Thu, 19 Apr 2012 07:54:59 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-50-31.revip2.asianet.co.th. [124.120.50.31]) by mx.google.com with ESMTPS id pj1sm2448746pbc.44.2012.04.19.07.54.56 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 07:54:58 -0700 (PDT) Message-ID: <4F90273E.9020407@gmail.com> Date: Thu, 19 Apr 2012 21:54:54 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com><1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com><58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:55:04 -0000 On 04/03/2012 02:24 PM, lionel.morand@orange.com wrote: > I think that this reflects the conclusion of our discussion during the dime session. > So, even if not deemed required, the statement "MUST_be_implemented, MAY_be_used" is correct and removes some ambiguity of the current text in RFC 3588. Isn't that statement true for both mechanisms? I think so, and suggest the following change: OLD: 5.2. Diameter Peer Discovery Allowing for dynamic Diameter agent discovery will make it possible for simpler and more robust deployment of Diameter services. In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms are described. These are based on existing IETF standards. The first option (manual configuration) MUST be supported by all Diameter nodes, while the latter option (DNS) MAY be supported. NEW: 5.2. Diameter Peer Discovery Allowing for dynamic Diameter agent discovery makes possible simpler and more robust deployment of Diameter services. In order to promote interoperable implementations of Diameter peer discovery, the following mechanisms (manual configuration and DNS) are described. These are based on existing IETF standards. Both mechanisms MUST be supported by all Diameter implementations; either MAY be used. > > Lionel > > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Adam Roach > Envoyé : mardi 3 avril 2012 05:45 > À : Glen Zorn > Cc : dime@ietf.org > Objet : Re: [Dime] 3588bis Peer Discovery Questions > > > > On Apr 2, 2012, at 22:10, Glen Zorn wrote: > >> I really don't think that it's any of our business _what_ people use, only what is implemented, so I would just leave out anything about that. > Given that "MAY" is non-constraining, I don't see the harm in including a statement to the effect that the mechanism "MAY be used". In fact, I think it clarifies that the implementation would be well served by allowing the mechanism to be turned off. Without the phrase, you're likely to find implementors who interpret the statement to mean that the mechanism is mandatory all the time, and will provide no means to configure it to be off. > > /a > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From adam@nostrum.com Thu Apr 19 08:33:14 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D404F21F869F for ; Thu, 19 Apr 2012 08:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMIqz0VhwUF7 for ; Thu, 19 Apr 2012 08:33:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C59521F869D for ; Thu, 19 Apr 2012 08:33:13 -0700 (PDT) Received: from [192.168.2.2] (ma85636d0.tmodns.net [208.54.86.168]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3JFXAKF090516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Apr 2012 10:33:12 -0500 (CDT) (envelope-from adam@nostrum.com) References: <949662E9-F54E-489D-9A6B-080C2D2B6C64@gmail.com> <1E1B2E40-A5A6-4803-AD4B-440786E607B3@nostrum.com> <58961781-8724-4AED-97A4-2462A420E4B4@nostrum.com> <4F90273E.9020407@gmail.com> In-Reply-To: <4F90273E.9020407@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <555FA7F4-FAFA-4CD8-BEFF-B1CD2D67E6BB@nostrum.com> X-Mailer: iPad Mail (9B176) From: Adam Roach Date: Thu, 19 Apr 2012 10:33:11 -0500 To: Glen Zorn Received-SPF: pass (nostrum.com: 208.54.86.168 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] 3588bis Peer Discovery Questions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:33:15 -0000 On Apr 19, 2012, at 9:54, Glen Zorn wrote: > NEW: > 5.2. Diameter Peer Discovery >=20 > Allowing for dynamic Diameter agent discovery makes possible simpler > and more robust deployment of Diameter services. In order to promote > interoperable implementations of Diameter peer discovery, the > following mechanisms (manual configuration and DNS) are described. > These are based on existing IETF standards. Both mechanisms MUST be > supported by all Diameter implementations; either MAY be used. That sounds good to me, and I think it reflects the consensus I've seen so f= ar. /a= From internet-drafts@ietf.org Fri Apr 20 01:13:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4715121F87B5; Fri, 20 Apr 2012 01:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRMGu3r3A5u7; Fri, 20 Apr 2012 01:13:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0427921F87B7; Fri, 20 Apr 2012 01:13:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120420081301.24750.12103.idtracker@ietfa.amsl.com> Date: Fri, 20 Apr 2012 01:13:01 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc3588bis-32.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 08:13:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Base Protocol Author(s) : Victor Fajardo Jari Arkko John Loughney Glen Zorn Filename : draft-ietf-dime-rfc3588bis-32.txt Pages : 154 Date : 2012-04-20 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719 and must be supported by all new Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-32.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-32.txt From Marco.Liebsch@neclab.eu Fri Apr 20 05:27:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4187521F86C4 for ; Fri, 20 Apr 2012 05:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzpUnjWzBp-5 for ; Fri, 20 Apr 2012 05:27:58 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0A621F8670 for ; Fri, 20 Apr 2012 05:27:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F3CE7100D8D; Fri, 20 Apr 2012 14:25:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XkodRXMp-4H; Fri, 20 Apr 2012 14:25:56 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BD354100D8C; Fri, 20 Apr 2012 14:25:41 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 20 Apr 2012 14:27:20 +0200 From: Marco Liebsch To: Qin Wu , jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded Thread-Index: AQHNF6EP6KvMuGZY/0iFk+anXwwzMpaVlBewgAFKCK6ADMzC8A== Date: Fri, 20 Apr 2012 12:27:19 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24DAC391@Polydeuces.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:27:59 -0000 Hi Qin, finally coming back to this discussion.. please see inline. > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Donnerstag, 12. April 2012 10:29 > To: Marco Liebsch; jouni korhonen; dime@ietf.org > Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty > IETF#83 meeting minutes uploaded >=20 > Hi, Marco, > I have a few followup comments. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "Qin Wu" ; "jouni korhonen" > ; > Sent: Wednesday, April 11, 2012 9:09 PM > Subject: RE: [Dime] discuss encoding of bulk commands /RE: very drafty > IETF#83 meeting minutes uploaded >=20 >=20 > Hi Qin, > please see inline. >=20 > > -----Original Message----- > > From: Qin Wu [mailto:bill.wu@huawei.com] > > Sent: Mittwoch, 11. April 2012 07:06 > > To: Marco Liebsch; jouni korhonen; dime@ietf.org > > Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty > > IETF#83 meeting minutes uploaded > > > > Hi, Marco: > > I think the criteria we need to consider are: > > how much protocol extension is really required? > > how much such protocol affects the existing implementaion? > > How many command exchanges can we reduce? > > please see my comments inline. >=20 > The list of criteria sounds reasonable to me. >=20 > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Marco Liebsch" > > To: "jouni korhonen" ; > > Sent: Tuesday, April 10, 2012 10:06 PM > > Subject: [Dime] discuss encoding of bulk commands /RE: very drafty > IETF#83 > > meeting minutes uploaded > > > > > > > Thanks for the meeting minutes. > > > > > > As the notes refer to a discussion about different means to signal bu= lk > > operation, > > > let's go through this exercise and evaluate the three candidates to s= ignal > > > bulk commands. > > > > > > Just to summarize the three alternatives according to Mark's > presentation: > > > (a) New group commands > > > (b) Re-use existing commands and command codes, indicate group > > operation > > > on the attached context (AVPs) within the message, e.g. by adding gro= up > > > identifier, flags, .. > > > (c) Single new bulk command (1 new command code), indicate Diameter > > command, > > > to which the group operation applies, within the message > > > > > > Whereas I see (a) as straight forward method, a counterargument could > be > > the > > > need of additional command codes for each command, which should be > > enabled > > > for group operation. Other SDOs, which specify new command codes, > need > > > to follow the same rules and request new command codes for all existi= ng > > commands > > > which should be bulk-operation enabled. > > > > [Qin]: Agree. One more thing I am thinking is how to use existing Comma= nd > > Code can handle > > group assigment. It looks to me additional semantics in these existing > > Command are needed to > > distinguish adding a session into group from removing a sesion into gro= up > or > > distinguish group > > assignment from bulk signaling operation. > > New Command flags may be example of such additional semantics but > > seems not compelling.:-) >=20 > IMO, join/leave of a session to/from one or multiple groups should be > treated > separately from bulk commands. >=20 > [Qin]:Yes. >=20 > > > > > With (b), all existing messages could be re-used and potentially bulk > > operation enabled > > > by using a different application ID and adding an additional label to= the > > message, e.g. > > > flags, Group session AVP, etc. Such approach allows much flexibil8ity= , but > > we need > > > to ensure compatibility with proxies etc, which are not bulk-operati= on > > enabled. > > > Possibly using a new application ID solves that issue already. > > > > [Qin]: I am not sure proxy in between needs to be bulk-operation enable= d. > > It looks to me bulk operation only happens on the source and final > > destination > > of the Diameter message. >=20 > What if a proxy receives a bulk command, which carries a new application = ID? > From operation it should not bother, I agree, as per-session and group > operations > are end-to-end. If implementations process the command code or > application ID, > then compatibility may depend on how proxies or relay agents treat such > messages. >=20 > [Qin]: Yes, proxies and relay agents should understand the message if any > new command code > or any new application ID is defined. This can be done by Capability Exch= ange. >=20 > Another point is proxies may not need to look into message and > deep parse the payload of the message. > e.g., if we have new AVP, do you think proxy also need to parse this AVP? Hmm, compared to a relay, a proxy could process (I guess even touch/modify)= command payload. Now, a new application ID and new command codes would require the proxy to support the new application. If we don't change the application ID= and re-use existing command codes for bulk signaling, a positive aspect could be to ke= ep bulk operations end-to-end and transparent to relays and proxies. The negative a= spect could be that a proxy assumes the command is meant for a single user sessio= n and tries to process or even modify the group command's AVPs as it would do for= single session commands. >=20 > > > > > With (c), the DIME WG could specify a single dedicated command for bu= lk > > operations, > > > and the actual payload carries the command code of the Diameter > message > > to be > > > executed as bulk operation (e.g. RAR, STR, ..) as well as the associa= ted > > command's > > > AVP, plus a group identifier. Any existing and new command, which is = so > far > > used > > > for single session operations, can be bulk operation enabled. Formatt= ing > of > > such > > > bulk operation message is still open, maybe it has impact to existing > > applications' > > > command parser. If we find a suitable encoding scheme for such > container > > message, > > > it's a concept that can be easily adopted by any Diameter command and > > application. > > > > [Qin]: With the approach (c), is the proposal here using nested Command > > Codes, i.e., encapsulate > > or group existing command codes into one logical container. The logical > > container is still a command code. > > If the answer is yes, I am thinking why we should carry the existing > command > > codes belonging to different user or the same user that needs bulk > > operation > > into one dedicated command code? Is it for a group of user or a single > user? >=20 > The idea was to have a single command code for bulk operations, which is > referred to in the Diameter header. I did 'not' consider having the compl= ete > Diameter header twice, for the bulk command and for the Diameter > command, > which is to be executed as bulk operation. So we may keep one Diameter > header, > which carries the bulk command code, a single new AVP, which carries the > Diameter > command (RAR, STR, ..), and the required attributes for group identificat= ion > and the AVPs, that apply to the group. So, I did not have nesting in mind= . >=20 > [Qin]: So your proposal is define one new container AVP to Carry all the= code > of commands that need > bulk operation. This AVP can be used to inform the receiver of the messag= e > that these commands codes > need bulk operation. am I right? > In that case, it looks to me bulk command code is not redundant since you > can use another new AVP that > carries group identifier to indicate this is for bulk operation. what am = I > missing? Not really. The proposal is to use a new command code for the container and within that container, as further single command code is added, which indicates for example a RAR command. Then the command comprises a group ID and further AVPs. Hence, the application knows from the group container command code that the command referred to inside is a bulk operation. Then a RAR applies to all sessions being part of the group.=20 Is your concern that having a group identifier plus a bulk command code is redundant? I think it depends at which level of the stack processing we want the Diameter function to know about single session or bulk operation. More important, we need to avoid failures due to wrong processing. If we want to avoid a new command code, we may again consider our initial proposal to indicate bulk operation by means of a dedicated session= ID, which is not assigned to any single use session ;-) I think that's similar to adding a flag.=20 marco >=20 >=20 > marco >=20 > > > > > We'd be interested in more opinions about the different approaches an= d > I > > hope that > > > this eMail can trigger such discussion. > > > > > > marco > > > > > >> -----Original Message----- > > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf > > Of > > >> jouni korhonen > > >> Sent: Dienstag, 10. April 2012 11:53 > > >> To: dime@ietf.org > > >> Subject: [Dime] very drafty IETF#83 meeting minutes uploaded > > >> > > >> Folks, > > >> > > >> They are up now for public review. Thanks to Shwetha for taking > excellent > > >> minutes. > > >> > > >> - Jouni > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime From Marco.Liebsch@neclab.eu Fri Apr 20 05:35:55 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D079A21F86D9 for ; Fri, 20 Apr 2012 05:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d+MrVe2tBjQ for ; Fri, 20 Apr 2012 05:35:54 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4C21F85F2 for ; Fri, 20 Apr 2012 05:35:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8BD9E100D8B; Fri, 20 Apr 2012 14:33:53 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZc3Fn-iHxZy; Fri, 20 Apr 2012 14:33:53 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 6E13E100D8A; Fri, 20 Apr 2012 14:33:33 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.31]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 20 Apr 2012 14:35:34 +0200 From: Marco Liebsch To: "lionel.morand@orange.com" , "bill.wu@huawei.com" , "jouni.nospam@gmail.com" , "dime@ietf.org" Thread-Topic: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded Thread-Index: AQHNF6EP6KvMuGZY/0iFk+anXwwzMpaVlBewgAAi2qCADfwgEA== Date: Fri, 20 Apr 2012 12:35:33 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D24DAD3BA@Polydeuces.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D24D8F56B@Polydeuces.office.hd> <69756203DDDDE64E987BC4F70B71A26D24D9A6EA@Polydeuces.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty IETF#83 meeting minutes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:35:55 -0000 Hi Lionel, please see inline. > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Mittwoch, 11. April 2012 17:01 > To: Marco Liebsch; bill.wu@huawei.com; jouni.nospam@gmail.com; > dime@ietf.org > Subject: RE: [Dime] discuss encoding of bulk commands /RE: very drafty > IETF#83 meeting minutes uploaded >=20 > > > > With (b), all existing messages could be re-used and potentially > > > > bulk > > > operation enabled > > > > by using a different application ID and adding an additional label > > > > to the message, e.g. > > > > flags, Group session AVP, etc. Such approach allows much > > > > flexibil8ity, but we need to ensure compatibility with proxies > > > > etc, which are not bulk-operation enabled. > > > > Possibly using a new application ID solves that issue already. > > > > > > [Qin]: I am not sure proxy in between needs to be bulk-operation > enabled. > > > It looks to me bulk operation only happens on the source and final > > > destination of the Diameter message. >=20 > > What if a proxy receives a bulk command, which carries a new applicatio= n > ID? > > From operation it should not bother, I agree, as per-session and group > > operations are end-to-end. If implementations process the command code > > or application ID, then compatibility may depend on how proxies or rela= y > agents treat such messages. >=20 > [LM] I think that the point is that the solution could be transparent to = proxy if > you can reuse existing applications without major impacts and not updatin= g > the application-Id. Of course, if you have to use a new application-id, a= ny > proxy will have to advertize the new application, as per definition of a = proxy, > even if the proxy is transparent to bulk operations. Is the proposal to keep the application ID but use a new command code? Or is the idea to keep the application ID and use existing command codes? Then we have to be careful with proxies, I guess, who may access commands under the assumption that it's a single session command, and if it happens that the proxy modifies the message, then it should not conflict with performing the group operation on the receiving endpoint. marco >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de > Marco Liebsch Envoy=E9=A0: mercredi 11 avril 2012 15:09 =C0=A0: Qin Wu; j= ouni > korhonen; dime@ietf.org Objet=A0: Re: [Dime] discuss encoding of bulk > commands /RE: very drafty IETF#83 meeting minutes uploaded >=20 > Hi Qin, > please see inline. >=20 > > -----Original Message----- > > From: Qin Wu [mailto:bill.wu@huawei.com] > > Sent: Mittwoch, 11. April 2012 07:06 > > To: Marco Liebsch; jouni korhonen; dime@ietf.org > > Subject: Re: [Dime] discuss encoding of bulk commands /RE: very drafty > > IETF#83 meeting minutes uploaded > > > > Hi, Marco: > > I think the criteria we need to consider are: > > how much protocol extension is really required? > > how much such protocol affects the existing implementaion? > > How many command exchanges can we reduce? > > please see my comments inline. >=20 > The list of criteria sounds reasonable to me. >=20 > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Marco Liebsch" > > To: "jouni korhonen" ; > > Sent: Tuesday, April 10, 2012 10:06 PM > > Subject: [Dime] discuss encoding of bulk commands /RE: very drafty > > IETF#83 meeting minutes uploaded > > > > > > > Thanks for the meeting minutes. > > > > > > As the notes refer to a discussion about different means to signal > > > bulk > > operation, > > > let's go through this exercise and evaluate the three candidates to > > > signal bulk commands. > > > > > > Just to summarize the three alternatives according to Mark's > presentation: > > > (a) New group commands > > > (b) Re-use existing commands and command codes, indicate group > > operation > > > on the attached context (AVPs) within the message, e.g. by adding > > > group identifier, flags, .. > > > (c) Single new bulk command (1 new command code), indicate Diameter > > command, > > > to which the group operation applies, within the message > > > > > > Whereas I see (a) as straight forward method, a counterargument > > > could be > > the > > > need of additional command codes for each command, which should be > > enabled > > > for group operation. Other SDOs, which specify new command codes, > > > need to follow the same rules and request new command codes for all > > > existing > > commands > > > which should be bulk-operation enabled. > > > > [Qin]: Agree. One more thing I am thinking is how to use existing > > Command Code can handle group assigment. It looks to me additional > > semantics in these existing Command are needed to distinguish adding > > a session into group from removing a sesion into group or distinguish > > group assignment from bulk signaling operation. > > New Command flags may be example of such additional semantics but > > seems not compelling.:-) >=20 > IMO, join/leave of a session to/from one or multiple groups should be > treated separately from bulk commands. >=20 > > > > > With (b), all existing messages could be re-used and potentially > > > bulk > > operation enabled > > > by using a different application ID and adding an additional label > > > to the > > message, e.g. > > > flags, Group session AVP, etc. Such approach allows much > > > flexibil8ity, but > > we need > > > to ensure compatibility with proxies etc, which are not > > > bulk-operation > > enabled. > > > Possibly using a new application ID solves that issue already. > > > > [Qin]: I am not sure proxy in between needs to be bulk-operation enable= d. > > It looks to me bulk operation only happens on the source and final > > destination of the Diameter message. >=20 > What if a proxy receives a bulk command, which carries a new application = ID? > From operation it should not bother, I agree, as per-session and group > operations are end-to-end. If implementations process the command code > or application ID, then compatibility may depend on how proxies or relay > agents treat such messages. >=20 >=20 > > > > > With (c), the DIME WG could specify a single dedicated command for > > > bulk > > operations, > > > and the actual payload carries the command code of the Diameter > > > message > > to be > > > executed as bulk operation (e.g. RAR, STR, ..) as well as the > > > associated > > command's > > > AVP, plus a group identifier. Any existing and new command, which is > > > so far > > used > > > for single session operations, can be bulk operation enabled. > > > Formatting of > > such > > > bulk operation message is still open, maybe it has impact to > > > existing > > applications' > > > command parser. If we find a suitable encoding scheme for such > > > container > > message, > > > it's a concept that can be easily adopted by any Diameter command > > > and > > application. > > > > [Qin]: With the approach (c), is the proposal here using nested > > Command Codes, i.e., encapsulate or group existing command codes into > > one logical container. The logical container is still a command code. > > If the answer is yes, I am thinking why we should carry the existing > > command codes belonging to different user or the same user that needs > > bulk operation into one dedicated command code? Is it for a group of > > user or a single user? >=20 > The idea was to have a single command code for bulk operations, which is > referred to in the Diameter header. I did 'not' consider having the compl= ete > Diameter header twice, for the bulk command and for the Diameter > command, which is to be executed as bulk operation. So we may keep one > Diameter header, which carries the bulk command code, a single new AVP, > which carries the Diameter command (RAR, STR, ..), and the required > attributes for group identification and the AVPs, that apply to the group= . So, I > did not have nesting in mind. >=20 > marco >=20 > > > > > We'd be interested in more opinions about the different approaches > > > and I > > hope that > > > this eMail can trigger such discussion. > > > > > > marco > > > > > >> -----Original Message----- > > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > > >> Behalf > > Of > > >> jouni korhonen > > >> Sent: Dienstag, 10. April 2012 11:53 > > >> To: dime@ietf.org > > >> Subject: [Dime] very drafty IETF#83 meeting minutes uploaded > > >> > > >> Folks, > > >> > > >> They are up now for public review. Thanks to Shwetha for taking > > >> excellent minutes. > > >> > > >> - Jouni > > >> _______________________________________________ > > >> DiME mailing list > > >> DiME@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenzorn@gmail.com Sat Apr 21 19:01:35 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C809321F853E for ; Sat, 21 Apr 2012 19:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBogeC+NvBKm for ; Sat, 21 Apr 2012 19:01:35 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id EB28521F853D for ; Sat, 21 Apr 2012 19:01:34 -0700 (PDT) Received: by dady13 with SMTP id y13so19525962dad.27 for ; Sat, 21 Apr 2012 19:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Rq5Dpnn/shD8glpITF87JXOjHamsGz8sAAxJJnNNPUM=; b=jHg2cHmsZxSeu+VXDYKYPey1ry0kHRzOYyG3BbEaY+b4WKUYHPJ591TlENMcbqwz/G DbxIdpUfmfq/o5qixfaJOCjJ62avm4b2Qf9VD7b2/qLHS0uPuV0u0Li8iCBRUeDHNdM2 /akCpU1R/03WIgtkv8xxmQQmsXsWZDh7AF2gWF1K+35NdiZkyV5H+zd2twRB4uNiKQ5M mcwIsWSwFCrFvtyC3oaUrsXD40sM0LL7qShSwE5tzDp7ZZsMWor4fdWveEjOXo/RJZ+L vVP0YJdwKBpQ2QoakweX015X3JBEoQ5kxvSlWBIRULSvhaSGjcxuszoz0aySe0F3s761 uwYQ== Received: by 10.68.222.38 with SMTP id qj6mr24492647pbc.69.1335060094697; Sat, 21 Apr 2012 19:01:34 -0700 (PDT) Received: from [192.168.1.98] (ppp-115-87-77-169.revip4.asianet.co.th. [115.87.77.169]) by mx.google.com with ESMTPS id vm4sm3623656pbc.47.2012.04.21.19.01.30 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 19:01:33 -0700 (PDT) Message-ID: <4F936678.1010202@gmail.com> Date: Sun, 22 Apr 2012 09:01:28 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Sean Turner References: <20120420081302.24750.93793.idtracker@ietfa.amsl.com> <4F92C198.1060603@ieca.com> In-Reply-To: <4F92C198.1060603@ieca.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] New Version Notification - draft-ietf-dime-rfc3588bis-32.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 02:01:35 -0000 On 04/21/2012 09:18 PM, Sean Turner wrote: > I cleared. Thanks, Sean! It appears to me that this draft can (finally!) go to the RFC Editor, which will clear the path to publication for draft-ietf-dime-local-keytran & draft-ietf-dime-capabilities-update. However, draft-ietf-dime-pmip6-lr is in the final stages of IESG evaluation and will shortly be blocked by a missing reference to draft-ietf-dime-rfc4005bis. To avoid having this situation persist for months on end can somebody either take 10 minutes to produce a proto write-up for that draft or 2 minutes to appoint a document shepherd who will? > > spt > > On 4/20/12 4:13 AM, internet-drafts@ietf.org wrote: >> New version (-32) has been submitted for >> draft-ietf-dime-rfc3588bis-32.txt: >> http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-32.txt >> >> Diff from previous version: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-dime-rfc3588bis-32 >> >> IETF Secretariat. >> >> From lionel.morand@orange.com Sun Apr 22 10:49:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241EF21F85BB for ; Sun, 22 Apr 2012 10:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMEJRwdDpzyk for ; Sun, 22 Apr 2012 10:49:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5421F85B6 for ; Sun, 22 Apr 2012 10:49:09 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C7E40A441DA; Sun, 22 Apr 2012 19:50:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id BAA42A441C8; Sun, 22 Apr 2012 19:50:40 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 Apr 2012 19:49:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 22 Apr 2012 19:49:08 +0200 Message-ID: In-Reply-To: <4F936678.1010202@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-ietf-dime-rfc3588bis-32.txt Thread-Index: Ac0gK+IBHuAfNHwiQ+S5IE10tlEhCAAhBZBQ References: <20120420081302.24750.93793.idtracker@ietfa.amsl.com> <4F92C198.1060603@ieca.com> <4F936678.1010202@gmail.com> From: To: , X-OriginalArrivalTime: 22 Apr 2012 17:49:08.0079 (UTC) FILETIME=[377B8FF0:01CD20B0] Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org, dime-chairs@tools.ietf.org Subject: Re: [Dime] New Version Notification - draft-ietf-dime-rfc3588bis-32.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 17:49:10 -0000 VGhhbmsgeW91IFNlYW4hDQoNCkdsZW4sIGl0IHdpbGwgYmUgZG9uZSB0aGlzIHdlZWsuDQoNClJl Z2FyZHMsDQoNCkxpb25lbA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEds ZW4gWm9ybiBbbWFpbHRvOmdsZW56b3JuQGdtYWlsLmNvbV0gDQpFbnZvecOpwqA6IGRpbWFuY2hl IDIyIGF2cmlsIDIwMTIgMDQ6MDENCsOAwqA6IFNlYW4gVHVybmVyDQpDY8KgOiBiY2xhaXNlQGNp c2NvLmNvbTsgZGltZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1yZmMz NTg4YmlzQHRvb2xzLmlldGYub3JnOyBkaW1lQGlldGYub3JnDQpPYmpldMKgOiBSZTogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1kaW1lLXJmYzM1ODhiaXMtMzIudHh0DQoN Ck9uIDA0LzIxLzIwMTIgMDk6MTggUE0sIFNlYW4gVHVybmVyIHdyb3RlOg0KPiBJIGNsZWFyZWQu DQoNClRoYW5rcywgU2VhbiEgIEl0IGFwcGVhcnMgdG8gbWUgdGhhdCB0aGlzIGRyYWZ0IGNhbiAo ZmluYWxseSEpIGdvIHRvIHRoZSANClJGQyBFZGl0b3IsIHdoaWNoIHdpbGwgY2xlYXIgdGhlIHBh dGggdG8gcHVibGljYXRpb24gZm9yIA0KZHJhZnQtaWV0Zi1kaW1lLWxvY2FsLWtleXRyYW4gJiBk cmFmdC1pZXRmLWRpbWUtY2FwYWJpbGl0aWVzLXVwZGF0ZS4gIA0KSG93ZXZlciwgZHJhZnQtaWV0 Zi1kaW1lLXBtaXA2LWxyIGlzIGluIHRoZSBmaW5hbCBzdGFnZXMgb2YgSUVTRyANCmV2YWx1YXRp b24gYW5kIHdpbGwgc2hvcnRseSBiZSBibG9ja2VkIGJ5IGEgbWlzc2luZyByZWZlcmVuY2UgdG8g DQpkcmFmdC1pZXRmLWRpbWUtcmZjNDAwNWJpcy4gIFRvIGF2b2lkIGhhdmluZyB0aGlzIHNpdHVh dGlvbiBwZXJzaXN0IGZvciANCm1vbnRocyBvbiBlbmQgY2FuIHNvbWVib2R5IGVpdGhlciB0YWtl IDEwIG1pbnV0ZXMgdG8gcHJvZHVjZSBhIHByb3RvIA0Kd3JpdGUtdXAgZm9yIHRoYXQgZHJhZnQg b3IgMiBtaW51dGVzIHRvIGFwcG9pbnQgYSBkb2N1bWVudCBzaGVwaGVyZCB3aG8gDQp3aWxsPw0K DQo+DQo+IHNwdA0KPg0KPiBPbiA0LzIwLzEyIDQ6MTMgQU0sIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyB3cm90ZToNCj4+IE5ldyB2ZXJzaW9uICgtMzIpIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3Ig DQo+PiBkcmFmdC1pZXRmLWRpbWUtcmZjMzU4OGJpcy0zMi50eHQ6DQo+PiBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRpbWUtcmZjMzU4OGJpcy0zMi50eHQN Cj4+DQo+PiBEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoNCj4+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kaW1lLXJmYzM1ODhiaXMtMzINCj4+DQo+PiBJ RVRGIFNlY3JldGFyaWF0Lg0KPj4NCj4+DQoNCg== From internet-drafts@ietf.org Sun Apr 22 17:50:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222C721F84EB; Sun, 22 Apr 2012 17:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bADEclRjZAlj; Sun, 22 Apr 2012 17:50:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6CD21F8427; Sun, 22 Apr 2012 17:50:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423005041.19284.95864.idtracker@ietfa.amsl.com> Date: Sun, 22 Apr 2012 17:50:41 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 00:50:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Address and Port Translation Control Ap= plication Author(s) : Frank Brockners Shwetha Bhandari Vaneeta Singh Victor Fajardo Filename : draft-ietf-dime-nat-control-16.txt Pages : 62 Date : 2012-04-22 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 networks to cope with IPv4-address space depletion. 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-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-16.txt From shwethab@cisco.com Sun Apr 22 17:51:26 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430CB21F85CC for ; Sun, 22 Apr 2012 17:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.297 X-Spam-Level: X-Spam-Status: No, score=-9.297 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF0JgT4hWTrE for ; Sun, 22 Apr 2012 17:51:25 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8099021F84DC for ; Sun, 22 Apr 2012 17:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=12422; q=dns/txt; s=iport; t=1335142283; x=1336351883; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ojK6g1JUrz3lYWTF6lrNwsZTnRbpLwk0W4jsUf1pB68=; b=fn03U2EZ9VyGNew+awAjueulFvyk4Y/wek/ErRl4iAoTNJamLvTNyJ06 akHXeDZOFtvrFZ3AHZvgz5LuvcF3LmsntUipb5RJu8Adigk0T/40/iuDf TGlCwLo1Lja8mZDwyk7onKrrmzq6ZtVoWHpX/pYpL1VkGBbcbtjdxwkjr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAC+mlE9Io8UY/2dsb2JhbAA6CrJIggkBAQEDARIBJwIBTgEICQgDAQIBewEBBQMBAQQLCAkZh2gFC5higSifEIQXhlcEhkEEiGGCZYJJh2uGYId1gWmCcYFMBQM X-IronPort-AV: E=Sophos;i="4.75,463,1330905600"; d="scan'208";a="10622833" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 23 Apr 2012 00:51:21 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3N0pLpW000660 for ; Mon, 23 Apr 2012 00:51:21 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); Mon, 23 Apr 2012 06:21:21 +0530 Received: from 10.65.80.134 ([10.65.80.134]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Apr 2012 00:51:20 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 23 Apr 2012 06:26:06 +0530 From: shwethab To: Message-ID: Thread-Topic: Martin Stiemerling's Discuss on draft-ietf-dime-nat-control-15: (with DISCUSS) Thread-Index: Ac0g69z0h870gKZg6kSHqq4DgVmhUg== In-Reply-To: <4F8D38CD.6040300@neclab.eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Apr 2012 00:51:21.0358 (UTC) FILETIME=[334B2AE0:01CD20EB] Subject: [Dime] FW: Martin Stiemerling's Discuss on draft-ietf-dime-nat-control-15: (with DISCUSS) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 00:51:26 -0000 Hello All, As discussed at IETF83, draft-ietf-dime-nat-control-16 has been submitted to address the open IESG DISCUSS. Additional Result-code to detect error as brought up during the meeting has been added. Following is the summary of the changes: 1. Conflicting configuration per endpoint due to multiple DNCA NAT-controllers: When multiple NAT-controllers peer with a single NAT-device it can receive conflicting NAT-configuration. Added clarification that there will be a single NAT-controller and NAT-device for an endpoint. 2. Conflicting configuration per endpoint due to multiple protocols (SNMP, PCP etc) deployed along with Diameter DNCA: Added a clarification that NAT-device can have a configurable precedence among the protocols deployed to control it. NAT-device MUST act based on this precedence and decide on allowing/disallowing DNCA session establishment. Addition Result-code MAX_BINDINGS_SET_FAILURE has been added. 3. NAT-device state w.r.t. DNCA sessions: When Diameter peer within the NAT-device detects that Diameter peer within the NAT-controller is unreachable or down for e.g. by Device-watch-dog timeout, NAT-device state pertaining to DNCA sessions established with that NAT-controller must be cleared after a configurable grace period. If the DNCA diameter peer within NAT-device crashes it is beyond the scope of DNCA protocol specification. In addition, during IETF83 it was proposed to use session re-authorization with Authorization-lifetime and Authorization-grace period AVP to handle this case. Since per session reauthorization to detect peer failure in NAT-controller will be an overkill, DWG timeout appears to be sufficient to handle this case. Appreciate if you can review and provide comments if you object to any of these changes. Thanks, Shwetha ------ Forwarded Message From: Martin Stiemerling Date: Tue, 17 Apr 2012 11:33:01 +0200 To: Shwetha bhandari Cc: The IESG , , Subject: Re: Martin Stiemerling's Discuss on draft-ietf-dime-nat-control-15: (with DISCUSS) Hi all, On 04/11/2012 12:12 PM, shwethab wrote: > Hi Martin, > > We are in the process of updating the draft and need your guidance, please > find our comments/proposed update inline. > > > On 3/29/12 7:33 PM, "Martin Stiemerling" > wrote: > >> Martin Stiemerling has entered the following ballot position for >> draft-ietf-dime-nat-control-15: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Referring to version -15 of the draft >> >> The below has been discussed with the authors and I'm waiting for an >> update of the draft: >> >> What happens when the DNCA peer in the NAT device crashes. This seems to >> be described at the end of Section 4.6 >> >> o The DNCA Diameter peer within the NAT-device is unreachable or >> down and NCR fails to get a response. Handling of this case >> depends on the actual service offering of the service provider. >> The service provider could for example choose to stop offering >> connectivity service. >> >> This is really weak from an operational view, i.e., a crashed DNCA peer >> will leave 'zombie' NAT bindings in the device. >> >> Each installed binding does not have a timeout value after the binding is >> automatically removed. At least I cannot find any timer in that respect. >> >> There is the "Event-Timestamp indicates the binding creation time. If >> NAT-Control-Binding-Status is set to Removed, Event-Timestamp indicates >> the binding removal time" >> >> However, this is not a timer which takes care that bindings are >> automatically removed, if nobody else is doing this. > > Agreed that NAT bindings should not continue to exist infinitely as a result > of failure of Diameter peers. To resolve this we have to detect that the > Diameter peers have failed and then have a mechanism to cleanup the NAT > bindings. > To detect the failure of the Diameter peers, we could: > Option 1. Rely on Diameter watch dog - Diameter protocol has a inbuilt > watchdog message exchange (RFC 3588 - Device-Watchdog-Request) that is a > keep alive mechanism used by Diameter protocol. > Option 2. Have an explicit keep alive between the DNCA peers. This was > proposed at the DIME wg, using per session recurring periodic > reauthorization. > Option 2 seems to be a overkill, so after discussing with the DIME chairs we > are planning to use Option 1 to detect failure of the peers either in NAT > device or NAT-controller and take specific action, do you agree? Option 1 is good, especially as it is reusing an existing mechanism. > > "When DNCA application on NAT device detects (using the above mechanism) > that the NAT-controller application has failed, it will trigger clearing of > all the NAT-bindings after a grace period that is configurable on the > NAT-device. When DNCA application within NAT-controller detects failure of > DNCA peer within NAT-device, it may try to reestablish DNCA sessions > associated with that peer or disconnect corresponding access sessions." The text is fine. > > To handle the case of DNCA peer within NAT-device having crashed, we plan to > add the following text in Section 4.6 (Failure scenarios) > "A discussion of the mechanisms how a NAT-device cleans up state in case the > DNCA-peer on the NAT-device crashes is outside the scope of this document. > Implementers of NAT-devices could choose from a variety of options such as > coupling the state (e.g. NAT bindings) to timers which require periodic > refresh, or time out otherwise, operating system watchdogs for applications, > etc." The text is fine. > > We also plan to update security-consideration with : > " The operator also needs to consider security threats resulting from > unplanned termination of the DNCA session. Unplanned session termination, > which could e.g. happen due to an attacker taking down the NAT-controller, > leads to the NAT-device cleaning up the state associated with this session > after a grace period. If the grace period is set to zero, the endpoint will > experience an immediate loss of connectivity to services reachable through > the NAT-device following the termination of the DNCA session." > > We plan to add the above text into the revised ID if you agree. The text is fine. > >> >> >> >> Some other questions left open by this draft: >> - What happens if a requested NAT binding is in conflict with an already >> installed NAT binding or local configuration policy? > > > We plan to add this text: > Operational considerations MAY require an operator to use > alternate control mechanisms or protocols such as SNMP or manual > configuration via a Command-Line-Interface to apply per-endpoint NAT- > specific configuration, like for example static NAT-bindings. For > these cases, the NAT-device MUST allow the operator to configure a > policy how configuration conflicts are resolved. Such a policy could > for example specify that manually configured NAT-bindings using the > Command-Line-Interface always take precedence over those configured > using DNCA. The text is fine. > > If DNCA peer in NAT device requests the entity that manages the Binding > within the NAT device to install a binding but fails due to a conflict, our > draft specifies that it should return an error to the controller with an > error code indicating (8.2.3. Permanent Failures) - > BINDING_FAILURE (TBD.RCX) > > DNCA indicates that the requested binding(s) could not be > installed. For example: Requested ports are already in use. The text is fine. > > We plan to add another error code as follows: > > MAX_BINDINGS_SET_FAILURE (TBD.RCX) > > The DNCA Diameter peer within the NAT-device indicates that it > failed to conform to a request to configure the maximum number > of bindings for a session. For example: An operator defined > the maximum number of bindings on the NAT-device using a method > or protocol which takes precendence over DNCA. The text is fine. > >> - Section 3.3, >> "This is to ensure that NAT-devices >> controlled by multiple NAT-controllers do not receive conflicting >> control requests for a particular endpoint, or would be unclear which >> NAT-controller to send accounting information to." >> But what happens if a DNCA NAT is receiving conflicting control >> requests? >> - what happens if DNCA has installed a binding which is also owned by >> some other entity? This can happen, but the question is if what happens >> with the NAT binding in the NAT itself, if the binding is removed from >> DNCA? How are bindings differentiated? Other approaches, such as SIMCO >> and the MIDCOM MIB introduce the onwership of the binding, allowing to >> identify which agent is owning the binding. This allows also >> implementations to have multiple owners for the same binding. >> - How would you express such ownership? > > > We plan to clarify this by adding following text: > "From a DNCA perspective an operator MUST ensure that the session > representing a particular endpoint is atomic." Not perfect, since the protocol does not give any hint if something is going wrong, but I can live with that. However, you cannot specific what an operator is supposed to do, i.e., 'MUST' is not appropriate here. You can only specify what the protocol must do. > > > By specifying end point being controlled by a single DNCA controller it > eliminates the cases where conflicting control messages can be received for > the same endpoint from different controllers. > All the control messages are received to be applied for a specific session > representing an endpoint, hence control message for a given endpoint cannot > conflict with control message for another. Conflicts can happen when an > existing session is updated. > For e.g. > Maximum NAT bindings to be installed for an endpoint is a control message- > This applies to a endpoint session, DNCA protocol handles update of this and > specifies behavior when an update message changes already active value. > Behavior and error codes are specified in 4.2. Session Re-Authorization. > > If you are referring to Bindings of a given endpoint that may conflict with > bindings to be installed for another endpoint session, we can add text in > the draft to clarify that: > "The endpoint identifier Framed-IP-Address and the internal address in > NAT-Internal-Address specified to install NAT-bindings for the session MUST > match." Yes, this would be good. > > If the external address + port required to create a binding is in use we > already have the Binding failure (BINDING_FAILURE error code) > > Ownership is expressed by the concept of DNCA session that is unique per > endpoint b/n the NAT-controller and the NAT device. How this ownership is > maintained by the NAT-device w.r.t NAT-binding is NAT-device implementation > detail and API specification between DNCA application and entity that > manages NAT binding within the NAT-device. Ok. > > Thanks, > Frank/Shwetha > I have not checked the spelling which is probably required here and there. Please submit an updated draft and I will clear my discuss once the draft is there. Thanks, Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 ------ End of Forwarded Message From internet-drafts@ietf.org Sun Apr 22 18:14:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16621F852D; Sun, 22 Apr 2012 18:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu+fKrBJV6mA; Sun, 22 Apr 2012 18:14:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E70521F852A; Sun, 22 Apr 2012 18:14:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423011431.24701.29073.idtracker@ietfa.amsl.com> Date: Sun, 22 Apr 2012 18:14:31 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 01:14:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Address and Port Translation Control Ap= plication Author(s) : Frank Brockners Shwetha Bhandari Vaneeta Singh Victor Fajardo Filename : draft-ietf-dime-nat-control-17.txt Pages : 62 Date : 2012-04-22 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 networks to cope with IPv4-address space depletion. 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-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-17.txt From internet-drafts@ietf.org Mon Apr 23 08:36:04 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395F21F8493; Mon, 23 Apr 2012 08:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeP8sFx5yMST; Mon, 23 Apr 2012 08:36:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C46A21F8470; Mon, 23 Apr 2012 08:36:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423153601.18275.36498.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 08:36:01 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:36:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Access Server Application Author(s) : Glen Zorn Filename : draft-ietf-dime-rfc4005bis-08.txt Pages : 66 Date : 2012-04-23 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. 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-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-08.txt From glenzorn@gmail.com Mon Apr 23 08:37:38 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239C921F85B6 for ; Mon, 23 Apr 2012 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M-HnJR3+LOs for ; Mon, 23 Apr 2012 08:37:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 984C021F86A2 for ; Mon, 23 Apr 2012 08:37:37 -0700 (PDT) Received: by yenm5 with SMTP id m5so7188615yen.31 for ; Mon, 23 Apr 2012 08:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dn/DA56BLzLMsVWJgcnr4+gPVG/xrU0b5A2BBof6eQQ=; b=B/y7XzHjM63vxR66mnwlbyMM+cJ9PSGa15uHRD8fI4EmlwBrVJ+iUcv4GDmb5coDg7 QRz/Oi7RLgjMsVhYW+fd9Ts/PaTJMlr0xTRS8AUuGEh2GfsOG+YuPXDHEBHWMhLsi2bU sThrI7MqsByuVx6XRQtm872lelX/jC7lwivA6ZDJSGrikEeUELY0aOt1YGdsH227LBGH SnMzrmMNLIZMujOgvkHhnitrj+kRxBcGt7zUrr/PSoZcavpBTauIw7EIJOzIfEXR7Wno 92KbVtYiYx5LG3o87bBZky4ur40JgcS/UrTplinRN/cD89pNlbuzAfD1yiDzz51/r5ur vTkg== Received: by 10.182.141.9 with SMTP id rk9mr14075733obb.50.1335195456915; Mon, 23 Apr 2012 08:37:36 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-135-9.revip2.asianet.co.th. [124.120.135.9]) by mx.google.com with ESMTPS id tx2sm16411185obb.8.2012.04.23.08.37.32 (version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 08:37:35 -0700 (PDT) Message-ID: <4F957738.7050807@gmail.com> Date: Mon, 23 Apr 2012 22:37:28 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: dime@ietf.org References: <20120423153601.18275.36498.idtracker@ietfa.amsl.com> In-Reply-To: <20120423153601.18275.36498.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:37:38 -0000 A few purely editorial changes. > 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) : Glen Zorn > Filename : draft-ietf-dime-rfc4005bis-08.txt > Pages : 66 > Date : 2012-04-23 > > This document describes the Diameter protocol application used for > Authentication, Authorization, and Accounting (AAA) services in the > Network Access Server (NAS) environment; it obsoletes RFC 4005. 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-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-08.txt > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Thu Apr 26 03:40:42 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCC021F87E6; Thu, 26 Apr 2012 03:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecuu4OdxDINF; Thu, 26 Apr 2012 03:40:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC35F21F87A2; Thu, 26 Apr 2012 03:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120426104041.18185.77218.idtracker@ietfa.amsl.com> Date: Thu, 26 Apr 2012 03:40:41 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:40:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Support for Proxy Mobile IPv6 Localized Routing Author(s) : Glen Zorn Qin Wu Marco Liebsch Jouni Korhonen Filename : draft-ietf-dime-pmip6-lr-11.txt Pages : 11 Date : 2012-04-26 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-pmip6-lr/