Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 24 September 2009 09:49 UTC

Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563563A687F; Thu, 24 Sep 2009 02:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYIpAlss3T8I; Thu, 24 Sep 2009 02:49:01 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 1436C3A689C; Thu, 24 Sep 2009 02:49:00 -0700 (PDT)
Envelope-to: iesg@ietf.org, mobopts@irtf.org
Received: from [91.113.129.90] (helo=[192.168.1.216]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1Mqkxi-0005fO-Mm; Thu, 24 Sep 2009 11:50:06 +0200
Message-ID: <4ABB40C9.4050909@informatik.haw-hamburg.de>
Date: Thu, 24 Sep 2009 11:50:01 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4ABB39DF.10609@piuha.net>
In-Reply-To: <4ABB39DF.10609@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: ipdvb-chairs@tools.ietf.org, draft-irtf-mobopts-mmcastv6-ps@tools.ietf.org, multimob-chairs@tools.ietf.org, IESG <iesg@ietf.org>, "16ng-chairs@tools.ietf.org" <16ng-chairs@tools.ietf.org>, ml-mobopts <mobopts@irtf.org>
Subject: Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/mobopts>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2009 09:49:02 -0000

Hi Jari,

many thanks for your review and in particular for the detailed comments: 
Most of them will obviously improve the document, some of them we have 
to consider in detail.

We will be back with an exhaustive response once we have re-worked all 
details.

Thanks again!

Thomas

Jari Arkko wrote:
> Hi all,
> 
> I have reviewed this document today. The purpose of my review and the 
> following IESG review is to perform a so called RFC 3932 check, i.e., 
> make sure that documents outside the IETF stream do not allocate IANA 
> values reserved for standards track protocols or otherwise collide with 
> IETF working group efforts.
> 
> I have not found any collision with this work and IETF work, though 
> obviously, this work has been one of the inputs for the formation of the 
> MOBOPTS working group, and also talks about IP over a number of link 
> layers.
> 
> I have recommended the standard RFC 3932 boilerplate IESG note about 
> non-IETF work. Once the 3932bis work is concluded we will be able to 
> make use of the new style of headers and boilerplates which do not 
> require IESG notes. I have written to the tracker that if this happens 
> before this document comes out of the RFC Editor queue then no note is 
> needed.
> 
> The document will be under the entire IESG's review in two weeks to 
> confirm my recommendation. Please remember that neither my review or the 
> IESG review is a technical review. In other words, the RG is fully 
> responsible for the correctness of the document. As a personal note I 
> wanted to say nevertheless that I was reasonably happy with the 
> document. Thank you for writing this.
> 
> In any case, I have included a few personal review comments below. Also, 
> as the document contains quite a bit of material relating to IP over 
> 802.16 and IP over DVB, I have Cced the relevant working group chairs in 
> case they have further comments.
> 
> Jari Arkko
> 
>> obility management may issue
>>    traffic directives that lead to suboptimal routing, i.e., erroneous
>>    subscriptions following predictive handover operations, or slow
>>    effective leaves caused by MLD querying, or by departure of the MN
>>    from a previous network without leaving the subscribed groups.
>>   
> 
> I had a hard time parsing this. Maybe say instead: "Mobility management 
> may impact routing by, e.g., erroneous ... or by MNs leaving networks 
> without unsubscribing form the groups they were receiving.". What's a 
> "slow effective leave"?
> 
>> IP multicast deployment in general has been hesitant over the past 15
>>    years
> 
> s/hesitant/slow/?
> 
>> a strong business case for IP
>>    portables
> ... portable IP-based devices.
> 
>> Current packet filtering practice causes inter-working problems 
>> between Mobile IPv6 nodes connected via GPRS [46 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-46>].
>>   
> This is incorrect AFAIK. There are filtering procedures in IMS that 
> cause problems for Mobile IPv6 and other things. However, those 
> filtering mechanisms are not a part of the link layer nor are they 
> applied for regular Internet access. I would suggest this statement be 
> deleted from the draft, along with the reference.
> 
>> PTM uses an
>>    unidirectional common channel, operating in unacknowledged without
>>    adjustment of power levels and no reporting on lost packets.
>>   
> 
> ... unacknowledged mode?
> 
>>  Mobility services transport for MIH naturally reside
>>    on the network layer and are currently in the process of
>>    specification [55 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-55>].
>>
>>   
> draft-ietf-mipshop-mstp-solution is an approved specification (though 
> not yet out of the RFC Ed queue).
> 
> Also, I believe 802.21 specifies both network and link layer transport, 
> so its not clear why you say "naturally" above.
> 
> In general Section 4 wanders off a little bit to topics outside 
> multicast. I understand that some amount of explanation is needed about 
> what each L2 technology does, but I'd consider tightening the text in 
> AUTH48 in some places.
> 
>> MLD
>>    router querying will allow the multicast forwarding state to be
>>    restored in case of an erroneous prediction (i.e., an anticipated
>>    move to a network that is not fulfilled).
> fulfilled?
> 
>>    Mobility protocols need to consider the implications and requirements
>>    for AAA. AAA binding records may change between attachments, or may
>>    be individually chosen prior to network (re-)association. The most
>>    appropriate network path may be one that satisfies user preferences,
>>    e.g., to use/avoid a specific network, minimize monetary cost, etc,
>>    rather than one that only minimizes the routing cost. Consequently,
>>    AAA bindings cannot be treated at a pure level of context transfer.
>>   
> It was not clear to me why AAA is relevant. And what's an "AAA binding 
> record"? I must say that I don't understand the rest of the paragraph 
> either.
> 
> The term AAA was not defined or expanded. Please check the other terms too.
> 
>> Due to lack of feedback, the admission [83 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-83>] 
>> and binding
>>    updates [84 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-84>] 
>> of mobile multicast sources require autonomously
>>    verifiable authentication as can be achieved by Cryptographically
>>    Generated Addresses (CGAs).
>>   
> And presumably with other means as well. I would suggest saying "... be 
> achieved by, for instance, ...".
> 
> It would have been interesting if Section 8 listed some of the multicast 
> specific issues around security. For instance, I would presume that a HA 
> operating tunneled multicast service by n-casting is more vulnerable to 
> a DoS attack than some other more native multicast solution.
> 
> Jari
> 
> _______________________________________________
> Mobopts mailing list
> Mobopts@irtf.org
> http://www.irtf.org/mailman/listinfo/mobopts

-- 

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 °