Re: [P2PSIP] Joel Jaeggli's Abstain on draft-ietf-p2psip-diagnostics-19: (with COMMENT)

"Songhaibin (A)" <haibin.song@huawei.com> Thu, 31 December 2015 03:05 UTC

Return-Path: <haibin.song@huawei.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BB1A1BA9; Wed, 30 Dec 2015 19:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMHfXS2B2oJL; Wed, 30 Dec 2015 19:05:50 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F251A1BA3; Wed, 30 Dec 2015 19:05:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCH48340; Thu, 31 Dec 2015 03:05:46 +0000 (GMT)
Received: from LHREML701-CAH.china.huawei.com (10.201.5.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 31 Dec 2015 03:05:43 +0000
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 31 Dec 2015 03:05:43 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Thu, 31 Dec 2015 11:05:37 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: Joel Jaeggli <joelja@bogus.com>, The IESG <iesg@ietf.org>
Thread-Topic: Joel Jaeggli's Abstain on draft-ietf-p2psip-diagnostics-19: (with COMMENT)
Thread-Index: AQHRN9RPCAJOs8SfcUCBC7c4ZExXbp7kahdw
Date: Thu, 31 Dec 2015 03:05:36 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F65DAB62F@nkgeml513-mbx.china.huawei.com>
References: <20151216073506.5692.45759.idtracker@ietfa.amsl.com>
In-Reply-To: <20151216073506.5692.45759.idtracker@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56849B8B.002D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 61c351946e24dd02350ac0a43cbcb67d
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/9ezJQ3RqAnGrj-7adVaaKbjorjI>
Cc: "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "draft-ietf-p2psip-diagnostics@ietf.org" <draft-ietf-p2psip-diagnostics@ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>
Subject: Re: [P2PSIP] Joel Jaeggli's Abstain on draft-ietf-p2psip-diagnostics-19: (with COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 31 Dec 2015 03:05:53 -0000

Dear Joel,

Please see my reply in line.

> -----Original Message-----
> From: Joel Jaeggli [mailto:joelja@bogus.com]
> Sent: Wednesday, December 16, 2015 3:35 PM
> To: The IESG
> Cc: draft-ietf-p2psip-diagnostics@ietf.org; p2psip-chairs@ietf.org;
> cjbc@it.uc3m.es; p2psip@ietf.org
> Subject: Joel Jaeggli's Abstain on draft-ietf-p2psip-diagnostics-19: (with
> COMMENT)
> 
> Joel Jaeggli has entered the following ballot position for
> draft-ietf-p2psip-diagnostics-19: Abstain
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Mhement Ersue did the opsdir review,

Thanks.

> 
> While I would not prevent this document on a technical basis I would hope very
> strongly that in addressing the discusses that further refinement can improve
> the proposed standard... where that done I'd be happy to ballot no objection.
> 
> -----------
> 
>  reviewed the document "P2P Overlay Diagnostics"
> (draft-ietf-p2psip-diagnostics-19.txt) as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the operational area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> 
> Intended status: Standards Track
> Updates: 6940 (if approved)
> Current IESG state: In Last Call (ends 2015-12-14) IANA Review State: IANA -
> Not OK (see for IANA comments at:
> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/history/)
> 
> Summary: The document describes mechanisms for P2P overlay diagnostics.
> It defines extensions to the RELOAD P2PSIP base protocol to collect diagnostic
> information, and details the protocol specifications for these extensions.
> 
> Comments:
> - The document is not easy to read and the clarity could be improved.

If it can be more specific, then it will be more helpful.

> - It is common practice and rule to mention in the document abstract the RFC
> which is going to be updated.

This will be resolved in another discussion thread that whether it updates RFC6940.

> - There are many occurrences of the word “should”. Are these meant to be
> normative language and “SHOULD”?

No, "should"s are not normative language in this document.

> 
> - There are different terms used in the first few sections, which are not
> introduced properly. One substantial term the reader is surprised with is
> "diagnostic kind type".

It is a language problem, "diagnostic Kind" is more clear than "diagnostic kind type". I can revise that.

> - I believe the basic terms used in the document should be defined in a
> Terminology section if not defined in RFC 6940. The Terminology section should
> mention that the terminology from RFC 6940 is used.
> - The term "Kind" has been defined in RFC 6940. If the term "kind" is to be used
> as defined in RFC 6940 it should be used with a capital "K".

It has already mentioned concepts from RFC6940 are used in the terminology section. The suggestion to change "kind" to "Kind" is correct and accepted.

> - There are different very long sentences and a few 5-to-6-part-substantives
> which don't contribute to readability (e.g.:
> “single, general P2PSIP overlay diagnostic framework”).

What about changing it to "a P2P overlay diagnostic framework ..."?

> - Concerning: "The second is a new method and response, PathTrack,"
> I would like to suggest to delete "and response" or call it "a new
> request/response method".

Accept.

> 
> The idnits tool returns one error and numerous warnings which need to be fixed
> (13 warnings, 2 comment and 1 error).
> See
> http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-p2psip-diagno
> stics-19.txt

The warnings of references (TBD1...TBD8) will be resolved after those numbers are assigned by IANA. Actually although they are embraced by square brackets, they are not references, but only the numbers to be determined. I do not understand why there are the following two warnings:
"  == Line 337 has weird spacing: '...ionType  type;...'

  == Line 531 has weird spacing: '... opaque  diagn..."

The comment for document date is invalid now as we run idnits tool today. And the other comment will be resolved in another thread on whether it updates RFC6940.
I will check why there is 1 error about too long lines in the document, and it will be easily solved.

Thanks again,

-Haibin Song