Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
"Songhaibin (A)" <haibin.song@huawei.com> Wed, 30 December 2015 09:18 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 430D31A1B6A; Wed, 30 Dec 2015 01:18:17 -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 Rj8cMLTKYZ5W; Wed, 30 Dec 2015 01:18:14 -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 57AB81A1B69; Wed, 30 Dec 2015 01:18:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGD90554; Wed, 30 Dec 2015 09:18:10 +0000 (GMT)
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 30 Dec 2015 09:18:09 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Wed, 30 Dec 2015 17:18:01 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Thread-Topic: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
Thread-Index: AQHRN7jZcW5g6EknVEW+vQa5IqGiDp7jReww
Date: Wed, 30 Dec 2015 09:18:00 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F65DAB49D@nkgeml513-mbx.china.huawei.com>
References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com>
In-Reply-To: <20151216041827.16193.95293.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5683A153.0021, 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: 27ef7e6dff8ec0cfd0f8b69d31f84b64
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/X60woDicweUKBaJ8vSicI7lLZnQ>
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] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and 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: Wed, 30 Dec 2015 09:18:17 -0000
Dear Barry, See my reply in line. > -----Original Message----- > From: P2PSIP [mailto:p2psip-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Wednesday, December 16, 2015 12:18 PM > To: The IESG > Cc: p2psip-chairs@ietf.org; draft-ietf-p2psip-diagnostics@ietf.org; > p2psip@ietf.org > Subject: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: > (with DISCUSS and COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-p2psip-diagnostics-19: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > For Sections 9.1 and 9.2, I would like to see some evidence of discussion that > resulted in the decision to make the registry policies Standards Action. Did > the working group actually discuss this and make a decision that Standards > Action is right? What's the reasoning for not using some softer policy, such as > "IETF Review" (which might allow for registrations from Experimental > documents) or Specification Required (which would allow review by a > designated expert of a non-RFC specification)? Why is Standards Action the > right thing? > The thought was that if a new value would be used for experimental purpose, then there are reserved values accordingly for overlay local use. And then if people want that value can be used across different RELOAD overlays, then they'd better need a standard track document to define it (that's why we assume it would be standard track). "Specification Required" allows non-RFC specifications, not sure that would reflect the IETF consensus (certain concerns might exist about certain kinds of diagnostic information). > Important note on the previous comment: Please don't just change this: > talk with me. I'm actually asking a question, and it might well be that > Standards Action is right. I want to hear the answer and have a discussion > about it. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In addition to what Ben has already said... > > >From the shepherd writeup: > > "The normal WG process was followed and the document has been discussed > for several years. The document as it is now, reflects WG consensus, with > nothing special worth noting." > > Is it really the case that with *several years* of discussion there's > *nothing* worth pointing out as something that generated discussion? > What were those several years spent on? > > "A review of Section 9.6 was requested to the APPS area and the authors > considered the received feedback." > > Similarly: was there nothing about the feedback that was worth mentioning? > I'm glad the authors considered it... it would have been good to say "the > feedback was only on minor points," or to say what review brought up. > > "The idnits tool returns 5 warnings and 1 comment. They do not seem to be a > problem." > > Well, one of the things that idnits calls out is this: > -- The draft header indicates that this document updates RFC6940, but the > abstract doesn't seem to mention this, which it should. > > I believe it's not a problem that the abstract doesn't mention it, but one > *reason* the abstract doesn't mention it is that the rest of the document > doesn't mention it either. It's not at all clear WHY this document updates > 6940, and that *is* a problem. Why? (This is in support of Ben's comment, > as well as being a question to the shepherd.) The document says it extends one RFC 6940 message and defines one new RELOAD message. I'm not clear whether it is an update or not. > The idnits tool also mentions the pre-5378 disclaimer, and the shepherd > writeup has no information about why the disclaimer is needed. What text is > in this document that is not subject to the IETF Trust terms from BCP 78, and > why is it not? I think this needs an explanation. This has been resolved in another thread. > I strongly agree with Ben's comment about needing explanations for a number > of SHOULDs (and SHOULD NOTs) in the document. RFC 2119 says that for > SHOULD, "the full implications must be understood and carefully weighed > before choosing a different course." Without any explanation, there's no way > for implementors to understand the implications and to weigh anything, and I > tripped over that quite a number of times during my review. It has been replied in another thread w.r.t. Ben's comments. And I agree that after carefully consideration, it's better to change them to "MUST"s. > > I agree with Spencer's comment that we don't usually strong-arm IANA with > 2119 key words. It's a small point, and I don't think IANA are easily offended > [ :-) ], but "IANA is asked to create" is a better approach than "IANA SHALL > create", and so on. We will revise the section and be carefully with those words in IANA section in future documents:) BR, -Haibin Song > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip
- [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2ps… Barry Leiba
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Carlos Jesús Bernardos Cano
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- [P2PSIP] FW: Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)
- Re: [P2PSIP] 答复: Barry Leiba's Discuss on draft-i… Barry Leiba
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)
- Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-… Songhaibin (A)