Re: [hrpc] resolving pending charter issues

Niels ten Oever <niels@article19.org> Sun, 29 November 2015 23:45 UTC

Return-Path: <niels@article19.org>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7B1B3BDD for <hrpc@ietfa.amsl.com>; Sun, 29 Nov 2015 15:45:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.424
X-Spam-Level:
X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_NL=1.545, SPF_NEUTRAL=0.779] autolearn=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 nHs7_EgkET7F for <hrpc@ietfa.amsl.com>; Sun, 29 Nov 2015 15:45:09 -0800 (PST)
Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1871B3BDA for <hrpc@irtf.org>; Sun, 29 Nov 2015 15:45:08 -0800 (PST)
Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 52CEB164008; Sun, 29 Nov 2015 23:45:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 29362164012; Sun, 29 Nov 2015 23:45:07 +0000 (UTC)
Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b2RDQnubbvr9; Sun, 29 Nov 2015 23:45:06 +0000 (UTC)
Received: from [192.168.1.78] (sd5112335.adsl.online.nl [213.17.35.53]) by mail.article19.io (Postfix) with ESMTPSA id 1A704164008; Sun, 29 Nov 2015 23:45:06 +0000 (UTC)
Message-ID: <565B8E01.907@article19.org>
Date: Mon, 30 Nov 2015 00:45:05 +0100
From: Niels ten Oever <niels@article19.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: Corinne Cath <cattekwaad@gmail.com>
References: <5654E952.3070707@article19.org> <45272FFA14C4DA4D9E98923BA818A06D153B211D@ADFAPWEXMBX02.ad.adfa.edu.au> <56587CB4.2000809@article19.org> <CAD499eKxdgROSArwBcngD9xDojdEAcZpgCEFig2NjM6DKzhKCg@mail.gmail.com>
In-Reply-To: <CAD499eKxdgROSArwBcngD9xDojdEAcZpgCEFig2NjM6DKzhKCg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/hrpc/h2bGxlKqgpLX_AyLpCY-jMUE2gQ>
Cc: Stanley Shanapinda <Stanley.Shanapinda@student.adfa.edu.au>, "hrpc@irtf.org" <hrpc@irtf.org>
Subject: Re: [hrpc] resolving pending charter issues
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.15
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: Sun, 29 Nov 2015 23:45:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Corinne,

The first mention of 'expose' was replaced by 'explore' as suggested
by Ted Hardie. But I still think there is value in keeping 'expose' in
there in the current instances because for me it goes back to the
thinking in phenomenology where one, if one studies an object or
relation close enough, the object or relation shows itself (Heidegger
calls it 'zeigen' [0] and Merleau-Ponty calls it 'découvrir' [1] if I
am not mistaken).

So it let's the explanation come for the phenomena itself instead of
'explaining' or 'clarifying' it, which implies much more interpretation.

Always happy to think of other wording, even though I would also like
to get the charter out of the door and get on with the real work ;)

Let me know what you think.

Cheers,

Niels

[0] In: Kunst, Koennen und Technik
[1] In: Phénoménologie de la perception



Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

