Re: [netext] Gen-ART LC review: draft-ietf-netext-update-notifications-07

Robert Sparks <rjsparks@nostrum.com> Tue, 24 September 2013 17:57 UTC

Return-Path: <rjsparks@nostrum.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 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 <rjsparks@nostrum.com>
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 <suresh.krishnan@ericsson.com>
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 <gen-art@ietf.org>, 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. " <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: 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
>>>
>>> <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.
>> 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
>>
>