From bpatil1@gmail.com Thu Sep 12 13:28:55 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19AD11E81DF for ; Thu, 12 Sep 2013 13:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 8hwfHNc14bT0 for ; Thu, 12 Sep 2013 13:28:55 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2EA11E80EE for ; Thu, 12 Sep 2013 13:28:55 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so341878oag.26 for ; Thu, 12 Sep 2013 13:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0U6VwSuKQWhjRxyMBJ21Ev3CbP830XJuD9BLtbViyw0=; b=TmixxalxhmYwLkFrFez+RVdyJkabvdKQHGrP1jEL44KBdN5ay6MzTApYV4Ly5NyK4c Y7iVXAm3gMntNKfoj6wJb/A5ItDxSR+KAH03sNswdBSKfAMz5C0CgbY74YfcpqF/H9xm ol1VFZJst7t1gRmtjELJYUfBdJGdid6Ib31YjJ+WmgqvawMoDWOLJ2Urv/SD6Qry2rjf jB1/fE/JYQum9wQVVbf2MvpcpyJ5JjexHB0VygPent/lq/JrWBxvbspP3DxI0c/hl04h R+E44wGn2GBZV1ezI/KmOyD6IEyjCaWjXLMkimLmC/oAM/JehmGDvSxtOjw1W8ITVWVz AOUw== MIME-Version: 1.0 X-Received: by 10.60.117.198 with SMTP id kg6mr2855090oeb.80.1379017734668; Thu, 12 Sep 2013 13:28:54 -0700 (PDT) Received: by 10.182.75.163 with HTTP; Thu, 12 Sep 2013 13:28:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Sep 2013 15:28:54 -0500 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a99f836c5ab04e635961d Cc: draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org, "netext-chairs@tools.ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:28:56 -0000 --047d7b3a99f836c5ab04e635961d Content-Type: text/plain; charset=ISO-8859-1 The consensus call for adopting this I-D has ended. We had sufficient support at the IETF 87 WG meeting and a few emails in support of the same over the mailing list. Authors; Please post the I-D as a WG document. -Chairs On Mon, Aug 26, 2013 at 11:23 AM, Basavaraj Patil wrote: > > Hello, > > This is a consensus call to adopt the following I-D as a working group > document. The I-D was discussed at IETF87 and there was consensus at the > meeting to adopt it. > This email is a followup to allow folks who were not at the meeting to > respond as well. > > I-D: Separation of Control and User Plane for Proxy Mobile IPv6 > > draft-wakikawa-netext-pmip-cp-up-separation > > > Please respond with a Yay or Nay by September 4th, 2013. > > -Chairs > > -- Basavaraj Patil --047d7b3a99f836c5ab04e635961d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The consensus call for adopting this I-D has ende= d.
We had sufficient support at the IETF 87 WG meeting and a few = emails in support of the same over the mailing list.

Authors; Please post the I-D as a WG document.

-Ch= airs



On Mon, Aug 26, 2013 at 11:23 AM, Basavaraj Patil <bpati= l1@gmail.com> wrote:

Hello,= =A0

This is a consensus call to adopt the followin= g I-D as a working group document. The I-D was discussed at IETF87 and ther= e was consensus at the meeting to adopt it.=A0
This email is a followup to allow folks who were not at the meeting to= respond as well.

I-D: =A0Separation of Control and User Plane for Proxy Mob= ile IPv6
    draft-wakikawa-netext-pmip-cp-up-separation

<= div>Please respond with a Yay or Nay by September 4th, 2013.

-Chairs




--
Basavaraj Pa= til --047d7b3a99f836c5ab04e635961d-- From ryuji.wakikawa@gmail.com Thu Sep 12 18:31:59 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C971511E819F for ; Thu, 12 Sep 2013 18:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iIyI7Yk9hrR for ; Thu, 12 Sep 2013 18:31:59 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7D111E813F for ; Thu, 12 Sep 2013 18:31:59 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so563424pbc.15 for ; Thu, 12 Sep 2013 18:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4c+Pz8EvNmoHVsQwO0ggFB1hGPYC7bcUkFQVmz6JrU4=; b=rize12hqbKIhrmtzYrfELr7fljtEmZY7miahmA0NAfFn2g6SlDIt48h9r2D/CViqk8 5yk9PzlEDXG+PElk3yZXr/lpPXlH7no8awx2GcpK+kqKAzF3gm7dDADkBxWgplNjggkt RKGCM0RMsPuwOw8oCBmP8jnTFMGouIuY/zw46t3kpSBNWVERkK2QgZXnrd6ebRKXi5z2 7bwE4FLuaXnbd73ociG+0V9GzJ/PIrtZ4Ocz99yFWNcMfrsZhWfEZQPIvEInQV0ORFc2 +A816LkUD9mSEdocCSDSBhWf7NeRZ3AQS1WXRXU5SIzvif3mH6b8O+H1sWrVzLxKw4S2 xl/A== X-Received: by 10.66.26.112 with SMTP id k16mr12350936pag.65.1379035919017; Thu, 12 Sep 2013 18:31:59 -0700 (PDT) Received: from [192.168.2.46] (122x216x203x186.ap122.ftth.ucom.ne.jp. [122.216.203.186]) by mx.google.com with ESMTPSA id wd6sm14090377pab.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 18:31:57 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ryuji Wakikawa In-Reply-To: Date: Fri, 13 Sep 2013 10:31:56 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <50F80510-CDFB-4264-8444-65DBF0675483@gmail.com> References: To: Basavaraj Patil X-Mailer: Apple Mail (2.1508) Cc: "netext@ietf.org" , draft-wakikawa-netext-pmip-cp-up-separation@tools.ietf.org, "netext-chairs@tools.ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-wakikawa-netext-pmip-cp-up-separation X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 01:31:59 -0000 Thanks Raj and all I will submit the draft as WG document. regards, ryuji On Sep 13, 2013, at 5:28 AM, Basavaraj Patil wrote: >=20 > The consensus call for adopting this I-D has ended. > We had sufficient support at the IETF 87 WG meeting and a few emails = in support of the same over the mailing list. >=20 > Authors; Please post the I-D as a WG document. >=20 > -Chairs >=20 >=20 >=20 > On Mon, Aug 26, 2013 at 11:23 AM, Basavaraj Patil = wrote: >=20 > Hello,=20 >=20 > This is a consensus call to adopt the following I-D as a working group = document. The I-D was discussed at IETF87 and there was consensus at the = meeting to adopt it.=20 > This email is a followup to allow folks who were not at the meeting to = respond as well. >=20 > I-D: Separation of Control and User Plane for Proxy Mobile IPv6 > draft-wakikawa-netext-pmip-cp-up-separation >=20 > Please respond with a Yay or Nay by September 4th, 2013. >=20 > -Chairs >=20 >=20 >=20 >=20 > --=20 > Basavaraj Patil > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From John.Kaippallimalil@huawei.com Fri Sep 13 07:57:35 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A21521E80D0 for ; Fri, 13 Sep 2013 07:57:35 -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 VrtKOZE7z-L9 for ; Fri, 13 Sep 2013 07:57:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A02B721E80AD for ; Fri, 13 Sep 2013 07:57:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXH35049; Fri, 13 Sep 2013 14:57:24 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 15:57:03 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 15:57:20 +0100 Received: from DFWEML511-MBB.china.huawei.com ([169.254.4.189]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 07:57:14 -0700 From: John Kaippallimalil To: "liebsch@neclab.eu" , "pierrick.seite@orange.com" , "yokota@kddilabs.jp" , "jouni.nospam@gmail.com" , "Sri Gundavelli (sgundave)" Thread-Topic: [netext] draft-ietf-netext-pmip6-qos-03 Thread-Index: Ac6wkYeZhEjuaLqrTnCIQZjZIVR69g== Date: Fri, 13 Sep 2013 14:57:13 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA11725DA07@dfweml511-mbb.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "netext@ietf.org" Subject: [netext] draft-ietf-netext-pmip6-qos-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 14:57:35 -0000 Hi, My comments on draft-ietf-netext-pmip6-qos-03. Overall, I think the draft i= s in very good condition and these comments should be relatively easy to co= nsider. John Comments: -- 01) chapter 1. Introduction Last para explains some details on how the parameters in PMIP QoS apply. E.= g.,to mobile node, mobility session or per flow, etc. Also, in section 3.5,= it is stated that, "....at minimum there is a need to convey the following= additional QoS parameters ....". On the other hand, some dynamic parameters from PCF (e.g. revised QCI, PDB)= are not conveyed at this time. Any guidance on what parameters can be considered/should not be considered = in future? It would be good to add a sentence or so in chapter 1 on the basis the para= meters were selected, and where it can be used: - is it to establish parity with GTP?=20 - required by MAG/router for enforcing QoS on IP path between MAG and LMA? - QoS in a radio access network, backhaul? - or some other basis? 02) chapter 2.2 Terminology=20 Add Policy Control Function (PCF), relation to PMIP QoS, reference to 23.20= 3? + Add text on Mobility Session, relation to IP flow 03) chapter 3.1. Technical Scope and Procedure "Non-cellular access techno= logies are not yet considered for per-flow QoS policing under control of a common PCF. ....." Is this sentence needed? Maybe confusing since TS 23.402 section 16.x consi= ders WLAN and mobile network including session continuity and uses existing= GTP mechanisms (QoS between TWAG (~MAG) and PGW (~LMA). 04) chapter 3.4. Use Case C -- Dynamic Update to QoS Policy "..The applica= tion on the mobile node initiates the communications via a dedicated network function (e.g. IMS Call Session Control Function). Once the communication is established, the application network function notifies the PCRF function about the new IP flow. The PCRF function in turn notifies the LMA about the needed QoS parameters identifying the IP flow and QoS parameters. LMA sends a Update Notification message [I-D.ietf-netext-update-notifications] to the MAG with the "Notification Reason" value set to "Force REREGISTER"..... 4A) PCRF - new term for Policy server introduced. Maybe better to stick wit= h PCF, or explain the term PCRF. 4B) UPDATE-SESSION-PARAMETERS for Notification Reason seems like a better c= hoice in this case. 4C)This example shows a model where policy updates are "pushed". In some ca= ses, such as for WiFi networks, it may be better for the MN to trigger the = sequence and have the policy "pulled" from the policy node - as in chapter = 3.6 where the MN is "pulling" policy. In chapter 4, where the MAG (4.1) and LMA (4.2) behavior is described, the = behavior describes the "pushing" of policy. Currently missing behavior to d= escribe, for example the MAG encoding QoS Attribute in PBU to LMA, or how t= he LMA is encodes PBA if it receives a PBU with QoS attribute. 05) chapter 3.5. Relevant QoS Attributes " This is the GSMA/3GPP mapping for EPC/LTE: QCI Traffic Class DiffServ PHB DSCP 1 Conversational EF 101110 2 Conversational EF 101110 3 Conversational EF 101110 4 Streaming AF41 100010 5 Interactive AF31 011010 6 Interactive AF32 011100 (Not approved) ......." AF32 is now included in GSMA IR.34 version 9.1. 06) 10.2. Informative References Revise GSMA IR 34 reference to latest: [GSMA.IR.34] Guidelines for IPX Provider networks (Previously Inter-Service= Provider IP Backbone Guidelines Version 9.1, May 2013. From internet-drafts@ietf.org Sun Sep 22 13:42:40 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408C021F9CC8; Sun, 22 Sep 2013 13:42:40 -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.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf9W2KrzoL9V; Sun, 22 Sep 2013 13:42:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C84C021F9CC0; Sun, 22 Sep 2013 13:42: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: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130922204239.20496.14761.idtracker@ietfa.amsl.com> Date: Sun, 22 Sep 2013 13:42:39 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 20:42:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Separation of Control and User Plane for Proxy Mobile IP= v6 Author(s) : Ryuji Wakikawa Charles E. Perkins Rajesh S. Pazhyannur Sri Gundavelli Filename : draft-ietf-netext-pmip-cp-up-separation-00.txt Pages : 7 Date : 2013-09-19 Abstract: This document describes splitting of Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a MAG to perform splitting of its control and user plane using Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not have semantics for allowing the LMA to perform such functional split. To realize this requirement, this specification defines a mobility option that enables a local mobility anchor to provide an alternate LMA address to be used for the bi-directional tunnel between the MAG and LMA. With this extension, a local mobility anchor will be able to use an IP address for its user plane which is different than what is used for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stephen.farrell@cs.tcd.ie Tue Sep 24 03:38:21 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F8621F9D19; Tue, 24 Sep 2013 03:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HnxNsmov8YD; Tue, 24 Sep 2013 03:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6263C11E80DE; Tue, 24 Sep 2013 03:38:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130924103819.29616.21400.idtracker@ietfa.amsl.com> Date: Tue, 24 Sep 2013 03:38:19 -0700 Cc: netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:38:21 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netext-update-notifications-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 5.2: What happens if the IPsec SA is re-negotiated automatically? Isn't there a potential layering/sync problem so that these notifications couldn't ever be verified since a new SA would be in use? I think you just need to say the same or an automatically renegotiated SA (not sure what's the right terminology, sorry). I think 6.1 has the same issue and maybe other bits too. That kind of check also seems to imply that the interface between the MAG or LMA and the IPsec code needs to know that the right SA is being used which could be tricky. What's really done here? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons need an explanation and/or (forward) reference. From sgundave@cisco.com Tue Sep 24 05:53:13 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964BD11E811F; Tue, 24 Sep 2013 05:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvaTZ5+nwDsS; Tue, 24 Sep 2013 05:53:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9883B11E8120; Tue, 24 Sep 2013 05:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3132; q=dns/txt; s=iport; t=1380027188; x=1381236788; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kawV55WWh0n+EhsO8coSqYzHfHNPDLD+mIV8Pl3J1Xs=; b=fPs21/v8hGvMSLvYDhB/+XFUbBbdKh4eoLAy4HZfo7b7p4yq7eh/ld6v MGOKESBjGSK8rKIDhTxmQebKkJ821rjxzB7xI1Ac+V/N6RupZOH+7ve6j YkrXWtj1hmUdELJGdn11Ijbqa9oMfLjtYpT2szzrwSqLW1F7MU0HOaUlx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAIqKQVKtJV2b/2dsb2JhbABagwc4UsBQgR8WdIIlAQEBAwE6PQIFDQEIIhQFPSUCBAENBQgBh3YGDLx5jgiBGDECBYMdgQADmSuQSIFmgT6BagcXBhw X-IronPort-AV: E=Sophos;i="4.90,970,1371081600"; d="scan'208";a="263788651" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 24 Sep 2013 12:53:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8OCr79S001092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 12:53:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.174]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 07:53:07 -0500 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) Thread-Index: AQHOuSUD72u2CSfM6UK8YmdDgylKOA== Date: Tue, 24 Sep 2013 12:53:06 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com> In-Reply-To: <20130924103819.29616.21400.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <673D4B2E9CF68641884B0DD4B08DC390@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "draft-ietf-netext-update-notifications@tools.ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:53:13 -0000 Hi Stephen, Thanks for the reviews. > 5.2: What happens if the IPsec SA is re-negotiated Renegotiation of IPSec SA should result in updated SPD and PAD entries at both the peers. Wondering, if MAG/LMA entities need to be aware of this, or assume IKEv2/IPsec layer is handling that. SA Renegotiation could potentially occur in the base protocol without this extension as well. I'm thinking, as long as the SPD entries cover the new MH type, the handling/validation is happening at the correct layers and no new checks are needed.=20 > - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons >need an explanation and/or (forward) reference. This is a request for updated Access Network Identifier parameters. Section 6.1 has some text for each of the NR codes. * If the Notification Reason is set to a value of (4) "ANI- PARAMS-REQUESTED", then the mobile access gateway MUST send a Proxy Binding Update message to the local mobility anchor with the Access Network Identifier Option [RFC6757 ]. The Access Network Identifier option MUST reflect the current access network parameters for that mobility session as known to the mobile access gateway at the time of sending the Proxy Binding Update message. Regards Sri On 9/24/13 3:38 AM, "Stephen Farrell" wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-netext-update-notifications-08: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > > >5.2: What happens if the IPsec SA is re-negotiated >automatically? Isn't there a potential layering/sync problem >so that these notifications couldn't ever be verified since a >new SA would be in use? I think you just need to say the same >or an automatically renegotiated SA (not sure what's the >right terminology, sorry). I think 6.1 has the same issue and >maybe other bits too. That kind of check also seems to >imply that the interface between the MAG or LMA and the >IPsec code needs to know that the right SA is being used >which could be tricky. What's really done here? > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all >these reasons need an explanation and/or (forward) reference. > > From stephen.farrell@cs.tcd.ie Tue Sep 24 05:56:48 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8218011E812A; Tue, 24 Sep 2013 05:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 JMhqpvBfqHNR; Tue, 24 Sep 2013 05:56:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF72B11E811F; Tue, 24 Sep 2013 05:56:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F5FFBE57; Tue, 24 Sep 2013 13:56:27 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89wV5ETn9V0L; Tue, 24 Sep 2013 13:56:27 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A836BE47; Tue, 24 Sep 2013 13:56:27 +0100 (IST) Message-ID: <52418BFB.4050108@cs.tcd.ie> Date: Tue, 24 Sep 2013 13:56:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , The IESG References: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com> In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , "draft-ietf-netext-update-notifications@tools.ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:56:48 -0000 Hiya, On 09/24/2013 01:53 PM, Sri Gundavelli (sgundave) wrote: > Hi Stephen, > > Thanks for the reviews. > > >> 5.2: What happens if the IPsec SA is re-negotiated > > Renegotiation of IPSec SA should result in updated SPD and PAD entries at > both the peers. Wondering, if MAG/LMA entities need to be aware of this, > or assume IKEv2/IPsec layer is handling that. SA Renegotiation could > potentially occur in the base protocol without this extension as well. I'm > thinking, as long as the SPD entries cover the new MH type, the > handling/validation is happening at the correct layers and no new checks > are needed. Perhaps those checks are already needed. What is currently done in implementations? But is the current text about "same SA" correct? I don't recall such text in the base spec, but maybe its there. And presumably re-negotiation is more likely when pushing notifications. S. > > > > >> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons >> need an explanation and/or (forward) reference. > > > This is a request for updated Access Network Identifier parameters. > Section 6.1 has some text for each of the NR codes. > > * If the Notification Reason is set to a value of (4) "ANI- > PARAMS-REQUESTED", then the mobile access gateway MUST send a > Proxy Binding Update message to the local mobility anchor with > the Access Network Identifier Option [RFC6757 > ]. The Access > Network Identifier option MUST reflect the current access > network parameters for that mobility session as known to the > mobile access gateway at the time of sending the Proxy Binding > Update message. > > > > > > Regards > Sri > > > > On 9/24/13 3:38 AM, "Stephen Farrell" wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-netext-update-notifications-08: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> 5.2: What happens if the IPsec SA is re-negotiated >> automatically? Isn't there a potential layering/sync problem >> so that these notifications couldn't ever be verified since a >> new SA would be in use? I think you just need to say the same >> or an automatically renegotiated SA (not sure what's the >> right terminology, sorry). I think 6.1 has the same issue and >> maybe other bits too. That kind of check also seems to >> imply that the interface between the MAG or LMA and the >> IPsec code needs to know that the right SA is being used >> which could be tricky. What's really done here? >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all >> these reasons need an explanation and/or (forward) reference. >> >> > From sgundave@cisco.com Tue Sep 24 06:27:50 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1721E11E8122; Tue, 24 Sep 2013 06:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pn4sGvHcU20; Tue, 24 Sep 2013 06:27:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6386311E811E; Tue, 24 Sep 2013 06:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1436; q=dns/txt; s=iport; t=1380029264; x=1381238864; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+PHAdeyapithEVv5eYTNjk1kalxgM1xBX4a/tQSd7Wg=; b=Cxn/ID5NzrOJd8eB62KYXYCWLDMoYsiPBg9qlIMzxkA1bVLpVRDKCI0F 4VHB3dJ6Mq3dXwPCndBKAp4fEtd96jiw88w3n+9s+d6zvkzRwwDaO8BVw KXvu3R3DkD8f3Xp2pG386ng00ouGyg08d+ktmsHSm19Evw5lgUwgq5NiA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFALySQVKtJXHB/2dsb2JhbABagweBCsBPgR0WdIIlAQEBBHcCEgEIGAoZPSUCBAENBQiHfb0VjyAxB4MdgQADqXOBZoE+gWokHA X-IronPort-AV: E=Sophos;i="4.90,970,1371081600"; d="scan'208";a="263807753" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 24 Sep 2013 13:27:44 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8ODRhVw011576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 13:27:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.174]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 08:27:43 -0500 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) Thread-Index: AQHOuSnZF13R9nrGG0696RVYFVYAZQ== Date: Tue, 24 Sep 2013 13:27:43 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81172A1FD@xmb-aln-x03.cisco.com> In-Reply-To: <52418BFB.4050108@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "draft-ietf-netext-update-notifications@tools.ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 13:27:50 -0000 Stephen, On 9/24/13 5:56 AM, "Stephen Farrell" wrote: > >Hiya, > >On 09/24/2013 01:53 PM, Sri Gundavelli (sgundave) wrote: >>Hi Stephen, >>Thanks for the reviews. >>>5.2: What happens if the IPsec SA is re-negotiated >>Renegotiation of IPSec SA should result in updated SPD and PAD entries at >>both the peers. Wondering, if MAG/LMA entities need to be aware of this, >>or assume IKEv2/IPsec layer is handling that. SA Renegotiation could >>potentially occur in the base protocol without this extension as well. >>I'm >>thinking, as long as the SPD entries cover the new MH type, the >>handling/validation is happening at the correct layers and no new checks >>are needed. > >Perhaps those checks are already needed. What is currently done >in implementations? Not beyond ensuring that the MH message that made it to the MIP layer had IPSec protection. There are no special interactions between MIP and IPsec layer, at least not in PMIP. For CMIP, there is lot of dance in 5555, for supporting NAT traversal=8Athere they both almost live together ... > >But is the current text about "same SA" correct? I don't recall >such text in the base spec, but maybe its there. And presumably >re-negotiation is more likely when pushing notifications. Can rephrase this to suggest, "currently established Security Association for protecting PBU/PBA =8A" Regards Sri From jouni.nospam@gmail.com Tue Sep 24 06:38:48 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F7811E8120; Tue, 24 Sep 2013 06:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xedvbm-4rQNp; Tue, 24 Sep 2013 06:38:45 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5793511E8137; Tue, 24 Sep 2013 06:38:40 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so3754920lbi.36 for ; Tue, 24 Sep 2013 06:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3LzN6pTKv6uUaQL1FZ9N1V3RKboRhWhpMOE3Y5fXVTw=; b=L/Ib1Z66YhUiwHuRtSsfwDJZGGocEPAZmyV8giAPVtuccdx54p16LFySXbMlOD07Q+ KFxEqGIoh0oSPBUNj0Fy33SJo0ANrQ390kxTQmF/OdQ3Q09QoPKP0gxRFs6rSyY/XVpC 95qSiFk6XvqAW8TtCHP7ZxDH9yBNJVTY4IPJ3N1gPRKpY971QN7wMMTTY3EVzBZs3JXw eEvuq4r648R+gfORBOzOwxNsz2pyKJf5dTBwtJMlXjWLqHu2e85zZyBKlCGwGV89aLve KPodHXFToRilvgRDg+TwXVbc2Kt8rzAcTZ/dreViHeMfxMxJoXiCmECWIxRec0Uogrdr M5cw== X-Received: by 10.112.156.166 with SMTP id wf6mr24329204lbb.13.1380029919158; Tue, 24 Sep 2013 06:38:39 -0700 (PDT) Received: from [192.168.43.158] (84-230-145-25.elisa-mobile.fi. [84.230.145.25]) by mx.google.com with ESMTPSA id ua4sm15385904lbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 06:38:38 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <52418BFB.4050108@cs.tcd.ie> Date: Tue, 24 Sep 2013 16:38:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3FF53F50-B0B1-4979-91ED-06748BBC430B@gmail.com> References: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com> <52418BFB.4050108@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1510) Cc: "netext@ietf.org" , "draft-ietf-netext-update-notifications@tools.ietf.org" , The IESG , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 13:38:49 -0000 Stephen, On Sep 24, 2013, at 3:56 PM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > On 09/24/2013 01:53 PM, Sri Gundavelli (sgundave) wrote: >> Hi Stephen, >>=20 >> Thanks for the reviews. >>=20 >>=20 >>> 5.2: What happens if the IPsec SA is re-negotiated >>=20 >> Renegotiation of IPSec SA should result in updated SPD and PAD = entries at >> both the peers. Wondering, if MAG/LMA entities need to be aware of = this, >> or assume IKEv2/IPsec layer is handling that. SA Renegotiation could >> potentially occur in the base protocol without this extension as = well. I'm >> thinking, as long as the SPD entries cover the new MH type, the >> handling/validation is happening at the correct layers and no new = checks >> are needed.=20 >=20 > Perhaps those checks are already needed. What is currently done > in implementations? PMIP and IPsec layers are separate. And rekeying the SA does not affect the operation nor the PMIP layer knows about it. The operation does not differ from normal IPsec behavior. - Jouni > But is the current text about "same SA" correct? I don't recall > such text in the base spec, but maybe its there. And presumably > re-negotiation is more likely when pushing notifications. >=20 > S. >=20 >>=20 >>=20 >>=20 >>=20 >>> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these = reasons >>> need an explanation and/or (forward) reference. >>=20 >>=20 >> This is a request for updated Access Network Identifier parameters. >> Section 6.1 has some text for each of the NR codes. >>=20 >> * If the Notification Reason is set to a value of (4) "ANI- >> PARAMS-REQUESTED", then the mobile access gateway MUST send a >> Proxy Binding Update message to the local mobility anchor = with >> the Access Network Identifier Option [RFC6757 >> ]. The Access >> Network Identifier option MUST reflect the current access >> network parameters for that mobility session as known to the >> mobile access gateway at the time of sending the Proxy = Binding >> Update message. >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards >> Sri >>=20 >>=20 >>=20 >> On 9/24/13 3:38 AM, "Stephen Farrell" = wrote: >>=20 >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-netext-update-notifications-08: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> = http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> 5.2: What happens if the IPsec SA is re-negotiated >>> automatically? Isn't there a potential layering/sync problem >>> so that these notifications couldn't ever be verified since a >>> new SA would be in use? I think you just need to say the same >>> or an automatically renegotiated SA (not sure what's the >>> right terminology, sorry). I think 6.1 has the same issue and >>> maybe other bits too. That kind of check also seems to >>> imply that the interface between the MAG or LMA and the >>> IPsec code needs to know that the right SA is being used >>> which could be tricky. What's really done here? >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all >>> these reasons need an explanation and/or (forward) reference. >>>=20 >>>=20 >>=20 From rjsparks@nostrum.com Tue Sep 24 10:57:41 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A649C21F8E70; Tue, 24 Sep 2013 10:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfR8chS0HnRz; Tue, 24 Sep 2013 10:57:40 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7423821F9DFB; Tue, 24 Sep 2013 10:57:23 -0700 (PDT) Received: from unnumerable.local (pool-71-170-125-188.dllstx.fios.verizon.net [71.170.125.188]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8OHvIJC003758 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 24 Sep 2013 12:57:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5241D27E.4040201@nostrum.com> Date: Tue, 24 Sep 2013 12:57:18 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Suresh Krishnan References: <521652E0.8030300@nostrum.com> <52167D67.2010103@ericsson.com> <521687CD.40502@nostrum.com> In-Reply-To: <521687CD.40502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 71.170.125.188 is authenticated by a trusted mechanism) Cc: netext@ietf.org, General Area Review Team , draft-ietf-netext-update-notifications@tools.ietf.org Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 17:57:41 -0000 Hi Suresh - It doesn't look like any of these changes made it into -08? RjS On 8/22/13 4:51 PM, Robert Sparks wrote: > On 8/22/13 4:06 PM, Suresh Krishnan wrote: >> Hi Robert, >> Thanks a lot for the review. We will include the changes in the next >> revision we submit. Please see proposed changes inline. >> >> On 08/22/2013 02:05 PM, Robert Sparks wrote: >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> . >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-netext-update-notifications-07 >>> Reviewer: Robert Sparks >>> Review Date: 2013-08-22 >>> IETF LC End Date: 2013-08-29 >>> IESG Telechat date: not scheduled >>> >>> Summary: This draft is ready for publication as Proposed Standard >>> >>> I had to read through this text several times to convince myself >>> implementers could figure out what order they were required to take >>> steps in vs where they had flexibility: >>> >>> o Upon accepting the Update Notification message, the mobile >>> access >>> gateway MUST process the message and perform the actions >>> based on >>> the Notification Reason. >>> * If the (A) flag in the message is set to a value of (1), the >>> mobile access gateway MUST first send an Update Notification >>> Acknowledgement message and set the status code field >>> according >>> to the result of processing the Update Notification message. >>> >>> In particular, it's not immediately obvious if there is tension between >>> that "MUST first" and having "the result of processing" available. >>> Please consider rewording to make it clearer that this "result of >>> processing" is not intended to include waiting for the result of some >>> action processing this notification message might trigger. >> I think we can lose the word first without losing anything. Does the >> following rewording work for you? > Yes, thanks! >> >> OLD: >> If the (A) flag in the message is set to a value of (1), the mobile >> access gateway MUST first send an Update Notification Acknowledgement >> message and set the status code field according to the result of >> processing the Update Notification message. >> >> NEW: >> If the (A) flag in the message is set to a value of (1), the mobile >> access gateway MUST send an Update Notification Acknowledgement message >> with the status code field set based on the result of processing the >> Update Notification message. >> >>> It might help readers understand the intended usual case retransmission >>> mechanics if the expected default values listed in section 7 were >>> called >>> out earlier in the document. >> Sure. Will call out the defaults at first use. >> >> Thanks >> Suresh >> > From rjsparks@nostrum.com Tue Sep 24 11:02:57 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD0E21F96DA; Tue, 24 Sep 2013 11:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSjBkLWzMc5D; Tue, 24 Sep 2013 11:02:56 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3732821F9E9D; Tue, 24 Sep 2013 11:02:55 -0700 (PDT) Received: from unnumerable.local (pool-71-170-125-188.dllstx.fios.verizon.net [71.170.125.188]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8OI2sj1004352 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 24 Sep 2013 13:02:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5241D3CE.8080206@nostrum.com> Date: Tue, 24 Sep 2013 13:02:54 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: General Area Review Team , netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org References: <521652E0.8030300@nostrum.com> In-Reply-To: <521652E0.8030300@nostrum.com> Content-Type: multipart/alternative; boundary="------------080803040207020305040206" Received-SPF: pass (shaman.nostrum.com: 71.170.125.188 is authenticated by a trusted mechanism) Subject: [netext] Gen-art telechat review: draft-ietf-netext-update-notifications-08 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:02:57 -0000 This is a multi-part message in MIME format. --------------080803040207020305040206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netext-update-notifications-08 Reviewer: Robert Sparks Review Date: 2013-09-24 IETF LC End Date: 2013-08-29 IESG Telechat date: 2013-09-26 Summary: This draft is (still) ready for publication as Proposed Standard, but there are nits the editors agreed to fix that have not yet been addressed. On 8/22/13 1:05 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-netext-update-notifications-07 > Reviewer: Robert Sparks > Review Date: 2013-08-22 > IETF LC End Date: 2013-08-29 > IESG Telechat date: not scheduled > > Summary: This draft is ready for publication as Proposed Standard > > I had to read through this text several times to convince myself > implementers could figure out what order they were required to take > steps in vs where they had flexibility: > o Upon accepting the Update Notification message, the mobile access > gateway MUST process the message and perform the actions based on > the Notification Reason. > * If the (A) flag in the message is set to a value of (1), the > mobile access gateway MUST first send an Update Notification > Acknowledgement message and set the status code field according > to the result of processing the Update Notification message. > > In particular, it's not immediately obvious if there is tension > between that "MUST first" and having "the result of processing" available. > Please consider rewording to make it clearer that this "result of > processing" is not intended to include waiting for the result of some > action processing this notification message might trigger. > > It might help readers understand the intended usual case > retransmission mechanics if the expected default values listed in > section 7 were called out earlier in the document. --------------080803040207020305040206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netext-update-notifications-08
Reviewer: Robert Sparks
Review Date: 2013-09-24
IETF LC End Date: 2013-08-29
IESG Telechat date: 2013-09-26