On 11/28/2015 08:28 PM, Corinne Cath wrote:
> Looks great!
> 
> Minor suggestion: change 'expose' (the relation between protocols
> and human rights) to 'clarify' (the relation between protocols and
> human rights). Expose feels a little like, I open the hood of the
> car and there by expose its underlying workings but what we are
> really doing goes one step beyond that we are actually trying to
> understand and make explicit the relations between protocols and
> human rights. But might be nit-picking.
> 
> Best,
> 
> Corinne
> 
> On Fri, Nov 27, 2015 at 3:54 PM, Niels ten Oever
> <niels@article19.org <mailto:niels@article19.org>> wrote:
> 
> Hi Stanley,
> 
> Thanks a lot for your question. Privacy is not specifically
> mentioned because the problem of security as well as privacy are
> already much better understood in the IETF than other rights
> concepts. Privacy for instance is already mentioned in RFC1087 [0]
> and culminated in the great document RFC6973 [1] to which we are
> referring in the charter.
> 
> So I would think it is sufficiently covered, let me know if after
> this you still think differently.
> 
> Another nice piece of reading on this topic is by Nick Doty [2].
> 
> Happy to discuss!
> 
> Best,
> 
> Niels
> 
> 
> 
> [0] https://tools.ietf.org/html/rfc1087 [1]
> https://tools.ietf.org/html/rfc6973 [2]
> https://npdoty.name/privacy-reviews/iwpe/
> 
> Niels ten Oever Head of Digital
> 
> Article 19 www.article19.org <http://www.article19.org>
> 
> PGP fingerprint    8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D
> 68E9
> 
> On 11/26/2015 01:53 AM, Stanley Shanapinda wrote:
>> Dear All, Thanks Niels, it looks and reads pretty well. Is there
>> a particular reason "the right to privacy' was not specified as
>> well but is simply implied in the overall human rights context?
>> One of the fundamental issues considered in every protocol is
>> security, i.e. "security" from unauthorized access and
>> interference. Secure communications denotes "private'
>> communications, In would like to think. Thanks and regards
>> Stanley ________________________________________ From: Niels ten
>> Oever [niels@article19.org <mailto:niels@article19.org>] Sent:
>> Wednesday,
> November 25, 2015 9:48 AM
>> To: hrpc@irtf.org <mailto:hrpc@irtf.org> Subject: [hrpc]
>> resolving
> pending charter issues
> 
>> Hello everyone,
> 
>> I looked at all comments provided on this list and other list
>> and have tried to resolve them below. Let me know what you think.
>> The edited version you can find on here on git: 
>> https://github.com/nllz/IRTF-HRPC/blob/master/hrpc%20charter.txt
> 
>> Looking forward to hear if any questions, comments or burning 
>> issues remain.
> 
>> Best,
> 
>> Niels
> 
> 
>> Background The Human Rights Protocol Consideration Proposed 
>> Research Group is chartered to research whether standards and 
>> protocols can enable, strengthen or threaten human rights, as 
>> defined in the Universal Declaration of Human Rights (UDHR) [0]
>> and the International Covenant on Civil and Political Rights
>> (ICCPR) [1], specifically, but not limited to the right to
>> freedom of expression and the right to freedom of assembly.
> 
>> The research group takes as its starting point the problem 
>> statement that human-rights-enabling characteristics of the 
>> Internet might be degraded if they're not properly defined, 
>> described and sufficiently taken into account in protocol 
>> development. Not protecting these characteristics could result
>> in (partial) loss of functionality and connectivity.
> 
>> # Mat Ford pointed out that this is not a direct quote from 
>> RFC1958, so # I changed 'stated in' into 'evinced by'.
> 
>> As evinced by RFC 1958, the Internet aims to be the global
>> network of networks that provides unfettered connectivity to all
>> users at all times and for any content. Open, secure and
>> reliable connectivity is essential for rights such as freedom of
>> expression and freedom of association. Since the Internet's
>> objective of connectivity makes it an enabler of human rights,
>> its architectural design converges with the human rights
>> framework.
> 
>> # Both Ted Hardie and Robin Wilton made the remark that the 
>> sentence # "Concerns for freedom of expression and association
>> were a strong part # of the world-view of the community involved
>> in developing the first # Internet protocols." might be a
>> stretch, so I removed it.
> 
>> The Internet was designed with freedom and openness of 
>> communications as core values. But as the scale and the 
>> industrialization of the Internet has grown greatly, the
>> influence of such world-views started to compete with other
>> values.
> 
>> # Ted Hardie suggested 'explore' instead of 'expose' since
>> 'exposed # might sound a bit hostile. I have no problems with
>> that.
> 
>> This research group aims to explore the relations between human 
>> rights and protocols and to provide guidelines to inform future 
>> protocol development and decision making where protocols impact 
>> the effective exercise of the rights to freedom of expression or 
>> association.
> 
>> Objective This research has two major aims: - to expose the 
>> relation between protocols and human rights, with a focus on the 
>> rights to freedom of expression and freedom of assembly, and
> 
>> - to propose guidelines to protect the Internet as a
>> human-rights- enabling environment in future protocol
>> development, in a manner similar to the work done for Privacy
>> Considerations in RFC 6973.
> 
>> # Introducing awareness raising as objective as per comment of 
>> Stephen # and supported by Robin and dkg
> 
>> - to increase the awareness in both the human rights community
>> and the technical community on the importance of the technical 
>> workings of the Internet and its impact on human rights.
> 
>> Outputs The research group plans on using  a variety of research 
>> methods to create different outputs including (but not limited 
>> to):
> 
>> # As Lars and Mat Ford pointed out, IRSG RFC track should be
>> IRSG RFC # stream, and a Dirk pointed out 'tracking' might be a
>> bit vague, to I # replaced it with 'documenting the progress'
> 
>> - Internet drafts - (some of which may be put on IRSG RFC
>> stream) These would concern documenting the progress of the
>> project, methodology, and would define any possible protocol 
>> considerations.
> 
>> - Policy and academic papers For in depth analysis and
>> discussion on the relationship between human rights and the
>> Internet architecture and protocols.
> 
>> # Based on the comments of Mary Burnes 'a diverse set' is 
>> introduced # in the following para:
> 
>> - Film and textual interviews with a diverse set of community 
>> members, to give an accessible insight into the variety of 
>> opinions on this topic represented in the IETF.
> 
>> - Data analysis and visualization To research and visualize the 
>> language used in current and historic RFCs and mailinglist 
>> discussions to expose core architectural principles, language
>> and deliberations on human rights of those affected by the
>> network.
> 
>> # As suggested by Seda and supported by dkg, including some 
>> language # suggestion from me:
> 
>> - Protocol analysis Data analysis and visualization of
>> (existing) protocols in the wild to research their concrete
>> impact on human rights.
> 
>> Membership Membership is open to any interested parties who
>> intend to remain current with the published documents and mailing
>> list issues.
> 
>> [0] http://www.un.org/en/documents/udhr/ [1] 
>> http://www.ohchr.org/EN/ProfessionalInterest/Pages/CCPR.aspx
> 
> 
> 
> 
> 
> _______________________________________________ hrpc mailing list 
> hrpc@irtf.org <mailto:hrpc@irtf.org> 
> https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
> 
> 
> --
> 
> 
> 'The management of normality is hard work'
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWW44BAAoJEAi1oPJjbWjptwQH/3D/yNb/fySOJLhU6zS1UhKX
Lr2QV0jfHNVT409MHrXxzvb2l3S3SfjzRy1GzyjP7Mrzaq2Szn+nfaL+E/5kcu4h
WfP7uuZ4YcIqpTxzVCXwOCb4issZe3068xZtzEVsozYTBWvBNu1TjsJWViltupzk
Y+7T67ayHjzx2ONIxlgkAAusHTcxwo3SfP2Moj1pAYZqediqlk8nqFS6Jcn6qG2l
+S7C6xgkBWyV4CdpgOBOgYZh88mdwQ6G9nZ2vpXtU3AR2pUo7jeRBg5i+u4tcIHX
A8fyDSDeEzu/UfusYfDt+fp7eAbPM5TWGvzxLAB3VULKq+s7DaiAQMp2k0V6dz0=
=msmI
-----END PGP SIGNATURE-----