Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 1 Aug 2013 09:37:27 +0000

Hi Carlos,

We will carefully go through these comments. If we have something to clarify, we will send to the list. Thank you very much for the review.

BR,
-Haibin

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
Sent: Thursday, August 01, 2013 7:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Review of draft-ietf-p2psip-diagnostics

Hi,

I've performed a Document Shepherd review of draft-ietf-p2psip-diagnostics. My review is attached to this e-mail (I added comments to the PDF version of the draft, hope this is fine).

I'd like authors to go through the comments before sending the document to the IESG. There might be some issues that need to be brought to the WG for discussion.

Thanks,

Carlos

---

From: "Songhaibin (A)" <[email-masked]>
Date: Fri, 9 Aug 2013 08:33:14 +0000

Thank you again, Carlos. Here is my feedback to you document shepherd review. I also had an email discussion with my co-authors.

Most of the comments are editorial and I agree on them. I copied the comments which are not editorial with my feedback below.

Section 2: What does "compatible" mean here? Also, depending on the discussion we are going to have about -concepts in the WG, it might be needed to remove this ref.
[Haibin] We will just use the word "use" instead of "compatible". We can remove this reference to the -concepts, and will refer to the -base document because it has definitions for terminologies we need.

Section 5.1.3: How is congestion measured? How are these 4 bits used? This should be explained more carefullt, especially to ensure interoperability/compatibility, as not all the nodes might report/measure in the same way
[Haibin] I agree this is a problem. But this document is not going to provide a measurement method for the congestion. I feel that a node can contemplate its CPU/Memory/Bandwidth usage percentage in the past seconds and normalize the highest value to the range [0x00, 0x0F], we can just reserve the bits and leave it for this purpose, but it will be defined in a future draft.

Section 5.1.4, paragraph 2: Remove this part, and/or bring it to the list to discuss what to do about it.
[Haibin] We will remove it.

Section 5.5.2, paragraph 3: Does this spec requires clock synchronization? (or adds more requirements on this aspect compared to -base) Some text clarifying this issue would be helpful
[Haibin} I think here we need a decision from the WG. We need careful consideration on how to use the timestamp because time synchronization is a barrier in open Internet environment, while in a managed environment, it may be less of a problem. Do we want to enforce the time synchronization or do we want to lose a feature to check the message expiration? We have to make a choice.

Section 7: I think this section is repetitive (the same content is in 10.6). I'd remove it from here and leve it in 10.6
[Haibin] ok.

BR,
-Haibin

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
Sent: Thursday, August 01, 2013 7:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Review of draft-ietf-p2psip-diagnostics

Hi,

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 13 Aug 2013 02:52:03 +0200

Hi Haibin,

Thanks for your reply. Please see my comments inline below.

On Fri, 2013-08-09 at 08:33 +0000, Songhaibin (A) wrote:
> Thank you again, Carlos. Here is my feedback to you document shepherd
> review. I also had an email discussion with my co-authors.
> 
> Most of the comments are editorial and I agree on them. I copied the
> comments which are not editorial with my feedback below.
> 
> Section 2: What does "compatible" mean here? Also, depending on the
> discussion we are going to have about -concepts in the WG, it might be
> needed to remove this ref.
> [Haibin] We will just use the word "use" instead of "compatible". We
> can remove this reference to the -concepts, and will refer to the
> -base document because it has definitions for terminologies we need.
> 
Well, now that the WG has decided to resume the work on -concepts, you
can keep the reference.
> 
> Section 5.1.3: How is congestion measured? How are these 4 bits used?
> This should be explained more carefullt, especially to ensure
> interoperability/compatibility, as not all the nodes might
> report/measure in the same way
> [Haibin] I agree this is a problem. But this document is not going to
> provide a measurement method for the congestion. I feel that a node
> can contemplate its CPU/Memory/Bandwidth usage percentage in the past
> seconds and normalize the highest value to the range [0x00, 0x0F], we
> can just reserve the bits and leave it for this purpose, but it will
> be defined in a future draft.
> 
I think some adding some informative text then would help.

> [Haibin] We will remove it.
OK.
> 
> Section 5.5.2, paragraph 3: Does this spec requires clock
> synchronization? (or adds more requirements on this aspect compared to
> -base) Some text clarifying this issue would be helpful
> [Haibin} I think here we need a decision from the WG. We need careful
> consideration on how to use the timestamp because time synchronization
> is a barrier in open Internet environment, while in a managed
> environment, it may be less of a problem. Do we want to enforce the
> time synchronization or do we want to lose a feature to check the
> message expiration? We have to make a choice.

Please, bring this to the ML in a separate thread and try to get
feedback from WG participants, especially those with implementation
experience, such as Marc.
> 
> Section 7: I think this section is repetitive (the same content is in
> 10.6). I'd remove it from here and leve it in 10.6
> [Haibin] ok.
> 
OK, thanks,

Carlos

---

From: "Songhaibin (A)" <[email-masked]>
Date: Fri, 16 Aug 2013 07:19:48 +0000

Hi Carlos,

Thank you for your reply and Please check if the updated version addressed your comments.

http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-13

We did not change the reference of UNIX time to the Wikipedia site so as to keep it consensus with the base protocol document. If you have any reference to UNIX time, we can also replace it.

I have posted the time synchronization issue to the list. IMHO, we can make the timestamp bit fields reserved but leave how to use them optional, for example, in the managed environment, the overlay can enforce time synchronization and use the timestamp for anti-replay attack or one-way-delay measurement, but in open Internet environment where nodes can be personal equipments, the overlay can just use them in another way. How does it sound?

BR,
-Haibin

-----Original Message-----
From: Carlos Jesús Bernardos Cano [mailto:[email-masked]] 
Sent: Tuesday, August 13, 2013 8:52 AM
To: Songhaibin (A)
Cc: [email-masked]; [email-masked]
Subject: Re: Review of draft-ietf-p2psip-diagnostics

Hi Haibin,

OK.

OK, thanks,

Carlos