Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
Note: This ballot was opened for revision 08 and is now closed.
(Brian Haberman) Yes
(Jari Arkko) No Objection
(Alia Atlas) No Objection
(Spencer Dawkins) No Objection
Comment (2014-03-25 for -08)
I have a couple of questions about text clarity. Please consider them, along with any other comments you receive from other reviewers. And I should say that MIP/PMIP drafts I've often read have been dense for me, and this one is clearer than most - thank you for that. 4.3.2. Operations of PIM in Phase One (RP Tree) Source handover management in PIM phase one admits low complexity and remains transparent to receivers. In addition, the source register tunnel management of PIM is a fast protocol operation and little overhead is induced thereof. ^^^^^^^^^^^^^^^ I didn't understand this text clearly. Is it saying something like "little overhead is introduced"? 7. Security Considerations In addition to proper authorization checks of MNs, rate controls at routing agents and replicators MAY be required to protect the agents and the downstream networks. In ^^^^^^^^ is this "may be needed"? The passive voice doesn't make the text easy to parse (and I'm thinking this MAY is not a 2119 MAY, but that's a separate issue). particular, MLD proxy implementations at MAGs SHOULD carefully procure for automatic multicast state extinction on the departure of ^^^^^^^ This word doesn't fit (a quick google of online directionaries pointed toward "procure" as obtaining something by special effort, for example). I wondered if you meant "probe", but I'm guessing. MNs, as mobile multicast listeners in the PMIPv6 domain will in general not actively terminate group membership prior to departure. Consequently, implementations of peering-enabled proxies SHOULD take particular care on maintaining (varying) IP configurations at the downstream in ^^^^^^^^^ I don't understand what "varying" means in this context (my first guess was that it was being used as a synonym for "maintaining", which didn't work). Is it needed at all? a reliable and timely manner (see [RFC6224] for requirements on PMIPv6-compliant implementations of MLD proxies).
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
(Kathleen Moriarty) No Objection
(Pete Resnick) No Objection
Comment (2014-03-26 for -08)
A quick review reveals nothing of significance for applications that I can find. I do wonder about why this is Experimental. Seems to me it could have been a Proposed Standard, and there's nothing in the document to indicate any "experimenting" that's truly going to be done or what the WG expects to discover from this "experiment". But if the AD is OK with it, I'm not going to hold it up.