Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications

"Sri Gundavelli (sgundave)" <> Sat, 27 July 2013 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40EDE11E8119 for <>; Sat, 27 Jul 2013 16:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mEGSj6YbT8l9 for <>; Sat, 27 Jul 2013 16:09:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5847F11E8111 for <>; Sat, 27 Jul 2013 16:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4518; q=dns/txt; s=iport; t=1374966587; x=1376176187; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KuUhu32IunwhH4SChj0T8vmrS7Bp3UogOoZRPRJusXE=; b=mfWbjZ5TGaO+g8ID0TJggcEXT+Twb5v5AiqTHqaGsVrkwd8+uSqSvayb SFmHQEWWM5dknrZNpCbsLfcPTZDvjDm9I43IUFCxhTYTQTKoM5t3EeUtt jzJPD43R+a3l59PrhLRjrWLF9pqhkfN611czp20MFginztUnfO68P/N0I c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.89,759,1367971200"; d="scan'208";a="240366159"
Received: from ([]) by with ESMTP; 27 Jul 2013 23:09:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6RN9j0K006926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 23:09:45 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 18:09:44 -0500
From: "Sri Gundavelli (sgundave)" <>
To: Brian Haberman <>, "" <>
Thread-Topic: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications
Thread-Index: AQHOix5h6rnp0tPc9k2iWrwsRpO7/Q==
Date: Sat, 27 Jul 2013 23:09:44 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications
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: Sat, 27 Jul 2013 23:09:52 -0000

Hi Brian,

Thanks for the review comments. Please see inline.

On 7/24/13 11:20 AM, "Brian Haberman" <> wrote:

>-------- Original Message --------
>Subject: AD Evaluation : draft-ietf-netext-update-notifications
>Date: Wed, 24 Jul 2013 14:16:26 -0400
>From: Brian Haberman <>
>To: <>rg>,
>      I have performed my AD evaluation of
>draft-ietf-netext-update-notifications as a part of the RFC publication
>process.  Thank you for a well-written document.  The following
>comments/questions need to be addressed prior to issuing an IETF Last
>Call for the draft.  Please let me know if there is any clarification I
>can provide on these comments.
>* Introduction
>- The 2nd sentence in the 2nd paragraph is clunky.  I finally figured
>out that what it is trying to say is that the MAG proxies all MIPv6
>signaling on behalf of the mobile node and the LMA acts as a MIPv6 home
>agent.  I would suggest re-writing the sentence to be clearer for those
>readers who are not experts in the mobility protocols.

OK. Will reword that sentence/paragraph.

>- The last sentence of the 2nd paragraph should say that PMIPv6 does not
>*currently* have an LMA-to-MAG signaling mechanism.


>- The first sentence in the 3rd paragraph is missing an article.  I
>believe it should be "... re-register the mobility session..."

Ok. Sure

>- The last sentence in the 3rd paragraph that discusses the use of
>existing headers is confusing.  It starts off by saying it is possible
>to use existing headers for this signaling and ends by saying they can't
>be used.

Will reword it.

>* Section 4
>- Is there any guidance needed on managing the wrapping of the Sequence

We just require some random number, without collusions. We can add some
text to say how to manage that field.

>- Is it worth mentioning the Pad1 and PadN options given the alignment

That was implied with all options. But, its probably good to include some

>- Are there informative references that could be added for mobility
>options other than the vendor-specific ones?

Potentially some some new work items that we can point to. If there are
Active I-D's will add a reference.

>* Section 5
>- The last bullet is extraneous since it simply points to the very next

Agree. Will remove it

>- Can you provide an example of where an LMA would not request an ACK
>for a UPN?

Message String extension. LMA sending some status messages related to the
service its offering. These service message may not need Ack's.

Also, a UPN message with NR=RE-register may not need a Ack messages. The
LMA after sending the UPN message with that NR code can wait the PBU

>- I assume that the sequence numbers used in these messages are the same
>sequence numbers used for other PMIPv6/MIPv6 messages.  It might be
>worthwhile to mention that, if it is true.

This is a good point. We did not say one way, or the other. Will clarify

>* Section 5.2
>- I am surprised by the use of SHOULD (SHOULD NOT) for re-transmission
>rules.  When would you expect these rules to be ignored?

Ok. Will review this again.

>* Section 6.1
>- The 2nd bullet is useless.  If an implementation does not support
>these messages, they wouldn't know to look here for responses.  The base
>PMIPv6 spec covers the response message for unknown message types.

This is about LMA sending a UPN message to a MAG that does not support and
how to deal with that scenario.
If the response to a UPN message is a Binding Error message, then the LMA
can be forced not to send any more UPN messages.

>- Should there be any validation performed on the sequence number?

Exact considerations from 6275 apply here. Its just for matching the
request to the response. Will review the text related to this field.

>- I would like to see some more guidance given to IANA on where the new
>registries should be placed in their protocol hierarchy.

Ok. Will review this

>netext mailing list