Skip to main content

Explicit Reverse Path Forwarding (RPF) Vector
draft-ietf-pim-explicit-rpf-vector-09

Yes

(Alvaro Retana)

No Objection

(Barry Leiba)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)

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

Alia Atlas Former IESG member
Yes
Yes (2016-01-05 for -07) Unknown
I agree with Brian's comment about clear applicability and with Alissa's
comments on the "we" language.
Alvaro Retana Former IESG member
Yes
Yes (for -07) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2016-01-05 for -07) Unknown
I find the use of the word "we" in this document to be confusing. Sometimes it seems to refer to the authors or the WG ("we're defining a new attribute") and sometimes to implementations ("we use the RPF Vector stack"). Particularly problematic is the use of a normative requirement on an ambiguous "we" (Section 1): "For these vectors we MUST NOT do a unicast route lookup." I would suggest replacing every instance of "we" with the appropriate subject, e.g., "the router" or "this document," or leaving the subject out altogether.
Barry Leiba Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-01-05 for -07) Unknown
I agree with Alissa's and Brian's comments
Brian Haberman Former IESG member
No Objection
No Objection (2016-01-04 for -07) Unknown
I support the publication of this document, but I do have two points I would like you to consider...

1. The use of 2119 keywords in the Introduction are inappropriate. They can easily be changed to non-normative words and the meaning will not be lost.

2. While this approach is viable, and needed, in a subset of deployment scenarios, it is also inappropriate for other scenarios. I think some guidance on when to use, or not use, this option would be useful as an addendum to the motivation provided in section 3.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-01-05 for -07) Unknown
I may have missed it, but don't see a response to the SecDir review.  In particular, the last question would be good to see answered/elaborated on in the security considerations section.

https://www.ietf.org/mail-archive/web/secdir/current/msg06295.html
"Also, the security consideration section in ietf-pim-rfc4601bis document
discusses the impact of a forget Join message and its implication on the
multicast traffic. You might want to add some text to explain if this new
attribute, defined in this document, changes the implication of a forged
Join message or not; if it does, you might want to explain how."
Martin Stiemerling 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 (2016-01-06 for -07) Unknown

Please take the comments below with a pinch of salt - I'm
not sure I understood what this was specifying so I may be
off base below. (Mind you, this caveat is also a comment
of sorts;-)

abstract: "RP" could be interpreted as reverse path or
rendezvous point, suggest expanding this in the abstract.

section 7: I don't understand: "A router processing
'Explicit' or 'Loose' RPF Vectors MUST verify that the
order in which RPF Vectors types appear in the PIM Join
Attribute list received from its downstream PIM neighbors
are equal." Seems like a bad plan to have a MUST in such a
hard to grok sentence. Or is that just me? (Actually, that
entire paragraph is hard to get.)

- section 12: couldn't this allow one node to try DoS
another by including it in the vector? Isn't that worth
noting?

- please also respond the secdir review [1] which raised a
couple more points.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06295.html