From bill.wu@huawei.com Sun Jul 3 23:53:53 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE2721F8642 for ; Sun, 3 Jul 2011 23:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRXTqpOAuRu7 for ; Sun, 3 Jul 2011 23:53:53 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id DA82921F8636 for ; Sun, 3 Jul 2011 23:53:52 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNS00BNJR5RTP@usaga01-in.huawei.com> for dime@ietf.org; Mon, 04 Jul 2011 01:53:52 -0500 (CDT) Received: from huawei.com ([172.17.1.90]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNS004WKR5Q5D@usaga01-in.huawei.com> for dime@ietf.org; Mon, 04 Jul 2011 01:53:51 -0500 (CDT) Received: from [172.24.1.33] (Forwarded-For: [10.138.41.76]) by szxmc01-in.huawei.com (mshttpd); Mon, 04 Jul 2011 14:53:50 +0800 Date: Mon, 04 Jul 2011 14:53:50 +0800 From: wuqin 53375 To: dime@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Dime] Remaining issues of draft-ietf-dime-erp-06 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, 04 Jul 2011 06:53:53 -0000 Hi=2C I have read the version 06 of draft-ietf-dime-erp and found a number of E= ditor notes in the form of QUESTION or PROBLEM that still needs to clean up=2C here are my editorial comments and sugges= tions on this draft=3A - Section 4=2C Paragraph 4=3A =22this ERP/DER message reachs this server=22= -=3E =22this ERP/DER message reaches this server=22 - Section 4=2C Paragraph 6=3A =22an error DIAMETER=5FUNABLE=5FTO=5FDELIVE= R is generated as specified in =5BRFC3588=5D and returned to the authenti= cator=2E=22 = -------------------------------------------------------------------------= ------- =5BQin Wu=5D=3A It is not clear who send this error message to the authen= ticator that sends ERP/DER message=3F I think it is home EAP server that send error message=2E - Section 4=2C Paragraph 9=3A =22the ER server should not possess the roo= t key in its local database=2E In this case=2C the ER server acts as a pr= oxy=22 -=3E =22the ER server may or may not possess the root key in its l= ocal database=2E If the ER server possess the root key=2Cthe ER server s= hould respond directly to the peer that initiate ERP exchange otherwise=2C= the ER server acts as a proxy=22 - Section 5=2E1=2C Paragraph 1=3A =22the server is immediatly available f= or re-authentication of the peer=22-=3E=22the server is immediately avail= able for re-authentication of the peer=22 - Section 5=2E2=2CParagraph 2=3A = =22 Change the content of Application-Auth-Id accordingly=2E = QUESTION=3A Is it better to leave it unmodified=2C so that the serv= er can easily differenciate between ERP and standard EAP message=3F =22 -------------------------------------------------------------------------= ------- =5BQin Wu=5D=3AOf Application-Auth-Id AVP is included=2C I think it will= be better to change Application-Auth-Id to get = consistent with the value of Application ID in the message header=2E - Section 5=2E2=2C Paragraph 2=3A =22 Add the ERP-RK-Request AVP=2C which contains the name of the domain= where the ER server is located=2E = PROBLEM=3A Add the Destination-Host AVP to reach the appropriate Diameter EAP server in case there is more than one in destination domain=2C the one with the EMSK=2E How does the ER server know thi= s information=3F Or can we require that all Diameter EAP servers can= be used interchangeably for this purpose=3F =22 -------------------------------------------------------------------------= ------- =5BQin WU=5D=3A What about the case where there are one ER server locat= ed in visited domain and one ER server located in the home domain=2C which domain name should be included in th= e ERP-RK-Request message=3F To fix this=2C we have two ways=3A 1=2E only allow the ER server that is close to the client to add th= e name of the domain where the ER server is located to the Diameter messa= ge=2E 2=2E Only allow one ER server between the peer and home EAP server=2C= i=2Ee=2E=2C either local ER server or home ER server=2E - Section 5=2E2=2C Paragraph 2=3A =22 PROBLEM=3A Add the Destination-Host AVP to reach the appropriate Diameter EAP server in case there is more than one in destination domain=2C the one with the EMSK=2E How does the ER server know thi= s information=3F Or can we require that all Diameter EAP servers can= be used interchangeably for this purpose=3F =22 =5BQin Wu=5D=3AIt seems to me the ER server doesn=A1=AFt know Destination= -Host AVP that contain the Diameter EAP server unless = the Diameter EAP server told the ER server during Root key transportation= in the bootstrapping phase=2E - Section 5=2E3=2C Paragraph 4=3A =22 In particular=2C it includes the Domain- Name TLV attribute with the content from the ERP-Realm AVP=2E =22 -------------------------------------------------------------------------= ------- =5BQin Wu=5DIt is not clear which message include Domain Name TLV=3F I guess the rationale here is to guarantee that the Diameter message rout= ing to and from the server go through the same path=2E If in such case=2C= this sentence should be placed behind the last sentence=2E =22 - Section 6=2CParagraph 4=3A=22It creates a Diameter EAP Request followin= g the general process of Diameter EAP =5BRFC4072=5D=22 -=3E =22It creates a Diameter ERP/DER message following the general proce= ss of Diameter EAP =5BRFC4072=5D=22 - Section 6=2C Paragraph 4=3A =22 The Auth-Request-Type AVP content is set to =5BEditor=27s note=3A FFS=5D=2E= =22 -------------------------------------------------------------------------= ------- =5BQin WU=5DIf we decouple authorization from authentication and leave a= uthorization out of scope=2C the Auth-Request-Type should be always authe= nticate=5Fonly=2E If we need to discuss how to deal with authorization AVP=2C the Auth=5Fre= quest-Type can be authoriz=5Fonly or authorize=5Fauthenticate=2E - Section 12=2C Paragraph 2=3A =22 = FFS=3A Do we really respect these security considerations with the mechanism we describe here=3F Is it safe to use ERP-RK-Request =26 Ke= y AVPs=3F What is the worst case=3F For example if a domain tricks the= peer into beliving it is located in a different domain=3F -------------------------------------------------------------------------= ------- =5BQin WU=5D=3AGood question=2C I think at least RFC3588 or bis and RFC4= 072 should apply here=2E = But I am not sure RFC5247 or RFC5295 should apply here=2E As described in RFC5296=2C in order to protect the content delivered in t= he EAP-Finish to = the local ER server=2C the home ER server need to verify the validity of = local ER server and = told the peer using authorization Indication TLV=2E =22 - Section 12=2C Paragraph 3=3A =22 EAP channel bindings may be necessary to ensure that the Diameter client and the server are in sync regarding the key Requesting Entity=27s Identity=2E Specifically=2C the Requesting Entity advertis= es its identity through the EAP lower layer=2C and the user or the EAP peer communicates that identity to the EAP server (and the EAP server communicates that identity to the Diameter server) via the EAP method for user/peer to server verification of the Requesting Entity=27s Identity=2E = QUESTION=3A What does this paragraph actually mean=3F -------------------------------------------------------------------------= ------- =5BQin WU=5D=3AI guess the motivation to write this paragraph is to deal= with authorization issue=2E If we agree authorization issue should be addressed in this document and= Session-Id is part = of Channel Binding information=2C this paragraph may be relevant=2E =22 Regards! -Qin *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** From Internet-Drafts@ietf.org Tue Jul 5 14:15:05 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5202221F89D4; Tue, 5 Jul 2011 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kdu7Odyh9So; Tue, 5 Jul 2011 14:15:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2181E21F89DC; Tue, 5 Jul 2011 14:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705211502.27961.59699.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 14:15:02 -0700 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-priority-avps-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 21:15:05 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Priority Attribute Value Pairs Author(s) : K. Carlberg, et al Filename : draft-ietf-dime-priority-avps-04.txt Pages : 7 Date : 2011-07-05 This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-priority-avps-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-priority-avps-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-05140448.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Wed Jul 6 06:38:56 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45921F86E6 for ; Wed, 6 Jul 2011 06:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMMROzMRc+fl for ; Wed, 6 Jul 2011 06:38:56 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D663F21F871D for ; Wed, 6 Jul 2011 06:38:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsBABplFE6HCzI1/2dsb2JhbABTmFaDVotXd7BtAptdhjYEl1iENoZx X-IronPort-AV: E=Sophos;i="4.65,487,1304308800"; d="scan'208";a="289053947" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jul 2011 09:38:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jul 2011 09:32:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 15:38:53 +0200 Message-ID: In-Reply-To: <543AF4F7-F5BE-4009-AC28-0B26ACD7E802@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? Thread-Index: AcwqDPdBWBGwZupnQYWRmhDXHpIHUgR1OrXA References: <543AF4F7-F5BE-4009-AC28-0B26ACD7E802@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" Cc: dime@ietf.org Subject: Re: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? 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, 06 Jul 2011 13:38:56 -0000 Hi Jouni,=20 What is the status?=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Tuesday, June 14, 2011 12:01 AM > To: Romascanu, Dan (Dan) > Cc: Victor Pascual Avila; dime@ietf.org > Subject: Re: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? >=20 > Hi, >=20 > I am basically waiting until the NAPTR & SRV DISCUSS with extended- > naptr draft gets solved as RFC3588bis will have the same issue. >=20 > - Jouni >=20 >=20 > On Jun 13, 2011, at 1:59 PM, Romascanu, Dan (Dan) wrote: >=20 > > > > > > Hi DIME chairs and participants, > > > > Your AD would also like to know the answer to this question :-) > > > > Thanks and Regards, > > > > Dan > > > >> -----Original Message----- > >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = Behalf > Of > >> Victor Pascual Avila > >> Sent: Tuesday, June 07, 2011 12:58 PM > >> To: dime@ietf.org > >> Subject: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? > >> > >> Hi, > >> > >> What's the plan to finish draft-ietf-dime-rfc3588bis? > >> > >> Many thanks in advance, > >> -- > >> Victor Pascual =C1vila > >> _______________________________________________ > >> 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 iesg-secretary@ietf.org Wed Jul 6 08:49:59 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8EB21F8853; Wed, 6 Jul 2011 08:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnpDFF-msshk; Wed, 6 Jul 2011 08:49:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E080421F876C; Wed, 6 Jul 2011 08:49:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706154958.18369.8715.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 08:49:58 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: (Diameter Priority Attribute Value Pairs) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:49:59 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Priority Attribute Value Pairs' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-priority-avps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-priority-avps/ No IPR declarations have been submitted directly on this I-D. From jouni.nospam@gmail.com Thu Jul 7 14:40:48 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8AD9E8023 for ; Thu, 7 Jul 2011 14:40:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCpuxOOwtKy0 for ; Thu, 7 Jul 2011 14:40:48 -0700 (PDT) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by ietfa.amsl.com (Postfix) with ESMTP id E00B59E8022 for ; Thu, 7 Jul 2011 14:40:47 -0700 (PDT) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id 9DF6E240044; Fri, 8 Jul 2011 00:40:46 +0300 (EEST) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A031AD9C376; Fri, 08 Jul 2011 00:40:46 +0300 Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id 90D0E240044; Fri, 8 Jul 2011 00:40:46 +0300 (EEST) Received: from a88-114-175-183.elisa-laajakaista.fi (a88-114-175-183.elisa-laajakaista.fi [88.114.175.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 296A72166A7; Fri, 8 Jul 2011 00:40:43 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Fri, 8 Jul 2011 00:40:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8701C2E1-4979-4586-9A33-7C8EFEFFF9AB@gmail.com> References: <543AF4F7-F5BE-4009-AC28-0B26ACD7E802@gmail.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) X-Antivirus: VAMS Cc: dime@ietf.org Subject: Re: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? 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, 07 Jul 2011 21:40:48 -0000 Dan, Sorry for a slow response. I am still on a vacation (kind of). The = status has not changed regarding the issue mentioned below. Working on = it.. - Jouni On Jul 6, 2011, at 4:38 PM, Romascanu, Dan (Dan) wrote: >=20 >=20 > Hi Jouni,=20 >=20 > What is the status?=20 >=20 > Thanks and Regards, >=20 > Dan=20 >=20 >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Tuesday, June 14, 2011 12:01 AM >> To: Romascanu, Dan (Dan) >> Cc: Victor Pascual Avila; dime@ietf.org >> Subject: Re: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? >>=20 >> Hi, >>=20 >> I am basically waiting until the NAPTR & SRV DISCUSS with extended- >> naptr draft gets solved as RFC3588bis will have the same issue. >>=20 >> - Jouni >>=20 >>=20 >> On Jun 13, 2011, at 1:59 PM, Romascanu, Dan (Dan) wrote: >>=20 >>>=20 >>>=20 >>> Hi DIME chairs and participants, >>>=20 >>> Your AD would also like to know the answer to this question :-) >>>=20 >>> Thanks and Regards, >>>=20 >>> Dan >>>=20 >>>> -----Original Message----- >>>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On = Behalf >> Of >>>> Victor Pascual Avila >>>> Sent: Tuesday, June 07, 2011 12:58 PM >>>> To: dime@ietf.org >>>> Subject: [Dime] Plan to finish draft-ietf-dime-rfc3588bis? >>>>=20 >>>> Hi, >>>>=20 >>>> What's the plan to finish draft-ietf-dime-rfc3588bis? >>>>=20 >>>> Many thanks in advance, >>>> -- >>>> Victor Pascual =C1vila >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 From internet-drafts@ietf.org Sun Jul 10 13:06:41 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861A521F867A; Sun, 10 Jul 2011 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZlpMsG25-Z9; Sun, 10 Jul 2011 13:06:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1717E21F8650; Sun, 10 Jul 2011 13:06: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: 3.55 Message-ID: <20110710200641.21474.46011.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 13:06:41 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 20:06:41 -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-09.txt Pages : 45 Date : 2011-07-10 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-09.txt From internet-drafts@ietf.org Mon Jul 11 10:54:39 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386FD21F8E53; Mon, 11 Jul 2011 10:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVi9+JUzX5Dk; Mon, 11 Jul 2011 10:54:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE76321F8E4B; Mon, 11 Jul 2011 10:54:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711175438.15721.61007.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 10:54:38 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4005bis-05.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, 11 Jul 2011 17:54:39 -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-05.txt Pages : 65 Date : 2011-07-11 This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc4005bis-05.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-05.txt From jouni.nospam@gmail.com Tue Jul 12 04:51:55 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7F521F8EF8 for ; Tue, 12 Jul 2011 04:51:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yACyeDtkA0Ag for ; Tue, 12 Jul 2011 04:51:54 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E61621F8E67 for ; Tue, 12 Jul 2011 04:51:54 -0700 (PDT) Received: by bwb17 with SMTP id 17so4654237bwb.31 for ; Tue, 12 Jul 2011 04:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=20gVtDCxZz+hcxX8MROSMDPtv50bhbjP01vjhKeyyxU=; b=OswCTgBiV2euhCmHuOH0gg7E59PJrExbl79O9osKWzXo3NpszoGXYt0Zww3ZS5Bc6D 8Je1a9EcwRL6ckTQaT9K8n2RbDkGmh8YXwSO3VU7uCy/lh4Gd7U2T+U9UhRsnPoTHCWc 4rysQ4h81/uD/W+xj4rcD73N/rgkz45v1rit4= Received: by 10.204.74.17 with SMTP id s17mr2130564bkj.229.1310471513491; Tue, 12 Jul 2011 04:51:53 -0700 (PDT) Received: from a88-114-171-141.elisa-laajakaista.fi (a88-114-171-141.elisa-laajakaista.fi [88.114.171.141]) by mx.google.com with ESMTPS id j20sm1341681bks.56.2011.07.12.04.51.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 04:51:52 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2011 14:51:50 +0300 Message-Id: <340C9796-D529-4FC3-BBC6-4E6E5AA1E399@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Dime] Note takers & jabber scribe volunteers for IETF#81 Dime meeting 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, 12 Jul 2011 11:51:55 -0000 Folks, Please volunteer as a note taker & jabber scribe for the WG meeting. If = you feel like helping here, send the chairs a mail. - Jouni & Lionel= From lionel.morand@orange-ftgroup.com Sat Jul 16 04:32:51 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657E221F8646 for ; Sat, 16 Jul 2011 04:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MBOXfbs+Qqf for ; Sat, 16 Jul 2011 04:32:50 -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 6863C21F84E7 for ; Sat, 16 Jul 2011 04:32:48 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 578876D8003 for ; Sat, 16 Jul 2011 13:34:05 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4625F6D8002 for ; Sat, 16 Jul 2011 13:34:05 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Jul 2011 13:32:46 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC43AC.15849F95" Date: Sat, 16 Jul 2011 13:32:44 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-topic: IETF 81 Audio Streaming Thread-index: AcxDOZ3Hko0nXfGgQ5qTPZ2w2JeV0wAYmhgAAAPoJ4A= From: To: X-OriginalArrivalTime: 16 Jul 2011 11:32:46.0538 (UTC) FILETIME=[15C21AA0:01CC43AC] Subject: [Dime] TR: IETF 81 Audio Streaming X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 11:32:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC43AC.15849F95 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC43AC.15849F95" ------_=_NextPart_002_01CC43AC.15849F95 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI, especially for people that would like to remotely attend IETF-81. =20 Regards, =20 Lionel & Jouni From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Nick Kukich Sent: Saturday, July 16, 2011 12:53 AM To: ietf@ietf.org Subject: IETF 81 Audio Streaming =20 Greetings! We're two weeks out from the beginning of meeting streaming. For those interested in monitoring sessions or participating remotely the following information may prove useful. - -Audio Streaming- All 8 parallel tracks at the IETF 81 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT. Because we have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule are best retrieved from the IETF tools agenda, which as per Standard operating procedure will be located here: http://tools.ietf.org/agenda/81/ =20 - -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html =20 or click on the Jabber links in the tools team agenda once you have a properly configured jabber/xmpp messaging client. - -Webex- Webex screen sharing participation is possible for a limited number of sessions. Consult with your working-group chair or the secretariat for more information. - -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org =20 For streaming related issues please send email to=20 ietf-streaming@verilan.com with info including the current time and affected streaming channel. Regards, =20 Nick Kukich =20 Network Engineer Verilan Event Services, Inc. 503.710.5115 =20 ------_=_NextPart_002_01CC43AC.15849F95 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

