Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
RFC 7028

Note: This ballot was opened for revision 07 and is now closed.

(Adrian Farrel) Yes

Comment (2013-08-13 for -07)
No email
send info
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) Yes

(Jari Arkko) No Objection

(Richard Barnes) (was Abstain) No Objection

(Stewart Bryant) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2013-08-15 for -07)
No email
send info
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.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-07-17 for -07)
No email
send info
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.

(Ted Lemon) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection