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

["Thomas C. Schmidt" <[e-mail]>]

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
> [e-mail]
> 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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °