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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 31 March 2014 19: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6A21A6F77; Mon, 31 Mar 2014 12:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 HKKBtimcuFHY; Mon, 31 Mar 2014 12:27:15 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 67A6F1A6F6C; Mon, 31 Mar 2014 12:27:13 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id t59so8047923yho.15 for <multiple recipients>; Mon, 31 Mar 2014 12:27:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u0cKJnnaqlJG1Mxqvgro7wFb7B5AMef6Y6jmX7T+TQY=; b=r513P2sLuU1LoWas/+lbX5s/3YIxBJ9gMND04ARdpf2knnMFhZliLsgOHuSi0zgLMg QvcLsJCMCP6RRHtWCPQRYAAURTr/wB4ZIv1llUAgUX1C/k53pEvA3J799D1MWm39mJCc zvUB+4XHmKwMBU0u92MaOXgdTm51b8wAhGpmf+wFuWAipN3QoJafY0rpsFdNo3mKCtkb 1mzRcuDicx+rUVZDywLZrrnPFAUyzh8n9++eoIQmn+PeXHfgKXjNeKdZcpfalXkop+QU xwxRS1t6OCsBhBc6nn1WNazTmxrp35IB5O10fAegIhup0/gycSERiZSS1mK+WaNt2msO fhQg==
MIME-Version: 1.0
X-Received: by 10.236.85.45 with SMTP id t33mr38762860yhe.74.1396294029885; Mon, 31 Mar 2014 12:27:09 -0700 (PDT)
Received: by 10.170.96.215 with HTTP; Mon, 31 Mar 2014 12:27:09 -0700 (PDT)
In-Reply-To: <5339AC38.4000706@informatik.haw-hamburg.de>
References: <20140325162722.24921.24684.idtracker@ietfa.amsl.com> <5339AC38.4000706@informatik.haw-hamburg.de>
Date: Mon, 31 Mar 2014 14:27:09 -0500
Message-ID: <CAKKJt-e0f5ESyHrMZha23+pmnM-+H98_0hXLhh-6aYc=-RsC9Q@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
Content-Type: multipart/alternative; boundary=20cf3005dd4ea7446704f5ec09a4
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/YqlKxFyIs7qHRwOM0rWVMKCeaRM
Cc: "multimob@ietf.org" <multimob@ietf.org>, "draft-ietf-multimob-pmipv6-source@tools.ietf.org" <draft-ietf-multimob-pmipv6-source@tools.ietf.org>, The IESG <iesg@ietf.org>, "multimob-chairs@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 19:27:18 -0000

Hi, Thomas,

These are all fine for me, and thank you.

You might want to make sure your AD is ready for a revision, of course.

Thanks,

Spencer

On Monday, March 31, 2014, Thomas C. Schmidt <
schmidt@informatik.haw-hamburg.de>; wrote:

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