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 at irtf.org
http://www.irtf.org/mailman/listinfo/mobopts