FYI, especially for people that would like to remotely attend = IETF-81.

 

Regards,

 

Lionel & Jouni

From:= = ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = Nick Kukich
Sent: Saturday, July 16, 2011 12:53 = AM
To: ietf@ietf.org
Subject: IETF 81 Audio = Streaming

 

Greetings!

We're two weeks out from the beginning of = meeting streaming. For those interested in monitoring sessions = or participating remotely the following information may prove = useful.

- = -Audio Streaming-

All 8 parallel tracks at the IETF 81 meeting will be broadcast starting = with the commencement of working group sessions on Monday, July 25, 2011 = at 0900 EDT (GMT-4) and continue until Friday, July 29 at 1515 = EDT.

Because we have been = asked several times in the past, note that if you wish to use the rooms = that are being recorded for impromptu meeting during unscheduled = sessions or lunch breaks that you can invite remote participants to tune = in to the appropriate stream. Recording cannot be guaranteed for = unscheduled sessions. Conversely, it should never be assumed that = recording or observation is not occurring on open microphones, they are = after all connected to the Internet.

The links for streaming sources and the schedule are best = retrieved from the IETF tools agenda, which as per Standard = operating procedure will be located here:

http://tools.ietf.org/agenda/81/

- -Jabber/XMPP-

For information on IETF Jabber participation = see:

