Re: [regext] "Considerations" Sections

"Gould, James" <jgould@verisign.com> Tue, 06 November 2018 16:50 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC0A12F1AC for <regext@ietfa.amsl.com>; Tue, 6 Nov 2018 08:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 LSz03lzqjTcW for <regext@ietfa.amsl.com>; Tue, 6 Nov 2018 08:50:22 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD53212F1A5 for <regext@ietf.org>; Tue, 6 Nov 2018 08:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=29983; q=dns/txt; s=VRSN; t=1541523021; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=RCYUb3HJlZs8CCeND9wUmV0iuDciu1wv4OVsgxVlLec=; b=EHKrsRW6W5PapATAqOjwVVUCneYQIvpdOYHeJFkgROsvk/rMyIbUFnjB Fs6UBRIfUQIuWaQBeK3BDD1ffFM+pzbxaBHFhW8mEuCVE2eaiU1TX2Xao cde4iOi1jlAdOE+cF2dYG/6wJe5BFyJcEFOSPcmSqwLcNF5jd+4bwch7p rbeYChmxdvHaRcIr/D/NpQ4YCCUquryCEgupibkdVUxd4xY+eZ0Ps7V4A Xy0B+dw2M3ugDim/k8QzbveIA62z2sFziCB2JAUBXJZqOJTUDQIOayBe7 H4vLDaR94AabRKF81UTs0Bxbva1hqxB5j9AjxL35g3vgZBdMDUMgbCVWD g==;
X-IronPort-AV: E=Sophos;i="5.54,472,1534809600"; d="scan'208,217";a="6369110"
IronPort-PHdr: 9a23:6BaJ1RWXZBJ/3Jobu/3p33nAiqHV8LGtZVwlr6E/grcLSJyIuqrYbRKOt8tkgFKBZ4jH8fUM07OQ7/i/HzRYqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba9wIRmssQndqtQdjJd/JKo21hbHuGZDdf5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXMTRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KptVRTmijoINyQh/W/XlMJ+kb5brhyiqRxxwYHbboCVO+Zxca7GZ9wWWW9BU9xNWyFbAI6xaZYEAeobPeZfqonwv1UCoxq5BQmxAOPg1ydEjWLy06Ig1uQuDxrG0AI9FN8JsnTUo9L1NLoWUe+o16TI0yvMb+lX2Tfm6YjIfRYhreuQUrJ3dMrc0E8iHB7LgFWXrIzqJTKV1uIVvmiF8eVgT+Ovi3UmqwF+pDivx8EshZXTio0JzVDE8CN0y5s2K92gUEN3fMKoHIFNuyyYOYZ6WN4uTmFmtSogxbALuoa3cDUWxJg92hLSaeCLf5KV7h/sV+udOyp0iXF9dLKxmRm/8lSsx+j5W8au01tHqjFKn9zCu3wTyhPe682KReB580qg2zuC0g7e5+9GLE8pk6fQNoQvzaQqlpUJtETOBir2mELrg6CIbkgk4e2o6/j/YrXhu5+cK5d4igHgPaQqncyyGfk1PBQWUWSG+euyzLLt8kzlTLlXlPE2jLXWsJfAJcQDvKK2GRJa3pw96xalFDem1s4UkmUALFJAYB6Hjo7pNE/SIP3gEPuzn06gnCppyv3IJLHtH5XAI3bZnLrufrtx80tcxxAyzdBb6ZJUELYBIPfrV0/zu9zYCQI5MwipzOv8FtVyyJkeWWOUAq+YP6PSt0WE6f4oI+mJfIMVoiryK+A55/7yin80gV4dcre13ZsZc324EOppI0WHbnr2jNcOC2IKvgs6TO3qklGCViRTZ3mqVaIm+j47EJ6mDZvERo21mryOwii7EYNZZ2BaEV2MEGnnd5mKW/sWbyKSOMBhwXQ4Uu3rSoI92zmguQ/30bRuK+vQ62sfr52pnIx06vHdvR8/9TFuAc2Y0mWcCWZukTVMD3Us0a9ysVBVy1qf3+5/mfMSXYhJ6vxEQhsSNJPAwap9Ed+kCSzbedLcAnmhX9GqRXkTR9c82JVGN0RyHMimgjjd0jCrGL4akfqAA5liofGU5GT4O8sokyWO76ImlVRzGsY=
X-IPAS-Result: A2EKAAAUxuFb/zCZrQphAxsBAQEBAwEBAQcDAQEBgVIFAQEBCwGBDYFcgSkKg2yWGCWXMIE/FyAEDAEYAQoLhD4CF4NkNQwNAQMBAQEBAQECAQECgQUMgjYiEksvCQEyAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCAIIBzUSAQEYAQEBAQIBASIKUQcEAgEIEQQBASEKAgICJgodCAIEARIUgw0BgR1cF6hGgS6EMQKFfYwPgUI+gREnDBOCTIMbAQEDgXUKJoI9MYImAo5hhiuKKwMGAoZthg2ELoIijkKNDIoYAgQCBAUCFIFEAYIMcBU7KgGCQQmFf4UUhT5yDSSMI4EfAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Tue, 6 Nov 2018 11:50:16 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1531.003; Tue, 6 Nov 2018 11:50:16 -0500
From: "Gould, James" <jgould@verisign.com>
To: "ietf@feherfamily.org" <ietf@feherfamily.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] "Considerations" Sections
Thread-Index: AdR1pJYa381rKIFaRxukr3d3vLHxXAALQKKAAAoEWED//7fXAIAAT2wA///AdoD//9WYVoAAlJaAgAAKxQCAAHq/gA==
Date: Tue, 06 Nov 2018 16:50:15 +0000
Message-ID: <BB87EF5B-86B0-4203-9D60-AA466B0D4B84@verisign.com>
References: <d250d4aa2e284ab1bc4fdc770770d2d1@verisign.com> <3feaffd7-902a-d9f3-5ff6-58313ef412a8@digitaldissidents.org> <d99249ab1a8a450996d936272e90ebcb@verisign.com> <05858420-677d-4569-82c5-f2fdcccd2eef@digitaldissidents.org> <89c3df7d69844e51aa156210d90052a6@verisign.com> <290edd26-2f7e-35ee-47d6-5708bcabcdd1@digitaldissidents.org> <5B212B3C-45B0-47BD-8BBB-91C6C0E0F0A6@verisign.com> <3f5815ca-e3cb-e696-12cf-c9bd7e4f120f@digitaldissidents.org> <1a4d3364-e138-a2ca-ed8b-5fd30ac0bbe1@feherfamily.org>
In-Reply-To: <1a4d3364-e138-a2ca-ed8b-5fd30ac0bbe1@feherfamily.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.f.0.180709
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_BB87EF5B86B042039D60AA466B0D4B84verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/t7VPkM29qCRZjsJcuQ3jzH78hzI>
Subject: Re: [regext] "Considerations" Sections
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 16:50:26 -0000

KF I wonder if this is a useful observation. I havent heard anyone

suggest that a HRPC section is required, only that it seems very

appropriate for this draft. So it might be appropriate to focus on why

the section should be or should not be present in the context of how an

implementer might consume the document.



I don’t believe adding an HRPC section to draft-ietf-regext-verificationcode will assist the implementer in consuming the draft, but instead will add confusion.  What makes it appropriate for this draft over other drafts?  My recommendation is to focus on addressing any applicable technical elements raised, and as Scott recommended, raise the inclusion of an HRPC section in any draft up to the IETF.



—

JG







James Gould

Distinguished Engineer

jgould@Verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 11/6/18, 11:31 PM, "regext on behalf of Kal Feher" <regext-bounces@ietf.org on behalf of ietf@feherfamily.org> wrote:





    On 6/11/18 10:52 pm, Niels ten Oever wrote:

    > On 11/6/18 1:00 PM, Hollenbeck, Scott wrote:

    >>> On Nov 6, 2018, at 4:32 PM, Niels ten Oever <lists@digitaldissidents.org> wrote:

    >>>

    >>>

    >>>

    >>> On 11/6/18 9:59 AM, Hollenbeck, Scott wrote:

    >>>>> -----Original Message-----

    >>>>> From: Niels ten Oever <lists@digitaldissidents.org>

    >>>>> Sent: Tuesday, November 06, 2018 3:36 AM

    >>>>> To: Hollenbeck, Scott <shollenbeck@verisign.com>; 'regext@ietf.org'

    >>>>> <regext@ietf.org>

    >>>>> Subject: [EXTERNAL] Re: [regext] "Considerations" Sections

    >>>>>

    >>>>>

    >>>>>

    >>>>> On 11/6/18 9:22 AM, Hollenbeck, Scott wrote:

    >>>>>>> -----Original Message-----

    >>>>>>> From: regext <regext-bounces@ietf.org> On Behalf Of Niels ten Oever

    >>>>>>> Sent: Tuesday, November 06, 2018 3:07 AM

    >>>>>>> To: regext@ietf.org

    >>>>>>> Subject: [EXTERNAL] Re: [regext] "Considerations" Sections

    >>>>>>>

    >>>>>>>> On 11/06/2018 09:01 AM, Hollenbeck, Scott wrote:

    >>>>>>>> Following up on the in-room discussion regarding Human Rights

    >>>>>>>> Protocol

    >>>>>>> Considerations as compared to Security Considerations and other types

    >>>>>>> of considerations that appear in IETF documents:

    >>>>>>>> I mentioned at the mic that we don't have any documents representing

    >>>>>>> IETF consensus that provide guidance for writing human rights

    >>>>>>> protocol considerations. It was mentioned that RFC 8280 describes such

    >>>>> guidelines.

    >>>>>>> True, it does, but it's an Informational document that "represents

    >>>>>>> the consensus of the Human Rights Protocol Considerations Research

    >>>>>>> Group of the Internet Research Task Force". RFCs 3552 (Security

    >>>>>>> Considerations) and

    >>>>>>> 8126 (IANA Considerations) are, in comparison, IETF BCPs. So, I'll

    >>>>>>> stand by my comment regarding the lack of _IETF_ consensus on the

    >>>>> topic.

    >>>>>>> Thanks Scott, as you know there are also Privacy Considerations, as

    >>>>>>> outlined in RFC6973, which also do not constitute community consensus

    >>>>>>> but are widely used.

    >>>>>>>

    >>>>>>> Furthermore, if something is not a community consensus, it doesn't

    >>>>>>> mean we MAY/SHOULD/MUST NOT do it.

    >>>>>> True. It also does not mean that we MUST do it. As Jim Galvin noted,

    KF I wonder if this is a useful observation. I havent heard anyone

    suggest that a HRPC section is required, only that it seems very

    appropriate for this draft. So it might be appropriate to focus on why

    the section should be or should not be present in the context of how an

    implementer might consume the document.

    >>>>> it's up to the editor and WG to decide how to address the topic.

    >>>>> My understanding is that at the point of WG adoption, change control is

    >>>>> handed over to the WG, right? So in that case it means that it is up to

    >>>>> the WG.

    >>>> The editor controls the pen. It's the responsibility of the editor to ensure that the text that appears in the document ultimately represents WG consensus.

    >>>>

    >>> I thought that it is up to the WG chair to establish what does or does not constitute consensus.

    >> See Section 6.3 of RFC 2418.

    >>

    >>> Am also a bit confused about the interchangeable use of editor and author here. James is the author, right?

    >> He is the author of the pre-WG version. He is the editor of the WG version that is the subject of WG discussion.

    >>

    > Are you saying that all people who are listed on RFCs that previously have been adopted by WGs are actually editors, and not RFC authors? I think this is not standing practice across the IETF.

    >

    > For instance in the QUIC WG, there are some documents where it is clearly indicated that there is an editor, and and in other cases someone is an author. Compare for instance:

    >

    > https://tools.ietf.org/html/draft-ietf-quic-http-16

    > https://tools.ietf.org/html/draft-ietf-quic-manageability-03

    >

    > Or has there been an agreement in this WG that James is an editor and not an author? Then I think that it should be made clear on the Internet Draft as well.



    KF I have no opinion on the author vs editor debate, but I do wonder if

    there is any utility to continue the discussion on that point.



    There are those who object to including the HRPC section on the basis

    that the technology is agnostic and shouldnt be saddled with moral

    judgement.



    There are those who think the section is a good idea based on the impact

    to those whose data is being shared.



    I'd much prefer a debate on the relevant topics than document pedantry,

    which probably has its place on another list.



    > Best,

    >

    > Niels

    >

    --

    Kal Feher

    Melbourne, Australia