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

"Songhaibin (A)" <haibin.song@huawei.com> Fri, 16 August 2013 07:20 UTC

Return-Path: <haibin.song@huawei.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42C921F99FD for <p2psip@ietfa.amsl.com>; Fri, 16 Aug 2013 00:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebUzGeheuBnB for <p2psip@ietfa.amsl.com>; Fri, 16 Aug 2013 00:20:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6401321F9815 for <p2psip@ietf.org>; Fri, 16 Aug 2013 00:20:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWB58146; Fri, 16 Aug 2013 07:19:59 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 16 Aug 2013 08:19:16 +0100
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 16 Aug 2013 08:19:52 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.203]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Fri, 16 Aug 2013 15:19:49 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>
Thread-Topic: Review of draft-ietf-p2psip-diagnostics
Thread-Index: AQHOjkR9jmG79cPdEEWjVWLtAbH0s5mMmCgggAVD2YCABaYlgA==
Date: Fri, 16 Aug 2013 07:19:48 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F247447AE@nkgeml501-mbs.china.huawei.com>
References: <1375312771.4417.7.camel@acorde.it.uc3m.es> <E33E01DFD5BEA24B9F3F18671078951F247206AF@nkgeml501-mbs.china.huawei.com> <1376355123.4168.13.camel@acorde.it.uc3m.es>
In-Reply-To: <1376355123.4168.13.camel@acorde.it.uc3m.es>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.66]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "p2psip@ietf.org" <p2psip@ietf.org>, "draft-ietf-p2psip-diagnostics@tools.ietf.org" <draft-ietf-p2psip-diagnostics@tools.ietf.org>
Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2013 07:20:13 -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:cjbc@it.uc3m.es] 
Sent: Tuesday, August 13, 2013 8:52 AM
To: Songhaibin (A)
Cc: p2psip@ietf.org; draft-ietf-p2psip-diagnostics@tools.ietf.org
Subject: Re: Review of draft-ietf-p2psip-diagnostics

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.

> 
> 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.
> 
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
> 
> BR,
> -Haibin
> 
> 
> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] 
> Sent: Thursday, August 01, 2013 7:20 AM
> To: p2psip@ietf.org
> Cc: draft-ietf-p2psip-diagnostics@tools.ietf.org
> 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
>