Subject: RE: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00

From: JiangXingFeng <[email-masked]>
Date: Thu, 10 May 2007 14:14:27 +0800

Sorry for delay response because of  seven day's Labor Day holiday in China.

Please see inline.

________________________________________
From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Tuesday, May 01, 2007 9:36 AM
To: [email-masked]
Subject: [P2PSIP] Comments on
draft-jiang-p2psip-peer-protocol-requirement-00

It seems this draft is a little out of update and probably needs some
re-organization as well.

1. First and foremost the draft needs to split requirements in more
categories: requirements pertaining to operate the p2p network itself
(join/leave/updates and other operations required for p2p network to work)
should be separate from transport level. It seems that other drafts are
talking about transport and control connections separate from the p2p
protocol itself and the draft needs to lay down requirements for these
separately from the p2p protocol. 
[JiangXingFeng] When I was writing this 00 draft, the criteria for
organizing requirements in my mind is : requirements on P2P overlay
maintenance and routing, including NAT traversal inherent in P2P
communication are called basic requirements.  On the other side, transport
protocol is very important for P2PSIP, so I place it into the basic
requirements. Some other requirements such as availability and efficiency
which are necessary to upper applications are called advanced requirements.

Maybe the further classification should be taken in the basic requirements.
But at present, I don't see any convincing reasons to do this in requirement
draft. 

2. At the p2p protocol level, the requirements are very vague and say too
little. In my understanding, they don't help much at this point to
specifically serve as guidance when choosing SIP or a new protocol
(comparing the bryan and henning drafts here). 

[JiangXingFeng] Yes, as a zero draft, it is relative rough. I will flesh it
out in the coming revision. On the other side, it is hard to make some
requirement more detailed than written in the draft. Any more detailed
description will be considered as specific solution which will not in the
scope of requirements and incur a lot of argument. 

3. Security requirements for the p2p protocol don't exist. There is a
section on security, but I am not sure it is giving any requirements for the
p2p protocol or the control connection protocol or transport. 

[JiangXingFeng] In the 00 draft, I only list some problems and threats in
P2P security, not present specific requirement. Next revision will address
it. 

4. Diagnostics collection is quite important, more so since there is no
management. I think requirements should be there for this as well since
diagnostics should be built into the protocol as well to test if it is
working properly. 
[JiangXingFeng] good suggestion, I will consider it in the next revision. 
Medhavi.

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 10 May 2007 07:04:43 -0700

>4. Diagnostics collection is quite important, more so since there is no
management.

> I think requirements should be there for this as well since
diagnostics should be built into the 

>protocol as well to test if it is working properly.

This is an interesting point and I sympathize with it, since the
serious, experimental P2P R&D has shown plenty of tools to assess
performance, such as those published for the openDHT. 

(I must confess my bias: Any P2P proposal not based on measured
performance is worthless).

Can you elaborate with any suggestion or references?

Thanks, Henry

________________________________

From: Medhavi Bhatia [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 8:36 PM
To: [email-masked]
Subject: [P2PSIP] Comments on
draft-jiang-p2psip-peer-protocol-requirement-00

1. First and foremost the draft needs to split requirements in more
categories: requirements pertaining to operate the p2p network itself
(join/leave/updates and other operations required for p2p network to
work) should be separate from transport level. It seems that other
drafts are talking about transport and control connections separate from
the p2p protocol itself and the draft needs to lay down requirements for
these separately from the p2p protocol. 

2. At the p2p protocol level, the requirements are very vague and say
too little. In my understanding, they don't help much at this point to
specifically serve as guidance when choosing SIP or a new protocol
(comparing the bryan and henning drafts here). 

3. Security requirements for the p2p protocol don't exist. There is a
section on security, but I am not sure it is giving any requirements for
the p2p protocol or the control connection protocol or transport. 

Medhavi.