From dromasca@avaya.com Mon Mar 7 03:51:56 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9A13A63D2 for ; Mon, 7 Mar 2011 03:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJHZtq8aoJQA for ; Mon, 7 Mar 2011 03:51:54 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id BA3FC3A63C9 for ; Mon, 7 Mar 2011 03:51:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU3GmAcF/2dsb2JhbACYKo47dKR5ApkWhWEEkAyDAA X-IronPort-AV: E=Sophos;i="4.62,276,1297054800"; d="scan'208";a="235509752" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Mar 2011 06:53:05 -0500 X-IronPort-AV: E=Sophos;i="4.62,276,1297054800"; d="scan'208";a="591523356" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Mar 2011 06:53:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 12:52:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-dime-nat-control-07.txt Thread-Index: AcvauFTU8mwfn3/0TCq1Z7d4KYneWQCBdGOg From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: Gen-ART review of draft-ietf-dime-nat-control-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 11:51:57 -0000 =20 -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]=20 Sent: Saturday, March 05, 2011 12:06 AM To: fbrockne@cisco.com; shwethab@cisco.com; vaneeta.singh@gmail.com; vf0213@gmail.com; Jouni Korhonen; Romascanu, Dan (Dan) Cc: General Area Review Team Subject: Gen-ART review of draft-ietf-dime-nat-control-07.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft. For background on Gen-ART, please see the FAQ at Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-nat-control-07.txt Reviewer: Miguel Garcia Review Date: 2011-03-04 IETF LC End Date: 2011-03-08 IESG Telechat date: Summary: This draft is on the right track but has open issues, described in the review. Major issues: none Minor issues: - The draft relies on the roles of a DNCA Manager and a DNCA Agent. I=20 don't understand why these two new roles need to be introduce, when RFC=20 3588 already provide some roles. In particular I don't see the difference=20 between what you call the DNCA Manager and what RFC 3588 calls a Diameter=20 Server; and I don't see the difference between your DNCA Agent and RFC=20 3588 Diameter Client. Furthermore, I haven't seen a proper definition of DNCA Manager and DNCA Agent, so, I have my own idea, which basically=20 points to the Diameter Sever and Client I just mentioned. The suggestion is to not invent the wheel twice and refer to the=20 terminology in RFC 3588, unless you can prove that this is insufficient. - When I was reading Section 4, which discusses the procedures, and I was=20 asking myself whether this application would use the ASR/ASA commands. I finished reading Section 4, and I found no reference to these commands,=20 and I thought there was an issue there. But then I found the first=20 reference to ASR/ASA in Section 5.3, and elsewhere in the document. So,=20 in order to avoid that the reader is as confused as me, I would suggest=20 to add a new section, which would be 4.6, and discusses "Session Abort"=20 like the rest of the procedures of the application. - On Section 6.2, the NCA command, I noticed that the NC-Request-Type AVP=20 is required in the message, because it is enclosed in curly brackets {}. It is not clear to me why this AVP should be mandatory in the answer (I=20 agree it should be mandatory in the request). - Also on Section 6.2, the NCA command, I don't see why the Result-Code=20 AVP is optional in an answer. I thought an answer should always report a result of any kind. - On Section 7, page 23, I have a question on the state machine marked as=20 "Open Access Session end detected Send STR Discon". I don't=20 understand what is "Access Session end detected". It is not obvious from the rest of the document, so, I guess it should be explained. - On Section 7, page 23, there are two instances of the term "client".=20 Now I am not sure if this is the Diameter client (that I think you should=20 be using throughout the document) or it is something else. - On Section 7, the DNCA Agent state machine (page 24). There is a line=20 that reads: "Open NCR request received, and unable to provide requested NAT control service Send failed NCA, Cleanup Idle". So, if I=20 understand correctly, the case is that under an Open state, if the DNCA=20 Agent receives an NCR request, but it is not able to provide the NAT=20 control service, so it sends back an NCA with a failed result. The=20 question is whether the NCR created a session or not. From the state=20 machine I understand it didn't create a session. So, I can conclude that a session is created when a successful NCA is sent. If this is the case, then look at Figure 5 on page 13, where there is a "Create session state"=20 in between an NCR and an NCA message. If this NCA had failed, you would=20 still had a session created. So, somehow you need to make Figure 5=20 congruent with the state machine of the DNCA Agent. You can modify figure=20 5 (and the surrounding text) to indicate that the session is created=20 after a successful NCA (and not before), or you can modify the state=20 machine line I mentioned, to indicate that not only you should send a=20 failed NCA, but also transition to a Disconn state in order to send an ASR. - On Sections 8.2.2 and 8.2.3, the RESOURCE_FAILURE and the=20 UNKNOWN_BINDING_RULE_NAME have both exactly the same description. The=20 only difference is that the former is a transient failure whereas the=20 latter is a permanent failure. Honestly, I don't understand the=20 difference between both, and when I should generate one or the other. I=20 would suggest that the latter adds a paragraph starting with "The=20 difference between this code and the RESOURCE_FAILURE is ..." Similarly, I don't see the difference between UNKNOWN_BINDING_RULE_NAME=20 and BINDING_FAILURE. I also suggest to clearly explain it or delete one=20 of them. - Section 12, IANA considerations section. You need to mention the=20 registry and subregistry where you want IANA to operate. For example:=20 This document instructs IANA to assign values to the [choose:=20 Commands/AVP Codes/etc] subregistry of the Authentication, Authorization,=20 and Accounting (AAA) Parameters registry. Also, in Tables 1 to 4, under the "Reference" column, you don't need to=20 refer to a section in this draft, but just right "RFC XXXX", which later will be replaced by the RFC number of this draft. Additionally, the headings of each table needs to be congruent with the=20 registry, so, Table 2 should read "AVP Code Attribute Name ", and so on. Take a look at the registry in=20 http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml and you=20 make some similar table. - I have an unparseable sentence in Section 12. Please split it and make it understandable. To secure the information exchange between the authorizing entity (DNCA Manager) and the NAT device (DNCA Agent) requires bilateral authentication of the involved parties, authorization of the involved parties to perform the required procedures and functions, and procedures to ensure integrity and confidentiality of the information exchange MAY be performed. Nits: - Section 3.3, at the beginning of the section, add "server" as follows: s/The role of the DNCA can be/The role of the DNCA server can be=20 ^^^^^^ - On Section 6.2, you have a duplicated "*[AVP]" towards the end of the=20 command. - On the title of Sections 8.4, 8.5, and 8.6 add "AVPs" as follows: s/Reused from/Reused AVPs from" - On Figure 14 (page 29), towards the bottom, there is a reference to the=20 "V" bit. However, the "V" is never used in this figure, so, I suggest to delete the sentence that describes the "V". - Section 8.7.1 under INITIAL_REQUEST, missing "a" s/is used to install binding at/is used to install a binding at - First paragraph in Section 8.7 various missing articles and other typos: s/that references predefined policy/that reference a predefined policy s/policy template on DNCA Agent/policy template on the DNCA Agent s/contain static bindings, maximum number/contain static binding, a=20 maximum number s/to be allowed, address pool/to be allowed, or an address pool s/external binding address/external binding addresses Regards, Miguel G. --=20 Miguel A. Garcia +34-91-339-3608 Ericsson Spain From Internet-Drafts@ietf.org Mon Mar 7 07:15:02 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 897A73A67D4; Mon, 7 Mar 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHe045EjD6uc; Mon, 7 Mar 2011 07:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E773A67EA; Mon, 7 Mar 2011 07:15:01 -0800 (PST) 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.12 Message-ID: <20110307151501.996.75000.idtracker@localhost> Date: Mon, 07 Mar 2011 07:15:01 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter S-NAPTR Usage Author(s) : M. Jones, et al. Filename : draft-ietf-dime-extended-naptr-06.txt Pages : 12 Date : 2011-03-07 The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates [RFC3588] and describes an improvement using an extended format for the Straightforward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-extended-naptr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07071258.I-D@ietf.org> --NextPart-- From jouni.korhonen@nsn.com Wed Mar 9 05:34:19 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7EC3A684D for ; Wed, 9 Mar 2011 05:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XqsJPrdQJhT for ; Wed, 9 Mar 2011 05:34:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 887C03A69A2 for ; Wed, 9 Mar 2011 05:34:17 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p29DZWid029517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2011 14:35:32 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p29DZUHM009890 for ; Wed, 9 Mar 2011 14:35:32 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 14:35:30 +0100 Received: from 10.144.246.189 ([10.144.246.189]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server demuexc023.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Mar 2011 13:35:29 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Mar 2011 15:35:27 +0200 From: Jouni Korhonen To: Message-ID: Thread-Topic: SECDIR review of draft-ietf-dime-nat-control-07 Thread-Index: AcveXtmlyWyz5l8Qz0+VPAQDYNhu9A== In-Reply-To: <4D77818E.4050703@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Mar 2011 13:35:30.0136 (UTC) FILETIME=[DB843D80:01CBDE5E] Subject: [Dime] FW: SECDIR review of draft-ietf-dime-nat-control-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 13:34:19 -0000 FYI: Secdir review. - JOuni ------ Forwarded Message > From: ext Matt Lepinski > Date: Wed, 09 Mar 2011 08:33:02 -0500 > To: , , > > Subject: SECDIR review of draft-ietf-dime-nat-control-07 > Resent-From: > Resent-Date: Wed, 9 Mar 2011 14:32:55 +0100 > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines a Diameter application whereby a Diameter NAT Control > Application (DNCA) server (either a AAA server or a Network Access Server) can > control a DNCA client (either a NAT or NAPT device). For example, the DNCA > server can determine the number of port bindings available to a given host, > cause the allocation of particular NAT bindings, define the external address > pool used for by the NAT device, or generate reports used for accounting > purposes. > > The principle security concern is that an unauthorized (or unauthenticated) > DNCA server could effect a denial of service of attack on any or all hosts > using a NAT/NAPT device in several ways. (E.g., an unauthorized server could > exhaust resources in the NAPT device, set maximum bindings to zero for all > hosts, provide a set of external addresses that are in use elsewhere in the > network, etc.) An additional concern is that an unauthenticated DNCA client > could provide incorrect reporting data to the DNCA server to prevent correct > accounting within the system. Therefore, the NAT control application requires > mutual authentication, authorization of the DNCA server, and integrity > protection of the Diameter messages in the DNCA interaction. Additionally, the > application may require confidentiality depending on the deployment scenario > and, particularly, how authorization is accomplished. > > The Security Considerations section of the document claims that security > considerations are essentially the same as in the Diameter QoS (RFC 5866). I > agree with the authors that the security concerns for Diameter NAT Control are > very similar to the security concerns for Diameter QoS, but I think the > additional layer of indirection is not helpful to the reader. (In particular, > the NAT Control Application has no dependencies on the Diameter QoS document. > Therefore it is reasonable to believe that an implementer of Diameter NAT > Control may not be familiar with the Diameter QoS document.) I would recommend > that the authors add additional text explaining why mutual authentication, > server authorization, and message integrity are required (copying a bit of > text from RFC 5866 may be appropriate). Then I would recommend that the > authors cite the Diameter specification (RFC 3588) for a discussion of how > IPsec or TLS can be used to obtain these security properties. (To me, this > seems preferable to sending a reader to RFC 5866 for discussion of required > security properties, which in turn sends the reader to RFC 3588 for an > information on the use of IPsec or TLS to achieve these properties.) > > Finally, the end of the security considerations section claims that > "Authorization between DNCA Agent and > DNCA Manager is beyond the scope of this document". I understand that the > authors do not want to mandate a particular mechanism for making an > authorization decision. That being said, providing some guidance as to how a > DNCA client would determine if a DNCA server were authorized to issue NAT > control commands. I imagine in practice that the way authorization is > accomplished is that the NAT/NAPT device stores a local authorization policy. > (E.g., the device stores a list of server identities that authorized, and then > once the server has been authenticated its identity can be checked against the > list). At the very least having text analogous to first paragraph of RFC 5866 > Section 11 would be helpful (RFC 5866 says the device making the authorization > decision needs to have sufficient information to make this decision and then > provides examples of where this information would come from.) > > - Matt Lepinski > > > ------ End of Forwarded Message From dromasca@avaya.com Wed Mar 9 08:49:55 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8763A6938 for ; Wed, 9 Mar 2011 08:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gzS46PDhQF6 for ; Wed, 9 Mar 2011 08:49:54 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 64D2F3A6930 for ; Wed, 9 Mar 2011 08:49:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFMtcU2HCzI1/2dsb2JhbACYKo47dKR5ApkWgn+CYgSQDA X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="268588635" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Mar 2011 11:51:10 -0500 X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="614017907" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Mar 2011 11:51:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Mar 2011 17:50:58 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECDIR review of draft-ietf-dime-nat-control-07 Thread-Index: AcveXoAI4/NYzV6BSlyRghF9Op12ZQAG6YMw From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: SECDIR review of draft-ietf-dime-nat-control-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:49:55 -0000 =20 -----Original Message----- From: Matt Lepinski [mailto:mlepinsk@bbn.com]=20 Sent: Wednesday, March 09, 2011 3:33 PM To: draft-ietf-dime-nat-control.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org Subject: SECDIR review of draft-ietf-dime-nat-control-07 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a Diameter application whereby a Diameter NAT Control Application (DNCA) server (either a AAA server or a Network Access Server) can control a DNCA client (either a NAT or NAPT device). For example, the DNCA server can determine the number of port bindings available to a given host, cause the allocation of particular NAT bindings, define the external address pool used for by the NAT device, or generate reports used for accounting purposes. The principle security concern is that an unauthorized (or unauthenticated) DNCA server could effect a denial of service of attack on any or all hosts using a NAT/NAPT device in several ways. (E.g., an unauthorized server could exhaust resources in the NAPT device, set maximum bindings to zero for all hosts, provide a set of external addresses that are in use elsewhere in the network, etc.) An additional concern is that an unauthenticated DNCA client could provide incorrect reporting data to the DNCA server to prevent correct accounting within the system. Therefore, the NAT control application requires mutual authentication, authorization of the DNCA server, and integrity protection of the Diameter messages in the DNCA interaction. Additionally, the application may require confidentiality depending on the deployment scenario and, particularly, how authorization is accomplished. The Security Considerations section of the document claims that security considerations are essentially the same as in the Diameter QoS (RFC 5866). I agree with the authors that the security concerns for Diameter NAT Control are very similar to the security concerns for Diameter QoS, but I think the additional layer of indirection is not helpful to the reader. (In particular, the NAT Control Application has no dependencies on the Diameter QoS document. Therefore it is reasonable to believe that an implementer of Diameter NAT Control may not be familiar with the Diameter QoS document.) I would recommend that the authors add additional text explaining why mutual authentication, server authorization, and message integrity are required (copying a bit of text from RFC 5866 may be appropriate). Then I would recommend that the authors cite the Diameter specification (RFC 3588) for a discussion of how IPsec or TLS can be used to obtain these security properties. (To me, this seems preferable to sending a reader to RFC 5866 for discussion of required security properties, which in turn sends the reader to RFC 3588 for an information on the use of IPsec or TLS to achieve these properties.) Finally, the end of the security considerations section claims that "Authorization between DNCA Agent and DNCA Manager is beyond the scope of this document". I understand that the authors do not want to mandate a particular mechanism for making an authorization decision. That being said, providing some guidance as to how a DNCA client would determine if a DNCA server were authorized to issue NAT control commands. I imagine in practice that the way authorization is accomplished is that the NAT/NAPT device stores a local authorization policy. (E.g., the device stores a list of server identities that authorized, and then once the server has been authenticated its identity can be checked against the list). At the very least having text analogous to first paragraph of RFC 5866 Section 11 would be helpful (RFC 5866 says the device making the authorization decision needs to have sufficient information to make this decision and then provides examples of where this information would come from.) - Matt Lepinski From sdecugis@nict.go.jp Thu Mar 10 18:06:29 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AA53A69B6; Thu, 10 Mar 2011 18:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VavfHiwrRfVg; Thu, 10 Mar 2011 18:06:28 -0800 (PST) Received: from sd-22293.dedibox.fr (sd-22293.dedibox.fr [88.191.125.50]) by core3.amsl.com (Postfix) with ESMTP id F41BA3A67FF; Thu, 10 Mar 2011 18:06:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sd-22293.dedibox.fr (Postfix) with ESMTP id 62271940E3; Fri, 11 Mar 2011 03:06:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at sd-22293.dedibox.fr Received: from sd-22293.dedibox.fr ([127.0.0.1]) by localhost (sd-22293.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPLHxYRhdlCE; Fri, 11 Mar 2011 03:06:35 +0100 (CET) Received: from [202.249.37.5] (morbier.koganei.wide.ad.jp [202.249.37.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by sd-22293.dedibox.fr (Postfix) with ESMTPSA id 7551C94018; Fri, 11 Mar 2011 03:06:33 +0100 (CET) Message-ID: <4D7983E1.2050605@nict.go.jp> Date: Fri, 11 Mar 2011 11:07:29 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: iesg-secretary@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" , dime-chairs@tools.ietf.org Subject: [Dime] Request to publish draft-ietf-dime-extended-naptr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:06:29 -0000 Hello, Here is the PROTO write-up for document "Diameter S-NAPTR Usage" http://tools.ietf.org/html/draft-ietf-dime-extended-naptr-06 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I, Sebastien Decugis (sdecugis@nict.go.jp), am the document shepherd, appointed by DiME chairs. I have reviewed the document and I believe it is ready to be forwarded to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has received several in-depth reviews by group members and sufficient discussion inside the DIME working-group. The document should still be reviewed by DNS experts. These reviews can be done during the IETF LC. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I don't have such concern. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I don't have such concerns or issues. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Since the WG consists of a few individuals, it is difficult to answer this question. However, the document was taken as WG item with a strong consensus on its usefulness, and received good contributions afterwards. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No, to the best of my knowledge. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have checked the ID nits and checklist, and confirmed that there is no issue with this document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split. There is a race condition with rfc3588bis draft, which is explicited in Section 10 of this draft (Editor's Note). There is no downward reference. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? I have verified the IANA consideration section. The new entries to existing registries are correctly identified. There is no new registry requested. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF syntax is verified and correct. There is no other formal language in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes an improvement to Diameter dynamic peers discovery mechanism using an extended format for the Straightforward-NAPTR (S-NAPTR) Application Service Tag that allows for discovery of the supported Diameter applications without doing Diameter capability exchange beforehand. Working Group Summary The WG process went smoothly for this document. The document is a result of collaborative WG work. Document Quality There is currently no publicly announced implementations of this mechanism, but there is known on-going implementation effort. S-NAPTR and Diameter are implemented protocols. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From jouni.nospam@gmail.com Mon Mar 14 02:57:35 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6B13A6C58 for ; Mon, 14 Mar 2011 02:57: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mym3RFQZHerA for ; Mon, 14 Mar 2011 02:57:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 71D583A6853 for ; Mon, 14 Mar 2011 02:57:33 -0700 (PDT) Received: by eye13 with SMTP id 13so1869935eye.31 for ; Mon, 14 Mar 2011 02:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=unL4OUJaiygkjedtbKW7dLEykgn7qpJYMHagODnYq7c=; b=YMUFY9ywLGhfb5W0+2qIolyS5JRyTXYQRE8FZNU4p0gdg3DYXbKh02ZbJIKVS+5geJ K08BiosWKUiW8Xkj0QWR7e70f/1DaPhx7HWeY9MgIAVp6nP0q/sqY20VkNJYBk+h/f2K ThWnAu10xai2905vBSRYDs9Onta1IlhNt7/h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=itYwUrI03nW63yavcfKM1L0INSVFLV4pS+8WB6KITfYGx1/kLJczOkfVedErWmltq1 b3qnynvToA1YbDWQshYZmAsf70iC+OsODHvKcRPWLAwM7J0W+NLSg9g4+saKKn788T4b 5AM3Sq32YbnZg82FwHPJW9LKK4FNnxQohUAa8= Received: by 10.213.14.20 with SMTP id e20mr1252516eba.28.1300096736222; Mon, 14 Mar 2011 02:58:56 -0700 (PDT) Received: from pc-a82194.wlan.inet.fi (pc-a82194.wlan.inet.fi [194.111.82.194]) by mx.google.com with ESMTPS id q53sm5769208eeh.10.2011.03.14.02.58.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 02:58:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4D3F8796.1090100@nict.go.jp> Date: Mon, 14 Mar 2011 11:58:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D3F8796.1090100@nict.go.jp> To: dime@ietf.org X-Mailer: Apple Mail (2.1082) Subject: [Dime] RFC3588bis; Result-Codes and AVP flags X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:57:35 -0000 Folks, A couple of things still need to be clarified. I have the forthcoming = -27 on my table, so.. 1) What was the conclusion on this Result-Code mismatch? See mail from = Sebastien that pointed this out: http://www.ietf.org/mail-archive/web/dime/current/msg04616.html Glen also rightfully pointed out that these changes cause changes in = peer behavior. So, a) are people happy with the new categorization = currently in RFC3588bis? Or b) should we go back to existing RFC3588 = categorization regarding Result-Code values?? (note that the numbering = of the values is wrong as there are overlaps with IANA registry but that = is easily fixable) Raise your opinion. If you prefer a) then also state how to handle the = "deprecated" values. 2) Discussion on AVP flags. RFC3588bis-26 Section 4.1 says: The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error.=20 See the discussion around here, which ended without a firm conclusion: http://www.ietf.org/mail-archive/web/dime/current/msg04626.html I would say we stay with the existing text. Any opinions against keeping = the existing text? If yes, propose the new text. - jouni On Jan 26, 2011, at 4:31 AM, Sebastien Decugis wrote: > Hello, >=20 > I just compared the Result-Code values described in rfc3588bis-26 > section 7.1.x with existing IANA registry, and found several > differences, which are currently not reflected in the IANA > Considerations section -- I believe someone is already working on this > section (although I lost track of whom) so I thought I would write = down > the differences I found to help in this work -- I hope this is not > redundant. >=20 > DIAMETER_COMMAND_UNSUPPORTED: > - value 3001 in IANA registry, > - value 5019 in 3588bis. >=20 > DIAMETER_INVALID_HDR_BITS: > - value 3008 in IANA, > - value 5020 in 3588bis > - also, >=20 > DIAMETER_INVALID_AVP_BITS: > - value 3009 in IANA, > - value 5021 in rfc3588bis >=20 > DIAMETER_UNKNOWN_PEER: > - value 3010 in IANA, > - value 5018 in rfc3588bis (conflicts with IANA) >=20 > DIAMETER_INVALID_BIT_IN_HEADER: > - 5013 in IANA, > - 3011 in rfc3588bis > - seems redundant with DIAMETER_INVALID_HDR_BITS. >=20 > DIAMETER_INVALID_MESSAGE_LENGTH: > - value 5015 in IANA, > - value 3012 in rfc3588bis >=20 > DIAMETER_INVALID_AVP_BIT_COMBO: > - value 5016 in IANA > - not defined in rfc3588bis > - is it deprecated? it seems redundant with DIAMETER_INVALID_AVP_BITS > anyway... >=20 > Hope this helps, > Sebastien. >=20 > --=20 > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Internet-Drafts@ietf.org Mon Mar 14 05:45:10 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732E53A6BFC; Mon, 14 Mar 2011 05:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L33FyZ6k-9hc; Mon, 14 Mar 2011 05:45:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21023A6D0F; Mon, 14 Mar 2011 05:45: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.12 Message-ID: <20110314124502.31755.3811.idtracker@localhost> Date: Mon, 14 Mar 2011 05:45:02 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-lr-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 12:45:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Support for Proxy Mobile IPv6 Localized Routing Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-pmip6-lr-03.txt Pages : 13 Date : 2011-03-14 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly by the MAG without involving the LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of localized routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-pmip6-lr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14053200.I-D@ietf.org> --NextPart-- From dlehmann@ulticom.com Tue Mar 15 11:39:07 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822773A6B1C for ; Tue, 15 Mar 2011 11:39: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfXfowtUR73C for ; Tue, 15 Mar 2011 11:39:06 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 9F08D3A6B10 for ; Tue, 15 Mar 2011 11:39:06 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id F76AA37D8DC2DDB2; Tue, 15 Mar 2011 14:40:29 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p2FIeSYE016575; Tue, 15 Mar 2011 14:40:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 14:40:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC3588bis; Result-Codes and AVP flags Thread-Index: AcviLn/wUx5aNdPwRN62aS9IreeCpQA4ocOQ References: <4D3F8796.1090100@nict.go.jp> From: "David Lehmann" To: "jouni korhonen" , Received-SPF: pass Subject: Re: [Dime] RFC3588bis; Result-Codes and AVP flags X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:39:07 -0000 > 2) Discussion on AVP flags. RFC3588bis-26 Section 4.1 says: >=20 > The AVP Flags field informs the receiver how each attribute must > be handled. The 'r' (reserved) bits are unused and SHOULD be set > to 0. Note that subsequent Diameter applications MAY define > additional bits within the AVP Header, and an unrecognized bit > SHOULD be considered an error. >=20 > See the discussion around here, which ended without a firm conclusion: > http://www.ietf.org/mail-archive/web/dime/current/msg04626.html >=20 > I would say we stay with the existing text. Any opinions against keeping the > existing text? If yes, propose the new text. I propose to use the language which is used for the command flags: "The AVP Flags field informs the receiver how each attribute must be handled. The 'r' (reserved) bits are reserved for future use, and MUST be set to zero, and ignored by the receiver." -- David Lehmann Ulticom, Inc. 856-787-2952 From mark@azu.ca Tue Mar 15 11:40:07 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998A03A6B1D for ; Tue, 15 Mar 2011 11:40:07 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc65Iqzwavwa for ; Tue, 15 Mar 2011 11:40:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D8E463A6B1C for ; Tue, 15 Mar 2011 11:40:05 -0700 (PDT) Received: by qwg5 with SMTP id 5so828963qwg.31 for ; Tue, 15 Mar 2011 11:41:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.142 with SMTP id s14mr11794024qce.174.1300214490444; Tue, 15 Mar 2011 11:41:30 -0700 (PDT) Received: by 10.229.214.3 with HTTP; Tue, 15 Mar 2011 11:41:30 -0700 (PDT) In-Reply-To: References: <4D3F8796.1090100@nict.go.jp> Date: Tue, 15 Mar 2011 14:41:30 -0400 Message-ID: From: Mark Jones To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] RFC3588bis; Result-Codes and AVP flags X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:40:07 -0000 On Mon, Mar 14, 2011 at 5:58 AM, jouni korhonen wr= ote: > Folks, > > A couple of things still need to be clarified. I have the forthcoming -27= on my table, so.. > > 1) What was the conclusion on this Result-Code mismatch? See mail from Se= bastien that pointed this out: > http://www.ietf.org/mail-archive/web/dime/current/msg04616.html > > Glen also rightfully pointed out that these changes cause changes in peer= behavior. So, a) are people happy with the new categorization currently in= RFC3588bis? Or b) should we go back to existing RFC3588 categorization reg= arding Result-Code values?? (note that the numbering of the values is wrong= as there are overlaps with IANA registry but that is easily fixable) > > Raise your opinion. If you prefer a) then also state how to handle the "d= eprecated" values. > To remain backwards compatible, an RFC3588bis implementation will need to handle both the RFC3588 values and RFC3588bis values. Doesn't this mean that they can't be simply removed from the RFC or IANA registry but instead must be somehow marked as 'deprecated'? Sounds messy so unless these incorrect categorizations in RFC3588 are causing IOT issues, my vote is (b); leave them be. > > 2) Discussion on AVP flags. RFC3588bis-26 Section 4.1 says: > > =A0 =A0 =A0The AVP Flags field informs the receiver how each attribute mu= st > =A0 =A0 =A0be handled. =A0The 'r' (reserved) bits are unused and SHOULD b= e set > =A0 =A0 =A0to 0. =A0Note that subsequent Diameter applications MAY define > =A0 =A0 =A0additional bits within the AVP Header, and an unrecognized bit > =A0 =A0 =A0SHOULD be considered an error. > > See the discussion around here, which ended without a firm conclusion: > http://www.ietf.org/mail-archive/web/dime/current/msg04626.html > > I would say we stay with the existing text. Any opinions against keeping = the existing text? If yes, propose the new text. > I expressed my opinion on per-app AVP flags on the thread so let's hear some new voices. However, nothing is broken and if there is no consensus for change then I guess it stays as is. I do agree with David Lehman on rewording the text on setting unused bits though. Something like: "The 'r' (reserved) bits are unused and MUST be set to 0 by the sender and ignored by the receiver". Regards Mark > - jouni > > > > On Jan 26, 2011, at 4:31 AM, Sebastien Decugis wrote: > >> Hello, >> >> I just compared the Result-Code values described in rfc3588bis-26 >> section 7.1.x with existing IANA registry, and found several >> differences, which are currently not reflected in the IANA >> Considerations section -- I believe someone is already working on this >> section (although I lost track of whom) so I thought I would write down >> the differences I found to help in this work -- I hope this is not >> redundant. >> >> DIAMETER_COMMAND_UNSUPPORTED: >> - value 3001 in IANA registry, >> - value 5019 in 3588bis. >> >> DIAMETER_INVALID_HDR_BITS: >> - value 3008 in IANA, >> - value 5020 in 3588bis >> - also, >> >> DIAMETER_INVALID_AVP_BITS: >> - value 3009 in IANA, >> - value 5021 in rfc3588bis >> >> DIAMETER_UNKNOWN_PEER: >> - value 3010 in IANA, >> - value 5018 in rfc3588bis (conflicts with IANA) >> >> DIAMETER_INVALID_BIT_IN_HEADER: >> - 5013 in IANA, >> - 3011 in rfc3588bis >> - seems redundant with DIAMETER_INVALID_HDR_BITS. >> >> DIAMETER_INVALID_MESSAGE_LENGTH: >> - value 5015 in IANA, >> - value 3012 in rfc3588bis >> >> DIAMETER_INVALID_AVP_BIT_COMBO: >> - value 5016 in IANA >> - not defined in rfc3588bis >> - is it deprecated? it seems redundant with DIAMETER_INVALID_AVP_BITS >> anyway... >> >> Hope this helps, >> Sebastien. >> >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > From sunseawq@huawei.com Tue Mar 15 19:19:47 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07DE3A6B5B for ; Tue, 15 Mar 2011 19:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ondxZB2FjYzp for ; Tue, 15 Mar 2011 19:19:47 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C1D1D3A6B17 for ; Tue, 15 Mar 2011 19:19:46 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI400GBDP71PI@szxga03-in.huawei.com> for dime@ietf.org; Wed, 16 Mar 2011 10:21:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI400GSUP71I1@szxga03-in.huawei.com> for dime@ietf.org; Wed, 16 Mar 2011 10:21:01 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI40011CP71SI@szxml06-in.huawei.com> for dime@ietf.org; Wed, 16 Mar 2011 10:21:01 +0800 (CST) Date: Wed, 16 Mar 2011 10:21:01 +0800 From: Qin Wu To: dime@ietf.org Message-id: <02b301cbe380$cb55d4b0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_mmq3bZ11QoUuo5iWy6E/1g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] draft-ietf-dime-pmip6-lr open issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:19:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_mmq3bZ11QoUuo5iWy6E/1g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, The open issue discussed in the IETF 79 beijing meeting is described as follows: In some cases (e.g., in figure 2,3,4), the Diameter Server need to return MN's LMA address while in some other case (e.g.,the authorization of the MAG location query in figure 5), the Diameter Server needs not return MN's LMA address. I think it will good to keep AAA procedure in all cases exactly the same and also it does not hurt to return the LMA address in all cases. If the receiver does not need that information, it can just ignore the AVP containing LMA. So we have two proposals: Proposal 1: Does not need to differentiate different success cases, return the same AVP containing LMA address. Propsoal 2: Differentiate different success cases using status code and return the same AVP containing LMA address Any opinions? Regards! -Qin --Boundary_(ID_mmq3bZ11QoUuo5iWy6E/1g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,
The open issue discussed in the IETF 79 beijing meeting is described as follows:
In some cases (e.g., in figure 2,3,4), the Diameter Server need to return MN's LMA address while in some other case
(e.g.,the authorization of the MAG location query in figure 5), the Diameter Server needs not return MN's LMA address.
 
