[netext] Gen-art telechat review: draft-ietf-netext-update-notifications-08

Robert Sparks <rjsparks@nostrum.com> Tue, 24 September 2013 18:02 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 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 <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: General Area Review Team <gen-art@ietf.org>, 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. " <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 18:02:57 -0000

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

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.