http://www.ietf.org/jabber/index.html

<= span class=3Dapple-style-span>or click on the Jabber links in the tools = team agenda once you have a properly configured jabber/xmpp messaging = client.

- = -Webex-

Webex screen = sharing participation is possible for a limited number of sessions. = Consult with your working-group chair or the secretariat for more = information.

- = -Ticketing-

For prompt = access to the meeting trouble desk, the email address = is:

mtd@ietf.org

For streaming related issues please send email = to ietf-streaming@verilan.com with info including = the current time and affected streaming channel.

Regards,

 

Nick = Kukich

 

Network = Engineer
Verilan Event Services, = Inc.

503.710.5115

 

------_=_NextPart_002_01CC43AC.15849F95-- ------_=_NextPart_001_01CC43AC.15849F95 Content-Type: text/plain; name="ATT4812602.txt" Content-Transfer-Encoding: base64 Content-Description: ATT4812602.txt Content-Disposition: inline; filename="ATT4812602.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklldGYgbWFp bGluZyBsaXN0DQpJZXRmQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lldGYNCg== ------_=_NextPart_001_01CC43AC.15849F95-- From jouni.nospam@gmail.com Wed Jul 20 09:52:53 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83021F8AFD for ; Wed, 20 Jul 2011 09:52: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNSwPzGmXrcz for ; Wed, 20 Jul 2011 09:52:52 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8821F8AFC for ; Wed, 20 Jul 2011 09:52:52 -0700 (PDT) Received: by eya28 with SMTP id 28so1207028eya.21 for ; Wed, 20 Jul 2011 09:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=S62P/6ENKJj3VRJDHfUDSbW00uxdVxjR+VgmoQ77M4g=; b=rqw2bnY/K5cTMCpXopACR0e/G9hDhu2fJM5MraSoHFabinu888HjrUhzdRhiI1+Trh NfIIWjie+WFurz8bm/c9kkOrV1Pv/XOxjkB2l9BK7iEUiXTrA6XP6/TaSYDs9fPsTW42 cm6WRZq2Km15o7QbNBm7R2lXh0fi8A5bMQi1M= Received: by 10.14.16.4 with SMTP id g4mr3451631eeg.240.1311180771575; Wed, 20 Jul 2011 09:52:51 -0700 (PDT) Received: from a83-245-214-115.elisa-laajakaista.fi (a83-245-214-115.elisa-laajakaista.fi [83.245.214.115]) by mx.google.com with ESMTPS id s55sm649927eeb.59.2011.07.20.09.52.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 09:52:50 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 19:52:48 +0300 Message-Id: <8DA91546-CA6F-4392-8559-A5BD95654852@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] Presentations! 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, 20 Jul 2011 16:52:53 -0000 Folks, Please, send your Dime WG presentations (ppt, pptx or pdf) to chairs by = the end of Tuesday (26th July). Jouni & Lionel= From Martin.Stiemerling@neclab.eu Wed Jul 20 06:33:53 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13BF21F8781; Wed, 20 Jul 2011 06:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.685 X-Spam-Level: X-Spam-Status: No, score=-100.685 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgvRkdZA5cXF; Wed, 20 Jul 2011 06:33:53 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DAFD921F8748; Wed, 20 Jul 2011 06:33:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BA10828000328; Wed, 20 Jul 2011 15:33:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc01lOc7ZVo4; Wed, 20 Jul 2011 15:33:51 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9B25928000326; Wed, 20 Jul 2011 15:33:31 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.125]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Wed, 20 Jul 2011 15:33:31 +0200 From: Martin Stiemerling To: "draft-ietf-dime-nat-control@tools.ietf.org" , "dime@ietf.org" Thread-Topic: tsv-dir review of daft-ietf-dime-nat-control-09 Thread-Index: AcxG2jxqScbzP0yQT824oXePckWTcA== Date: Wed, 20 Jul 2011 13:33:30 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Jul 2011 16:41:35 -0700 Cc: "tsv-ads@tools.ietf.org" , "tsv-dir@ietf.org" Subject: [Dime] tsv-dir review of daft-ietf-dime-nat-control-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: Wed, 20 Jul 2011 13:33:53 -0000 Hi there, I've reviewed this document as part of the transport area directorate's ong= oing effort to review key IETF documents. These comments were written prima= rily for the transport area directors, but are copied to the document's aut= hors for their information and to allow them to address any issues raised. = The authors should consider this review together with any other last-call c= omments they receive. Please always CC tsv-dir@ietf.org if you reply to or= forward this review. **Executive Summary: This draft has serious issues, described in the review, and needs to be ret= hought. **Review comments: *General - There is no place where the prior work of MIDCOM is mentioned. Is this intentionally and did the WG not know or consider prior work of the= IETF? MIDCOM is going beyond what this draft is specifying, as it also includes f= irewall control, plus some further features, such as learning about the int= erfaces used for the MIDCOM server.=20 What was the reasoning to not reuse MIDCOM or semantics developed for MIDCO= M? - The usage of RFC 2119 is missing in parts of the draft, e.g., the text in= Section 4 seems to be meant as mandatory but there is almost no RFC 2119 l= anguage.=20 - Is the DNCA able to allocate 2 consecutive transport ports? This is somet= imes required by legacy RTP/RTCP applications.=20 * Detailed review - Section 1, 1st paragraph, a nit: "... in their networks to deal with the depletion of available public IPv4 = Addresses". This is one reason out of many. NATs are around for 10+ years,= i.e., way before we were about to run out of IPv4 addresses.=20 - Section 2, and rest of the document: The terminology used in this draft is not well documented. There are NAT bi= ndings, NAT binding rules and predefined NAT binding rules (templates?). Ho= wever, the difference is not well documented, even though I understand the = difference. How do you name a NAT binding which is actually used by a data = exchange? - Section 3.1, page 8, 1st paragraph, "to increase the efficiency of the g= lobal IPv4 address pool utilization.": Not sure that this setting is only used for this use case. How about just w= riting: "Figure 2 depicts the deployment scenario where a service provider places a= NAT between the host and the public Internet." - It would be good to cite RFC6144-6147 for 6to4 to indicate on what basis = the address family translation is working in this draft. The same holds tru= e for IPv4.=20 - IPv6 to IPv4 translation: I was not able to figure out how such a signali= ng would be. There are no examples for this or guidance at all.=20 - IPv4 to IPv4 translation: It would be good to have one or some few exampl= es to see how such DNCA messages would look like.=20 - All figures: The figures are not especially meaningful for the reader and= do not help in my opinion to understand the protocol, but do not hamper un= derstanding either.=20 - Section 4.2, page 15, last bullet point starting with "If a NCR redfines.= ..": This touches a critical point of what happens if the new number of allowed = bindings is lower than the prior selected number of allowed bindings. The t= ext is not giving a good guidance of what should happen in this case and I = see it a weak point to let this open to the discretion of the implementatio= n. For a good specification I would at least expect a RECOMMENDATION or SHO= ULD, better a MUST. However, this comment relates to the lack of RFC 2119 l= anguage in this section.=20 - Section 4.2, page 16, bullet point "If a NCR specifies a new...": What happens in this case with already binding rules which are installed an= d actively used by a data session? Is the data session stopped and the bind= ing removed? - Section 4.3, page 17, bullet "2. Retrieve...": How does the DNCA peer with the NAT controller know about the available ext= ernal IP addresses at the NAT? This is not clear to me. Is this a feature o= f another DIAMETER application or is it assumed that the controller just kn= ows this somehow? - Section 4.4, 1st paragraph, "In response, the DNCA...": I cannot understand this sentence. - Figure 8: The text belonging to this figure does not mention that the NAT= bindings MUST be removed if the STR is received. This is only shown in the= figure. The text seems to be incomplete and also lacking RFC 2119 language= .=20 - Section 4.6, 1st paragraph: What is the redundancy support mentioned ther= e which is mandatory? Something which is a MUST must be well documented. I = cannot see this here.=20 - IANA section and IANA points in text: The use of TBD throughout the draft for IANA code-points and also in the IA= NA section is harmful for IANA and also for the draft at best. Why are you = not using meaningful identifiers for code-points and reference them in the = IANA section? The use of generic TBD placeholders will just create confusio= n for IANA and for you. - Section 6.1 and 6.2: I was surprise to see the list of parameters which c= an be included in requests and responses, after reading Section 4, where th= ose parameters are omitted. Given all these parameters and the lack of expl= anation in the draft, it seems to be hard for an implementer to get the lin= k between Section 4 and this. This needs further explanation in the draft, = see also my comment about how IPv6 to IPv4 translation works and about the = missing usage examples. - Section 8.x, broken labels of the tables: The figures in Section 8.x are actually tables, i.e., their description is = incorrect and broken.=20 - Section 8.5, Figure 13, "Reused QoS-attributes": Why are the AVP codes set to TBD if they are taken from RFC 5777? E.g., Dir= ection AVP (AVP Code 514) but not TBD! Kind regards Martin Stiemerling martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From gwz@net-zen.net Mon Jul 25 14:05:52 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BAA11E809E for ; Mon, 25 Jul 2011 14:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUCovWipZeLm for ; Mon, 25 Jul 2011 14:05:52 -0700 (PDT) Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) by ietfa.amsl.com (Postfix) with SMTP id 76BC411E809A for ; Mon, 25 Jul 2011 14:05:44 -0700 (PDT) Received: (qmail 13398 invoked from network); 25 Jul 2011 20:59:04 -0000 Received: from unknown (70.81.213.81) by p3plsmtpa06-10.prod.phx3.secureserver.net (173.201.192.111) with ESMTP; 25 Jul 2011 20:59:03 -0000 Message-ID: <4E2DD917.3040002@net-zen.net> Date: Mon, 25 Jul 2011 16:59:03 -0400 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/alternative; boundary="------------050403010000010903070103" Subject: [Dime] Fwd: ID Tracker State Update Notice: 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, 25 Jul 2011 21:05:52 -0000 This is a multi-part message in MIME format. --------------050403010000010903070103 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This is certainly progress! -------- Original Message -------- Subject: ID Tracker State Update Notice: Date: Mon, 25 Jul 2011 00:21:05 -0700 From: IETF Secretariat To: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc3588bis@tools.ietf.org State changed to Dead from AD is watching::AD Followup. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ --------------050403010000010903070103 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit This is certainly progress!

