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

Robert Sparks <rjsparks@nostrum.com> Thu, 22 August 2013 18:05 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 7485211E8100; Thu, 22 Aug 2013 11:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.216
X-Spam-Level:
X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 nz5Ivs39-Mia; Thu, 22 Aug 2013 11:05:30 -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 236FD21F9E7E; Thu, 22 Aug 2013 11:05:29 -0700 (PDT)
Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r7MI5KIL084756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 13:05:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <521652E0.8030300@nostrum.com>
Date: Thu, 22 Aug 2013 13:05:20 -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
Content-Type: multipart/alternative; boundary="------------040800040901010008090007"
Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism)
Subject: [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: Thu, 22 Aug 2013 18:05:31 -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>.

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.