Re: [hrpc] 2nd Research Group Last Call for draft-irtf-hrpc-research

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 13 February 2017 15:32 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD34F1296D4 for <hrpc@ietfa.amsl.com>; Mon, 13 Feb 2017 07:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 duqyZKIGEmez for <hrpc@ietfa.amsl.com>; Mon, 13 Feb 2017 07:32:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F6C12965A for <hrpc@irtf.org>; Mon, 13 Feb 2017 07:31:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 925B9BE5F; Mon, 13 Feb 2017 15:31:53 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu9YA8-_ahgP; Mon, 13 Feb 2017 15:31:53 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E112ABE80; Mon, 13 Feb 2017 15:31:52 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486999913; bh=ES29EwY03dCZmH5DoEQDtApeXX5ZrHrAmHbQyvyvsJY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pmPmQrpXVza6FDkEYOMo20LptXHY3bg879mcLLnYg/KRGSkpceisJ5QZvVETMkOo7 Ddn11+48HxsQIShfQkLd7PI4Mgk7hxAQPJq57uRD3wVQJE5s1St0lrHgHxZCNnrLcF KLmzbY1ZFoTgo18d0xnRxAbggSoPxZb/JgS4ddo8=
To: Niels ten Oever <niels@article19.org>, hrpc@irtf.org
References: <5ebc4c20-5ff1-1f3f-df5c-31213bee2890@acm.org> <808700d7-a9d2-cdf8-9e3e-395d6acc292c@cs.tcd.ie> <2bea99b1-2346-8f03-785b-ed364890b29c@article19.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <af9b25ff-a6e1-45c4-d533-ca09514441f9@cs.tcd.ie>
Date: Mon, 13 Feb 2017 15:31:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <2bea99b1-2346-8f03-785b-ed364890b29c@article19.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="CB4IWUUOa2VeCNiVakQVvBCThaEHEUMQk"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/oK_i5rg6dibRdWoUCEbjdi4pV10>
Subject: Re: [hrpc] 2nd Research Group Last Call for draft-irtf-hrpc-research
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "niels@article19.org" <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 15:32:10 -0000

Hiya,

On 13/02/17 14:50, Niels ten Oever wrote:
> Hi Stephen,
> 
> On 02/10/2017 11:36 PM, Stephen Farrell wrote:
>>
>> I flicked quickly through this but I didn't give it a
>> full read-through. With so much change I hope someone does
>> do that, but I don't have time right now sorry. As always
>> (sorry:-) I have a few comments:
>>
>> - Abstract:
>>
>> I hate >1 para abstracts. 
> 
> Do you mean we should delete the hard return between these paras?:

Well, you could, but I meant more that I think abstracts should
be a *short* one paragraph description of the content. I don't
think you end up with that by merging these paragraphs.

IOW, please synopsize harder:-)

That said, this is just a style thing.

> 
> This document aims to propose guidelines for human rights
> considerations, similar to the work done on the guidelines for privacy
> considerations {{RFC6973}}. This is achieved by providing a proposal for
> a vocabulary to discuss the relation between human rights and Internet
> protocols, an overview of the discussion in technical and academic
> literature and communities, a proposal for the mapping of the relation
> between human rights and technical concepts, as well as guidelines.
> 
> 
> 
> If you want to see how to apply this work to your own, you can directly
> go to <xref
> target="model-for-developing-human-rights-protocol-considerations" />.
> The rest of the document explains the background of the guidelines and
> how they were developed.
> 
> I think it adds to readability and giving people what they need, but if
> you feel strongly....
> 
> The rest of the abstract is mostly boilerplate text, merging that with
> the above doesn't seem very useful to me.
> 
> 
> It also seems wrong at this point
>> for the document to say that it "aims to be a consensus
>> document" - but maybe the intent was to change that to
>> "this represents RG consensus" after Avri calls the result
>> of the 2nd LC? 
> 
> Exactly
> 
>>
>> - section 4:
>>
>> This bit needs fixing: "if the IETF were to bake the UDHR
>> into its protocols, countries who do not agree with that
>> might completely withdraw from the standard setting process."
>> Countries do not participate in the IETF's process so this
>> makes no sense. I'd also not like s/countries/people from
>> countries/ as that assumes all a country's citizens agree
>> with something at once. I'd delete that argument, reducing
>> to three arguments, which is enough.
>>
> 
> OK - removed.
> 
>> - later in section 4:
>>
>> "Our position is..." I'm not at all sure that's appropriate
>> language for a document that claims to have rough consensus.
>> I'm also not at all sure that the rest of that para does in
>> fact represent rough consensus of the RG.
> 
> You think this does not represent the rough consensus of the RG ? 

