From internet-drafts@ietf.org Fri Sep 2 02:13:18 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6049C21F900D; Fri, 2 Sep 2011 02:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlJFiaJa0gOl; Fri, 2 Sep 2011 02:13:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF821F8FFF; Fri, 2 Sep 2011 02:13:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902091317.19196.6744.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 02:13:17 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 09:13:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Address and Port Translation Control Ap= plication Author(s) : Frank Brockners Shwetha Bhandari Vaneeta Singh Victor Fajardo Filename : draft-ietf-dime-nat-control-10.txt Pages : 59 Date : 2011-09-02 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-10.txt From internet-drafts@ietf.org Fri Sep 2 05:16:09 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5096521F8FDE; Fri, 2 Sep 2011 05:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROdkGSkwWiw7; Fri, 2 Sep 2011 05:16:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0189221F8FDD; Fri, 2 Sep 2011 05:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902121601.6393.77793.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 05:16:01 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-nat-control-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 12:16:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Network Address and Port Translation Control Ap= plication Author(s) : Frank Brockners Shwetha Bhandari Vaneeta Singh Victor Fajardo Filename : draft-ietf-dime-nat-control-11.txt Pages : 59 Date : 2011-09-02 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-nat-control-11.txt From fbrockne@cisco.com Fri Sep 2 09:18:36 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2212421F8B9A; Fri, 2 Sep 2011 09:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.393 X-Spam-Level: X-Spam-Status: No, score=-9.393 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+8rXxGCDLgl; Fri, 2 Sep 2011 09:18:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8F59821F86AF; Fri, 2 Sep 2011 09:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=17924; q=dns/txt; s=iport; t=1314980410; x=1316190010; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d3NO/496Fi5jQDI3dHfSPptfb5wzEzcp3tPIavKlTs0=; b=GjqkdPk3C/ebZ7JktdVahwAiH+OUhSDNyTliHKmoujhTFYqlBFsOw3FC DdC8rt3K4XpNu3lh0TyEdnGNd6U9Zhc+QoBGCAx5ztHSPk8PVW/c9dtKj FFSm0PN33jDSdmo/NCokqv8TAsgMoWtQtWFVSVzvfx+Z8YzAQSkbykiBe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsAADMBYU6Q/khL/2dsb2JhbABCmHOPdHiBRgEBAQECAQEBAQ8BHQozAQQHDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBMHh1AEmhIBnxKGBWAEmESLdw X-IronPort-AV: E=Sophos;i="4.68,320,1312156800"; d="scan'208";a="53019737" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 02 Sep 2011 16:20:03 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p82GK34V029976; Fri, 2 Sep 2011 16:20:03 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Sep 2011 18:20:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Sep 2011 18:20:00 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 Thread-Index: AcxG2jxqScbzP0yQT824oXePckWTcAirVqQg References: From: "Frank Brockners (fbrockne)" To: "Martin Stiemerling" , , X-OriginalArrivalTime: 02 Sep 2011 16:20:03.0680 (UTC) FILETIME=[2BB93E00:01CC698C] Cc: tsv-ads@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 16:18:36 -0000 Martin, thanks for your comments and sorry for the delay in getting the draft updated. We just posted a new revision (draft-ietf-dime-nat-control-11), reflecting your comments. Please see additional comments inline... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Wednesday, July 20, 2011 3:34 PM > To: draft-ietf-dime-nat-control@tools.ietf.org; dime@ietf.org > Cc: tsv-ads@tools.ietf.org; tsv-dir@ietf.org > Subject: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 >=20 > Hi there, >=20 > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were > written primarily for the transport area directors, but are copied to > the document's authors for their information and to allow them to > address any issues raised. The authors should consider this review > together with any other last-call comments they receive. Please always > CC tsv-dir@ietf.org if you reply to or forward this review. >=20 > **Executive Summary: > This draft has serious issues, described in the review, and needs to be > rethought. >=20 > **Review comments: >=20 > *General > - There is no place where the prior work of MIDCOM is mentioned. > Is this intentionally and did the WG not know or consider prior work of > the IETF? > MIDCOM is going beyond what this draft is specifying, as it also > includes firewall control, plus some further features, such as learning > about the interfaces used for the MIDCOM server. > What was the reasoning to not reuse MIDCOM or semantics developed for > MIDCOM? ...FB: The question on the relationship of DNCA and MIDCOM was also=20 raised by other reviewers. Following those comments,=20 the relationship of DNCA to MIDCOM was discussed by the DIME WG =20 again at the last IETF in Quebec (the WG had a first round of discussions on this topic when draft-brockners-nat-control- protocols-review-00 was presented). See also IETF 81 DIME notes. Conclusion was that for network management, there can be different protocols, aiming at a similar solution domains. These different protocol follow the deployment requirements of different=20 operators. SNMP and NETCONF were mentioned as examples.=20 =20 DNCA is targeted at deployments which already heavily employ the Diameter protocol for per-subscriber device control (e.g. mobile networks). DNCA qualifies as a MIDCOM protocol, and at the same time offers capabilities for per-subscriber control. It is not there to replace existing solutions, but complement them. If there is interest, the DNCA protocol work could potentially be complemented with a BCP in the ops area, providing additional deployment guidance.=20 Following the outcome of the discussion, we added a paragraph=20 to section 1 to explicitly discuss DNCA as a MIDCOM protocol:=20 =20 With the above capabilities, DNCA qualifies as a MIDCOM protocol [RFC3303], [RFC3304], [RFC5189] for middle boxes which perform NAT. The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a candidate protocol for MIDCOM. DNCA provides the extensions to the Diameter base protocol [RFC3588] following the MIDCOM protocol requirements, such as the support of NAT-specific rule transport, support for oddity of mapped ports, as well as support for consecutive range port numbers. DNCA adds to the MIDCOM protocol capabilities in that it allows to maintain the reference to an end point representing a user or subscriber in the control operation, enabling the control of the behavior of a NAT-device on a per end point basis. Following the requirements of different operators and deployments, different management protocols are employed. Examples include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can both be used for device configuration. Similarly, DNCA is complementing existing MIDCOM implementations, offering a MIDCOM protocol option for operators with an operational environment that is Diameter- focused which desire to use Diameter to perform per end point NAT control. >=20 > - The usage of RFC 2119 is missing in parts of the draft, e.g., the > text in Section 4 seems to be meant as mandatory but there is almost no > RFC 2119 language. ...FB: We fixed this in the most recent version, and used RFC 2119=20 throughout the document. > - Is the DNCA able to allocate 2 consecutive transport ports? This is > sometimes required by legacy RTP/RTCP applications. ...FB: We've updated DNCA to allow for this use (which is also a MIDCOM requirement). This is now reflected with a new AVP: 8.7.10. NAT-External-Port-Style AVP The NAT-External-Port-Style AVP (AVP Code TBD) is of type Enumerated and contains the style to be followed while selecting the external port for a NAT-Binding relative to the internal port. The following values are defined: FOLLOW_INTERNAL_PORT_STYLE (1) External port numbers selected MUST follow the same sequence and oddity as the internal ports of the NAT-bindings. The port odditity is required to support protocols like RTP and RTCP as defined in [RFC3550]. If for example the internal port in a requested NAT-binding is odd numbered then the external port allocated MUST also be odd numbered, and vice versa for an even numbered port. In addition, the sequence of port numbering is maintained: If internal ports are consecutive, then the NAT- device MUST choose consecutive external ports for the NAT- bindings. >=20 > * Detailed review > - Section 1, 1st paragraph, a nit: > "... in their networks to deal with the depletion of available public > IPv4 Addresses". This is one reason out of many. NATs are around for > 10+ years, i.e., way before we were about to run out of IPv4 addresses. ...FB: Agreed. Current text no longer mentions this as exclusive, but makes this a key example: [..] Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. [..] > - Section 2, and rest of the document: > The terminology used in this draft is not well documented. There are > NAT bindings, NAT binding rules and predefined NAT binding rules > (templates?). However, the difference is not well documented, even > though I understand the difference. How do you name a NAT binding which > is actually used by a data exchange? ...FB: We cleaned up the language around those, and added two entries to the abbreviation section (e.g. NAT binding rules and predefined binding rules got consolidated into=20 "NAT Binding Predefined template"): NAT-binding or binding: Association of two IP address/port pairs (with one IP address typically being private and the other one public) to facilitate NAT NAT Binding Predefined template: Is a policy template or configuration that is predefined at the NAT-device. It may contain NAT-bindings, IP-address pools for allocating the external IP-address of a NAT-binding, the maximum number of allowed NAT- bindings for end-points, etc. > - Section 3.1, page 8, 1st paragraph, "to increase the efficiency of > the global IPv4 address pool utilization.": > Not sure that this setting is only used for this use case. How about > just writing: > "Figure 2 depicts the deployment scenario where a service provider > places a NAT between the host and the public Internet." ...FB: Thanks. The text now reflects your suggestion. > - It would be good to cite RFC6144-6147 for 6to4 to indicate on what > basis the address family translation is working in this draft. The same > holds true for IPv4. ...FB: The intro section now references NAT related RFCs relevant to DNCA, see below. What I'm not sure about is why you refer to 6to4 (which would be RFC3056) - which I don't really see applicable to DNCA (because there is no translation in 6to4, just tunneling). Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. This document defines a Diameter application allowing providers to control the behavior of NAT and NAPT devices that implement IPv4-to-IPv4 network address and port translation [RFC2663] as well as stateful IPv6-to-IPv4 address family translation translation as defined in [RFC2663], [RFC6145], and [RFC6146]. The use of a Diameter application allows for simple integration into the existing Authentication, Authorization and Accounting (AAA) environment of a provider. =20 > - IPv6 to IPv4 translation: I was not able to figure out how such a > signaling would be. There are no examples for this or guidance at all. > - IPv4 to IPv4 translation: It would be good to have one or some few > examples to see how such DNCA messages would look like. ...FB: We've created an entire new section (section 13) showing=20 examples for several uses of DNCA. There are no real differences wrt/ signaling between IPv6 and IPv4. The only real difference is that you'd either define an internal IPv4 or IPv6 address using a respective AVP. > - All figures: The figures are not especially meaningful for the reader > and do not help in my opinion to understand the protocol, but do not > hamper understanding either. > - Section 4.2, page 15, last bullet point starting with "If a NCR > redfines...": > This touches a critical point of what happens if the new number of > allowed bindings is lower than the prior selected number of allowed > bindings. The text is not giving a good guidance of what should happen > in this case and I see it a weak point to let this open to the > discretion of the implementation. For a good specification I would at > least expect a RECOMMENDATION or SHOULD, better a MUST. However, this > comment relates to the lack of RFC 2119 language in this section. ...FB: Agreed. We've updated the bullet using a SHOULD recommendation: o If an NCR redefines the maximum number of NAT-bindings allowed for the endpoint, the new value MUST override any previously defined limit on NAT bindings. It depends on the implementation of the NAT-device on how the NAT-device copes with a case where the new value is lower than the actual number of allocated bindings. The NAT-device SHOULD refrain from enforcing the new limit immediately (that is, actively remove bindings), but rather disallows the establishment of new bindings until the current number of bindings is lower than the newly established maximum number of allowed bindings. > - Section 4.2, page 16, bullet point "If a NCR specifies a new...": > What happens in this case with already binding rules which are > installed and actively used by a data session? Is the data session > stopped and the binding removed? ...FB: We've clarified this by stating that a change of templates should not impact existing sessions: o If an NCR specifies a new NAT Binding Predefined template on the NAT-device, the NAT Binding Predefined template overrides any previously defined rule for the session. Existing NAT-bindings SHOULD NOT be impacted by the change of templates. > - Section 4.3, page 17, bullet "2. Retrieve...": > How does the DNCA peer with the NAT controller know about the available > external IP addresses at the NAT? This is not clear to me. Is this a > feature of another DIAMETER application or is it assumed that the > controller just knows this somehow? ..FB: The NAT-Controller will know this information via configuration and/or through interaction with the overall OSS/BSS systems. More specifically, it is not a feature of DNCA. > - Section 4.4, 1st paragraph, "In response, the DNCA...": > I cannot understand this sentence. ...FB: We're did a bit of editing on section 4.4 to now be more understandable: 4.4. Session Termination Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT-controller. The DNCA Diameter peer sends a Session Terminate Request (STR) message to its peer within the NAT-device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR message processing the DNCA Diameter peer within the NAT-device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT- device MUST notify its DNCA Diameter peer in the NAT-controller about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers. If a DNCA Diameter peer within a NAT-device receives a STR and fails to find a matching session, the DNCA Diameter peer MUST return a STA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. > - Figure 8: The text belonging to this figure does not mention that the > NAT bindings MUST be removed if the STR is received. This is only shown > in the figure. The text seems to be incomplete and also lacking RFC > 2119 language. ...FB: In order to avoid inconsistencies as well as redundancies between figures and text, we've simplified the figures and expanded the text where necessary. The first paragraph of section 4.4. now reads: Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT-controller. The DNCA Diameter peer sends a Session Terminate Request (STR) message to its peer within the NAT-device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR message processing the DNCA Diameter peer within the NAT-device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT- device MUST notify its DNCA Diameter peer in the NAT-controller about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers. > - Section 4.6, 1st paragraph: What is the redundancy support mentioned > there which is mandatory? Something which is a MUST must be well > documented. I cannot see this here. ...FB: Agreed that asking for "some redundancy mechanism" but not specifying it is confusing at least. Given that state recovery of Diameter peers is not touched upon in other Diameter applications, we decided after discussion with the DIME chairs to remove references to redundancy mechanisms altogether from the document: 4.6. Failure cases of the DNCA Diameter peers This document does not specify the behavior in case the NAT-device and NAT-controller, or their respective DNCA Diameter peers are out of sync or lose state. > - IANA section and IANA points in text: > The use of TBD throughout the draft for IANA code-points and also in > the IANA section is harmful for IANA and also for the draft at best. > Why are you not using meaningful identifiers for code-points and > reference them in the IANA section? The use of generic TBD placeholders > will just create confusion for IANA and for you. ...FB: Per Miguel Garcia's note, IANA seems to understand what is required. > - Section 6.1 and 6.2: I was surprise to see the list of parameters > which can be included in requests and responses, after reading Section > 4, where those parameters are omitted. Given all these parameters and > the lack of explanation in the draft, it seems to be hard for an > implementer to get the link between Section 4 and this. This needs > further explanation in the draft, see also my comment about how IPv6 to > IPv4 translation works and about the missing usage examples. ...FB: Per what I stated above, we've added an entire section 13 to show several examples. In addition, we've added text to section 6 and 8 to make things hopefully easier to understand. > - Section 8.x, broken labels of the tables: > The figures in Section 8.x are actually tables, i.e., their description > is incorrect and broken. ...FB: We're using tables now :-). > - Section 8.5, Figure 13, "Reused QoS-attributes": > Why are the AVP codes set to TBD if they are taken from RFC 5777? E.g., > Direction AVP (AVP Code 514) but not TBD! ...FB: Good catch. We've updated the table accordingly. Best regards, Frank >=20 >=20 > Kind regards >=20 > Martin Stiemerling >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Tue Sep 6 02:47:44 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CFA21F8582; Tue, 6 Sep 2011 02:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03dZEO0c2AND; Tue, 6 Sep 2011 02:47:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B297621F8573; Tue, 6 Sep 2011 02:47:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110906094743.4967.27587.idtracker@ietfa.amsl.com> Date: Tue, 06 Sep 2011 02:47:43 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 09:47:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter support for EAP Re-authentication Protocol (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-07.txt Pages : 15 Date : 2011-09-06 The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-erp-07.txt From bill.wu@huawei.com Tue Sep 6 03:54:39 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A0A21F8663 for ; Tue, 6 Sep 2011 03:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.123 X-Spam-Level: X-Spam-Status: No, score=-5.123 tagged_above=-999 required=5 tests=[AWL=1.476, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AFCDvMFb4v8 for ; Tue, 6 Sep 2011 03:54:38 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4421F858D for ; Tue, 6 Sep 2011 03:54:38 -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 <0LR30052WL1F54@szxga03-in.huawei.com> for dime@ietf.org; Tue, 06 Sep 2011 18:56:03 +0800 (CST) Received: from szxrg01-dlp.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 <0LR300BNXL1FSX@szxga03-in.huawei.com> for dime@ietf.org; Tue, 06 Sep 2011 18:56:03 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV11882; Tue, 06 Sep 2011 18:55:18 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 18:55:16 +0800 Received: from w53375q (10.138.41.130) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 18:55:15 +0800 Date: Tue, 06 Sep 2011 18:55:14 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: dime@ietf.org Message-id: <4B596EC5310046E68BBCC5CCCF58FE7D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected Subject: [Dime] New version of draft-ietf-dime-erp-07 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 10:54:39 -0000 Hi,folks: The new version of draft-ietf-dime-erp is available at http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-07.txt which addresses the remaining two issues we discussed in the Quebec meeting. Also the editiorial notes and section 9 have all been cleared. The diff is: http://tools.ietf.org/rfcdiff?url2=draft-ietf-dime-erp-07.txt Let me know if you think the proposed change in the new version addresses the open issues. Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Tuesday, September 06, 2011 5:47 PM Subject: [Dime] I-D Action: draft-ietf-dime-erp-07.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 EAP Re-authentication Protocol (ERP) > Author(s) : Julien Bournelle > Lionel Morand > Sebastien Decugis > Qin Wu > Glen Zorn > Filename : draft-ietf-dime-erp-07.txt > Pages : 15 > Date : 2011-09-06 > > The EAP Re-authentication Protocol (ERP) defines extensions to the > Extensible Authentication Protocol (EAP) to support efficient re- > authentication between the peer and an EAP Re-authentication (ER) > server through a compatible authenticator. This document specifies > Diameter support for ERP. It defines a new Diameter ERP application > to transport ERP messages between an ER authenticator and the ER > server, and a set of new AVPs that can be used to transport the > cryptographic material needed by the re-authentication server. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-erp-07.txt > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Fri Sep 9 00:27:53 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70821F8AA8; Fri, 9 Sep 2011 00:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.954 X-Spam-Level: X-Spam-Status: No, score=-100.954 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmHPaqwOYRSV; Fri, 9 Sep 2011 00:27:52 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1021F888A; Fri, 9 Sep 2011 00:27:51 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40E318B8009; Fri, 9 Sep 2011 09:31:03 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2D9297B8003; Fri, 9 Sep 2011 09:31:03 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 09:28:40 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Sep 2011 09:28:38 +0200 Message-ID: In-reply-to: <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 Thread-index: AcxG2jxqScbzP0yQT824oXePckWTcAirVqQgAU5tUHA= References: <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com> From: To: X-OriginalArrivalTime: 09 Sep 2011 07:28:40.0113 (UTC) FILETIME=[18874210:01CC6EC2] Cc: tsv-ads@tools.ietf.org, dime@ietf.org, rdroms.ietf@gmail.com, tsv-dir@ietf.org, draft-ietf-dime-nat-control@tools.ietf.org Subject: Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 07:27:53 -0000 Hi Martin, Does this new version of the draft answer your concerns? Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Frank Brockners (fbrockne) Envoy=E9=A0: vendredi 2 septembre 2011 18:20 =C0=A0: Martin Stiemerling; draft-ietf-dime-nat-control@tools.ietf.org; = dime@ietf.org Cc=A0: tsv-ads@tools.ietf.org; tsv-dir@ietf.org Objet=A0: Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 Martin, thanks for your comments and sorry for the delay in getting the draft updated. We just posted a new revision (draft-ietf-dime-nat-control-11), reflecting your comments. Please see additional comments inline... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Wednesday, July 20, 2011 3:34 PM > To: draft-ietf-dime-nat-control@tools.ietf.org; dime@ietf.org > Cc: tsv-ads@tools.ietf.org; tsv-dir@ietf.org > Subject: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 >=20 > Hi there, >=20 > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were > written primarily for the transport area directors, but are copied to > the document's authors for their information and to allow them to > address any issues raised. The authors should consider this review > together with any other last-call comments they receive. Please always > CC tsv-dir@ietf.org if you reply to or forward this review. >=20 > **Executive Summary: > This draft has serious issues, described in the review, and needs to be > rethought. >=20 > **Review comments: >=20 > *General > - There is no place where the prior work of MIDCOM is mentioned. > Is this intentionally and did the WG not know or consider prior work of > the IETF? > MIDCOM is going beyond what this draft is specifying, as it also > includes firewall control, plus some further features, such as learning > about the interfaces used for the MIDCOM server. > What was the reasoning to not reuse MIDCOM or semantics developed for > MIDCOM? ...FB: The question on the relationship of DNCA and MIDCOM was also=20 raised by other reviewers. Following those comments,=20 the relationship of DNCA to MIDCOM was discussed by the DIME WG =20 again at the last IETF in Quebec (the WG had a first round of discussions on this topic when draft-brockners-nat-control- protocols-review-00 was presented). See also IETF 81 DIME notes. Conclusion was that for network management, there can be different protocols, aiming at a similar solution domains. These different protocol follow the deployment requirements of different=20 operators. SNMP and NETCONF were mentioned as examples.=20 =20 DNCA is targeted at deployments which already heavily employ the Diameter protocol for per-subscriber device control (e.g. mobile networks). DNCA qualifies as a MIDCOM protocol, and at the same time offers capabilities for per-subscriber control. It is not there to replace existing solutions, but complement them. If there is interest, the DNCA protocol work could potentially be complemented with a BCP in the ops area, providing additional deployment guidance.=20 Following the outcome of the discussion, we added a paragraph=20 to section 1 to explicitly discuss DNCA as a MIDCOM protocol:=20 =20 With the above capabilities, DNCA qualifies as a MIDCOM protocol [RFC3303], [RFC3304], [RFC5189] for middle boxes which perform NAT. The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a candidate protocol for MIDCOM. DNCA provides the extensions to the Diameter base protocol [RFC3588] following the MIDCOM protocol requirements, such as the support of NAT-specific rule transport, support for oddity of mapped ports, as well as support for consecutive range port numbers. DNCA adds to the MIDCOM protocol capabilities in that it allows to maintain the reference to an end point representing a user or subscriber in the control operation, enabling the control of the behavior of a NAT-device on a per end point basis. Following the requirements of different operators and deployments, different management protocols are employed. Examples include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can both be used for device configuration. Similarly, DNCA is complementing existing MIDCOM implementations, offering a MIDCOM protocol option for operators with an operational environment that is Diameter- focused which desire to use Diameter to perform per end point NAT control. >=20 > - The usage of RFC 2119 is missing in parts of the draft, e.g., the > text in Section 4 seems to be meant as mandatory but there is almost no > RFC 2119 language. ...FB: We fixed this in the most recent version, and used RFC 2119=20 throughout the document. > - Is the DNCA able to allocate 2 consecutive transport ports? This is > sometimes required by legacy RTP/RTCP applications. ...FB: We've updated DNCA to allow for this use (which is also a MIDCOM requirement). This is now reflected with a new AVP: 8.7.10. NAT-External-Port-Style AVP The NAT-External-Port-Style AVP (AVP Code TBD) is of type Enumerated and contains the style to be followed while selecting the external port for a NAT-Binding relative to the internal port. The following values are defined: FOLLOW_INTERNAL_PORT_STYLE (1) External port numbers selected MUST follow the same sequence and oddity as the internal ports of the NAT-bindings. The port odditity is required to support protocols like RTP and RTCP as defined in [RFC3550]. If for example the internal port in a requested NAT-binding is odd numbered then the external port allocated MUST also be odd numbered, and vice versa for an even numbered port. In addition, the sequence of port numbering is maintained: If internal ports are consecutive, then the NAT- device MUST choose consecutive external ports for the NAT- bindings. >=20 > * Detailed review > - Section 1, 1st paragraph, a nit: > "... in their networks to deal with the depletion of available public > IPv4 Addresses". This is one reason out of many. NATs are around for > 10+ years, i.e., way before we were about to run out of IPv4 addresses. ...FB: Agreed. Current text no longer mentions this as exclusive, but makes this a key example: [..] Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. [..] > - Section 2, and rest of the document: > The terminology used in this draft is not well documented. There are > NAT bindings, NAT binding rules and predefined NAT binding rules > (templates?). However, the difference is not well documented, even > though I understand the difference. How do you name a NAT binding which > is actually used by a data exchange? ...FB: We cleaned up the language around those, and added two entries to the abbreviation section (e.g. NAT binding rules and predefined binding rules got consolidated into=20 "NAT Binding Predefined template"): NAT-binding or binding: Association of two IP address/port pairs (with one IP address typically being private and the other one public) to facilitate NAT NAT Binding Predefined template: Is a policy template or configuration that is predefined at the NAT-device. It may contain NAT-bindings, IP-address pools for allocating the external IP-address of a NAT-binding, the maximum number of allowed NAT- bindings for end-points, etc. > - Section 3.1, page 8, 1st paragraph, "to increase the efficiency of > the global IPv4 address pool utilization.": > Not sure that this setting is only used for this use case. How about > just writing: > "Figure 2 depicts the deployment scenario where a service provider > places a NAT between the host and the public Internet." ...FB: Thanks. The text now reflects your suggestion. > - It would be good to cite RFC6144-6147 for 6to4 to indicate on what > basis the address family translation is working in this draft. The same > holds true for IPv4. ...FB: The intro section now references NAT related RFCs relevant to DNCA, see below. What I'm not sure about is why you refer to 6to4 (which would be RFC3056) - which I don't really see applicable to DNCA (because there is no translation in 6to4, just tunneling). Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. This document defines a Diameter application allowing providers to control the behavior of NAT and NAPT devices that implement IPv4-to-IPv4 network address and port translation [RFC2663] as well as stateful IPv6-to-IPv4 address family translation translation as defined in [RFC2663], [RFC6145], and [RFC6146]. The use of a Diameter application allows for simple integration into the existing Authentication, Authorization and Accounting (AAA) environment of a provider. =20 > - IPv6 to IPv4 translation: I was not able to figure out how such a > signaling would be. There are no examples for this or guidance at all. > - IPv4 to IPv4 translation: It would be good to have one or some few > examples to see how such DNCA messages would look like. ...FB: We've created an entire new section (section 13) showing=20 examples for several uses of DNCA. There are no real differences wrt/ signaling between IPv6 and IPv4. The only real difference is that you'd either define an internal IPv4 or IPv6 address using a respective AVP. > - All figures: The figures are not especially meaningful for the reader > and do not help in my opinion to understand the protocol, but do not > hamper understanding either. > - Section 4.2, page 15, last bullet point starting with "If a NCR > redfines...": > This touches a critical point of what happens if the new number of > allowed bindings is lower than the prior selected number of allowed > bindings. The text is not giving a good guidance of what should happen > in this case and I see it a weak point to let this open to the > discretion of the implementation. For a good specification I would at > least expect a RECOMMENDATION or SHOULD, better a MUST. However, this > comment relates to the lack of RFC 2119 language in this section. ...FB: Agreed. We've updated the bullet using a SHOULD recommendation: o If an NCR redefines the maximum number of NAT-bindings allowed for the endpoint, the new value MUST override any previously defined limit on NAT bindings. It depends on the implementation of the NAT-device on how the NAT-device copes with a case where the new value is lower than the actual number of allocated bindings. The NAT-device SHOULD refrain from enforcing the new limit immediately (that is, actively remove bindings), but rather disallows the establishment of new bindings until the current number of bindings is lower than the newly established maximum number of allowed bindings. > - Section 4.2, page 16, bullet point "If a NCR specifies a new...": > What happens in this case with already binding rules which are > installed and actively used by a data session? Is the data session > stopped and the binding removed? ...FB: We've clarified this by stating that a change of templates should not impact existing sessions: o If an NCR specifies a new NAT Binding Predefined template on the NAT-device, the NAT Binding Predefined template overrides any previously defined rule for the session. Existing NAT-bindings SHOULD NOT be impacted by the change of templates. > - Section 4.3, page 17, bullet "2. Retrieve...": > How does the DNCA peer with the NAT controller know about the available > external IP addresses at the NAT? This is not clear to me. Is this a > feature of another DIAMETER application or is it assumed that the > controller just knows this somehow? ..FB: The NAT-Controller will know this information via configuration and/or through interaction with the overall OSS/BSS systems. More specifically, it is not a feature of DNCA. > - Section 4.4, 1st paragraph, "In response, the DNCA...": > I cannot understand this sentence. ...FB: We're did a bit of editing on section 4.4 to now be more understandable: 4.4. Session Termination Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT-controller. The DNCA Diameter peer sends a Session Terminate Request (STR) message to its peer within the NAT-device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR message processing the DNCA Diameter peer within the NAT-device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT- device MUST notify its DNCA Diameter peer in the NAT-controller about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers. If a DNCA Diameter peer within a NAT-device receives a STR and fails to find a matching session, the DNCA Diameter peer MUST return a STA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. > - Figure 8: The text belonging to this figure does not mention that the > NAT bindings MUST be removed if the STR is received. This is only shown > in the figure. The text seems to be incomplete and also lacking RFC > 2119 language. ...FB: In order to avoid inconsistencies as well as redundancies between figures and text, we've simplified the figures and expanded the text where necessary. The first paragraph of section 4.4. now reads: Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT-controller. The DNCA Diameter peer sends a Session Terminate Request (STR) message to its peer within the NAT-device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR message processing the DNCA Diameter peer within the NAT-device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT- device MUST notify its DNCA Diameter peer in the NAT-controller about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers. > - Section 4.6, 1st paragraph: What is the redundancy support mentioned > there which is mandatory? Something which is a MUST must be well > documented. I cannot see this here. ...FB: Agreed that asking for "some redundancy mechanism" but not specifying it is confusing at least. Given that state recovery of Diameter peers is not touched upon in other Diameter applications, we decided after discussion with the DIME chairs to remove references to redundancy mechanisms altogether from the document: 4.6. Failure cases of the DNCA Diameter peers This document does not specify the behavior in case the NAT-device and NAT-controller, or their respective DNCA Diameter peers are out of sync or lose state. > - IANA section and IANA points in text: > The use of TBD throughout the draft for IANA code-points and also in > the IANA section is harmful for IANA and also for the draft at best. > Why are you not using meaningful identifiers for code-points and > reference them in the IANA section? The use of generic TBD placeholders > will just create confusion for IANA and for you. ...FB: Per Miguel Garcia's note, IANA seems to understand what is required. > - Section 6.1 and 6.2: I was surprise to see the list of parameters > which can be included in requests and responses, after reading Section > 4, where those parameters are omitted. Given all these parameters and > the lack of explanation in the draft, it seems to be hard for an > implementer to get the link between Section 4 and this. This needs > further explanation in the draft, see also my comment about how IPv6 to > IPv4 translation works and about the missing usage examples. ...FB: Per what I stated above, we've added an entire section 13 to show several examples. In addition, we've added text to section 6 and 8 to make things hopefully easier to understand. > - Section 8.x, broken labels of the tables: > The figures in Section 8.x are actually tables, i.e., their description > is incorrect and broken. ...FB: We're using tables now :-). > - Section 8.5, Figure 13, "Reused QoS-attributes": > Why are the AVP codes set to TBD if they are taken from RFC 5777? E.g., > Direction AVP (AVP Code 514) but not TBD! ...FB: Good catch. We've updated the table accordingly. Best regards, Frank >=20 >=20 > Kind regards >=20 > Martin Stiemerling >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Mon Sep 12 13:40:34 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB86D21F8DF0; Mon, 12 Sep 2011 13:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRih7tMjP7PH; Mon, 12 Sep 2011 13:40:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CDD21F8DEA; Mon, 12 Sep 2011 13:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912204033.4498.89516.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 13:40:33 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ikev2-psk-diameter-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 20:40:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter IKEv2 PSK: Pre-Shared Key-based Support for IKE= v2 Server to Diameter Server Interaction Author(s) : Violeta Cakulev Avi Lior Semyon Mizikovsky Filename : draft-ietf-dime-ikev2-psk-diameter-10.txt Pages : 22 Date : 2011-09-12 The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and pre-shared keys. Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for pre-shared key based authentication available with IKEv2. This document specifies the IKEv2 Server to the Diameter server communication when the IKEv2 Peer authenticates using the Internet Key Exchange v2 with Pre-Shared Key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-ikev2-psk-diameter-10.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-ikev2-psk-diameter-10.txt From Martin.Stiemerling@neclab.eu Tue Sep 13 08:12:08 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D6721F8B01; Tue, 13 Sep 2011 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.629 X-Spam-Level: X-Spam-Status: No, score=-100.629 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woVDDaEmEh2r; Tue, 13 Sep 2011 08:12:04 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD121F88B7; Tue, 13 Sep 2011 08:12:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 86F5A28000332; Tue, 13 Sep 2011 17:14:07 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYXbEsduwcJy; Tue, 13 Sep 2011 17:14:07 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 656A9280001AA; Tue, 13 Sep 2011 17:13:42 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 13 Sep 2011 17:13:21 +0200 From: Martin Stiemerling To: "Frank Brockners (fbrockne)" , "draft-ietf-dime-nat-control@tools.ietf.org" , "dime@ietf.org" Thread-Topic: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 Thread-Index: AcxG2jxqScbzP0yQT824oXePckWTcAirVqQgAif1vgA= Date: Tue, 13 Sep 2011 15:13:23 +0000 Message-ID: References: <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 13 Sep 2011 08:23:00 -0700 Cc: "tsv-ads@tools.ietf.org" , "tsv-dir@ietf.org" Subject: Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 15:12:08 -0000 Hi Frank, all, This all looks good, i.e., my comments have been addressed. Danke sch=F6n/Thanks=20 Martin > -----Original Message----- > From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] > Sent: Friday, September 02, 2011 6:20 PM > To: Martin Stiemerling; draft-ietf-dime-nat-control@tools.ietf.org; > dime@ietf.org > Cc: tsv-ads@tools.ietf.org; tsv-dir@ietf.org > Subject: RE: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 >=20 > Martin, >=20 > thanks for your comments and sorry for the delay in getting the draft upd= ated. > We just posted a new revision (draft-ietf-dime-nat-control-11), reflectin= g your > comments. Please see additional comments inline... >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of > > Martin Stiemerling > > Sent: Wednesday, July 20, 2011 3:34 PM > > To: draft-ietf-dime-nat-control@tools.ietf.org; dime@ietf.org > > Cc: tsv-ads@tools.ietf.org; tsv-dir@ietf.org > > Subject: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 > > > > Hi there, > > > > I've reviewed this document as part of the transport area > directorate's > > ongoing effort to review key IETF documents. These comments were > > written primarily for the transport area directors, but are copied to > > the document's authors for their information and to allow them to > > address any issues raised. The authors should consider this review > > together with any other last-call comments they receive. Please always > > CC tsv-dir@ietf.org if you reply to or forward this review. > > > > **Executive Summary: > > This draft has serious issues, described in the review, and needs to > be > > rethought. > > > > **Review comments: > > > > *General > > - There is no place where the prior work of MIDCOM is mentioned. > > Is this intentionally and did the WG not know or consider prior work > of > > the IETF? > > MIDCOM is going beyond what this draft is specifying, as it also > > includes firewall control, plus some further features, such as > learning > > about the interfaces used for the MIDCOM server. > > What was the reasoning to not reuse MIDCOM or semantics developed for > > MIDCOM? >=20 > ...FB: The question on the relationship of DNCA and MIDCOM was also > raised by other reviewers. Following those comments, > the relationship of DNCA to MIDCOM was discussed by the DIME WG > again at the last IETF in Quebec (the WG had a first round of > discussions on this topic when draft-brockners-nat-control- > protocols-review-00 was presented). See also IETF 81 DIME notes. > Conclusion was that for network management, there can be different > protocols, aiming at a similar solution domains. These different > protocol follow the deployment requirements of different > operators. SNMP and NETCONF were mentioned as examples. >=20 > DNCA is targeted at deployments which already heavily employ > the Diameter protocol for per-subscriber device control > (e.g. mobile networks). DNCA qualifies as a MIDCOM protocol, > and at the same time offers capabilities for per-subscriber > control. It is not there to replace existing solutions, but > complement them. If there is interest, the DNCA protocol work > could potentially be complemented with a BCP in the ops > area, providing additional deployment guidance. >=20 > Following the outcome of the discussion, we added a paragraph > to section 1 to explicitly discuss DNCA as a MIDCOM protocol: >=20 > With the above capabilities, DNCA qualifies as a MIDCOM protocol > [RFC3303], [RFC3304], [RFC5189] for middle boxes which perform NAT. > The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a > candidate protocol for MIDCOM. DNCA provides the extensions to the > Diameter base protocol [RFC3588] following the MIDCOM protocol > requirements, such as the support of NAT-specific rule transport, > support for oddity of mapped ports, as well as support for > consecutive range port numbers. DNCA adds to the MIDCOM protocol > capabilities in that it allows to maintain the reference to an end > point representing a user or subscriber in the control operation, > enabling the control of the behavior of a NAT-device on a per end > point basis. Following the requirements of different operators and > deployments, different management protocols are employed. Examples > include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can both be > used for device configuration. Similarly, DNCA is complementing > existing MIDCOM implementations, offering a MIDCOM protocol option > for operators with an operational environment that is Diameter- > focused which desire to use Diameter to perform per end point NAT > control. >=20 > > > > - The usage of RFC 2119 is missing in parts of the draft, e.g., the > > text in Section 4 seems to be meant as mandatory but there is almost > no > > RFC 2119 language. >=20 > ...FB: We fixed this in the most recent version, and used RFC 2119 > throughout the document. >=20 > > - Is the DNCA able to allocate 2 consecutive transport ports? This is > > sometimes required by legacy RTP/RTCP applications. >=20 > ...FB: We've updated DNCA to allow for this use (which is also a MIDCOM > requirement). This is now reflected with a new AVP: >=20 > 8.7.10. NAT-External-Port-Style AVP >=20 > The NAT-External-Port-Style AVP (AVP Code TBD) is of type Enumerated > and contains the style to be followed while selecting the external > port for a NAT-Binding relative to the internal port. >=20 > The following values are defined: >=20 > FOLLOW_INTERNAL_PORT_STYLE (1) >=20 > External port numbers selected MUST follow the same sequence > and oddity as the internal ports of the NAT-bindings. The port > odditity is required to support protocols like RTP and RTCP as > defined in [RFC3550]. If for example the internal port in a > requested NAT-binding is odd numbered then the external port > allocated MUST also be odd numbered, and vice versa for an even > numbered port. In addition, the sequence of port numbering is > maintained: If internal ports are consecutive, then the NAT- > device MUST choose consecutive external ports for the NAT- > bindings. >=20 > > > > * Detailed review > > - Section 1, 1st paragraph, a nit: > > "... in their networks to deal with the depletion of available public > > IPv4 Addresses". This is one reason out of many. NATs are around for > > 10+ years, i.e., way before we were about to run out of IPv4 > addresses. >=20 > ...FB: Agreed. Current text no longer mentions this as exclusive, but > makes this a key example: >=20 > [..] > Internet service providers deploy Network Address Translators (NATs) > and Network Address and Port Translators (NAPTs) [RFC3022] in their > networks. A key motivation for doing so is the depletion of > available public IPv4 addresses. [..] >=20 > > - Section 2, and rest of the document: > > The terminology used in this draft is not well documented. There are > > NAT bindings, NAT binding rules and predefined NAT binding rules > > (templates?). However, the difference is not well documented, even > > though I understand the difference. How do you name a NAT binding > which > > is actually used by a data exchange? >=20 > ...FB: We cleaned up the language around those, and added two entries > to the abbreviation section (e.g. NAT binding rules and predefined > binding rules got consolidated into > "NAT Binding Predefined template"): >=20 > NAT-binding or binding: Association of two IP address/port pairs > (with one IP address typically being private and the other one > public) to facilitate NAT >=20 > NAT Binding Predefined template: Is a policy template or > configuration that is predefined at the NAT-device. It may > contain NAT-bindings, IP-address pools for allocating the external > IP-address of a NAT-binding, the maximum number of allowed NAT- > bindings for end-points, etc. >=20 > > - Section 3.1, page 8, 1st paragraph, "to increase the efficiency of > > the global IPv4 address pool utilization.": > > Not sure that this setting is only used for this use case. How about > > just writing: > > "Figure 2 depicts the deployment scenario where a service provider > > places a NAT between the host and the public Internet." >=20 > ...FB: Thanks. The text now reflects your suggestion. >=20 > > - It would be good to cite RFC6144-6147 for 6to4 to indicate on what > > basis the address family translation is working in this draft. The > same > > holds true for IPv4. >=20 > ...FB: The intro section now references NAT related RFCs relevant to DNCA= , > see below. What I'm not sure about is why you refer to 6to4 (which > would be RFC3056) - which I don't really see applicable to DNCA > (because there is no translation in 6to4, just tunneling). >=20 > Internet service providers deploy Network Address Translators (NATs) > and Network Address and Port Translators (NAPTs) [RFC3022] in their > networks. A key motivation for doing so is the depletion of > available public IPv4 addresses. This document defines a Diameter > application allowing providers to control the behavior of NAT and > NAPT devices that implement IPv4-to-IPv4 network address and port > translation [RFC2663] as well as stateful IPv6-to-IPv4 address family > translation translation as defined in [RFC2663], [RFC6145], and > [RFC6146]. The use of a Diameter application allows for simple > integration into the existing Authentication, Authorization and > Accounting (AAA) environment of a provider. >=20 >=20 >=20 > > - IPv6 to IPv4 translation: I was not able to figure out how such a > > signaling would be. There are no examples for this or guidance at all. > > - IPv4 to IPv4 translation: It would be good to have one or some few > > examples to see how such DNCA messages would look like. >=20 > ...FB: We've created an entire new section (section 13) showing > examples for several uses of DNCA. There are no real differences > wrt/ signaling between IPv6 and IPv4. The only real difference is > that you'd either define an internal IPv4 or IPv6 address using > a respective AVP. >=20 > > - All figures: The figures are not especially meaningful for the > reader > > and do not help in my opinion to understand the protocol, but do not > > hamper understanding either. > > - Section 4.2, page 15, last bullet point starting with "If a NCR > > redfines...": > > This touches a critical point of what happens if the new number of > > allowed bindings is lower than the prior selected number of allowed > > bindings. The text is not giving a good guidance of what should happen > > in this case and I see it a weak point to let this open to the > > discretion of the implementation. For a good specification I would at > > least expect a RECOMMENDATION or SHOULD, better a MUST. However, this > > comment relates to the lack of RFC 2119 language in this section. >=20 > ...FB: Agreed. We've updated the bullet using a SHOULD recommendation: >=20 > o If an NCR redefines the maximum number of NAT-bindings allowed for > the endpoint, the new value MUST override any previously defined > limit on NAT bindings. It depends on the implementation of the > NAT-device on how the NAT-device copes with a case where the new > value is lower than the actual number of allocated bindings. The > NAT-device SHOULD refrain from enforcing the new limit immediately > (that is, actively remove bindings), but rather disallows the > establishment of new bindings until the current number of bindings > is lower than the newly established maximum number of allowed > bindings. >=20 > > - Section 4.2, page 16, bullet point "If a NCR specifies a new...": > > What happens in this case with already binding rules which are > > installed and actively used by a data session? Is the data session > > stopped and the binding removed? >=20 > ...FB: We've clarified this by stating that a change of templates should > not impact existing sessions: >=20 > o If an NCR specifies a new NAT Binding Predefined template on the > NAT-device, the NAT Binding Predefined template overrides any > previously defined rule for the session. Existing NAT-bindings > SHOULD NOT be impacted by the change of templates. >=20 > > - Section 4.3, page 17, bullet "2. Retrieve...": > > How does the DNCA peer with the NAT controller know about the > available > > external IP addresses at the NAT? This is not clear to me. Is this a > > feature of another DIAMETER application or is it assumed that the > > controller just knows this somehow? >=20 > ..FB: The NAT-Controller will know this information via > configuration and/or through interaction with the overall OSS/BSS > systems. More specifically, it is not a feature of DNCA. >=20 > > - Section 4.4, 1st paragraph, "In response, the DNCA...": > > I cannot understand this sentence. >=20 > ...FB: We're did a bit of editing on section 4.4 to now be more > understandable: >=20 > 4.4. Session Termination >=20 > Similar to session initiation, session tear down MUST be initiated by > the DNCA Diameter peer within the NAT-controller. The DNCA Diameter > peer sends a Session Terminate Request (STR) message to its peer > within the NAT-device upon receiving a trigger signal. The source of > the trigger signal is outside the scope of this document. As part of > STR message processing the DNCA Diameter peer within the NAT-device > MAY send an accounting stop record reporting all bindings. All the > NAT-bindings belonging to the session MUST be removed and the session > state MUST be cleaned up. The DNCA Diameter peer within the NAT- > device MUST notify its DNCA Diameter peer in the NAT-controller about > successful session termination using a Session Terminate Answer (STA) > message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the > protocol interaction between the two DNCA Diameter peers. >=20 > If a DNCA Diameter peer within a NAT-device receives a STR and fails > to find a matching session, the DNCA Diameter peer MUST return a STA > with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. >=20 > > - Figure 8: The text belonging to this figure does not mention that > the > > NAT bindings MUST be removed if the STR is received. This is only > shown > > in the figure. The text seems to be incomplete and also lacking RFC > > 2119 language. >=20 > ...FB: In order to avoid inconsistencies as well as redundancies > between figures and text, we've simplified the figures and expanded > the text where necessary. The first paragraph of section 4.4. > now reads: >=20 > Similar to session initiation, session tear down MUST be initiated by > the DNCA Diameter peer within the NAT-controller. The DNCA Diameter > peer sends a Session Terminate Request (STR) message to its peer > within the NAT-device upon receiving a trigger signal. The source of > the trigger signal is outside the scope of this document. As part of > STR message processing the DNCA Diameter peer within the NAT-device > MAY send an accounting stop record reporting all bindings. All the > NAT-bindings belonging to the session MUST be removed and the session > state MUST be cleaned up. The DNCA Diameter peer within the NAT- > device MUST notify its DNCA Diameter peer in the NAT-controller about > successful session termination using a Session Terminate Answer (STA) > message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the > protocol interaction between the two DNCA Diameter peers. >=20 > > - Section 4.6, 1st paragraph: What is the redundancy support mentioned > > there which is mandatory? Something which is a MUST must be well > > documented. I cannot see this here. >=20 > ...FB: Agreed that asking for "some redundancy mechanism" but not > specifying it is confusing at least. Given that state recovery > of Diameter peers is not touched upon in other Diameter applications, > we decided after discussion with the DIME chairs to remove > references to redundancy mechanisms altogether from the document: >=20 > 4.6. Failure cases of the DNCA Diameter peers >=20 > This document does not specify the behavior in case the NAT-device > and NAT-controller, or their respective DNCA Diameter peers are out > of sync or lose state. >=20 > > - IANA section and IANA points in text: > > The use of TBD throughout the draft for IANA code-points and also in > > the IANA section is harmful for IANA and also for the draft at best. > > Why are you not using meaningful identifiers for code-points and > > reference them in the IANA section? The use of generic TBD > placeholders > > will just create confusion for IANA and for you. >=20 > ...FB: Per Miguel Garcia's note, IANA seems to understand what is > required. >=20 > > - Section 6.1 and 6.2: I was surprise to see the list of parameters > > which can be included in requests and responses, after reading Section > > 4, where those parameters are omitted. Given all these parameters and > > the lack of explanation in the draft, it seems to be hard for an > > implementer to get the link between Section 4 and this. This needs > > further explanation in the draft, see also my comment about how IPv6 > to > > IPv4 translation works and about the missing usage examples. >=20 > ...FB: Per what I stated above, we've added an entire section 13 to > show several examples. In addition, we've added text to section 6 and > 8 to make things hopefully easier to understand. >=20 > > - Section 8.x, broken labels of the tables: > > The figures in Section 8.x are actually tables, i.e., their > description > > is incorrect and broken. >=20 > ...FB: We're using tables now :-). >=20 > > - Section 8.5, Figure 13, "Reused QoS-attributes": > > Why are the AVP codes set to TBD if they are taken from RFC 5777? > E.g., > > Direction AVP (AVP Code 514) but not TBD! >=20 > ...FB: Good catch. We've updated the table accordingly. >=20 > Best regards, Frank >=20 > > > > > > Kind regards > > > > Martin Stiemerling > > > > martin.stiemerling@neclab.eu > > > > NEC Laboratories Europe - Network Research Division NEC Europe Limited > > | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > > Registered in England 2832014 > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Wed Sep 14 20:10:39 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E83F21F8A57; Wed, 14 Sep 2011 20:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT7gUVLU-Wkx; Wed, 14 Sep 2011 20:10:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A4821F873A; Wed, 14 Sep 2011 20:10:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110915031039.28869.6822.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 20:10:39 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 03:10:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions W= orking Group of the IETF. Title : Diameter Support for Proxy Mobile IPv6 Localized Routing Author(s) : Glen Zorn Qin Wu Marco Liebsch Jouni Korhonen Filename : draft-ietf-dime-pmip6-lr-06.txt Pages : 18 Date : 2011-09-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 ro= uted directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-06.txt From bill.wu@huawei.com Wed Sep 14 20:23:02 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60ED21F8744 for ; Wed, 14 Sep 2011 20:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 tagged_above=-999 required=5 tests=[AWL=1.381, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJRVVLkKu5bu for ; Wed, 14 Sep 2011 20:23:02 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8D21F8A70 for ; Wed, 14 Sep 2011 20:23:01 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ00819O5WFQ@szxga05-in.huawei.com> for dime@ietf.org; Thu, 15 Sep 2011 11:25:08 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRJ005GTO5H57@szxga05-in.huawei.com> for dime@ietf.org; Thu, 15 Sep 2011 11:25:08 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADZ16095; Thu, 15 Sep 2011 11:25:08 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 11:25:03 +0800 Received: from w53375q (10.138.41.130) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 11:25:05 +0800 Date: Thu, 15 Sep 2011 11:25:04 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: dime@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected Subject: [Dime] New version of draft-ietf-dime-pmip6-lr //Fw: I-D Action: draft-ietf-dime-pmip6-lr-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 03:23:03 -0000 This has minor fixes Jouni pointed out a few days ago. We are not aware of any remaining open issue and the draft should be ready for the chairs' review and moving forward. Diff: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dime-pmip6-lr-06.txt Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Thursday, September 15, 2011 11:10 AM Subject: [Dime] I-D Action: draft-ietf-dime-pmip6-lr-06.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) : Glen Zorn > Qin Wu > Marco Liebsch > Jouni Korhonen > Filename : draft-ietf-dime-pmip6-lr-06.txt > Pages : 18 > Date : 2011-09-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 between an MN's MAG and the MAG of its Correspondent Node > (CN) without involving any LMA. In order to establish a localized > routing session between two Mobile Access Gateways in a Proxy Mobile > IPv6 domain, two tasks must be accomplished: > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dime-pmip6-lr-06.txt > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From glenn@aaa.lucent.com Wed Sep 14 22:02:50 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE3221F8696 for ; Wed, 14 Sep 2011 22:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8hoCqUOVnok for ; Wed, 14 Sep 2011 22:02:50 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4AF21F85CE for ; Wed, 14 Sep 2011 22:02:49 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8F54w9A001097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Sep 2011 00:04:58 -0500 (CDT) Received: from hal.8950aaa.com (phil.aaa.lucent.com [135.140.160.4]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8F54tMU005283 for ; Thu, 15 Sep 2011 00:04:55 -0500 Received: from [127.0.0.1] (wolf.8950aaa.com [192.168.0.67]) by hal.8950aaa.com (Postfix) with ESMTP id 9718E22EF for ; Wed, 14 Sep 2011 22:04:54 -0700 (PDT) Message-ID: <4E718770.1050403@aaa.lucent.com> Date: Wed, 14 Sep 2011 22:04:48 -0700 From: Glenn Mcgregor Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [Dime] 3588bis-29 nit - section 3.3 example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 05:02:51 -0000 The example given in section 3.3 uses Session-Terminate-Request and Session-Terminate-Answer. Perhaps Session-Termination-xxxx was desired? Glenn McGregor Alcatel-Lucent From jouni.nospam@gmail.com Fri Sep 16 03:03:51 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F390021F8B8C for ; Fri, 16 Sep 2011 03:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz8F9fLyuEcw for ; Fri, 16 Sep 2011 03:03:50 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38C4521F8B8A for ; Fri, 16 Sep 2011 03:03:50 -0700 (PDT) Received: by bkaq10 with SMTP id q10so3641674bka.31 for ; Fri, 16 Sep 2011 03:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=fasHkvEpPTFJC9o8gOlQKiTEM0Evendt/Z5JemiHr+8=; b=lYXM/g87xatS/SngvIJ9bJWdHb8PfjM2vwsBsh8btnjFQ44qQEYnnyx4Z6P2G03jMi 8R7wTQRJfpn63JLYHh3kOh7MhvuPguLAyBNOrT0FAJs46ODPrCylaM5nk33IOj3n51Zc IJRGJ29w+AQ4wUgMiEb2eLEcP8DrQbQOX3MZw= Received: by 10.204.9.201 with SMTP id m9mr1479644bkm.308.1316167562363; Fri, 16 Sep 2011 03:06:02 -0700 (PDT) Received: from [192.168.2.88] (ip202-115.seclan.com. [81.19.115.202]) by mx.google.com with ESMTPS id z9sm5910545bkn.7.2011.09.16.03.06.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 03:06:01 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Sep 2011 13:05:59 +0300 Message-Id: <9DF4D05C-A857-42D1-842F-918284ED14CC@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: [Dime] WGLC for draft-ietf-dime-pmip6-lr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 10:03:51 -0000 Folks, This email starts (yet another) short one week WGLC for = draft-ietf-dime-pmip6-lr-06 due to non-editorial changes since -06. See = diff = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dime-p= mip6-lr-06.txt The WGLC ends 23:59 CET+1 on Friday 23-Sep-2011. Please provide your = comments, if any, to the list and write them up into the issue tracker. - Jouni & Lionel=20= From xiayangsong@huawei.com Mon Sep 19 09:58:50 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8B421F8C51 for ; Mon, 19 Sep 2011 09:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKKsxD6SzdHz for ; Mon, 19 Sep 2011 09:58:50 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6267421F8C50 for ; Mon, 19 Sep 2011 09:58:50 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS00MYH4M1VU@usaga04-in.huawei.com> for dime@ietf.org; Mon, 19 Sep 2011 12:01:13 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS0092Y4LWEN@usaga04-in.huawei.com> for dime@ietf.org; Mon, 19 Sep 2011 12:01:13 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 10:01:06 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.103]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 10:01:04 -0700 Date: Mon, 19 Sep 2011 17:01:04 +0000 From: xiayangsong In-reply-to: <6CFBF38F356D4B699638A77D4564DAB2@china.huawei.com> X-Originating-IP: [10.193.217.91] To: "jouni.nospam@gmail.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Dime] WGLC for draft-ietf-dime-pmip6-lr-06 Thread-index: AQHMdnQufWZiYAIiXUqmCneHr9JH35VU7ZPw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6CFBF38F356D4B699638A77D4564DAB2@china.huawei.com> Cc: "dime@ietf.org" Subject: Re: [Dime] WGLC for draft-ietf-dime-pmip6-lr-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 16:58:51 -0000 Hi Folks I think the draft is ready to move on. BR Frank ----- Original Message ----- From: "jouni korhonen" To: Cc: Sent: Friday, September 16, 2011 6:05 PM Subject: [Dime] WGLC for draft-ietf-dime-pmip6-lr-06 > Folks, > > This email starts (yet another) short one week WGLC for draft-ietf-dime-pmip6-lr-06 due to non-editorial changes since -06. See diff http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dime-pmip6-lr-06.txt > > The WGLC ends 23:59 CET+1 on Friday 23-Sep-2011. Please provide your comments, if any, to the list and write them up into the issue tracker. > > - Jouni & Lionel > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Mon Sep 26 05:39:14 2011 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406F721F8BF6 for ; Mon, 26 Sep 2011 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.39 X-Spam-Level: X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6+w30nyJ7f6 for ; Mon, 26 Sep 2011 05:39:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD621F8BE4 for ; Mon, 26 Sep 2011 05:39:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHAKVxgE7GmAcF/2dsb2JhbABBmUyOQniBVQEBAxIeClEBFRUGDAwHVwEEGxMHokKEDwKae4YrYASZE4t0 X-IronPort-AV: E=Sophos;i="4.68,444,1312171200"; d="scan'208";a="269764344" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Sep 2011 08:41:47 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Sep 2011 08:40:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 14:41:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-rfc3588bis-29 Thread-Index: Acx8SaaY+OYo+0gYRSWqtE0wuTQbfw== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] draft-ietf-dime-rfc3588bis-29 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 12:39:14 -0000 The I-D draft-ietf-dime-rfc3588bis-29 was discussed in the IESG telechat on 9/23. As expected it was not approved, as there are a number of DISCUSSes and COMMENTs raised by some of the IESG members. The document is now in the Revised-ID Needed status, and the editors and the shepherd need to work in order to address the issues raised by the ADs and suggest solutions. Thanks and Regards, Dan