Last Call Review of draft-ietf-p2psip-concepts-08
review-ietf-p2psip-concepts-08-opsdir-lc-chown-2016-03-23-00

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