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

["Koodli, Rajeev" <[e-mail]>]

 
Hi Jari,

Thanks for your review. The authors will find your input useful and will
address them.

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

Perhaps you meant MULTIMOB above.

Regards,

-Rajeev


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