Re: [netext] Review of I-D: draft-ietf-netext-update-notifications-03

Basavaraj Patil <bpatil1@gmail.com> Fri, 17 May 2013 16:44 UTC

Return-Path: <bpatil1@gmail.com>
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 0F19921F9729 for <netext@ietfa.amsl.com>; Fri, 17 May 2013 09:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level:
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vsp+PukZQQyq for <netext@ietfa.amsl.com>; Fri, 17 May 2013 09:44:19 -0700 (PDT)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3227121F9733 for <netext@ietf.org>; Fri, 17 May 2013 09:44:18 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id m1so5484965oag.34 for <netext@ietf.org>; Fri, 17 May 2013 09:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ysgl3PMtINVzltiqnqWcDZzV9K4ueWqifCBXKAfBDeo=; b=swflPQ1K8h7MKmA/utEbJNE2tBI6QDA0wAOXmm9DLayDVmZrc03mhwQfm97gXNPe8c CrHDyoAJA1tk5ipM8npHFZ6vQh4xZMbZ4WPYb9PQTfCavNW1gcqj7ftYyEywlrIy/pbJ x7XSpIlyqL3fwn3eWpam8dyYQUgZSLaT0aa1WqkRM9qkWkRDuHFB8ncfRKAb3epk47d2 qBV3P9qCBOQQ4nOrVfR5z1j/nbosg7DcYFR+iCfyxfgruJjOdcWUjfvbw34I7fFxToHz R1zp+0979nndlRYGfbOfGaVLHTQM+IEBQp4raAda9xrZukYQ8VlQPO7rkdogcAas2D6C v/sA==
MIME-Version: 1.0
X-Received: by 10.182.237.77 with SMTP id va13mr22250268obc.65.1368809057761; Fri, 17 May 2013 09:44:17 -0700 (PDT)
Received: by 10.76.180.165 with HTTP; Fri, 17 May 2013 09:44:17 -0700 (PDT)
In-Reply-To: <lgaqln5hv9ey0vyp4c48dvjx.1368764941954@email.android.com>
References: <CAA5F1T29LitDBBdfWt13yaj4MXQnnKaP+Mews1HeXMFD8EPTMQ@mail.gmail.com> <lgaqln5hv9ey0vyp4c48dvjx.1368764941954@email.android.com>
Date: Fri, 17 May 2013 11:44:17 -0500
Message-ID: <CAA5F1T3+UZiyan4v1njsYei+X+=x7e5X2TYaGQOem7RBvo6E3Q@mail.gmail.com>
From: Basavaraj Patil <bpatil1@gmail.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Content-Type: multipart/alternative; boundary=e89a8ff1cdcca7910d04dcecb14f
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-update-notifications-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. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 16:44:24 -0000

Hi Suresh,

I just wanted to make sure that we are requiring IANA registration for all
reasons that get specified subsequently. Since that is required and clearly
mentioned in the IANA considerations section of the I-D I am fine with it.

Will go ahead and submit a WG LC request.

-Raj


On Thu, May 16, 2013 at 11:29 PM, Suresh Krishnan <
suresh.krishnan@ericsson.com> wrote:

>  Hi Raj,
> Thanks for your detailed review. We have submitted a new version of the draft to address your comments. Specifically we have added a new configuration value for limiting the number of retransmissions and fixed all the editorial issues.
>
> I did not understand the issue about the vendor specific reason. We require IANA registration of all reasons with the policy "specification required". Did you want us to change this? Once we agree on a resolution to this issue, the draft will be ready for WGLC.
>
> Thanks
> Suresh
>
>
> ----- Original Message -----
> From: Basavaraj Patil <bpatil1@gmail.com>
> To: "netext@ietf.org" <netext@ietf.org>
> Sent: 5/8/2013 5:50 PM
> Subject: [netext] Review of I-D: draft-ietf-netext-update-notifications-03
>
>
>
>
>  My review of this I-D.
>
>  -Raj
>
>  Comments:
> ---------
>
>  In order to ensure interoperability, the I-D should state that if an
> LMA sends an Update notification to a MAG and does not receive an Ack,
> then the MAG may not support the ability to update sessions.
> The I-D should specify a backoff mechanism in terms of retransmitting
> an update message from the LMA and stop after X number of messages
> with no response.
>
>  The update notification message could be abused by the introduction of
> a vendor specific notification reason. The specification should
> mandate the registration of all notification reasons in IANA and not
> allow any vendor specific types.
>
>
>
>  Editorial:
>
>  s/ These update notifications are exchanged using a Mobility
>    Header message type specifically designed for this purpose./These
>    update notifications are exchanged using a new Mobility
>    Header message type specifically designed for this purpose.
>
>  Comment:
>
>  The Introduction starts off as : "In some situations, there is a need
> for the local mobility anchor ..."
> This is pretty ambiguous. Please rephrase.
>
>  s/The base Proxy
>    Mobile IPv6 specification does not have a provision for this./ The
>    base Proxy Mobile IPv6 specification does not have a provision for
>    sending unsolicited informational messages from the LMA to the
>    MAG.
>
>  s/participation from the mobile node/participation by the mobile node
>
>  s/for the mobile node in Mobile IPv6 [RFC6275]/for the mobile node as
> specified in Mobile IPv6 [RFC6275]
>
>  Q: ID states:
> "One such scenario where such a mechanism is needed is when the local
>    mobility anchor wants to inform the mobile access gateway that it
>    needs to re-register mobility session for a mobile node."
>
>  In what scenario would the LMA want to inform the MAG that an MN needs
> to be re-registered?
>
>  s/and so it can obtain the updated policy/in order to update the
> policies associated with the mobility session of an MN.
>
>  s/or and updated IPv4/or an updated IPv4
>
>
>  --
> Basavaraj Patil
>



-- 
Basavaraj Patil