-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 protected]
Professional email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5IERIACgkQ9RoMZyVa61cDmACglWMsJRxCvddS/7QtGkNE8NiY
pTwAn3o2W24CXP/Wsx98csYNZV3wnrDT
=QPgB
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to