Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
"Songhaibin (A)" <haibin.song@huawei.com> Thu, 25 February 2016 03:10 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 C12161B2ECA; Wed, 24 Feb 2016 19:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 9kx4d-NGdFn0; Wed, 24 Feb 2016 19:10:33 -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 09C331B2EC1; Wed, 24 Feb 2016 19:10:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJD04337; Thu, 25 Feb 2016 03:10:28 +0000 (GMT)
Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 03:10:27 +0000
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 25 Feb 2016 03:10:26 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Thu, 25 Feb 2016 11:10:19 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: Alissa Cooper <alissa@cooperw.in>, Barry Leiba <barryleiba@computer.org>
Thread-Topic: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
Thread-Index: AQHRN7jZcW5g6EknVEW+vQa5IqGiDp7jRewwgC3qCQCAAAWVAIABZu+AgCniSUA=
Date: Thu, 25 Feb 2016 03:10:19 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F65DBDE51@nkgeml513-mbx.china.huawei.com>
References: <20151216041827.16193.95293.idtracker@ietfa.amsl.com> <E33E01DFD5BEA24B9F3F18671078951F65DAB4AF@nkgeml513-mbx.china.huawei.com> <D0BF613A-D35C-4BDF-8FD0-6BC8EB5B7E18@cooperw.in> <CALaySJ+QjHHfPxWFvG=8XvB9oz=1wpPQskw0-SwgVLt2uzUe3g@mail.gmail.com> <E3A881B6-BC75-4A9E-947F-13C490C9C59B@cooperw.in>
In-Reply-To: <E3A881B6-BC75-4A9E-947F-13C490C9C59B@cooperw.in>
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.0A0B0205.56CE70A4.0129, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.112, 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/5b2q0qfxU8jZTNDWzSwOxlPf2vY>
Cc: "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "draft-ietf-p2psip-diagnostics@ietf.org" <draft-ietf-p2psip-diagnostics@ietf.org>, IESG <iesg@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: Thu, 25 Feb 2016 03:10:37 -0000
Dear Alissa and all, I did the editing job and have submitted a new version of the document according to the comments received and the discussion in the list. I also add some text in the change history appendix for it. Please check if the updated version has addressed your comments. https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-20 I keep the intended status of the document as it is. Alvaro thought Experimental might be a better status, when I check the change history in the document, as it is defined as a mandatory RELOAD extension, the current intended status seems suitable. Otherwise we need go through another WGLC to change the intended status. "C.7. Changes in version -10 Resolve the authorization issue and other comments (e.g. define diagnostics as a mandatory extension) from WGLC. And check for the languages. " Best Regards! -Haibin > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Saturday, January 30, 2016 3:13 AM > To: Barry Leiba > Cc: IESG; Roni Even; p2psip-chairs@ietf.org; > draft-ietf-p2psip-diagnostics@ietf.org; p2psip@ietf.org; Songhaibin (A) > Subject: Re: [P2PSIP] Barry Leiba's Discuss on draft-ietf-p2psip-diagnostics-19: > (with DISCUSS and COMMENT) > > I looked through the mailing list archives and the meeting minutes from the > meetings around the time when the registration policy was added to the > document (the -01). I did not see any discussion of the registration policy. > > I fully agree with Haibin’s analysis, though, which is that the potential for > introducing sensitive diagnostic types (e.g., location) is sufficient to make > Standards Action or IETF Review a good choice. These should get IETF-wide > security review before being added to the registries. > > Alissa > > > On Jan 28, 2016, at 1:47 PM, Barry Leiba <barryleiba@computer.org> wrote: > > > >> Does Haibin’s answer clear up your concern? > > > > Sorry, it must have gotten lost in the end-of-year mess. > > > > No, it doesn't: Haibin gives his thoughts on the question, but I asked > > about what discussion the working group had in coming to the decision. > > Further comment: > > > >>> 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 (0xF000-0xFFFE). 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). > > > > Yes, "Specification Required" allows non-RFC specifications, with a > > designated expert to review the request and sanity-check it. Why does > > the working group think this registry needs only Standards Track RFCs > > to make registrations? Why can't IETF consensus approve a > > non-Standards-Track RFC (as with "IETF Review")? Why couldn't a > > designated expert handle the review, consulting with whatever > > appropriate working group(s) exist at the time (as with "Specification > > Required")? > > > > I'm honest OK with Standards Action if that's really what the working > > group wants, and they have a reasonable explanation for why that's > > necessary here. I'm asking because I can't see any evidence that it > > was actually discussed, and I'm concerned that we consistently use > > too-strict registration policies because we think they're necessary, > > and that often bites us later on, when we wish we hadn't been so > > strict. > > > > Can you point me at any messages or minutes that show the working > > group discussion about the registration policy? Can the working group > > explain what harm could be caused if registrations were allowed to be > > made without Standards Track RFCs? > > > > Barry
- [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)