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

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.

I agree with Alissa's and Brian's comments

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.

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."

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