Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Please note in this review and comments that P2PSIP is not an area I have followed closely, though I am familiar with distributed messaging/storage systems, DHTs, etc.  I found the draft generally easy to read and follow, though I have suggestions for improvement further below, with a small number of suggested minor corrections. Overall I believe the document is Ready with Nits. The draft presents an overview of the concepts behind the operation of SIP in a peer-to-peer model, rather than the more classic client-server model. It explains the rationale for a distributed architecture, gives an example of how an overlay network might look using P2PSIP, defines the terminology used, and discusses various aspects of the operation of the overlay, including joining it, and the lookup of Contact URIs. The draft seems to have had a long history, with the original -00 personal ID dating back to 2007, and the first WG adopted draft appearing in 2009. The updates since then have been sporadic. It appears the WG has instead focused on the selection and definition of the solution protocol, and presumably is now seeking to publish this document as a ‘retrospective background’ to the definition of that protocol, i.e. the Resource Location and Discovery (RELOAD) Base Protocol.  This seems an appropriate thing to do, should anyone wish to look back at how RELOAD was arrived it.  RELOAD was published in January 2014 as RFC 6940. It  provides a solution to the problem discussed in the  p2psip-concepts draft, specifying how clients can use an abstract storage and messaging service between cooperating peers in an overlay network. The RELOAD specification is detailed, running to 175 pages, and went through 26 revisions since its original WG 00 version (draft-ietf-p2psip-base-00) was posted back in 2009. So there also appears to be a long history to the eventual publication of the solution protocol. Comments: 1) There’s a very long list of definitions. As I read the discussion section 5, I was referring back to these. I would recommend putting the definitions in alphabetic order to make looking them up faster. 2) RELOAD includes a security model which is not discussed in this draft. It would be good to see a section added to discuss at least the *concepts* of that security model, to complement the other concepts discussed in the draft. I think purely pointing to the security content of RELOAD leaves a bit of a gap in understanding the original rationale for the RELOAD security model. Nits: a) In 2.5, say Contact URI, not just Contact?  And perhaps use a term such as looking up, rather than turning. b) Also in 2.5, there is now work in the dnssd WG in scalable DNS based service discovery, so seeing concerns about scalability expressed here without reference to that appears a bit of a gap (though I am a little biased as co-chair of that WG).  RFC 7558 is one reference that could be used here to point to the ongoing work, and/or draft-ietf-dnssd-hybrid-03. c) In 2.6, presumably if all clients/peers are IPv6, this goes away. One might add a comment that in a pure IPv6 overlay, the architecture / complexity is simplified? d) In the discussion, some definitions expressed in upper case are used in lower case form here.  e.g. Resource-ID and resource-id. Is it worth being consistent? e) In 5.4, it may be a personal preference, but seeing the text say ‘broadcast’ to a multicast address seems wrong. Just ‘send’ ?  And perhaps say multicast bootstrap group address, adding ‘group’. f) In 5.6, there is a much more detailed architecture description in the RELOAD RFC - perhaps point explicitly to that too. Tim