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

Brian Haberman <> Mon, 29 July 2013 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 696A221F999E for <>; Mon, 29 Jul 2013 00:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mf3+aWogDdiv for <>; Mon, 29 Jul 2013 00:43:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB40421F9980 for <>; Mon, 29 Jul 2013 00:43:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 83915880F0; Mon, 29 Jul 2013 00:43:49 -0700 (PDT)
Received: from clemson.local ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id DF9BF130003; Mon, 29 Jul 2013 00:43:48 -0700 (PDT)
Message-ID: <>
Date: Mon, 29 Jul 2013 03:43:47 -0400
From: Brian Haberman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
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: Mon, 29 Jul 2013 07:44:00 -0000

Hi Sri,
      I have deleted those points where there is no additional 
discussion needed...

On 7/27/13 7:09 PM, Sri Gundavelli (sgundave) wrote:
>> * Section 4
>> - Is there any guidance needed on managing the wrapping of the Sequence
>> #'s?
> We just require some random number, without collusions. We can add some
> text to say how to manage that field.

Ok.  Just ensure that the descriptive text does not impact the Sequence 
# usage defined in the base PMIPv6 spec.

>> - 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.

That would be useful.  Just make sure they are informative references so 
that this spec does not get held up on a reference to an I-D.

>> - 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
> message.

So, is it worth mentioning these in the draft?  It seems that the LMA is 
in full control of whether an ACK is needed, but it *could* be useful to 
describe the *types* of options that do not need an ACK.

I am not insisting on this.  Just trying to see if such an addition 
would make the spec easier to understand/implement.

>> * 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.

If the SHOULDs are appropriate, it would be good to describe a scenario 
(or type of scenaro) where the SHOULD would be ignored.

>> * 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.

Given that section 6.1 talks about MAG considerations, it seemed odd to 
describe how the MAG is supposed to respond if it doesn't support this