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

"Thomas C. Schmidt" <> Thu, 24 September 2009 09:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 563563A687F; Thu, 24 Sep 2009 02:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.45
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GYIpAlss3T8I; Thu, 24 Sep 2009 02:49:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1436C3A689C; Thu, 24 Sep 2009 02:49:00 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <>) id 1Mqkxi-0005fO-Mm; Thu, 24 Sep 2009 11:50:06 +0200
Message-ID: <>
Date: Thu, 24 Sep 2009 11:50:01 +0200
From: "Thomas C. Schmidt" <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Jari Arkko <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc:,,, IESG <>, "" <>, ml-mobopts <>
Subject: Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

Thanks again!


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 
>> <>].
> 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 
>> <>].
> 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 
>> <>] 
>> and binding
>>    updates [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


Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
°                   Fon: +49-40-42875-8452 °
°    Fax: +49-40-42875-8409 °