I think it will good to keep AAA procedure in all cases exactly the same and also it does not hurt to return the LMA address in all cases. 
 If the receiver does not need that information, it can just ignore the AVP containing LMA. So we have two proposals:
Proposal 1: Does not need to differentiate different success cases, return the same AVP containing LMA address.
 
Propsoal 2: Differentiate different success cases using status code and return the same AVP containing LMA address
 
Any opinions?
 
Regards!
-Qin
 
--Boundary_(ID_mmq3bZ11QoUuo5iWy6E/1g)-- From sunseawq@huawei.com Tue Mar 15 19:26:27 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477E23A6B98 for ; Tue, 15 Mar 2011 19:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvQAYmzjr+bg for ; Tue, 15 Mar 2011 19:26:24 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 012533A6A7E for ; Tue, 15 Mar 2011 19:26:23 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI400IBEPI199@szxga03-in.huawei.com> for dime@ietf.org; Wed, 16 Mar 2011 10:27:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI400671PI1YX@szxga03-in.huawei.com> for dime@ietf.org; Wed, 16 Mar 2011 10:27:37 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI400E80PI1JW@szxml06-in.huawei.com> for dime@ietf.org; Wed, 16 Mar 2011 10:27:37 +0800 (CST) Date: Wed, 16 Mar 2011 10:27:37 +0800 From: Qin Wu To: dime@ietf.org Message-id: <02b401cbe381$b7827e60$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110314124502.31755.3811.idtracker@localhost> Subject: Re: [Dime] I-D Action:draft-ietf-dime-pmip6-lr-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:26:27 -0000 Hi, Sorry for late updating. The new version of draft-ietf-dime-pmip6-lr-03 is ready at: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-03.txt Taking into account the comments and feedback in the last meeting, the major changes compared to the previous version are: 1.Allow return the LMA address in all cases. 2.Using localized routing for terminology consistency 3.Allow localized routing service authorization before localized routing is initialized. Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Monday, March 14, 2011 8:45 PM Subject: [Dime] I-D Action:draft-ietf-dime-pmip6-lr-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. > > > Title : Diameter Support for Proxy Mobile IPv6 Localized Routing > Author(s) : G. Zorn, et al. > Filename : draft-ietf-dime-pmip6-lr-03.txt > Pages : 13 > Date : 2011-03-14 > > In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the > Mobile Access Gateway (MAG) to which it is attached are typically > tunneled to a Local Mobility Anchor (LMA) for routing. The term > "localized routing" refers to a method by which packets are routed > directly by the MAG without involving the LMA. In order to establish > a localized routing session between two Mobile Access Gateways in a > Proxy Mobile IPv6 domain, two tasks must be accomplished: > > 1. The usage of localized routing must be authorized for both MAGs > > and > > 2. The address of the MAG to which the Correspondent Node (CN) is > > attached must be ascertained > > This document specifies how to accomplish these tasks using the > Diameter protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From jouni.nospam@gmail.com Wed Mar 16 14:25:39 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B64A3A6A51 for ; Wed, 16 Mar 2011 14:25:39 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6RBH6832aer for ; Wed, 16 Mar 2011 14:25:38 -0700 (PDT) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by core3.amsl.com (Postfix) with ESMTP id F0CD03A6A3D for ; Wed, 16 Mar 2011 14:25:37 -0700 (PDT) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id 9AB681A9088 for ; Wed, 16 Mar 2011 23:27:03 +0200 (EET) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A07B1698593; Wed, 16 Mar 2011 23:27:03 +0200 Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id 8CD761A9088 for ; Wed, 16 Mar 2011 23:27:03 +0200 (EET) Received: from a88-112-206-148.elisa-laajakaista.fi (a88-112-206-148.elisa-laajakaista.fi [88.112.206.148]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 85BEA2166D5 for ; Wed, 16 Mar 2011 23:27:02 +0200 (EET) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Mar 2011 23:27:01 +0200 Message-Id: <07C9A5C4-8D7D-4456-882F-16F85AA838B3@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Subject: [Dime] Draft agenda posted X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 21:25:39 -0000 Folks, Draft agenda for the Friday Dime WG meeting has been posted. See http://www.ietf.org/proceedings/80/agenda/dime.txt - Jouni From avi@bridgewatersystems.com Thu Mar 17 14:34:02 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B45B3A6A4A for ; Thu, 17 Mar 2011 14:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhBfYunupods for ; Thu, 17 Mar 2011 14:34:01 -0700 (PDT) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id 361663A693B for ; Thu, 17 Mar 2011 14:34:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-5.tower-200.messagelabs.com!1300397727!92656684!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 12501 invoked from network); 17 Mar 2011 21:35:28 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-5.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 17 Mar 2011 21:35:28 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Thu, 17 Mar 2011 17:35:26 -0400 From: Avi Lior To: "dime@ietf.org" , jouni korhonen Date: Thu, 17 Mar 2011 17:35:25 -0400 Thread-Topic: [Dime] Diameter Group: Type? Thread-Index: Acvk6zq1Q3uz+VojT9O5fzRFlusDlA== Message-ID: In-Reply-To: <4D50A3C3.50809@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mark Jones , Erez Nassimi Subject: Re: [Dime] Diameter Group: Type? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 21:34:02 -0000 Hi All, Just summarizing and reasserting my objection. There are two issues here: A) Should we have a bit definition for a grouped AVP. B) Can bits be defined by Applications etc; and WRT to (A). And putting aside (B). I haven't heard any compelling reason to add the G-bit. As stated by more then one person: You either support the AVP based on its command code or not - whether its a grouped AVP or not only becomes when you have to dive in to it - and you would only do that for an AVP that you support. And you would know the type of the AVP (whether it is an int or a group etc) if you support the AVP. As to B) I agree with Glen. As per the specification an Application can define its own AVP flag. Thus if an application writer can design a new Application and add a G-Bit if they want. What we cant do is add the G-bit as a general mechanism that can be applied to all application (like the M-bit) and this is because (as mentioned on this thread) the specification was not written properly and we cant deal with such modification and not break things. See "the senders shall set to zero(clear) and receivers shall ignore" discussion. We can't fix that in BIS since it will break existing applications. We could say that new applications shall include the above statement. We can also RECOMMEND that new application don't define their own AVP bits (if we want). This may create a bit of a war as those entities that have done so come out of the wood work. Do we know anyone that has done that? Here is some text: It is recommended that new Applications not define their own AVP flags bits. New Applications shall treat any reserved AVP flag bits as follows: The sender of the AVP shall clear (set to zero) all reserved AVP flag bits and receivers shall ignore all reserved AVP flag bits. =20 Is there anything to fix in BIS. Yes. We need to state somewhere that if an existing application changes the meaning/semantics of their AVP Flags then a new Application ID must be assigned to that application. This could be added to the section describing when to get a new Application ID. In V2 we can support properly the notion of applications defining their own Flag bits (yuck) or not (my vote) -- Avi Lior --Bridgewater Systems > From jouni.nospam@gmail.com Tue Mar 22 09:26:00 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D7428C0D6 for ; Tue, 22 Mar 2011 09:26:00 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfZC0jorKabA for ; Tue, 22 Mar 2011 09:26:00 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id DED0828C0CF for ; Tue, 22 Mar 2011 09:25:59 -0700 (PDT) Received: by wwk4 with SMTP id 4so4917487wwk.1 for ; Tue, 22 Mar 2011 09:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=Tyol66U3H4v4ypCCTjhzc3Jv7SW+CRla1CbXyfhoczA=; b=Rqw90NAOLeEBn4F4uJXbX4HIurjuzPPtL4sDuAz0qr4kGXHDOKvq2MGZ9lfC9my7nS BBr0uPJYdIuOHv1DtaneoKbRpovNfCpAzT5vOrfoGKr9/ESY80wlUvcsrSxdxRidnTT2 MEH7bx/TynWTT/iSKziRUQ/wyMQfDX3bbkCdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=cAOEOnP/TJJVZJP0LsTnuF5Ih2rIkINVg7Jm/g/uLTcBhzp4BQxyY6TbHthOTgrTkj VT8WqxqSzpGT2w0WN86YU6kZhmPqC4YVwu/iMl4onnCuicJ3xtT/CAWx/i01hch4RgAU E1g3Hy2FYG0o82bPc+Zjk00/R3S0t4+VYREuU= Received: by 10.227.195.129 with SMTP id ec1mr5501440wbb.180.1300811252477; Tue, 22 Mar 2011 09:27:32 -0700 (PDT) Received: from a83-245-210-31.elisa-laajakaista.fi (a83-245-210-31.elisa-laajakaista.fi [83.245.210.31]) by mx.google.com with ESMTPS id g7sm3347243wby.31.2011.03.22.09.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2011 09:27:31 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Mar 2011 18:27:27 +0200 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Dime] Note takers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 16:26:01 -0000 Folks,=20 Dime meeting is approaching... if someone feels an urge to ease the = starting of the WG meeting, please volunteer as a notetaker.=20 - Jouni & Lionel From jouni.nospam@gmail.com Sat Mar 26 09:34:41 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F75D3A6939 for ; Sat, 26 Mar 2011 09:34:41 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwbOPZNFDOaO for ; Sat, 26 Mar 2011 09:34:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 78F463A68FC for ; Sat, 26 Mar 2011 09:34:40 -0700 (PDT) Received: by fxm15 with SMTP id 15so1965851fxm.31 for ; Sat, 26 Mar 2011 09:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=xU4f/EIHYdECvzrwfL37RHLQuxql72xFa9ndhqc033k=; b=WQxgHoFTkfUzoBxNH7o+kKKRzYRjJLrl8JGkutubYfX1s31Aw3lfj4ssbg6BhbSGPa fI78DbyljLCRF/D0ttToVcu7vDXzosBAA9CeqpWfDtRkYcjVjsVjJIrkTjqy6exLSaXP dAguhWefP6grBlEKIOGMOrQOGZb8r4wJPOEdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=lAOrxEkBhFxlaDd0xFdt1vOri0zJPcEVVAaHls8Tex34w7UxwrtsAQANu6+jiAWtTv YWfPKdGUojkhyqH8XlPGOwM6vrTdY5Z73keihRv3LfypQJzvKbF7gL46mkCTaRqQ/WT+ YHIzw+nKKh9t/j7tanh2Ac9mb4VmlxHGEh5so= Received: by 10.223.73.133 with SMTP id q5mr24871faj.127.1301157277777; Sat, 26 Mar 2011 09:34:37 -0700 (PDT) Received: from ?IPv6:2001:df8::80:223:12ff:fe57:6994? ([62.237.209.18]) by mx.google.com with ESMTPS id f15sm833858fax.10.2011.03.26.09.34.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 09:34:36 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Mar 2011 18:34:33 +0200 Message-Id: <0BFBC18E-CF49-4C35-A4E7-06253D263394@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Dime] Presentation slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 16:34:41 -0000 Hi, Those who have a presentation slot, please send the slides to chairs by = Wednesday noon. - Jouni & LIonel= From lionel.morand@orange-ftgroup.com Wed Mar 30 09:59:06 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6BBA3A6B89; Wed, 30 Mar 2011 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.645 X-Spam-Level: X-Spam-Status: No, score=-101.645 tagged_above=-999 required=5 tests=[AWL=0.603, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrvYqG1pSqS6; Wed, 30 Mar 2011 09:59:05 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 4E6ED3A6A4D; Wed, 30 Mar 2011 09:59:04 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DB3D26C8003; Wed, 30 Mar 2011 19:01:15 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id C418F6C0001; Wed, 30 Mar 2011 19:01:15 +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, 30 Mar 2011 19:00:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEEFC.0066CB3E" Date: Wed, 30 Mar 2011 18:58:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for the Diameter IKEv2 PSK - draft-ietf-dime-ikev2-psk-diameter-04.txt Thread-Index: Acvu+8GeAYqHmTgbQX6N69bLTQpxnA== From: To: X-OriginalArrivalTime: 30 Mar 2011 17:00:41.0973 (UTC) FILETIME=[009E3A50:01CBEEFC] Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: [Dime] Publication request for the Diameter IKEv2 PSK - draft-ietf-dime-ikev2-psk-diameter-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:59:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEEFC.0066CB3E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Secretary, =20 This is a request for publication of draft-ietf-dime-ikev2-psk-diameter-04.txt as a standards track RFC. Please find below the document shepherd proto write-up. =20 Best Regards. =20 Lionel =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= PROTO WRITEUP for draft-ietf-dime-ikev2-psk-diameter-04.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 =20 http://www.ietf.org/id/draft-ietf-dime-ikev2-psk-diameter-04.txt =20 =20 =20 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 =20 -- Lionel Morand (lionel.morand@orange-ftgroup.com) is the Document Shepherd, Dime co-chair. He has done a review on the document and believes it is ready to be forwarded to IESG for publication. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 =20 -- The document has had an extensive review by the DIME WG and the lastest version is the result of the consensus reached within the WG.=20 =20 The shepherd has reviewed the document himself and has no issue with it. Nor the shepherd has issues with the reviews done by others. =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 =20 -- No. =20 =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 =20 -- No. =20 =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 =20 -- There is Dime WG consensus behind the document. =20 =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 =20 -- No. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 =20 -- The shepherd has checked the document with the idnits tool. There is only one issue: the reference to the IKEv2 protocol needs to be updated (from RFC 4306 to RFC 5996). The document does not need MIB doctor review. The document does not contain any media and URI types. =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 =20 -- References are split accordingly. There is a normative reference to a draft (draft-ietf-dime-local-keytran)=20 but a request for publication has been already sent for this draft. There are no other references to documents with unclear status or=20 are in progress. =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 =20 -- This document defines a new Diameter application and 3 new AVP codes.=20 IANA is requested to allocate values for the application id and the AVP codes. IANA is also requested to assign a new value for the Key-Type AVP from the=20 registry defined by the draft draft-ietf-dime-local-keytran-08. This registry=20 will have to be created first. =20 No new registry is defined.. =20 =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 =20 -- Yes. Note that the ABNF used in this document follows the modified ABNF syntax defined in RFC3588. =20 =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 =20 Technical Summary=20 =20 -- =20 This document therefore extends the functionality offered by the Diameter Mobile IPv6 application [RFC 5778] with pre-shared key based authentication offered by IKEv2 when no EAP is used. =20 =20 =20 Working Group Summary=20 =20 --- The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. =20 Document Quality=20 =20 --- The document is complete, straightforward, simple and well-written. =20 =20 =20 ------_=_NextPart_001_01CBEEFC.0066CB3E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear = Secretary,

 

This is a request for = publication of draft-ietf-dime-ikev2-psk-diameter-04.txt as a standards track RFC.

Please find below the = document shepherd proto write-up.

 

Best = Regards.

 

Lionel

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 PROTO WRITEUP for = draft-ietf-dime-ikev2-psk-diameter-04.txt

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

http://www.ietf.org/id/draft-ietf-dime-ikev2-psk-diameter-04.txt

 

 

  (1.a) Who is the Document = Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the =

        document and, in particular, does he or she believe this =

        version is ready for forwarding to the IESG for publication? =

 

         --

         Lionel Morand (lionel.morand@orange-ftg= roup.com)

         is the Document Shepherd, Dime co-chair. He has done a = review

         on the document and believes it is ready to be forwarded = to

         IESG for publication.

 

  (1.b) Has the document = had adequate review both from key WG members

        and from key non-WG members? Does the Document Shepherd have =

        any concerns about the depth or breadth of the reviews that =

        have been performed? 

 

         --

         The document has had an extensive review by the DIME WG = and

         the lastest version is the result of the consensus = reached

         within the WG.

          =           

         The shepherd has reviewed the document himself and has = no

         issue with it. Nor the shepherd has issues with the = reviews

         done by others.

 

  (1.c) Does the Document = Shepherd have concerns that the document

        needs more review from a particular or broader perspective, =

        e.g., security, operational complexity, someone familiar with =

        AAA, internationalization or XML?

 

         --

         No.

 

 

  (1.d) Does the Document = Shepherd have any specific concerns or

        issues with this document that the Responsible Area = Director

        and/or the IESG should be aware of? For example, perhaps he =

        or she is uncomfortable with certain parts of the document, or =

        has concerns whether there really is a need for it. In any =

        event, if the WG has discussed those issues and has indicated =

        that it still wishes to advance the document, detail those =

        concerns here. Has an IPR disclosure related to this document =

        been filed? If so, please include a = reference to the

        disclosure and summarize the WG discussion and conclusion on =

        this issue.

 

         --

         No.

 

 

  (1.e) How solid is the WG = consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with =

        others being silent, or does the WG as a whole understand and =

        agree with it?  

 

         --

         There is Dime WG consensus behind the document.

 

 

  (1.f) Has anyone = threatened an appeal or otherwise indicated extreme

        discontent? If so, please summarise the areas of conflict in =

        separate email messages to the Responsible Area Director. (It =

        should be in a separate email because this questionnaire is =

        entered into the ID Tracker.)

 

         --

         No.

 

  (1.g) Has the Document = Shepherd personally verified that the

        document satisfies all ID nits? (See the Internet-Drafts Checklist =

        and http://tools.ietf.org/tools/= idnits/). Boilerplate checks are

        not enough; this check needs to be thorough. Has the document =

        met all formal review criteria it needs to, such as the MIB =

        Doctor, media type and URI type reviews?

 

         --

         The shepherd has checked the = document with the idnits tool.

         There is only one issue: the reference to the IKEv2 protocol needs = to

         be updated (from RFC 4306 to RFC 5996).

        The document does not need MIB doctor review.

         The document does not contain any media and URI = types.

 

  (1.h) Has the document = split its references into normative and

        informative? Are there normative references to documents that =

        are not ready for advancement or are otherwise in an unclear =

        state? If such normative references exist, what is the =

        strategy for their completion? Are there normative references =

        that are downward references, as described in [RFC3967]? If =

        so, list these downward references to support the Area =

        Director in the Last Call procedure for them [RFC3967]. =

 

         --

         References are split accordingly.

         There is a normative reference to a draft = (draft-ietf-dime-local-keytran)

         but a request for publication has been already sent for this = draft.

         There are no other references to documents with unclear status or =

         are in progress.

 

  (1.i) Has the Document = Shepherd verified that the document IANA

        consideration section exists and is consistent with the body =

        of the document? If the document specifies protocol =

        extensions, are reservations requested in appropriate IANA =

        registries? Are the IANA registries clearly identified? If =

        the document creates a new registry, does it define the =

        proposed initial contents of the registry and an allocation =

        procedure for future registrations? Does it suggest a =

        reasonable name for the new registry? See [RFC5226]. If the =

        document describes an Expert Review process has Shepherd =

        conferred with the Responsible Area Director so that the IESG =

        can appoint the needed Expert during the IESG Evaluation? =

 

         --

         This document defines a new Diameter application and 3 new AVP codes. =

         IANA is requested to allocate values for the application id and the AVP = codes.

        IANA is also requested to assign a new value for the Key-Type AVP from the =

        registry defined by the draft draft-ietf-dime-local-keytran-08. This registry =

        will have to be created first.

 

        No new registry is defined..

 

 

  (1.j) Has the Document = Shepherd verified that sections of the

        document that are written in a formal language, such as XML =

        code, BNF rules, MIB definitions, etc., validate correctly in =

        an automated checker?

 

         --

         Yes. Note that the ABNF used in this document follows = the

         modified ABNF syntax defined in RFC3588.

        

        

  (1.k) The IESG approval = announcement includes a Document

        Announcement Write-Up. Please provide such a Document =

        Announcement Write-Up? Recent examples can = be found in the

        "Action" announcements for approved documents. The approval =

        announcement contains the following sections:

 

     = Technical Summary

 

         --

 

  =
;    This document therefore =
extends
  =
;    the functionality offered by the Diameter Mobile =
IPv6 application [RFC =
5778] with =
pre-shared key based
  =
    authentication offered by IKEv2 when no EAP is =
used.
 

        

        

     Working = Group Summary

 

         ---

         The document was discussed for more than one year in the WG and =

         the document captures the results of the collaborative WG = work.

 

     = Document Quality

 

         ---

         The document is complete, straightforward, simple and well-written.        =

        

 

------_=_NextPart_001_01CBEEFC.0066CB3E-- From tom111.taylor@bell.net Wed Mar 30 10:56:27 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713CD3A6BB0 for ; Wed, 30 Mar 2011 10:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdiTmLCZrBdU for ; Wed, 30 Mar 2011 10:56:26 -0700 (PDT) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by core3.amsl.com (Postfix) with ESMTP id A9D4D3A6BAF for ; Wed, 30 Mar 2011 10:56:26 -0700 (PDT) Received: from BLU0-SMTP8 ([65.55.116.73]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 10:58:05 -0700 X-Originating-IP: [130.129.19.162] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [130.129.19.162] ([130.129.19.162]) by BLU0-SMTP8.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 10:58:04 -0700 Date: Wed, 30 Mar 2011 19:58:03 +0200 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: jouni korhonen References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2011 17:58:04.0818 (UTC) FILETIME=[04B6AF20:01CBEF04] Cc: dime@ietf.org Subject: Re: [Dime] Note takers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 17:56:27 -0000 Unless I'm surprised by another ad hoc meeting, I can volunteer. On 22/03/2011 5:27 PM, jouni korhonen wrote: > Folks, > > Dime meeting is approaching... if someone feels an urge to ease the starting of the WG meeting, please volunteer as a notetaker. > > - Jouni& Lionel > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From lionel.morand@orange-ftgroup.com Wed Mar 30 16:38:38 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B51128C0F5; Wed, 30 Mar 2011 16:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnqxMrmHYF1n; Wed, 30 Mar 2011 16:38:36 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 72C963A6A7B; Wed, 30 Mar 2011 16:38:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3BD228B8007; Thu, 31 Mar 2011 01:40:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2CCEF8B8001; Thu, 31 Mar 2011 01:40:45 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 01:40:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEF33.D08041D3" Date: Thu, 31 Mar 2011 01:40:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for Diameter Attribute-Value Pairs for Cryptographic Key Transport Thread-Index: Acvu5mQcGepS5GeSQMKNoT9Ozwe2Zg== From: To: X-OriginalArrivalTime: 30 Mar 2011 23:40:13.0052 (UTC) FILETIME=[D07E9BC0:01CBEF33] Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: [Dime] Publication request for Diameter Attribute-Value Pairs for Cryptographic Key Transport X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:38:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEF33.D08041D3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Secretary, =20 This is a request for publication of draft-ietf-dime-local-keytran-08 as a standards track RFC. Please find below the document shepherd proto write-up. =20 Best Regards. =20 Lionel =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PROTO WRITEUP for draft-ietf-dime-local-keytran-08.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 http://www.ietf.org/id/draft-ietf-dime-local-keytran-08.txt =20 =20 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 =20 -- Lionel Morand (lionel.morand@orange-ftgroup.com) is the Document Shepherd, Dime co-chair. He has done a review on the document and believes it is ready to be forwarded to IESG for publication. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 =20 -- The document has had an extensive review by the DIME WG and the lastest version is the result of the consensus reached after discussion.=20 =20 The shepherd has reviewed the document himself and has no issue with it. Nor the shepherd has issues with the reviews done by others. =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 =20 -- No. =20 =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 =20 -- No. =20 =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 =20 -- There is Dime WG consensus behind the document. =20 =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 =20 -- No. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 =20 -- The shepherd has checked the document with the idnits tool and found no issues. The document does not need MIB doctor review. The document does not contain any media and URI types. =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 =20 -- References are split accordingly. There is a normative reference=20 to a draft (draft-ietf-dime-rfc3588bis) but this draft should be published soon. There are no other references to documents with unclear status or are in progress. =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 =20 -- This document defines 6 new Diameter AVP codes and requests IANA for code value assignment in an existing registry. =20 This document defines also a new IANA registry for values assigned=20 to one of the newly defined AVP (Key-Type AVP). Allocation of new=20 values is decided after expert review and the sheperd discussed this point with Dan Romascanu, AD of the OPS AREA. =20 =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 =20 -- Yes. Note that the ABNF used in this document follows the modified ABNF syntax defined in RFC3588. =20 =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 =20 Technical Summary=20 =20 -- =20 This document specifies a set of AVPs allowing the transport of multiple cryptographic keys in a single Diameter message. Such=20 capability is required by several AAA applications. =20 =20 Working Group Summary=20 =20 --- The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. =20 Document Quality=20 =20 --- The document is complete, straightforward, simple and well-written. =20 =20 ------_=_NextPart_001_01CBEF33.D08041D3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear = Secretary,

 

This is a request for = publication of draft-ietf-dime-local-keytran-08 as a standards track = RFC.

Please find below the = document shepherd proto write-up.

 

Best = Regards.

 

Lionel

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 PROTO WRITEUP for = draft-ietf-dime-local-keytran-08.txt

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

http= ://www.ietf.org/id/draft-ietf-dime-local-keytran-08.txt

 

 

  (1.a) Who is the Document = Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the =

        document and, in particular, does he or she believe this =

        version is ready for forwarding to the IESG for publication? =

 

         --

         Lionel Morand (lionel.morand@orange-ftg= roup.com)

         is the Document Shepherd, Dime co-chair. He has done a = review

         on the document and believes it is ready to be forwarded = to

         IESG for publication.

 

  (1.b) Has the document = had adequate review both from key WG members

        and from key non-WG members? Does the Document Shepherd have =

        any concerns about the depth or breadth of the reviews that =

        have been performed? 

 

         --

         The document has had an extensive review by the DIME WG = and

         the lastest version is the result of the consensus = reached

         after discussion.

          =           

         The shepherd has reviewed the document himself and has = no

         issue with it. Nor the shepherd has issues with the = reviews

         done by others.

 

  (1.c) Does the Document = Shepherd have concerns that the document

        needs more review from a particular or broader perspective, =

        e.g., security, operational complexity, someone familiar with =

        AAA, internationalization or XML?

 

         --

         No.

 

 

  (1.d) Does the Document = Shepherd have any specific concerns or

        issues with this document that the Responsible Area = Director

        and/or the IESG should be aware of? For example, perhaps he =

        or she is uncomfortable with certain parts of the document, or =

        has concerns whether there really is a need for it. In any =

        event, if the WG has discussed those issues and has indicated =

        that it still wishes to advance the document, detail those =

        concerns here. Has an IPR disclosure related to this document =

        been filed? If so, please include a = reference to the

        disclosure and summarize the WG discussion and conclusion on =

        this issue.

 

         --

         No.

 

 

  (1.e) How solid is the WG = consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with =

        others being silent, or does the WG as a whole understand and =

        agree with it?  

 

         --

         There is Dime WG consensus behind the document.

 

 

  (1.f) Has anyone = threatened an appeal or otherwise indicated extreme

        discontent? If so, please summarise the areas of conflict in =

        separate email messages to the Responsible Area Director. (It =

        should be in a separate email because this questionnaire is =

        entered into the ID Tracker.)

 

         --

         No.

 

  (1.g) Has the Document = Shepherd personally verified that the

        document satisfies all ID nits? (See the Internet-Drafts Checklist =

        and http://tools.ietf.org/tools/= idnits/). Boilerplate checks are

        not enough; this check needs to be thorough. Has the document =

        met all formal review criteria it needs to, such as the MIB =

        Doctor, media type and URI type reviews?

 

         --

         The shepherd has checked the = document with the idnits tool and

         found no issues. The document does not need MIB doctor = review.

         The document does not contain any media and URI = types.

 

  (1.h) Has the document = split its references into normative and

        informative? Are there normative references to documents that =

        are not ready for advancement or are otherwise in an unclear =

        state? If such normative references exist, what is the =

        strategy for their completion? Are there normative references =

        that are downward references, as described in [RFC3967]? If =

        so, list these downward references to support the Area =

        Director in the Last Call procedure for them [RFC3967]. =

 

         --

         References are split accordingly. There is a normative reference =

         to a draft (draft-ietf-dime-rfc3588bis) but this draft should = be

         published soon. There are no other references to documents with =

         unclear status or are in progress.

 

  (1.i) Has the Document = Shepherd verified that the document IANA

        consideration section exists and is consistent with the body =

        of the document? If the document specifies protocol =

        extensions, are reservations requested in appropriate IANA =

        registries? Are the IANA registries clearly identified? If =

        the document creates a new registry, does it define the =

        proposed initial contents of the registry and an allocation =

        procedure for future registrations? Does it suggest a =

        reasonable name for the new registry? See [RFC5226]. If the =

        document describes an Expert Review process has Shepherd =

        conferred with the Responsible Area Director so that the IESG =

        can appoint the needed Expert during the IESG Evaluation? =

 

         --

         This document defines 6 new Diameter AVP codes and requests IANA = for

         code value assignment in an existing registry.

 

         This document defines also a new IANA registry for values assigned =

         to one of the newly defined AVP (Key-Type AVP). Allocation of new =

         values is decided after expert review and the sheperd discussed = this

         point with Dan Romascanu, AD of the OPS AREA.

 

 

  (1.j) Has the Document = Shepherd verified that sections of the

        document that are written in a formal language, such as XML =

        code, BNF rules, MIB definitions, etc., validate correctly in =

        an automated checker?

 

         --

         Yes. Note that the ABNF used in this document follows = the

         modified ABNF syntax defined in RFC3588.

        

        

  (1.k) The IESG approval = announcement includes a Document

        Announcement Write-Up. Please provide such a Document =

        Announcement Write-Up? Recent examples can = be found in the

        "Action" announcements for approved documents. The approval =

        announcement contains the following sections:

 

     = Technical Summary

 

         --

 

         This document specifies a set of AVPs allowing the transport of =

         multiple cryptographic keys in a single Diameter message. Such =

         capability is required by several AAA = applications.

        

        

     Working = Group Summary

 

         ---

         The document was discussed for more than one year in the WG and =

         the document captures the results of the collaborative WG = work.

 

     = Document Quality

 

         ---

         The document is complete, straightforward, simple and well-written.        =

        

------_=_NextPart_001_01CBEF33.D08041D3-- From lionel.morand@orange-ftgroup.com Wed Mar 30 17:12:28 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E4728C1C5; Wed, 30 Mar 2011 17:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGZ5OZpwZMuu; Wed, 30 Mar 2011 17:12:26 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 9DE3628C1B7; Wed, 30 Mar 2011 17:12:25 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 862BA858003; Thu, 31 Mar 2011 02:20:04 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 78C13778002; Thu, 31 Mar 2011 02:20:04 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 02:14:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEF38.89ACF7D8" Date: Thu, 31 Mar 2011 02:14:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for Diameter Priority Attribute Value Pairs - draft-ietf-dime-priority-avps-03.txt Thread-Index: Acvu5mQcGepS5GeSQMKNoT9Ozwe2ZgATeB9g From: To: X-OriginalArrivalTime: 31 Mar 2011 00:14:01.0558 (UTC) FILETIME=[89940F60:01CBEF38] Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: [Dime] Publication request for Diameter Priority Attribute Value Pairs - draft-ietf-dime-priority-avps-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 00:12:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEF38.89ACF7D8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Secretary, =20 This is a request for publication of draft-ietf-dime-priority-avps-03.txt as a standards track RFC. Please find below the document shepherd proto write-up. =20 Best Regards. =20 Lionel =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PROTO WRITEUP for draft-ietf-dime-priority-avps-03.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 =20 http://www.ietf.org/id/draft-ietf-dime-priority-avps-03.txt =20 =20 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 =20 -- Lionel Morand (lionel.morand@orange-ftgroup.com) is the Document Shepherd, Dime co-chair. He has done a review on the document and believes it is ready to be forwarded to IESG for publication. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 =20 -- The document has had an extensive review by the DIME WG. This=20 document has been also reviewed and discussed by people from 3GPP. The lastest version is the result of the consensus reached after discussion.=20 =20 The shepherd has reviewed the document himself and has no issue with it. Nor the shepherd has issues with the reviews done by others. =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 =20 -- No. =20 =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 =20 -- No. =20 =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 =20 -- There is Dime WG consensus behind the document. =20 =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 =20 -- No. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 =20 -- The shepherd has checked the document with the idnits tool and found no critical issues. However several lines exceed the maximum length of 72 characters. =20 The document does not need MIB doctor review. The document does not contain any media and URI types. =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 =20 -- References are split accordingly. There is a normative reference=20 to a draft (draft-ietf-tsvwg-emergency-rsvp-14) but this draft is already=20 in the RFC ed queue. There are no other references to documents with=20 unclear status or are in progress. =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 =20 -- This document defines 10 new Diameter AVP codes and requests IANA for code value assignment in an existing registry. =20 This document defines several new Diameter AVPs.=20 IANA is requested to allocate values for the AVP codes. No new registry is defined.. =20 =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 =20 -- Yes. Note that the ABNF used in this document follows the modified ABNF syntax defined in RFC3588. =20 =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 =20 Technical Summary=20 =20 -- =20 This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. =20 =20 Working Group Summary=20 =20 --- The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. =20 Document Quality=20 =20 --- The document is complete, straightforward, simple and well-written. =20 =20 ------_=_NextPart_001_01CBEF38.89ACF7D8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear = Secretary,

 

This is a request for = publication of draft-ietf-dime-priority-avps-03.txt

as a standards track = RFC.

Please find below the = document shepherd proto write-up.

 

Best = Regards.

 

Lionel

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 PROTO WRITEUP for = draft-ietf-dime-priority-avps-03.txt

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

http= ://www.ietf.org/id/draft-ietf-dime-priority-avps-03.txt

 

 

  (1.a) Who is the Document = Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the =

        document and, in particular, does he or she believe this =

        version is ready for forwarding to the IESG for publication? =

 

         --

         Lionel Morand (lionel.morand@orange-ftg= roup.com)

         is the Document Shepherd, Dime co-chair. He has done a = review

         on the document and believes it is ready to be forwarded = to

         IESG for publication.

 

  (1.b) Has the document = had adequate review both from key WG members

        and from key non-WG members? Does the Document Shepherd have =

        any concerns about the depth or breadth of the reviews that =

        have been performed? 

 

         --

         The document has had an extensive review by the DIME WG. This

         document has been also reviewed and discussed by people from = 3GPP.

        The lastest version is the result of the consensus = reached

         after discussion. =

          =           

         The shepherd has reviewed the document himself and has = no

         issue with it. Nor the shepherd has issues with the = reviews

         done by others.

 

  (1.c) Does the Document = Shepherd have concerns that the document

        needs more review from a particular or broader perspective, =

        e.g., security, operational complexity, someone familiar with =

        AAA, internationalization or XML?

 

         --

         No.

 

 

  (1.d) Does the Document = Shepherd have any specific concerns or

        issues with this document that the Responsible Area = Director

        and/or the IESG should be aware of? For example, perhaps he =

        or she is uncomfortable with certain parts of the document, or =

        has concerns whether there really is a need for it. In any =

        event, if the WG has discussed those issues and has indicated =

        that it still wishes to advance the document, detail those =

        concerns here. Has an IPR disclosure related to this document =

        been filed? If so, please include a = reference to the

        disclosure and summarize the WG discussion and conclusion on =

        this issue.

 

         --

         No.

 

 

  (1.e) How solid is the WG = consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with =

        others being silent, or does the WG as a whole understand and =

        agree with it?  

 

         --

         There is Dime WG consensus behind the document.

 

 

  (1.f) Has anyone = threatened an appeal or otherwise indicated extreme

        discontent? If so, please summarise the areas of conflict in =

        separate email messages to the Responsible Area Director. (It =

        should be in a separate email because this questionnaire is =

        entered into the ID Tracker.)

 

         --

         No.

 

  (1.g) Has the Document = Shepherd personally verified that the

        document satisfies all ID nits? (See the Internet-Drafts Checklist =

        and http://tools.ietf.org/tools/= idnits/). Boilerplate checks are

        not enough; this check needs to be thorough. Has the document =

        met all formal review criteria it needs to, such as the MIB =

        Doctor, media type and URI type reviews?

 

         --

         The shepherd has checked the = document with the idnits tool and

         found no critical issues. However several lines exceed the = maximum

         length of 72 characters.

 

        =  The document does not need MIB doctor review.

         The document does not contain any media and URI = types.

 

  (1.h) Has the document = split its references into normative and

        informative? Are there normative references to documents that =

        are not ready for advancement or are otherwise in an unclear =

        state? If such normative references exist, what is the =

        strategy for their completion? Are there normative references =

        that are downward references, as described in [RFC3967]? If =

        so, list these downward references to support the Area =

        Director in the Last Call procedure for them [RFC3967]. =

 

         --

         References are split accordingly. There is a normative reference =

         to a draft (draft-ietf-tsvwg-emergency-rsvp-14) but this draft is = already

         in the RFC ed queue. There are no other references to documents with =

         unclear status or are in progress.

 

  (1.i) Has the Document = Shepherd verified that the document IANA

        consideration section exists and is consistent with the body =

        of the document? If the document specifies protocol =

        extensions, are reservations requested in appropriate IANA =

        registries? Are the IANA registries clearly identified? If =

        the document creates a new registry, does it define the =

        proposed initial contents of the registry and an allocation =

        procedure for future registrations? Does it suggest a =

        reasonable name for the new registry? See [RFC5226]. If the =

        document describes an Expert Review process has Shepherd =

        conferred with the Responsible Area Director so that the IESG =

        can appoint the needed Expert during the IESG Evaluation? =

 

         --

         This document defines 10 new Diameter AVP codes and requests IANA = for

         code value assignment in an existing registry.

 

         This document defines several new Diameter AVPs.

         IANA is requested to allocate values for the AVP = codes.

         No new registry is defined..

 

 

  (1.j) Has the Document = Shepherd verified that sections of the

        document that are written in a formal language, such as XML =

        code, BNF rules, MIB definitions, etc., validate correctly in =

        an automated checker?

 

         --

         Yes. Note that the ABNF used in this document follows = the

         modified ABNF syntax defined in RFC3588.

        

        

  (1.k) The IESG approval = announcement includes a Document

        Announcement Write-Up. Please provide such a Document =

        Announcement Write-Up? Recent examples can = be found in the

        "Action" announcements for approved documents. The approval =

        announcement contains the following sections:

 

     = Technical Summary

 

         --

       

        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.

        

        

     Working = Group Summary

 

         ---

         The document was discussed for more than one year in the WG and =

         the document captures the results of the collaborative WG = work.

 

     = Document Quality

 

         ---

         The document is complete, straightforward, simple and well-written.        =

        

------_=_NextPart_001_01CBEF38.89ACF7D8-- From jouni.nospam@gmail.com Thu Mar 31 00:11:50 2011 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD5F28C0D0 for ; Thu, 31 Mar 2011 00:11:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kj4wJrvb4HAs for ; Thu, 31 Mar 2011 00:11:48 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DE2623A69B6 for ; Thu, 31 Mar 2011 00:11:47 -0700 (PDT) Received: by fxm15 with SMTP id 15so1798490fxm.31 for ; Thu, 31 Mar 2011 00:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=RfYZonHiaGPf9ePtRucSZ4EbNFOSF2+HbDLzQK/d5EQ=; b=LPLD4qEmXWGijgR3N8fNhcoBzqwmXMcX82anKVcQGLF+pyl+kru7ZnWqjF4c8wgEDf 9u/K16x1dEi9Tf41632ZVG8v+DtBhT5QIdO9BQ3bEZ7q5w8t0mAq40UL0Mc0XZA8jOhx DYfdx+CEOU9uklfWqjdUOSdzyl20hDVa+l4B4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LX/Ryzq0bHQEwrtKw16fsV/VlyJD+7Xz36pOIRHepKuAlFdsswm6bbxOmKr7xKtsCH o6BxKEWsJsUIFtZNI7MtXB3dfrWHt0gFHvOlWX8BZeduCQlx1wafPQjCddjFB5U+i8AX 27FrUyE1VNAjH0Y3Oq1F0Ffn30NN3Wu+PqA0A= Received: by 10.223.160.8 with SMTP id l8mr2004724fax.114.1301555606425; Thu, 31 Mar 2011 00:13:26 -0700 (PDT) Received: from dhcp-10f2.meeting.ietf.org (dhcp-10f2.meeting.ietf.org [130.129.16.242]) by mx.google.com with ESMTPS id 17sm272816far.43.2011.03.31.00.13.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 00:13:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 31 Mar 2011 10:13:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Taylor X-Mailer: Apple Mail (2.1082) Cc: dime@ietf.org Subject: Re: [Dime] Note takers X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:11:50 -0000 Thanks Tom! - Jouni On Mar 30, 2011, at 8:58 PM, Tom Taylor wrote: > Unless I'm surprised by another ad hoc meeting, I can volunteer. >=20 > On 22/03/2011 5:27 PM, jouni korhonen wrote: >> Folks, >>=20 >> Dime meeting is approaching... if someone feels an urge to ease the = starting of the WG meeting, please volunteer as a notetaker. >>=20 >> - Jouni& Lionel >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20