Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The current security consideration section is extremely limited.
I understand that the additional risks introduced by the current
specification are limited. I also understand that securing PIM is a
problem by itself, that is well beyond the goals of this section
(e.g. it is currently being considered in the KARP WG).

However I'd appreciate if the authors can improve the current section:

** clarify that the main risk is the fact different RPs be selected for the
same group. Is there anything else? E.g. can forged control messages
lead PIM routers to point to a non existing RP for some (all?) groups
which would cause a DoS? (I have no idea if this is feasible or not, it's
just an example).

** the following sentence is ambiguous.
  "The updated algorithm will not completely prevent the possibility of
   different routers selecting different group-to-rp mappings for the
   same group."
It suggests (but does not say explicitly) that the updated algorithm
reduces the possibility of selecting different RP for the same group.
Is it the case?

** the last sentence is the key sentence and it MUST be developed.
What does:
"if various mechanisms [...] are secure and consistent across the network"
mean? You don't have to give answers (as I said it's a problem by itself
that deserved a specific WG to be created). However you can give a
few pointers, and illustrate with a simple attack that can make the
choice incoherent across the network, etc.

I hope these comments are useful.
Regards,

   Vincent

---
Two typos:

* section 2: "Wherever this term in used in this document..." -> "is"

* section 6: it is said (bullets 5, 6 and 7):


       *  If there is only one entry available then that is selected as 


Group-to-RP mapping.



I suggest: "... then that entry is selected..."