Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments
draft-ietf-pim-rfc4601-update-survey-report-03

I have no objection to publishing this document, I think it's a very fine thing for us to do interoperability reports, and I'd be happy to see more of them.  So take the following comments with that in mind, and also with the note that they're mostly meant for the IESG to ponder.

Will there be real value to this document a year or two from now?  Is there real value in having this as a snapshot, frozen in time, rather than as a wiki page that can be updated with new information and further experience?

Mostly, I think we should be publishing these sorts of things in more streamlined ways, and in ways that allow ongoing work on them.

But again, this is NOT an objection to publishing this document.  Just something I'd like us to think about.

You went into some explanation of the process in 1.2. Even with some history (RFC 2026 versus RFC 6410). Fine.
However, I don't understand why you only listed 2 of the 4 conditions from RFC 6410

   Section 2.2 of [RFC6410] states that:"(1)
   There are at least two independent interoperating implementations
   with widespread deployment and successful operational experience. (3)
   There are no unused features in the specification that greatly
   increase implementation complexity."

Christer Holmberg made a Gen-ART review of this document and had a number of editorial comments. Do the authors want to respond to those comments in some way? From my perspective, the comments seemed very reasonable suggestions.

I think it'd be fine to add the information from the
response to Sean's earlier discuss (copied below to
make that easier) into the security considerations.
That is, I'm suggesting to add a paraphrase of:

"FWIW, I am aware of at least two implementations (but I
expect there are more) where you can use IPsec to protect
PIM messages.

For at least one of them, IPsec is not part of the PIM
implementation at all, you just configure IPsec with SPDs
where interface, the ALL_PIM_ROUTERS multicast address
etc. can be used as selectors, according to RFC 5796."

Section 3 doesn't say anything, but I noticed that earlier in the document it was mentioned in section 2.3.2 that (*,*,RP) was not implemented in some cases due to security concerns.   If those concerns were real, might it be worth mentioning what they were in section 3?

There are a surprising number of page breaks in this document...   :)