Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
draft-ietf-multimob-pmipv6-ropt-08
Yes
(Brian Haberman)
No Objection
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)
(Stewart Bryant)
(Ted Lemon)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2013-08-13 for -07)
Unknown
I am balloting Yes on this document on the strength of reviews by the PIM WG. I would be glad if you looked at my comments below. ==== Thank you for recognising that this work is best brought forward as Experimental. I should like it if the Abstract made the point that this is intended as an Experiment. I think it important to add some text to the Introduction to: - state that this work is Experimental - describe the scope of the experiment and how it is contained - explain what happens if any of this experiment interacts with the wider Internet - indicate what people should experiment with, what they should report back, how the experiment will be judged, and what the next steps might be. --- The RFC Editor will ask you to remove the citation from the Abstract. --- Section 2 In this draft we refine such definition from the point of view of the s/draft/document/ --- Section 5.1.2 Maybe the explanatory text should be ordered the same as in the message option? --- Section 5.1.2 The description of "Dynamic IP Multicast Selector Mode Flag" uses "SHOULD" for behaviors of 1 and 0. That implies that there is an option to do something different. Can you describe the circumstances where an implementation MAY do something else. --- Section 9 should really identify the registry from which the allocation is to be made per Barry's comment.
Brian Haberman Former IESG member
Yes
Yes
(for -07)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-07-17 for -07)
Unknown
I've just one quibble with the document: the IANA Considerations do not properly specify what needs to be done -- the registry isn't mentioned at all. This is *not* a DISCUSS, because IANA have figured out what to do. That said, it wouldn't hurt to make it clear in the document, so that others reading it will know what registry is involved: OLD This document defines a new mobility option, the Dynamic IP Multicast Selector, which has been assigned the type TBD by IANA. NEW This document defines a new mobility option, the Dynamic IP Multicast Selector (see Section 5.1). IANA has assigned this option the type TBD and has registered it in the Mobility Options subregistry of the Mobile IPv6 Parameters registry. [RFC Editor: Please replace "TBD" above with the value assigned by IANA.] END Oh, and I think our custom is to name Section 11 as "Contributors", not "Authors". The RFC Editor will sort that out, I suppose.
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Richard Barnes Former IESG member
(was Abstain)
No Objection
No Objection
(for -07)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -07)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -07)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-08-15 for -07)
Unknown
Apologies, I didn't have time to really review this but I don't get how you can change the multicast anchor and routing and yet introduce no new security considerations. The secdir review [1] raised some similar questions to which the authors responded with some suggested changes that I assume will be made in -08. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04128.html One note: in the answer to the secdir review, the author said: "The addition of the new option does not address any security issue as long as the signaling is properly secured reusing Proxy Mobile IPv6 mechanisms." That could be a misinterpretation of what this section is meant to contain. If so, I'd suggest taking a read of BCP 72 [2] which says that you should document the security considerations of this protocol and not just the new security features it introduces. Or maybe the quoted text is just a slightly loose email, which is quite understandable. [2] http://tools.ietf.org/html/bcp72 Lastly, that's a lot of complicated IPR declarations. I'd not be surprised if those disincentivise implementers. It'd put me off for example. But I guess the wg had consensus that it's ok with that.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -07)
Unknown