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

[Jari Arkko <jari.arkko at piuha.net>]

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