[multimob] Spencer Dawkins' No Objection on draft-ietf-multimob-pmipv6-source-08: (with COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Tue, 25 March 2014 16:27 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 96DC11A01E9; Tue, 25 Mar 2014 09:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id p7wKb4NETkdV; Tue, 25 Mar 2014 09:27:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247D1A01D1; Tue, 25 Mar 2014 09:27:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140325162722.24921.24684.idtracker@ietfa.amsl.com>
Date: Tue, 25 Mar 2014 09:27:23 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/HbeBys6kbQgaXcw00zoVfpfwySc
Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob-chairs@tools.ietf.org
Subject: [multimob] Spencer Dawkins' No Objection on draft-ietf-multimob-pmipv6-source-08: (with COMMENT)
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob/>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Mar 2014 16:27:25 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-multimob-pmipv6-source-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I have a couple of questions about text clarity. Please consider them,
along with any other comments you receive from other reviewers. 

And I should say that MIP/PMIP drafts I've often read have been dense for
me, and this one is clearer than most - thank you for that.

4.3.2.  Operations of PIM in Phase One (RP Tree)

   Source handover management in PIM phase one admits low complexity and
   remains transparent to receivers.  In addition, the source register
   tunnel management of PIM is a fast protocol operation and little
   overhead is induced thereof.  

I didn't understand this text clearly. Is it saying something like
"little overhead is introduced"?

7.  Security Considerations

   In addition to proper authorization checks
   of MNs, rate controls at routing agents and replicators MAY be
   required to protect the agents and the downstream networks.  In

is this "may be needed"? The passive voice doesn't make the text easy to
parse (and I'm thinking this MAY is not a 2119 MAY, but that's a separate

   particular, MLD proxy implementations at MAGs SHOULD carefully
   procure for automatic multicast state extinction on the departure of

This word doesn't fit (a quick google of online directionaries pointed
toward "procure" as obtaining something by special effort, for example).
I wondered if you meant "probe", but I'm guessing.

   MNs, as mobile multicast listeners in the PMIPv6 domain will in
   general not actively terminate group membership prior to departure.

   implementations of peering-enabled proxies SHOULD take particular
   care on maintaining (varying) IP configurations at the downstream in
I don't understand what "varying" means in this context (my first guess
was that it was being used as a synonym for "maintaining", which didn't
work). Is it needed at all?

   a reliable and timely manner (see [RFC6224] for requirements on
   PMIPv6-compliant implementations of MLD proxies).