-------- Original Message --------
Subject: ID Tracker State Update Notice:
Date: Mon, 25 Jul 2011 00:21:05 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
To: dime-chairs@tools.ietf.org, draft-ietf-dime-rfc3588bis@tools.ietf.org 


State changed to Dead from AD is watching::AD Followup.
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/
--------------050403010000010903070103-- From fbrockne@cisco.com Thu Jul 28 14:00:28 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C75E8023 for ; Thu, 28 Jul 2011 14:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il10m6oLwvSN for ; Thu, 28 Jul 2011 14:00:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76C5E8014 for ; Thu, 28 Jul 2011 14:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=12401; q=dns/txt; s=iport; t=1311886826; x=1313096426; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=QKSG5CkwGPRTbK76tTLgxlbmkSREsSU+HqMfwoh41Ek=; b=VdgsoYU99noMwI4XOEiQg5MSCpaDX69BG8A5e0oboDAUD1tudNvKepMK 7OCcev0LFX+jFhSSKnkzc065AWFKEvGEHEaJBQEfCBuSmnqUSR2oScXnf wd4KRCjcou0VQX5EpLPnqyxBUn0kt8N4kNpK9vGB7U0m+r5Uz+3xHqf/h k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAALvNMU6Q/khR/2dsb2JhbAApDQEBAxQBIQozBAcaASsGBgEJFAcTUgEFEhEUB5drj093rEuBI549gyMBGguCGV8EmAmLVjo X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208";a="105273994" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 28 Jul 2011 21:00:13 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SL0D4B030647 for ; Thu, 28 Jul 2011 21:00:13 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 23:00:13 +0200 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 22:58:19 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC064689CE@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME IETF81 draft notes Thread-Index: AcxNaRSF1z14u6BJSpOi/CvQ9SqUOw== From: "Frank Brockners (fbrockne)" To: X-OriginalArrivalTime: 28 Jul 2011 21:00:13.0859 (UTC) FILETIME=[587FFF30:01CC4D69] Subject: [Dime] DIME IETF81 draft notes 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, 28 Jul 2011 21:00:28 -0000 FYI. Below are the raw notes from today's DIME WG session at IETF 81 (sorry for any typos/misspelled names etc). Please review and unicast me any updates/changes. I'll consolidate those into the final version. Thanks, Frank ------------------------------------------------------------------------ ------ DIME IETF 81 notes THURSDAY, July 28, 2011 1300-1500 Afternoon Session I =3D=3D Administrative =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ** WG status update (Jouni) ---------------------------- Discussion on Status of drafts in IESG processing: Discussion on draft-dime-priority-avps) * Ken C: IESG asks for of motivating new AVPs. Additions to an existing application. Will refer to the existing application incl. the security section. Revised i-d which has the reference to QoS needed. * Jouni K: Had discussions with IESG members. Conclusion is that not every ID has to have an outline of solution applicability. It is left to the reader to think of deployment scenarios/ applicability. * Simon M: Think that there are additions required for 3588-bis. (not the encrypted indicator). Indicator required in the message header. Will provide details during the presentation. General: * Dan R: There was an issue with the tools, which is why 3588bis temporarily disapeared. * Dan R:=20 Still waiting for base protocol mib. * Glen Z: Issues with co-author. Glen hopes to finish i-d. * Glen Z: Question: When 2 or more docs relate to each other they put them into a holding pattern - meaning that they are completed but wait for publication. Does this process still exist? * Jouni K: Don't know. =3D=3D Working group draft presentations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ** Diameter IKEv2 PSK (Simon M) draft-ietf-dime-ikev2-psk-diameter=20 (-v09 is in progress - being circulated among authors) --------------------------------------------------------- * Simon (see also presentation): - added architectural background to the draft - clarified that they do not specify how the IKE peer derives the PSK - key issue clarified that mutually authenticated TLS between Diameter nodes is already expected * Glen: Why "Key-SPI AVP is included in the request instead of Key AVP"? * Simon: In the request it does not make sense to send the full key, it only=20 needs to send the reference which key to use. This was based on comments received. * Simon: There would need to be an indication in the diameter header that "this avp=20 is critical", so that it would be encrypted. Does this make sense? * Glen: Wishful thinking that this would be a solution. Most attacks come from inside. * Simon: What is the solution? * Glen: Getting rid of hop by hop security is not the way to go. * Simon: 3588 does not mandate hop by hop security. * Simon: They will add a note to the security section. * Glen: Best solution would be encrypt it in the application. * Simon: This draft is not the right place to specify a solution * Lionel: Doc says that you need to have a secure transport. But it does not enforce IPsec/TLS. * Glen: Simple approach: "My network is secure - hence we don't have to do everything" - which isn't=20 appropriate - "my network is secure because i say it is secure" logic should not be applied. * Lionel: Then it is up to the telco/operator - not to the protocol, because the protocol says that=20 you have to secure it. Doc says it has to be secure - it does not say which mechanism (i.e.=20 TLS/IPsec).=20 * Glen: Putting a flag that says: If you go to the evil internet, then encrypt - is wrong. * Lionel: Then we have agreement. We're covered we don't need anything else. * Simon: So conclusion is that 358bis is sufficient. * Ken C: What exactly means "secure" - we probably needs to be specify what we mean. * Simon: Don't care about integrity protection - I care about encrypting the key. * Lionel: Please re-check whether the existing text in 3588bis reflects all security needs. * Simon: Text is sufficient. But from a practical point of view it is not. ** AAA support for PMIP mobility - localized routing (Qin Wu) (draft-ietf-dime-pmip6-lr) (see also presentation) =20 ------------------------------------------------------------=20 * Simon: What is A21? * Qin: Reference to problem statement for PMIP (specific use case). * Simon: Is this for MN goes through two MAGs to the same LMA at the same time. * Qin: No it is not. * Marco: Use case is different: It is two MNs - which communicate directly.=20 A21 is two MNs connected to two different MAGs. ** Diameter ERP=20 draft-ietf-dime-erp (Qin Wu) (see also presentation) ------------------------------- * Qui: discussed multiple times, but very little progress due to some issues * presentation outlines approach to resolve remaining issues: first is session management during peer handover * Linoel: How would it be possible to have the same session id by multiple NAS?=20 * Qin: They use different session IDs. Server would correlate session IDs. * Simon: Session is associated with client ID and IP-address. When handover happens,=20 one can easily assign the same IP address. He understands that one can have a=20 correlation id - but it is the same as client-id+ip-address. * Glen: what is the client ID? * Simon: Client id is included in accounting start. * Glen: Still unclear / don't understand * Simon: Mobile requests session through the NAS. Identity of the mobile is send to AAA that auths the session. In the response AAA asigns IP address to mobile. Mobile receives HAA. This identifies the session to AAA. * Qin: we talk different sessions - Diameter session vs. mobile session. * Simon: Unique identifier for accounting etc. is required - identifiers stay. * Linoel: Do we need something else to identify existing sessions. * Qin: Reuse acct-multi-session id * Lionel: Is this too limited? It is all about having a user move from one access to another access. * Glen: It is an authentication protocol. The user id is the same.=20 * Linoel: You can use this identifier. * Glen: Then NAS assigns a new accounting session ID. Some carriers see this as a big problem. * Linoel: OK it is only an accounting problem. Now I understand. * Simon: Old NAS sends accounting stop. The new NAS sends a start. It is not the same session. * Glen: acc-multi-session-id is included. Hence records can be correlated. * Simon: UDRs will be put into different caches. Are you saying that we now use this parameter to correlate different caches. * Mark Jones: Diagram does not help us - should say session-id 1 and 2 (not 1).=20 You are using acc-multi-session id the way it was expected to used. Works for me. * Glen: Everything works natural. Will be uncontroversial. * Simon: How is acc-multi-session id passed * Glen: Assigned by the server - it always comes back to the NAS (NAS1 or NAS2) * Qin: Second issue: Multiple EAP servers in the same home realm * Lionel: Any feedback from Hokey received? Do we need to combine the issue with the application? * Glen: We need to discuss the issue: ERP needs to talk to the same guy all the time (guaranteed by Diameter - may be? maybe not?). If it is somebody else, then this guy has to have the key. Once we resolve it we say e.g.: Once we have multiple EAP servers, they MUST by synchronized. * Lionel: Do we need to solve it within Diameter?=20 * Glen: There can be multiple solutions. Radius has the same issue. It is not an EAP problem. It is a transport problem. * Lionel: We need this for ERP at least - but issue is more generic. * Simon: Multiple servers in home domain is not an issue - but it is in local domain. * Glen: It is an issue in the home domain if there is explicit bootstrapping. * Glen: Issue only comes up with servers with disjoint databases. * Simon: Load balancing is common - but they ensure to have all the same state. ** draft-ietf-dime-nat-control (Frank B) ---------------------------------------- * Frank: Sorry no slides. Verbal summary: - Several DISCUSS received. Key ones are - How many NAT-controllers and NAT-devices? New rev will clarify the n:m relationship between controller and NAT-device It needs to be ensured that for a single endpoint there's only a single controller-NAT-device pair responsible. - Relationship MIDCOM (and other NAT control protocols) - Intended to be resolved by putting DNCA into the MIDCOM context. RFC 4097 studies Diameter as a potential MIDCOM candidate. DNCA almost fits MIDCOM. Small additions required to cope with consecutive ports and oddity of RTP/RTCP. - Security questions (largely around trust domain. Updated rev will include additional considerations) * Dan R.: Key issue in IESG: MIDCOM - RFC 4097 (framework doc) was prepared to provide context for MIDCOM protocol selection. - Protocol happend not to be Diameter.=20 - Positioning: There can be multiple implementations of MIDCOM - because management requirements and deployments by operators differ. Examples already exist: e.g. SNMP and NETCONF. - We're proposing *another* standards track - intended to complement existing protocol for MIDCOM. Not intended for replacement. There can be more than a single management protocol - following the requirements of different operators/deployments (and Diameter is already used in multiple deployments); Having multiple protocol options is typical for management protocols.=20 - Protocol work on DNCA could potentially (if there is interest) be complemented with BCP work in transport area, recommending one over another solution. - If desired (see note on n:m), it could even be that a single NAT-box is controlled by different protocols (while ensuring that a single endpoint is=20 only under the control of a single Controller and NAT-device pair) ** draft-ietf-dime-extended-naptr (Mark J) * Mark provides brief update (see slides). No comments from the WG. ------------------------------------------------------------------- ** Diameter Bulk Signaling (Marco)=20 (draft-liebsch-dime-diameter-bulksig) (draft-liebsch-dime-diameter-gps) (please also see presentation) -------------------------------------- * Dan R.: Do you have a feeling how much you can reduce the load? * Marco: Depends on the scenario. * Jouni: Could be a huge amount. * Dan R: Do we need to have TISPAN/3GPP approve the doc? * Marco: Shouldn't we do the work first? * Dan R: Proposal should be circulated during individual submission phase with other SDOs first. * Glen: Seems 4th time that it comes up. Does not have anything to do with AAA. But while back, Glen=20 said: Let's have a BOF - but it never happened. He does not have the time and energy to spare on a BOF.=20 Request to the Chairs: Take it or don't take it. We need a decision: Whether it belongs here (i.e.=20 change the charter of dime) or start a BOF. * Mark J: I would like to see this done. I don't mind where it is done. 3GPP and others have use=20 cases. The way things are done right now - we don't want to see this happening. I want this group to=20 review this (or another group of experts). * Lionel: Do we really need to do such work? We need to have clear requirements for this work. We need=20 to ensure that this work will be useful for other SDOs and be used. * Mark J.: My concern is that there is a certain time window. If we hesitate, we look at the BCP out=20 there and do things on their own. * Janrong Wang: Followed 3GPP. Comes to IETF to look for solutions. Includes overload scenarios (e.g.=20 server tells client that he's overloaded).=20 * Marco: Problems are out there. What do you want us to do? * Dan R.: If there are other SDOs - have them come to IETF, submit to the dime list. If we say that=20 we solve the problems of other SDOs, then these other groups need to tell us.