Subject: [P2PSIP] Review of draft-ietf-p2psip-concepts-03

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 14 Aug 2011 11:16:51 -0700

1. Section 3, third paragraph.

To improve the reading flow of section 3 as a whole, I would suggest to replace
the first sentence by this:

"A P2PSIP Overlay consists of one or more nodes called Peers and may also
include Clients."

2. Section 3.5 OPEN ISSUE

I would suggest to move this whole section into a "Design Notes" appendix at the
end of the document.  See also comment 10.

3. Section 4, 2rd paragraph "SIP Redirector"

I would suggest to use "SIP Redirect Server" instead, as defined in RFC 3261
Section 6.

4. Section 5: Peer-ID

All the other drafts use the "Node-ID" terminology, so why not invert the
definition, I.e. define Node-ID and says that this is sometimes called a
"Peer-ID"?  See also the definition of "Peer" and Section 6.4 that both use
"Peer-ID".

5. Section 5: Resource Record

Not a comment on this draft, but I like this term more than the terms that are
used in other drafts (e.g. PDU in p2psip-sip, or structure in
p2psip-service-discovery).  I will propose this change when I will review the
other drafts.

6. Section 5: Responsible Peer

I did not read all the literature on the subject, but I never saw the term "Root
Peer" used as synonym for "Responsible Peer."

7. Section 6.4, second paragraph: "The P2PSIP WG..."

Replace by "This document..."

8. Section 6.4, third paragraph

This paragraph talks about "multicast-bootstrap", but it should also talk about
unicast bootstrap (or s/multicast-bootstrap/bootstrap/)

9. Security Section

Security section missing.

10. Section 7 Open Issues

As an implementer that is constantly confronted to interoperability issues, I
think that preserving the reasons why decisions were made is really important
and should be part of each RFC as an appendix.  This would prevent a lot of
guessing when future implementers who never participate in the discussion will
start working on this.

I have no opinion on the use cases.

Nits
====

- - Abstract

s/mechansims/mechanisms/

An abstract should not contain references.

- - Section 1.

s/eselection/selection/

- - Section 3.

"Session Initiation Protocol (SIP)" is already defined in Section 2, so using
only "SIP" is OK.

- - Section 6.1

s/resource-id/Resource-ID/
s/resource record/Resource Record/

- - Section 6.2

s/resource record/Resource Record/

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 25 Aug 2011 15:22:07 -0700

Thanks for the comments. I'm working on a new version. Many of these are
great suggestions and require no comment, but a few comments on a few are
inline:

4. Section 5: Peer-ID
> "Peer-ID"?  See also the definition of "Peer" and Section 6.4 that both use

Actually,back in the day there was a long discussion on this, and Node-ID
was decided (by the group) as the preferred term. Despite that, as things
evolved the editors of base used Peer-ID, and it stuck. (particularly
unfortunate since RELOAD gives Peer-IDs to clients). In any case, the name
has stuck, and I'll definitely make the change.

> Peer" used as synonym for "Responsible Peer."

It is used quite a bit in the early academic literature (again going back to
when this was first written), but I agree responsible peer is used more now
(and is better for an arrangement-agnostic design like RELOAD anyway)

9. Security Section
> Security section missing.

This is an interesting point. Since it has turned out that security is
discussed in more detailed context in the specific drafts, do we want
something like this in here, and if so, what do we want in this draft? My
thought would be either a) we don't have a security section in here or b) we
have a generic section on P2P security threats, but although I'm making the
other changes, I'm not sure I'll have time to write something like that.

Thoughts on that?

David (as individual)

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 25 Aug 2011 18:57:09 -0400

> has stuck, and I'll definitely make the change.

Just to make sure, I think the explanation was backward.  The group
decided to use the term "Peer-ID" but as we edited the base draft, we
got tired of writing the phrase "Peer-ID of a peer or Client-ID of a
client" and just used "Node-ID" because it was clearer.

Bruce

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 25 Aug 2011 15:58:03 -0700

On 08/25/2011 03:22 PM, David A. Bryan wrote:
> Thanks for the comments. I'm working on a new version. Many of these are great
> suggestions and require no comment, but a few comments on a few are inline:
> 

[...]

> This is an interesting point. Since it has turned out that security is discussed
> in more detailed context in the specific drafts, do we want something like this
> in here, and if so, what do we want in this draft? My thought would be either a)
> we don't have a security section in here or b) we have a generic section on P2P
> security threats, but although I'm making the other changes, I'm not sure I'll
> have time to write something like that.
> 
> Thoughts on that?

My comment was more about the fact that such section is mandatory, according to
RFC 2223.

Because this spec is for "Peer to Peer SIP", not "Peer to Peer", I do not think
that a generic section on P2P security threats is needed.  Perhaps it is OK to
just say that the security sections of p2psip-base and p2psip-sip cover everything.

- -- 
Marc Petit-Huguenin