Summary: This draft is (still) ready for publication as Proposed Standard, but there are nits the editors agreed to fix that have not yet been addressed.

On 8/22/13 1:05 PM, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netext-update-notifications-07
Reviewer: Robert Sparks
Review Date: 2013-08-22
IETF LC End Date: 2013-08-29
IESG Telechat date: not scheduled

Summary: This draft is ready for publication as Proposed Standard

I had to read through this text several times to convince myself implementers could figure out what order they were required to take steps in vs where they had flexibility:
   o  Upon accepting the Update Notification message, the mobile access
      gateway MUST process the message and perform the actions based on
      the Notification Reason.
      *  If the (A) flag in the message is set to a value of (1), the
         mobile access gateway MUST first send an Update Notification
         Acknowledgement message and set the status code field according
         to the result of processing the Update Notification message.
In particular, it's not immediately obvious if there is tension between that "MUST first" and having "the result of processing" available.
Please consider rewording to make it clearer that this "result of processing" is not intended to include waiting for the result of some action processing this notification message might trigger.

It might help readers understand the intended usual case retransmission mechanics if the expected default values listed in section 7 were called out earlier in the document.

--------------080803040207020305040206-- From barryleiba@computer.org Wed Sep 25 12:40:33 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9384511E80E4; Wed, 25 Sep 2013 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf4DFaRcua7r; Wed, 25 Sep 2013 12:40:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E00AF11E8126; Wed, 25 Sep 2013 12:40:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130925194032.29986.2555.idtracker@ietfa.amsl.com> Date: Wed, 25 Sep 2013 12:40:32 -0700 Cc: netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Barry Leiba's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:40:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-netext-update-notifications-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Simple to resolve, and the authors are already aware of this: as raised in the IANA review, the IANA Considerations section uses the correct URI for the IANA registry in actions 1 and 2: http://www.iana.org/assignments/mobility-parameters ...but does not use the correct one for actions 3 and 4: = https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xh= tml Please change the URIs in actions 3 and 4 to match the ones in actions 1 and 2 (it doesn't matter whether they use http: or https:, but please make all four the same). From sgundave@cisco.com Wed Sep 25 21:28:33 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF05211E8140; Wed, 25 Sep 2013 21:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di0Dz0P27AUU; Wed, 25 Sep 2013 21:28:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E507B11E8136; Wed, 25 Sep 2013 21:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3214; q=dns/txt; s=iport; t=1380169709; x=1381379309; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kOlvU+v6mcwAUThsyzMSGhAIEcTXE7u+2lRv2lt8VSo=; b=KRHv+7KY1ojY8TE2kpZIHMYLwuT5HIhgFyi9HT5zCzQCc3KoIOObD/rc h6iYctYQWFIk8UMAPHViRjRDaGsTi8q1ywIe5vnDO7nNzAtBSplsA01Pm lHBcS0FIvXDMLUJ503yYGuhEoda7TP0kLeek5snKB8WTSL7juVmQH0tZ7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHG3Q1KtJXG//2dsb2JhbABbgwc4UsBdgSMWdIIlAQEBBDo9AhIBCA4GBAoUQiUCBAENBQiHfgy8T48gMQeDHYEBA5QfhQyQSIMkgio X-IronPort-AV: E=Sophos;i="4.90,982,1371081600"; d="scan'208";a="264599731" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2013 04:28:28 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8Q4SSwj017692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 04:28:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.174]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 23:28:27 -0500 From: "Sri Gundavelli (sgundave)" To: Robert Sparks , Suresh Krishnan Thread-Topic: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07 Thread-Index: AQHOunDYtakOjXNb8EKqID0dYvvK9A== Date: Thu, 26 Sep 2013 04:28:26 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA811732F11@xmb-aln-x03.cisco.com> In-Reply-To: <5241D27E.4040201@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <415FCA18BFDD7E4A8855647E3E99A724@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , General Area Review Team , "draft-ietf-netext-update-notifications@tools.ietf.org" Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 04:28:33 -0000 Hi Robert, We seem to have missed this change. Will fix it in the next rev. Regards Sri On 9/24/13 10:57 AM, "Robert Sparks" wrote: >Hi Suresh - > >It doesn't look like any of these changes made it into -08? > >RjS > >On 8/22/13 4:51 PM, Robert Sparks wrote: >> On 8/22/13 4:06 PM, Suresh Krishnan wrote: >>> Hi Robert, >>> Thanks a lot for the review. We will include the changes in the next >>> revision we submit. Please see proposed changes inline. >>> >>> On 08/22/2013 02:05 PM, Robert Sparks wrote: >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> . >>>> >>>> Please resolve these comments along with any other Last Call comments >>>> you may receive. >>>> >>>> Document: draft-ietf-netext-update-notifications-07 >>>> Reviewer: Robert Sparks >>>> Review Date: 2013-08-22 >>>> IETF LC End Date: 2013-08-29 >>>> IESG Telechat date: not scheduled >>>> >>>> Summary: This draft is ready for publication as Proposed Standard >>>> >>>> I had to read through this text several times to convince myself >>>> implementers could figure out what order they were required to take >>>> steps in vs where they had flexibility: >>>> >>>> o Upon accepting the Update Notification message, the mobile >>>> access >>>> gateway MUST process the message and perform the actions >>>> based on >>>> the Notification Reason. >>>> * If the (A) flag in the message is set to a value of (1), the >>>> mobile access gateway MUST first send an Update Notification >>>> Acknowledgement message and set the status code field >>>> according >>>> to the result of processing the Update Notification message. >>>> >>>> In particular, it's not immediately obvious if there is tension >>>>between >>>> that "MUST first" and having "the result of processing" available. >>>> Please consider rewording to make it clearer that this "result of >>>> processing" is not intended to include waiting for the result of some >>>> action processing this notification message might trigger. >>> I think we can lose the word first without losing anything. Does the >>> following rewording work for you? >> Yes, thanks! >>> >>> OLD: >>> If the (A) flag in the message is set to a value of (1), the mobile >>> access gateway MUST first send an Update Notification Acknowledgement >>> message and set the status code field according to the result of >>> processing the Update Notification message. >>> >>> NEW: >>> If the (A) flag in the message is set to a value of (1), the mobile >>> access gateway MUST send an Update Notification Acknowledgement message >>> with the status code field set based on the result of processing the >>> Update Notification message. >>> >>>> It might help readers understand the intended usual case >>>>retransmission >>>> mechanics if the expected default values listed in section 7 were >>>> called >>>> out earlier in the document. >>> Sure. Will call out the defaults at first use. >>> >>> Thanks >>> Suresh >>> >> > From sgundave@cisco.com Wed Sep 25 21:29:24 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06B11E8136; Wed, 25 Sep 2013 21:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SdSRLJvzSlQ; Wed, 25 Sep 2013 21:29:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 326D111E8106; Wed, 25 Sep 2013 21:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1514; q=dns/txt; s=iport; t=1380169757; x=1381379357; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FdpczAOpplLJ+V8jdEZ0CtylQ01pnSefCa66AC1ALPI=; b=Eh8xdHCkDJ4mz0WoKCvv7003Fhe4s5RAfL4XD2KhyDK581rumgqDVgBW 9SR96XSPCmJxj+cBgpyvnE4GfAILBD3dhpmEpJ0c0YrRk2a1ucsB4HFuj AzS0Lsx6ZGEw1mNHM17vzEqUsbBG+MIIND5xsWdH2vuFqp56h+jjKYugP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKW3Q1KtJXG9/2dsb2JhbABbgwc4UsBdgSMWdIInAQQ6PQISAQgiFEIlAgQBDQUIAYd9DLxPjgiBGDECBYMdgQEDmSuQSIFmgT6BcTk X-IronPort-AV: E=Sophos;i="4.90,982,1371081600"; d="scan'208";a="264597162" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2013 04:29:16 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8Q4TGkW014401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 04:29:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.174]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 23:29:15 -0500 From: "Sri Gundavelli (sgundave)" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS) Thread-Index: AQHOunD13d4QgHY7y06rSqOmLtEN6w== Date: Thu, 26 Sep 2013 04:29:15 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA811732F4B@xmb-aln-x03.cisco.com> In-Reply-To: <20130925194032.29986.2555.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DB26E4556F2CE4090F0FDF688BC7FCA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" , "draft-ietf-netext-update-notifications@tools.ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Barry Leiba's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 04:29:24 -0000 Hi Barry, Ack. You will see this fix in the next version. Regards Sri On 9/25/13 12:40 PM, "Barry Leiba" wrote: >Barry Leiba has entered the following ballot position for >draft-ietf-netext-update-notifications-08: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Simple to resolve, and the authors are already aware of this: as raised >in the IANA review, the IANA Considerations section uses the correct URI >for the IANA registry in actions 1 and 2: > > http://www.iana.org/assignments/mobility-parameters > >...but does not use the correct one for actions 3 and 4: > > =20 >https://www.iana.org/assignments/mobility-parameters/mobility-parameters.x >html > >Please change the URIs in actions 3 and 4 to match the ones in actions 1 >and 2 (it doesn't matter whether they use http: or https:, but please >make all four the same). > > > > From suresh.krishnan@ericsson.com Wed Sep 25 23:43:02 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5CD21F9FD5; Wed, 25 Sep 2013 23:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wrtZ9pTJqqZY; Wed, 25 Sep 2013 23:42:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95021F9A96; Wed, 25 Sep 2013 23:42:56 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-a0-5243d76fe87c Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0D.CD.09414.F67D3425; Thu, 26 Sep 2013 08:42:55 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 26 Sep 2013 02:42:54 -0400 From: Suresh Krishnan To: Robert Sparks Thread-Topic: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07 Thread-Index: AQHOn3viWuJBnfE5x0mfHumRiJHjvJmiB4GAgDObmQCAAcit4A== Date: Thu, 26 Sep 2013 06:42:54 +0000 Message-ID: References: <521652E0.8030300@nostrum.com> <52167D67.2010103@ericsson.com> <521687CD.40502@nostrum.com> <5241D27E.4040201@nostrum.com> In-Reply-To: <5241D27E.4040201@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPgm7+decggy0NRhYPNixhtLj66jOL xbWfT9ktrs1pZHNg8Viy5CeTx6ydT1g8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsXP2BraCTbIV J8+cZm5gbBTvYuTkkBAwkbg4YT0zhC0mceHeerYuRi4OIYGjjBJ3J79iBEkICSxnlDh+pxzE ZgNq2LDzMxOILSKgIXFtyRJ2EJtZ4CSjxPW2XBBbWCBE4v2vB6wQNaESH3/2s0PYThITby0E 62URUJX4erUJrIZXwFtixtpXzBCLOxglzvVuBruIU0BbYt6zdrBmRqDrvp9awwSxTFzi1pP5 TBBXC0gs2XMe6gNRiZeP/7FC2MoS3+c8YoGo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2 C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzAKDomwaa7g3HPS8tDjNIcLErivKv0zgQK CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKx4pJ2ZI+Ky9ekTzZZvoZaP0yq2W4UIdX+WzdjL ZfB4y6JSbiNJjU3v6to9D3mnfM1X5FerPlnHH6qdnpUom/8u2HNixNuPRW2GeglcjMIcv30L 1FVnOB62Zy4Mlbunv0Zjva9Nb07broqp7aJWlY7nfZV6ufvWK8j9q1zFud5LlE/uZIcSS3FG oqEWc1FxIgAlVOG6cAIAAA== Cc: "netext@ietf.org" , General Area Review Team , "draft-ietf-netext-update-notifications@tools.ietf.org" Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:43:02 -0000 Hi Robert, Due to an editorial mixup the changes did not make it to -08. We apologi= ze for that. We have made the changes to the draft now and will ensure that= they are included in the -09 rev or RFC editor notes depending on whether = any other changes are needed. Thanks Suresh > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: September-24-13 1:57 PM > To: Suresh Krishnan > Cc: General Area Review Team; netext@ietf.org; draft-ietf-netext-update- > notifications@tools.ietf.org > Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update- > notifications-07 >=20 > Hi Suresh - >=20 > It doesn't look like any of these changes made it into -08? >=20 > RjS >=20 > On 8/22/13 4:51 PM, Robert Sparks wrote: > > On 8/22/13 4:06 PM, Suresh Krishnan wrote: > >> Hi Robert, > >> Thanks a lot for the review. We will include the changes in the > >> next revision we submit. Please see proposed changes inline. > >> > >> On 08/22/2013 02:05 PM, Robert Sparks wrote: > >>> I am the assigned Gen-ART reviewer for this draft. For background on > >>> Gen-ART, please see the FAQ at > >>> > >>> . > >>> > >>> Please resolve these comments along with any other Last Call > >>> comments you may receive. > >>> > >>> Document: draft-ietf-netext-update-notifications-07 > >>> Reviewer: Robert Sparks > >>> Review Date: 2013-08-22 > >>> IETF LC End Date: 2013-08-29 > >>> IESG Telechat date: not scheduled > >>> > >>> Summary: This draft is ready for publication as Proposed Standard > >>> > >>> I had to read through this text several times to convince myself > >>> implementers could figure out what order they were required to take > >>> steps in vs where they had flexibility: > >>> > >>> o Upon accepting the Update Notification message, the mobile > >>> access > >>> gateway MUST process the message and perform the actions > >>> based on > >>> the Notification Reason. > >>> * If the (A) flag in the message is set to a value of (1), th= e > >>> mobile access gateway MUST first send an Update Notificatio= n > >>> Acknowledgement message and set the status code field > >>> according > >>> to the result of processing the Update Notification message= . > >>> > >>> In particular, it's not immediately obvious if there is tension > >>> between that "MUST first" and having "the result of processing" > available. > >>> Please consider rewording to make it clearer that this "result of > >>> processing" is not intended to include waiting for the result of > >>> some action processing this notification message might trigger. > >> I think we can lose the word first without losing anything. Does the > >> following rewording work for you? > > Yes, thanks! > >> > >> OLD: > >> If the (A) flag in the message is set to a value of (1), the mobile > >> access gateway MUST first send an Update Notification > Acknowledgement > >> message and set the status code field according to the result of > >> processing the Update Notification message. > >> > >> NEW: > >> If the (A) flag in the message is set to a value of (1), the mobile > >> access gateway MUST send an Update Notification Acknowledgement > >> message with the status code field set based on the result of > >> processing the Update Notification message. > >> > >>> It might help readers understand the intended usual case > >>> retransmission mechanics if the expected default values listed in > >>> section 7 were called out earlier in the document. > >> Sure. Will call out the defaults at first use. > >> > >> Thanks > >> Suresh > >> > > From bclaise@cisco.com Thu Sep 26 03:05:42 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97211E8188; Thu, 26 Sep 2013 03:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ekynYXccVxWx; Thu, 26 Sep 2013 03:05:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6E921F9399; Thu, 26 Sep 2013 03:05:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130926100537.29653.10844.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2013 03:05:37 -0700 Cc: cpignata@cisco.com, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org, netext@ietf.org Subject: [netext] Benoit Claise's No Objection on draft-ietf-netext-update-notifications-08: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 10:05:42 -0000 Benoit Claise has entered the following ballot position for draft-ietf-netext-update-notifications-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- For the record, here is Carlos Pignataro's feedback, part of OPS-DIR. It's been worked on by Suresh Minor comment: This document specifies two configurable variables in Section 7. It clearly specifies that these variables need to survive reboots, and also specifies what it seems to be sensible defaults. However, it does not specify ranges or considerations for these two values. I'd suggest adding some more details about ranges. = The MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT default says it can be retransmitted once. The MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY default is the minimum value, which means that retransmission delay cannot be less than a second. I expect this is OK, but would ask whether it makes sense to have the variable in milliseconds and the default as 1,000. The answer can perfectly be "no, does not make sense". Also, a small nit in two IANA actions: o Action-3: This specification defines a new registry for Notification Reasons. Its called, "Update Notification Reasons Registry". This registry should be created under "Mobile IPv6 Parameters" registry at (https://www.iana.org/assignments/ mobility-parameters/mobility-parameters.xhtml). The Notification o Action-4: This specification defines a new registry for Status. Its called, "Update Notification Acknowledgement Status Registry". This registry should be created under "Mobile IPv6 Parameters" registry at (https://www.iana.org/assignments/mobility-parameters/ mobility-parameters.xhtml). The status is a field in the Update The URL should not point to the .xhtml pages, they should point to the extension-less URLs. A question: If the Status Codes are partitioned as 0-127 as success and 128-255 as error, why the error allocations start at 129? 0 - Success 129 - FAILED-TO-UPDATE-SESSION-PARAMETERS 130 - MISSING-VENDOR-SPECIFIC-OPTION = Should 128 be assigned? Another protocol problem: o If the local mobility anchor receives an Update Notification Acknowledgement message with a failure Status and the value of larger than 128, then it SHOULD log an error. Why the status "larger" than 128 and not "larger than or equal to" 128? This needs to be fixed (> 127 or >=3D 128) Hope these are clear and useful! Carlos. From jari.arkko@piuha.net Thu Sep 26 04:22:05 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF54B11E8198; Thu, 26 Sep 2013 04:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 sFxiHNoAeLOn; Thu, 26 Sep 2013 04:21:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7921F11E8199; Thu, 26 Sep 2013 04:21:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C386D2CC95; Thu, 26 Sep 2013 14:21:43 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh68UxhKkYgZ; Thu, 26 Sep 2013 14:21:43 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 6024E2CC6F; Thu, 26 Sep 2013 14:21:43 +0300 (EEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: Date: Thu, 26 Sep 2013 14:21:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <521652E0.8030300@nostrum.com> <52167D67.2010103@ericsson.com> <521687CD.40502@nostrum.com> <5241D27E.4040201@nostrum.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1508) Cc: "netext@ietf.org" , General Area Review Team , "draft-ietf-netext-update-notifications@tools.ietf.org" , Robert Sparks Subject: Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 11:22:05 -0000 Thank you Robert very much for your review. And I agree with the issue = you raised. Thank you Suresh and others for the revision. But I do wish = you'd submit the -09=85. Jari From jari.arkko@piuha.net Thu Sep 26 04:27:43 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B8921F9C0A; Thu, 26 Sep 2013 04:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se8gS30SbYxg; Thu, 26 Sep 2013 04:27:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5F11E8184; Thu, 26 Sep 2013 04:27:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130926112713.29653.90936.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2013 04:27:13 -0700 Cc: netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org, Robert Sparks Subject: [netext] Jari Arkko's No Objection on draft-ietf-netext-update-notifications-08: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 11:27:43 -0000 Jari Arkko has entered the following ballot position for draft-ietf-netext-update-notifications-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Robert Sparks raised a clarity issue in the document in his Gen-ART review, and there has been discussion with the authors to correct the issue, and the correction has made it to a private version of the draft. I wish that version would be published so that we could deal with as clean document as possible, free of issues that have already been resolved. (If you had no other issues to resolve, I'd probably raise this as a discuss, because I'd want to avoid accidentally approving the document without the changes making it to the last version.) From internet-drafts@ietf.org Fri Sep 27 22:09:19 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067A021F9C83; Fri, 27 Sep 2013 22:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1swEpvxFvCe; Fri, 27 Sep 2013 22:09:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606121F92DA; Fri, 27 Sep 2013 22:09:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130928050918.9951.17347.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 22:09:18 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 05:09:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Update Notifications for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Sri Gundavelli Marco Liebsch Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-netext-update-notifications-09.txt Pages : 19 Date : 2013-09-27 Abstract: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-update-notifications-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Sep 27 22:09:23 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1611D21F9FB4 for ; Fri, 27 Sep 2013 22:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kEa4loL5rTm; Fri, 27 Sep 2013 22:09:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2721F9BC2; Fri, 27 Sep 2013 22:09:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext@ietf.org, brian@innovationslab.net, stephen.farrell@cs.tcd.ie, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130928050918.9951.40394.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 22:09:18 -0700 Subject: [netext] New Version Notification - draft-ietf-netext-update-notifications-09.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 05:09:23 -0000 A new version (-09) has been submitted for draft-ietf-netext-update-notific= ations: http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-= 09.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From stephen.farrell@cs.tcd.ie Sat Sep 28 03:55:35 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7621F9FD7; Sat, 28 Sep 2013 03:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXOlgWfE5PwE; Sat, 28 Sep 2013 03:55:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22E21F93BA; Sat, 28 Sep 2013 03:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130928105534.9951.28210.idtracker@ietfa.amsl.com> Date: Sat, 28 Sep 2013 03:55:34 -0700 Cc: netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Stephen Farrell's No Objection on draft-ietf-netext-update-notifications-09: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 10:55:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netext-update-notifications-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for clarifying the relationship between netext and IPsec SAs. From barryleiba@computer.org Sat Sep 28 06:22:12 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2821E80DD; Sat, 28 Sep 2013 06:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn7FMEulzjYG; Sat, 28 Sep 2013 06:22:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F022221E80DB; Sat, 28 Sep 2013 06:22:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130928132211.9951.46440.idtracker@ietfa.amsl.com> Date: Sat, 28 Sep 2013 06:22:11 -0700 Cc: netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Barry Leiba's No Objection on draft-ietf-netext-update-notifications-09: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 13:22:12 -0000 Barry Leiba has entered the following ballot position for draft-ietf-netext-update-notifications-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -09 fixes the IANA URI issue. Thanks. From internet-drafts@ietf.org Sat Sep 28 11:38:41 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321BE11E8151; Sat, 28 Sep 2013 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HfvlNt-Vcjo; Sat, 28 Sep 2013 11:38:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0CB11E8110; Sat, 28 Sep 2013 11:38:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130928183838.9951.76473.idtracker@ietfa.amsl.com> Date: Sat, 28 Sep 2013 11:38:38 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-update-notifications-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 18:38:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Update Notifications for Proxy Mobile IPv6 Author(s) : Suresh Krishnan Sri Gundavelli Marco Liebsch Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-netext-update-notifications-10.txt Pages : 20 Date : 2013-09-28 Abstract: This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-update-notifications-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Sep 28 11:38:42 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F371E11E813D for ; Sat, 28 Sep 2013 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SFqL+9WywiV; Sat, 28 Sep 2013 11:38:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 453FB11E8143; Sat, 28 Sep 2013 11:38:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, netext@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130928183838.9951.4653.idtracker@ietfa.amsl.com> Date: Sat, 28 Sep 2013 11:38:38 -0700 Subject: [netext] New Version Notification - draft-ietf-netext-update-notifications-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 18:38:42 -0000 A new version (-10) has been submitted for draft-ietf-netext-update-notific= ations: http://www.ietf.org/internet-drafts/draft-ietf-netext-update-notifications-= 10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-update-notifications-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From rjsparks@nostrum.com Mon Sep 30 07:14:49 2013 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683C21F87B7; Mon, 30 Sep 2013 07:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFtiw106nE9S; Mon, 30 Sep 2013 07:14:48 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1F21F893E; Mon, 30 Sep 2013 07:14:40 -0700 (PDT) Received: from unnumerable.local (pool-71-170-125-188.dllstx.fios.verizon.net [71.170.125.188]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8UEEdYI061201 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 09:14:39 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52498754.2050601@nostrum.com> Date: Mon, 30 Sep 2013 09:14:44 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jari Arkko References: <20130926112713.29653.90936.idtracker@ietfa.amsl.com> In-Reply-To: <20130926112713.29653.90936.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 71.170.125.188 is authenticated by a trusted mechanism) Cc: netext@ietf.org, draft-ietf-netext-update-notifications@tools.ietf.org, The IESG , netext-chairs@tools.ietf.org Subject: Re: [netext] Jari Arkko's No Objection on draft-ietf-netext-update-notifications-08: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 14:14:49 -0000 On 9/26/13 6:27 AM, Jari Arkko wrote: > Jari Arkko has entered the following ballot position for > draft-ietf-netext-update-notifications-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Robert Sparks raised a clarity issue in the document in his Gen-ART > review, and there has been discussion with the authors to correct the > issue, and the correction has made it to a private version of the draft. > I wish that version would be published so that we could deal with as > clean document as possible, free of issues that have already been > resolved. My comments were addressed at -09. > > (If you had no other issues to resolve, I'd probably raise this as a > discuss, because I'd want to avoid accidentally approving the document > without the changes making it to the last version.) > >