See below wrt the text that follows this phrase...

The "Our position is..." phrase is problematic regardless.

If the rest of the para does represent RG consensus then
there's no need for the problematic phrase. You could
delete it, or s/Our/The RG's/ and it'd be ok.

If the rest of the para does not represent RG consensus
then I'm not sure why the authors' divergent opinions are
being presented, and if they are, it'd be better to be
clearer about that position not being part of the RG
consensus. And to also be as clear if there are any other
similar bits of text. (And it'd probably be good to be
consistently clear in how that's done too:-)

> This
> has been in here for quite a while, and I haven't heard many people
> arguing against this position:
> 
> ... hard-coding human rights into protocols is complicated and changes
> with the context. At this point is difficult to say whether hard-coding
> human rights into protocols is wise or feasible.

The rest of that paragraph is much longer than that. And yes,
I'm not convinced that all of the rest of that para does
represent RG consensus, for example the last sentence which
says:

  "In addition, it
   ensures that the impact of specific protocol on human rights is
   carefully considered and that concrete design decisions are
   documented in the protocol."

I'd be surprised if that "ensures" was widely accepted. I
don't buy it anyway;-)

While this specific point isn't mega-important, since it's
fairly obvious that we can't often "ensure" stuff like this
gets done, I'm raising it as it could be indicative of
two relatively new to the process authors not quite getting
how RG consensus ought be reflected in a draft that claims
to represent the RG consensus. (And yes, apologies for not
raising this before.)

Note that I'm not accusing you guys of anything here, (we
have an odd process, and this is an odd document even in
that odd process, and this bit of text is an even odder
corner case in that pile of oddity;-) but if there are
other bits of text that you think represent your opinion
but not the RG consensus (or where Avri thinks that) then
it'd be good to call those out in some consistent and
very clear manner, or to remove the text. I haven't gone
through the whole doc looking for that kind of text and
I'm not sure if anyone else has. My feeble excuse for not
having done that is that as I said before I think this'd
have been better not aiming to be an RG consensus document:-)
And I'm willing to believe you/Avri if told that you had a
look and there are in fact no other bits of text like that.

If this turns out to be the only bit of text like this,
then I'd also wonder if it's really worth including.

Cheers,
S.

PS: I don't recall another IRTF RG consensus draft that
had bits of text representing the authors' non-consensus
opinions, but maybe someone else does in which case whatever
was done before could be copied. I'd be fine with us following
a precedent like that. If we're setting one here though,
then I'd prefer we try set a precedent that this kind of
thing ought be called out clearly and consistently.


> 
> Cheers,
> 
> Niels
> 
>>
>> My conclusion from the list discussion and from the above
>> is that I'm supportive of this being published. That'll be
>> better as an informational RFC, as otherwise we may waste
>> time debating "so what's the experiment exactly" which'd
>> be a bit pointless in this case.
>>
> 
> 
> 
>> Cheers,
>> S.
>>
>>
>> On 09/02/17 20:37, avri doria wrote:
>>> Hi,
>>>
>>> As mentioned in an earlier note, many changes were made to the draft in
>>> response to comments made during the last last call. As these changes
>>> were not just editorial, decided we needed another RGLC to review the
>>> changes.
>>>
>>> As of now starting a 2 weeks call on:
>>>
>>> 	Title           : Research into Human Rights Protocol Considerations
>>>         Authors         : Niels ten Oever
>>>                           Corinne Cath
>>> 	Filename        : draft-irtf-hrpc-research-10.txt
>>> 	Pages           : 74
>>> 	Date            : 2017-02-08
>>>
>>> The call will end on Noon 1200 UTC 24 Feb 2017,
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-irtf-hrpc-research-10
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-irtf-hrpc-research-10
>>>
>>> For a diff to the previous RGLC version (-07)
>>> Use: https://tools.ietf.org/rfcdiff
>>> and refer to drafts:
>>> https://www.ietf.org/archive/id/draft-irtf-hrpc-research-07.txt
>>> https://www.ietf.org/id/draft-irtf-hrpc-research-10.txt
>>>
>>> Please send comments to: hrpc@irtf.org
>>>
>>> Please forward this call to anyone you think should consider reviewing this doc.
>>>
>>> Thanks
>>> Avri
>>>
>>>
>>>
>>> ---
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>> _______________________________________________
>>> hrpc mailing list
>>> hrpc@irtf.org
>>> https://www.irtf.org/mailman/listinfo/hrpc
>>>
>>
>>
>>
>> _______________________________________________
>> hrpc mailing list
>> hrpc@irtf.org
>> https://www.irtf.org/mailman/listinfo/hrpc
>>
> 
> 
> 
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>