Skip to main content

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