Skip to main content

Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
RFC 7028

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 steering group member) Yes

Yes (2013-08-13 for -07)
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 steering group member) Yes

Yes (for -07)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2013-07-17 for -07)
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 steering group member) No Objection

No Objection (for -07)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -07)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -07)

                            

(Richard Barnes; former steering group member) (was Abstain) No Objection

No Objection (for -07)

                            

(Sean Turner; former steering group member) No Objection

No Objection (for -07)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -07)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2013-08-15 for -07)
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 steering group member) No Objection

No Objection (for -07)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (for -07)