Re: [regext] "Considerations" Sections

Niels ten Oever <lists@digitaldissidents.org> Tue, 06 November 2018 17:02 UTC

Return-Path: <lists@digitaldissidents.org>
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 3329612F1A5 for <regext@ietfa.amsl.com>; Tue, 6 Nov 2018 09:02:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7s4CtmLuItlE for <regext@ietfa.amsl.com>; Tue, 6 Nov 2018 09:02:27 -0800 (PST)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B0212D4EB for <regext@ietf.org>; Tue, 6 Nov 2018 09:02:26 -0800 (PST)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <lists@digitaldissidents.org>) id 1gK4kC-0004tO-Si for regext@ietf.org; Tue, 06 Nov 2018 18:02:25 +0100
To: regext@ietf.org
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> <BB87EF5B-86B0-4203-9D60-AA466B0D4B84@verisign.com>
From: Niels ten Oever <lists@digitaldissidents.org>
Openpgp: preference=signencrypt
Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= xsFNBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABzShOaWVscyB0ZW4g T2V2ZXIgPG1haWxAbmllbHN0ZW5vZXZlci5uZXQ+wsGZBBMBCABDAhsjBQkJZgGABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AWIQQkWAtwXEr9ipSIZDoO2D86RorIswUCWyJaFgIZAQAK CRAO2D86RorIs8I2D/wNc4kT+dRC3Y9lSygeVWuxNj21z/QlbNvfXx9NicgBx4uCjsCm0ZhS 6qnp0uHYZYr8rdIzrL3GazyEuG9uvNzZBvIHm92UY1x0NH0TOVbGwJCWKULStvg9S+DjmNgp x8XM9amCtuXZyCiESeoOVRUanzD1JIidJtKgDfxvC63kqYoXl3azP0ra2nZbpktMm2fW5YdN D6kp6otjBH/jtpLay1CpVDS2Ehl3rLXJVUu96hlBnQB8q+64qyhTZ23HnbU+ib5Zb3OFgYoB KHjukJ4tV4x9rQprCQeirKX627vcNniDPnMp/nr9Qww6iVidX2vsG/22cx8MqLfs4B9tOVCJ Ft9D7MOwxOWgKnaYvrPZBOEmnuGq7btQe1tQZukL1Z83jKkV/e43k1gJaRt4Nl3/6YYCAlnn aQwRmySxznojsEl+X41UaJ6QFcoCphucOHoO9MeVzuNzgOgodXXEvlA8OJAqxRbE5AqB0leJ z1PfyrF1lsy8ETPRGKUKPBVed1vpZCQBfd/5RksOYBGhyfQ8p0w0hGs8SG6Xl6UtorJ+baLZ ZtnYbakfroxQBsF4bD/0P4fZ8wvTUDNLT8WN/9KFoTXrKn2pTLD+V9iw6nQAH4LSPw0G8XsL ce3Ihkf/2bvorGCUO7YXG4u6FPzEHsa/ZNfWHA5kbpGfwe2OVYNeI87BTQRYKXEdARAAxYOE 3/AFmEfQ0SVVFujYFhZKX+BGXolYytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fx j+uXvLKAm9xQRI/DCug7/NGULMk9bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHw yIawsSCN9AhDXZQWVRqkR1QXcq3IYKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVO BR8xUCBbyk5aRW4VSGO6pUD3H21ur+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8IT aNdFSAttkdT56wAQpxE2h8zaOmBaFUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZ tPP9gIX+ic8QO5iuct37bRXJU/rmrH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJH E8JMaX0yYT6h4PGRS3mNM4bka8hjdfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCV aTfJLFPEru3drxNwi6ogdkRmcLGKqqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+ uPlDtuExehLsNOMpjP8qhZpFtyLeDS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwO DyVwk3MK5Em4pJ0+IAJx+F6gta0Bk2MAEQEAAcLBZQQYAQgADwUCWClxHQIbDAUJCWYBgAAK CRAO2D86RorIs0ykD/4t151SZG9MbeKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvb gB4CtkBuXQlq+plOBWv+rFEThOzy3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK 83OGnfM02qP1Ky8d7EoZz+nTSMf/DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9O y1wWy6fHjwx3r+wQSokBNfxgQyAFonmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDv LwOUYKevBIeJJcqTyfAn3TtJbPCEHOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWv KKmBNBB5OJ/rmHogbNU+wWPJ723qMBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiG pWv4tMc5oB/qVh3my1VO65ErcJ3S9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJ BX6jeYZabGvnTicQlBAzfGpblFqV3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0 OhbnytnopKJKk99bwMoCqDkfQvT3LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ 9DYmtE40zO6g70VVxUj+dKt2hbJTy/KQTb7Ijhw7wZrGp/P7nhbVyA==
Message-ID: <236de218-13cb-d1c3-e831-0a6a24e10d8e@digitaldissidents.org>
Date: Tue, 06 Nov 2018 18:02:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <BB87EF5B-86B0-4203-9D60-AA466B0D4B84@verisign.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 7969115219f8fafc5e1233f7e15217de
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/8nDLYQot78AuHE42Yb8xZF0RRWA>
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 17:02:32 -0000

On 11/6/18 5:50 PM, Gould, James wrote:
> 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.  

Why would a well formulated paragraph, as laid out in RFC6973 and expanded in RFC8280, add confusing?

> What makes it appropriate for this draft over other drafts? 

I think it would also be appropriate for other drafts, as we've for instance seen today in the discussion of the reverse search.

>  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. 

That was not the way forward was summarized by Jim. 

The WG can decide what we add to the draft or not, so I think we should discuss it in the WG and seek for consensus. 

Next to that we can also discuss in other parts of the IETF whether this should be applicable to drafts in general, or how to further and structurally integrate such reviews in our processes. 

Best,

Niels


> 
>   
> 
> —
> 
> 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
> 
>    
> 
>     
> 
>     
> 
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3