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

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Mon, 31 March 2014 17:56 UTC

Return-Path: <prvs=160a38399=schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11851A6F51; Mon, 31 Mar 2014 10:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8bRUTRO0-xH; Mon, 31 Mar 2014 10:56:16 -0700 (PDT)
Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0B1A6F15; Mon, 31 Mar 2014 10:56:15 -0700 (PDT)
Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 31 Mar 2014 19:56:11 +0200
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 0A1C910679D7; Mon, 31 Mar 2014 19:56:11 +0200 (CEST)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18801-08; Mon, 31 Mar 2014 19:56:10 +0200 (CEST)
Received: from [192.168.178.49] (g231227163.adsl.alicedsl.de [92.231.227.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 7534810679CF; Mon, 31 Mar 2014 19:56:09 +0200 (CEST)
Message-ID: <5339AC38.4000706@informatik.haw-hamburg.de>
Date: Mon, 31 Mar 2014 19:56:08 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
References: <20140325162722.24921.24684.idtracker@ietfa.amsl.com>
In-Reply-To: <20140325162722.24921.24684.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/3qSQanA64qqgGoHsZ70OITVwxW8
Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob-chairs@tools.ietf.org
Subject: Re: [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
Precedence: list
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: Mon, 31 Mar 2014 17:56:18 -0000

Hi Spencer,

thanks for the review and comments on presentation issues. Please see 
inline.

On 25.03.2014 17:27, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-multimob-pmipv6-source-08: No Objection
>

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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"?
>

Yes, we reworded: "... PIM is a fast protocol operation that introduces 
little overhead."

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

Yes, you're right: "may be needed" is what we wanted to say ;)

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

"Probe" would refer to a special solution to achieve this clean-up of 
state. We would reword:

"MLD proxy implementations at MAGs SHOULD automatically extinct 
multicast state on the departure of"


>     Consequently,
>     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?
>

The focus here is on the changing IP connectivity at a MAG's downstream. 
We reword:

"implementations of peering-enabled proxies SHOULD take particular care 
on keeping IP configurations consistent"

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

We will update the draft accordingly.

Best,

thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °