Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments
RFC 7063

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

(Spencer Dawkins) Yes

(Adrian Farrel) Yes

(Brian Haberman) (was Discuss) Yes

Comment (2013-09-11 for -02)
No email
send info
Thanks for addressing my question.  I look forward to the advancement of 4601bis.

(Jari Arkko) No Objection

Comment (2013-09-12 for -02)
No email
send info
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.

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-09-09 for -02)
No email
send info
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."

(Stephen Farrell) No Objection

Comment (2013-09-12 for -02)
No email
send info
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."

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-09-11 for -02)
No email
send info
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.

(Ted Lemon) No Objection

Comment (2013-09-09 for -02)
No email
send info
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...   :)

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

(Pete Resnick) Abstain

Comment (2013-09-11 for -02)
No email
send info
As Barry said, this is more for IESG conversation and not about this document per se, but I had the same reaction he did: Is there really a reason to publish interoperability reports of this sort as RFCs? Why not just put this information into the writeup for 4601's move to IS? I don't think there's any significant harm in publishing this, but it doesn't seem necessary.