Subject:	New Version Notification for draft-doria-hrpc-proposal-00.txt
Date:	Mon, 27 Oct 2014 03:15:19 -0700
From:	internet-drafts@ietf.org
To:	Avri Doria <avri@acm.org>, Joana Varon <joana@varonferraz.com>, Joana Varon <joana@varonferraz.com>, Niels ten Oever <niels@article19.org>, Niels ten Oever <niels@article19.org>, Avri Doria <avri@acm.org>

On Tue, Jan= 20, 2015 at 3:38 PM, <hrpc-request@article19.io> w= rote:

Send hrpc mailing list submissions = to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc@artic= le19.io

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.ghserv.net/mailman/listinfo/hrp= c
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hr= pc-request@article19.io

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hrpc= -owner@article19.io

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hrpc digest..."

Today's Topics:

=C2=A0 =C2=A01. Summary ID on Human Rights presentation & next steps (J= oana Varon)

----------------------------------------------------------------------

Message: 1
Date: Tue, 20 Jan 2015 13:34:16 -0200
From: Joana Varon <joana@varonf= erraz.com>
To: hrpc@article19.io
Subject: [hrpc] Summary ID on Human Rights presentation & next steps Message-ID: <54BE757= 8.3010503@varonferraz.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Dear all,

Happy 2015! We hope it will bring us the opportunity for enlightening
and rich debates on human rights and protocols over here.

For the purpose of doing so, this is an attempt to summarize and and
structure our work. So, please, find underneath (a) the summary of the
session at IETF91 where we presented the Internet Draft on Human Rights
considerations for Internet protocols and (b) a brainstorming of some
research priorities for the coming time.

At the bottom you can also find the links for the records of the session and related documents. The full transcription of the Q&A are also here<= br> attached.

All comments, questions and suggestions for research methods and angles
are very welcome. We are also looking for more help of researchers who
are interested in helping us with researching specific RFCs to help us
refine the methodology. Please, feel free to ping us on or offlist.

Best,

Joana and Niels

*
**a) Summary of the Session*

An active debate about standards, protocols and human rights took place
during the meeting of the Security Area Advisory Group -- SAAG at IETF
91, Hawaii. The discussion was framed by the Internet Draft "Proposal<= br> for research on human rights protocol considerations". [1]

The Draft departs from the work that has been done by IETF on privacy
and Internet protocols, such as RFC 6973 on Privacy Consideration
guidelines [2], suggesting that some standards and protocols can
solidify, enable or threaten human rights, such as freedom of expression and the right to association online. The proposal aims to establish a
research group under the IRTF to study the structural relationship and
impact between Internet standards and protocols and freedom of
expression and association.

A deeper rationale for presenting such proposal was explained during the presentation at SAAG. The presenters, who are also the authors of this
note highlighted that the Internet was designed with freedom and
openness of communications as core values, but were also questioning
whether this a structural value that can or needs to be preserved on a
technical level. As the politicization of the Internet management space
increases, it is argued that IETF should have an active role to promote
a more structured and holistic approach. This would allow sustained
future proofing of standards and protocols to avoid ad hoc decisions
following incidents or disclosures at a variety of other foras and actors.<= br>
The proposal raised some eyebrows and concerns about the politicization
of the work of the community. Dan Harkins posed that: "doing the human=
rights study will likely politicize protocols. Not want the technology
to have political context. I want technology to be so unpolitical as
possible." This sparked a discussion with a rapid follow up by Justin,=
who stated that "we have to stop pretending that technology is a
non-political decision", a remark that was followed by a round of
applause. One of the presenters responded that the research proposal was exactly aimed at avoiding further politicization of protocols or the
community, but rather give the community time in a proper process to
define its position.

Both John Levine and Alissa Cooper remarked that it is crucial to start
of with a focus on specific human rights, because it will help keep the
research manageable and help start the thinking about the balancing of
different rights. The presenters reaffirmed that the primary focus will
indeed be on the rights to freedom of expression and right to
association.=C2=A0 =C2=A0Alissa Cooper mentioned the IAB ID=C2=A0 on filter= ing
considerations [3] and the RFC=C2=A0 Policy Considerations for Internet
Protocols [4] as relevant sources for research.

Several RFCs already make quite explicit statement about the objectives
of the Internet, such as RFC1958 which=C2=A0 mentions 'the community be= lieves
that the goal [of the Internet] is connectivity, the tool is the
Internet Protocol'.=C2=A0 It continues a bit further: 'The current<= br> exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such
as=C2=A0 mail or the World-Wide Web.'=C2=A0 This marks the intrinsic va= lue of
connectivity which is facilitated by the Internet, both in principle,
and in practice.=C2=A0 This shows that the underlying=C2=A0 principles of t= he
Internet aim to preserve connectivity, which is fundamental and similar
to the part of article 19 of the Universal Declaration of Human Rights,
which defines a right to receive and to impart information.

But there are also protocols that enable freedom of expression and
access to information in an unprecedented way, such as HTTP. Even though there is not an explicit reference to rights in RFC7230, it does form
the basis for a rights enabling architecture. The challenge of the
research would be to seek out the specific protocol attribute(s) that
enable that protocol to affect a specific human right.

The major challenge as next step would be to developed to develop an
appropriate methodology to research the existing implicit safeguards in
current standards and protocols, and making them explicit. Open
discussions already gave some insights for possible methodological
approaches. Richard Barnes suggests: "seems that you are reading RFCs<= br> and that you are looking for statement on rights and human rights that
are laid out in RFCs. You might risk irritating people at least by
reading reading technical documents as political statements. I think it
might be more useful to use RFCs as a window into the rights that the
community that developed these RFCs presumes." Mark Nottingham also proposed a perspective of stakeholder prioritization as described in ID
Representing Stakeholder Rights in Internet Protocols [5]=C2=A0 which is as=
already implemented at the W3C.

Other very useful remarks were made during and after the session, as
well on the mailinglist [6] which are currently being used to improve
the next version of the draft, possibly, to be further discussed at a
Birds of Feather session in Dallas.
*
**b) Research priorities and next steps*

The proceedings of this session lead the presenters and authors of the
ID to conclude that the subject and the research raised interest in the
community. Their aim is to continue the research work an produce an
updated ID before the Dallas meeting.

The research in the coming time will focus on documenting the specific
protocol attributes that explicitly or implicitly affect specific human
rights. For achieving that, a research methodology will be further
developed; suggestions for the first steps consist of:

a) improving the list of RFCs that possibly have attributes to the right to freedom of expression and association;

b) conduct interviews at the Dallas meeting to further understand the
intention that Area Directors and RFC authors have with specific
protocols and how rights play a role in that;

c) set a common template to analyze standards and protocols describing
the exact features, functions, characteristics or entities that allow a
more defined understanding on the relation between them and the right to freedom of expression and association.

Nevertheless, these are just our suggestions to keep developing the ID
and the work ahead of it. Comments, suggestions, hints are more then
welcome and very much appreciated.

*References*
=C2=A0[1] Proposal for research on human rights protocol considerations, =C2=A0http://www.ietf.org/id/draft-doria-hrpc-proposal-00.txt

=C2=A0[2]=C2=A0 RFC 6973 on Privacy Considerations for Internet Protocols =C2=A0 https://www.rfc-editor.org/rfc/rfc6973.txt

=C2=A0[3] Technical Considerations for Internet Service Blocking and Filter= ing
=C2=A0http://www.ietf.org/archive/id/draft-iab= -filtering-considerations-06.txts

=C2=A0[4]=C2=A0 Policy Considerations for Internet Protocols
=C2=A0https://tools.ietf.org/html/draft-morris-policy-cons-00

=C2=A0[5] Representing Stakeholder Rights in Internet Protocols,
=C2=A0 https://tools.ietf.org/id/draft-nottingham-st= akeholder-rights-00.txt

=C2=A0[6]=C2=A0 https://lists.ghserv.net/mailman/listinfo/hrpc

* Other relevant links and information*
=C2=A0IETF91 SAAG Agenda:
http://www.ietf.org/proceedings/91/agenda/agenda-91-saag =C2=A0IETF 91 SAAG minutes:
=C2=A0http://www.ietf.org/proceedings/91/minutes/minutes-91-s= aag
=C2=A0IETF 91 SAAG audio recording:
=C2=A0http://www.ietf.org/audio/ietf91/ietf91-coral= 3-20141113-1300-pm1.mp3
=C2=A0Presentation starts at 40:15
=C2=A0Presentation:
http://www.ietf.org/proceedings/91/slides/slides-91-saag-= 6.pdf

--
--
Joana Varon
@joana_varon
https://antivigila= ncia.org
Fingerprint
239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ghserv.net/pi= permail/hrpc/attachments/20150120/67c01860/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Transcription of the Q&A at SAAG IETF91 Hawaii.doc
Type: application/msword
Size: 29696 bytes
Desc: not available
URL: <http://lists.ghserv.net/pip= ermail/hrpc/attachments/20150120/67c01860/attachment.doc>

------------------------------

_______________________________________________
hrpc mailing list
hrpc@article19.io
https://lists.ghserv.net/mailman/listinfo/hrpc

End of hrpc Digest, Vol 4, Issue 1
**********************************

'The management of normality is hard work'
<= /div>

--047d7b5d348ca42b63050d1799e9-- From stephen.farrell@cs.tcd.ie Tue Jan 20 17:22:20 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YDbZM-00039Z-QB for hrpc@article19.io; Tue, 20 Jan 2015 17:22:20 +0100 Received: from mercury.scss.tcd.ie ([134.226.56.6]) by mx2.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YDbZJ-0004Lg-5N for hrpc@article19.io; Tue, 20 Jan 2015 17:22:20 +0100 Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9DA55BED0 for ; Tue, 20 Jan 2015 16:22:16 +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 Tn8Hberip84h for ; Tue, 20 Jan 2015 16:22:16 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7991CBECC for ; Tue, 20 Jan 2015 16:22:16 +0000 (GMT) Message-ID: <54BE80B8.2070602@cs.tcd.ie> Date: Tue, 20 Jan 2015 16:22:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: hrpc@article19.io Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Level: / X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: 0.8 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 645486d610a00fe5591aab0f6aa1616b Subject: [hrpc] unesco study event in Paris X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:22:21 -0000 Hiya, And adding to the welcome flurry of traffic on this list... UNESCO are doing a study that seems relevant here and will have a conference in Paris on that March 2-4. [1] (I'll be there on some panel or other:-) Seems like it overlaps with this effort some as they are also considering how human rights and the Internet are related I think. Cheers, S. [1] http://www.unesco.org/new/en/communication-and-information/events/calendar-of-events/events-websites/connecting-the-dots/home/ From mallory@apc.org Tue Jan 20 18:21:39 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YDcUl-0003E1-HR for hrpc@article19.io; Tue, 20 Jan 2015 18:21:39 +0100 Received: from mail.gn.apc.org ([37.220.108.136]) by mx2.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YDcUi-0005bA-3P for hrpc@article19.io; Tue, 20 Jan 2015 18:21:39 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.gn.apc.org (Postfix) with ESMTP id C267A200C236 for ; Tue, 20 Jan 2015 17:21:35 +0000 (GMT) X-Virus-Scanned: by amavisd-new at mail.gn.apc.org Received: from mail.gn.apc.org ([127.0.0.1]) by localhost (mail.gn.apc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H3zasXSjvMc for ; Tue, 20 Jan 2015 17:21:33 +0000 (GMT) Received: from anonymous ([10.254.254.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mallory) by mail.gn.apc.org (Postfix) with ESMTPSA id 75E53200C209 for ; Tue, 20 Jan 2015 17:21:32 +0000 (GMT) Message-ID: <54BE8E9B.2090207@apc.org> Date: Tue, 20 Jan 2015 12:21:31 -0500 From: Mallory Knodel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: hrpc@article19.io References: <54BE7578.3010503@varonferraz.com> In-Reply-To: <54BE7578.3010503@varonferraz.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ELheV22lqT9ccqWf7WC6RM0pjknHvs8nC" X-Spam-Level: - X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50, HTML_MESSAGE, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -1.5 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 55bb320f4425806547ba14d4976758db Subject: Re: [hrpc] Summary ID on Human Rights presentation & next steps X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 17:21:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ELheV22lqT9ccqWf7WC6RM0pjknHvs8nC Content-Type: multipart/alternative; boundary="------------050401010006060908010803" This is a multi-part message in MIME format. --------------050401010006060908010803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi joana Congrats on sparking an interesting debate at the IETF in Hawaii. I found all comments in the transcript useful, even those that questioned the foundation of the research. In particular, I thought the suggestion to analyze RFCs carefully for assumptions of rights is a better approach than searching for overt mentions of rights. Interviews in Dallas could certainly give more weight to the findings if we take this approach. Questioning the apolitics of protocols is really a fundamental goal of this work. I think while difficult, it would also be extremely productive to continue to engage with folks in the community who feel technology should strive to be apolitical, thereby developing a very strong counterposition. Very happy to lend a hand with this work, -Mallory On 01/20/2015 10:34 AM, Joana Varon wrote: > Dear all, > > Happy 2015! We hope it will bring us the opportunity for enlightening > and rich debates on human rights and protocols over here. > > For the purpose of doing so, this is an attempt to summarize and and > structure our work. So, please, find underneath (a) the summary of the > session at IETF91 where we presented the Internet Draft on Human > Rights considerations for Internet protocols and (b) a brainstorming > of some research priorities for the coming time. > > At the bottom you can also find the links for the records of the > session and related documents. The full transcription of the Q&A are > also here attached. > > All comments, questions and suggestions for research methods and > angles are very welcome. We are also looking for more help of > researchers who are interested in helping us with researching specific > RFCs to help us refine the methodology. Please, feel free to ping us > on or offlist. > > Best, > > Joana and Niels > > * > **a) Summary of the Session* > > An active debate about standards, protocols and human rights took > place during the meeting of the Security Area Advisory Group -- SAAG > at IETF 91, Hawaii. The discussion was framed by the Internet Draft > "Proposal for research on human rights protocol considerations". [1] > > The Draft departs from the work that has been done by IETF on privacy > and Internet protocols, such as RFC 6973 on Privacy Consideration > guidelines [2], suggesting that some standards and protocols can > solidify, enable or threaten human rights, such as freedom of > expression and the right to association online. The proposal aims to > establish a research group under the IRTF to study the structural > relationship and impact between Internet standards and protocols and > freedom of expression and association. > > A deeper rationale for presenting such proposal was explained during > the presentation at SAAG. The presenters, who are also the authors of > this note highlighted that the Internet was designed with freedom and > openness of communications as core values, but were also questioning > whether this a structural value that can or needs to be preserved on a > technical level. As the politicization of the Internet management > space increases, it is argued that IETF should have an active role to > promote a more structured and holistic approach. This would allow > sustained future proofing of standards and protocols to avoid ad hoc > decisions following incidents or disclosures at a variety of other > foras and actors. > > The proposal raised some eyebrows and concerns about the > politicization of the work of the community. Dan Harkins posed that: > "doing the human rights study will likely politicize protocols. Not > want the technology to have political context. I want technology to be > so unpolitical as possible." This sparked a discussion with a rapid > follow up by Justin, who stated that "we have to stop pretending that > technology is a non-political decision", a remark that was followed by > a round of applause. One of the presenters responded that the research > proposal was exactly aimed at avoiding further politicization of > protocols or the community, but rather give the community time in a > proper process to define its position. > > Both John Levine and Alissa Cooper remarked that it is crucial to > start of with a focus on specific human rights, because it will help > keep the research manageable and help start the thinking about the > balancing of different rights. The presenters reaffirmed that the > primary focus will indeed be on the rights to freedom of expression > and right to association. Alissa Cooper mentioned the IAB ID on > filtering considerations [3] and the RFC Policy Considerations for > Internet Protocols [4] as relevant sources for research. > > Several RFCs already make quite explicit statement about the > objectives of the Internet, such as RFC1958 which mentions 'the > community believes that the goal [of the Internet] is connectivity, > the tool is the Internet Protocol'. It continues a bit further: 'The > current exponential growth of the network seems to show that > connectivity is its own reward, and is more valuable than any > individual application such as mail or the World-Wide Web.' This > marks the intrinsic value of connectivity which is facilitated by the > Internet, both in principle, and in practice. This shows that the > underlying principles of the Internet aim to preserve connectivity, > which is fundamental and similar to the part of article 19 of the > Universal Declaration of Human Rights, which defines a right to > receive and to impart information. > > But there are also protocols that enable freedom of expression and > access to information in an unprecedented way, such as HTTP. Even > though there is not an explicit reference to rights in RFC7230, it > does form the basis for a rights enabling architecture. The challenge > of the research would be to seek out the specific protocol > attribute(s) that enable that protocol to affect a specific human right= =2E > > The major challenge as next step would be to developed to develop an > appropriate methodology to research the existing implicit safeguards > in current standards and protocols, and making them explicit. Open > discussions already gave some insights for possible methodological > approaches. Richard Barnes suggests: "seems that you are reading RFCs > and that you are looking for statement on rights and human rights that > are laid out in RFCs. You might risk irritating people at least by > reading reading technical documents as political statements. I think > it might be more useful to use RFCs as a window into the rights that > the community that developed these RFCs presumes." Mark Nottingham > also proposed a perspective of stakeholder prioritization as described > in ID Representing Stakeholder Rights in Internet Protocols [5] which > is as already implemented at the W3C. > > Other very useful remarks were made during and after the session, as > well on the mailinglist [6] which are currently being used to improve > the next version of the draft, possibly, to be further discussed at a > Birds of Feather session in Dallas. > * > **b) Research priorities and next steps* > > The proceedings of this session lead the presenters and authors of the > ID to conclude that the subject and the research raised interest in > the community. Their aim is to continue the research work an produce > an updated ID before the Dallas meeting. > > The research in the coming time will focus on documenting the specific > protocol attributes that explicitly or implicitly affect specific > human rights. For achieving that, a research methodology will be > further developed; suggestions for the first steps consist of: > > a) improving the list of RFCs that possibly have attributes to the > right to freedom of expression and association; > > b) conduct interviews at the Dallas meeting to further understand the > intention that Area Directors and RFC authors have with specific > protocols and how rights play a role in that; > > c) set a common template to analyze standards and protocols describing > the exact features, functions, characteristics or entities that allow > a more defined understanding on the relation between them and the > right to freedom of expression and association. > > Nevertheless, these are just our suggestions to keep developing the ID > and the work ahead of it. Comments, suggestions, hints are more then > welcome and very much appreciated. > > > *References* > [1] Proposal for research on human rights protocol considerations, > http://www.ietf.org/id/draft-doria-hrpc-proposal-00.txt > > [2] RFC 6973 on Privacy Considerations for Internet Protocols > https://www.rfc-editor.org/rfc/rfc6973.txt > > [3] Technical Considerations for Internet Service Blocking and Filteri= ng > http://www.ietf.org/archive/id/draft-iab-filtering-considerations-06.t= xts > > [4] Policy Considerations for Internet Protocols > https://tools.ietf.org/html/draft-morris-policy-cons-00 > > [5] Representing Stakeholder Rights in Internet Protocols, > https://tools.ietf.org/id/draft-nottingham-stakeholder-rights-00.txt > > [6] https://lists.ghserv.net/mailman/listinfo/hrpc > > * Other relevant links and information* > IETF91 SAAG Agenda: > http://www.ietf.org/proceedings/91/agenda/agenda-91-saag > IETF 91 SAAG minutes: > http://www.ietf.org/proceedings/91/minutes/minutes-91-saag > IETF 91 SAAG audio recording: > http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1300-pm1.mp3 > Presentation starts at 40:15 > Presentation: > http://www.ietf.org/proceedings/91/slides/slides-91-saag-6.pdf > --=20 > -- > Joana Varon > @joana_varon > https://antivigilancia.org > Fingerprint=20 > 239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73 > > > _______________________________________________ > hrpc mailing list > hrpc@article19.io > https://lists.ghserv.net/mailman/listinfo/hrpc --=20 Mallory Knodel Association for Progressive Communications :: apc.org gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------050401010006060908010803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi joana

Congrats on sparking an interesting debate at the IETF in Hawaii. I found all comments in the transcript useful, even those that questioned the foundation of the research. In particular, I thought the suggestion to analyze RFCs carefully for assumptions of rights is a better approach than searching for overt mentions of rights. Interviews in Dallas could certainly give more weight to the findings if we take this approach.

Questioning the apolitics of protocols is really a fundamental goal of this work. I think while difficult, it would also be extremely productive to continue to engage with folks in the community who feel technology should strive to be apolitical, thereby developing a very strong counterposition.

Very happy to lend a hand with this work,
-Mallory

On 01/20/2015 10:34 AM, Joana Varon wrote:

Dear all,

Happy 2015! We hope it will bring us the opportunity for enlightening and rich debates on human rights and protocols over here.

For the purpose of doing so, this is an attempt to summarize and and structure our work. So, please, find underneath (a) the summary of the session at IETF91 where we presented the Internet Draft on Human Rights considerations for Internet protocols and (b) a brainstorming of some research priorities for the coming time.

At the bottom you can also find the links for the records of the session and related documents. The full transcription of the Q&A are also here attached.

All comments, questions and suggestions for research methods and angles are very welcome. We are also looking for more help of researchers who are interested in helping us with researching specific RFCs to help us refine the methodology. Please, feel free to ping us on or offlist.

Best,

Joana and Niels

a) Summary of the Session

An active debate about standards, protocols and human rights took place during the meeting of the Security Area Advisory Group –= ; SAAG at IETF 91, Hawaii. The discussion was framed by the Internet Draft “Proposal for research on human rights protocol considerations”. [1]

The Draft departs from the work that has been done by IETF on privacy and Internet protocols, such as RFC 6973 on Privacy Consideration guidelines [2], suggesting that some standards and protocols can solidify, enable or threaten human rights, such as freedom of expression and the right to association online. The proposal aims to establish a research group under the IRTF to study the structural relationship and impact between Internet standards and protocols and freedom of expression and association.<= br>
A deeper rationale for presenting such proposal was explained during the presentation at SAAG. The presenters, who are also the authors of this note highlighted that the Internet was designed with freedom and openness of communications as core values, but were also questioning whether this a structural value that can or needs to be preserved on a technical level. As the politicization of the Internet management space increases, it is argued that IETF should have an active role to promote a more structured and holistic approach. This would allow sustained future proofing of standards and protocols to avoid ad hoc decisions following incidents or disclosures at a variety of other foras and actors.
The proposal raised some eyebrows and concerns about the politicization of the work of the community. Dan Harkins posed that: “doing the human rights study will likely politicize protocols. Not want the technology to have political context. I want technology to be so unpolitical as possible.” This spark= ed a discussion with a rapid follow up by Justin, who stated that “= ;we have to stop pretending that technology is a non-political decision”, a remark that was followed by a round of applause.= One of the presenters responded that the research proposal was exactly aimed at avoiding further politicization of protocols or the community, but rather give the community time in a proper process to define its position.

Both John Levine and Alissa Cooper remarked that it is crucial to start of with a focus on specific human rights, because it will help keep the research manageable and help start the thinking about the balancing of different rights. The presenters reaffirmed that the primary focus will indeed be on the rights to freedom of expression and right to association. Alissa Cooper ment= ioned the IAB ID on filtering considerations [3] and the RFC Poli= cy Considerations for Internet Protocols [4] as relevant sources for research.

Several RFCs already make quite explicit statement about the objectives of the Internet, such as RFC1958 which mentions 't= he community believes that the goal [of the Internet] is connectivity, the tool is the Internet Protocol'. It continue= s a bit further: 'The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wid= e Web.' This marks the intrinsic value of connectivity which is= facilitated by the Internet, both in principle, and in practice.&nb= sp; This shows that the underlying principles of the Internet aim= to preserve connectivity, which is fundamental and similar to the part of article 19 of the Universal Declaration of Human Rights, which defines a right to receive and to impart information.

But there are also protocols that enable freedom of expression and access to information in an unprecedented way, such as HTTP. Even though there is not an explicit reference to rights in RFC7230, it does form the basis for a rights enabling architecture. The challenge of the research would be to seek out the specific protocol attribute(s) that enable that protocol to affect a specific human right.

The major challenge as next step would be to developed to develop an appropriate methodology to research the existing implicit safeguards in current standards and protocols, and making them explicit. Open discussions already gave some insights for possible methodological approaches. Richard Barnes suggests: “seems th= at you are reading RFCs and that you are looking for statement on rights and human rights that are laid out in RFCs. You might risk irritating people at least by reading reading technical documents as political statements. I think it might be more useful to use RFCs as a window into the rights that the community that developed these RFCs presumes.” Mark Nottingham also proposed a perspec= tive of stakeholder prioritization as described in ID Representing Stakeholder Rights in Internet Protocols [5] which is as alre= ady implemented at the W3C.

Other very useful remarks were made during and after the session, as well on the mailinglist [6] which are currently being used to improve the next version of the draft, possibly, to be further discussed at a Birds of Feather session in Dallas.

b) Research priorities and next steps

The proceedings of this session lead the presenters and authors of the ID to conclude that the subject and the research raised interest in the community. Their aim is to continue the research work an produce an updated ID before the Dallas meeting.

The research in the coming time will focus on documenting the specific protocol attributes that explicitly or implicitly affect specific human rights. For achieving that, a research methodology will be further developed; suggestions for the first steps consist of:

a) improving the list of RFCs that possibly have attributes to the right to freedom of expression and association;

b) conduct interviews at the Dallas meeting to further understand the intention that Area Directors and RFC authors have with specific protocols and how rights play a role in that;

c) set a common template to analyze standards and protocols describing the exact features, functions, characteristics or entities that allow a more defined understanding on the relation between them and the right to freedom of expression and association.

Nevertheless, these are just our suggestions to keep developing the ID and the work ahead of it. Comments, suggestions, hints are more then welcome and very much appreciated.

References
[1] Proposal for research on human rights protocol considerations,
= http://www.ietf.org/id/draft-doria-hrpc-proposal-00.txt

[2] RFC 6973 on Privacy Considerations for Internet Pro= tocols
https://www.r= fc-editor.org/rfc/rfc6973.txt

[3] Technical Considerations for Internet Service Blocking an= d Filtering
http://www.ietf.org/archive/id/draft-iab-filtering-consideratio= ns-06.txts

[4] Policy Considerations for Internet Protocols
= https://tools.ietf.org/html/draft-morris-policy-cons-00

[5] Representing Stakeholder Rights in Internet Protocols, https://tools.ietf.org/id/draft-nottingham-stakeholder-rights-00.txt=

[6] https://l= ists.ghserv.net/mailman/listinfo/hrpc

Other relevant links and information
IETF91 SAAG Agenda: http://www.ietf.org/proceedings/91/agenda/agenda-91-saag
IETF 91 SAAG minutes:
http://www.ietf.org/proceedings/91/minutes/minutes-91-saag
IETF 91 SAAG audio recording:
http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1300-pm1.mp3=
Presentation starts at 40:15
Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-saag-6.pdf=

--=20 -- Joana Varon @joana_varon https://antivigilancia.org Fingerprint=20 239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73

_______________________________________________ hrpc mailing list h= rpc@article19.io https://lists.ghserv.net/mailman/listinfo/hrpc

--
Mallory Knodel
Association for Progressive Communications :: apc.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

--------------050401010006060908010803-- --ELheV22lqT9ccqWf7WC6RM0pjknHvs8nC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUvo6bAAoJEAwyonG9PMeAZtUH/3SkJjh8ujilR54UEynLkPsf anrVR29kr7DantGcqIi+tZCNVktUSYZduUSkkKpL628RQ3PxL8+Waj4NpZzkbbh6 PKE44Y/0pl69nSZGujb6HLc+cINj4oL8R3Z+6mj1zSLEMXDnDxqiMJ6kSP24S3Hu xH1JUuxm2Wv+kVgb0XjYJj66ZtB9WHTtohRcVDSQE/PdagRUiAYDGKSzf/1uUOEf SpGAXQPAfs3VTlC0G8Go5t0dwML8MzGKkZpHrr2KztXrvOk7LQeGVB71N2UiLTCL Us9qLjkWwW62T0IAc22doSYcUwwi852caYqtjNxJFjtm9K71S3HYX7sJ9TGvjCI= =dt3H -----END PGP SIGNATURE----- --ELheV22lqT9ccqWf7WC6RM0pjknHvs8nC-- From joana@varonferraz.com Tue Jan 20 20:56:43 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YDeup-0003Pj-NV for hrpc@article19.io; Tue, 20 Jan 2015 20:56:43 +0100 Received: from smarthost1.greenhost.nl ([195.190.28.81]) by mx1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YDeup-0002Nq-L1 for hrpc@article19.io; Tue, 20 Jan 2015 20:56:43 +0100 Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YDeug-0003bY-W9 for hrpc@article19.io; Tue, 20 Jan 2015 20:56:43 +0100 Message-ID: <54BEB2F1.4050406@varonferraz.com> Date: Tue, 20 Jan 2015 17:56:33 -0200 From: Joana Varon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hrpc@article19.io References: <54BE7578.3010503@varonferraz.com> <54BE8E9B.2090207@apc.org> In-Reply-To: <54BE8E9B.2090207@apc.org> Content-Type: multipart/alternative; boundary="------------080102090506000309090306" X-Authenticated-As-Hash: 0663834574f9da71d8f82ee71c27915bbc5237b0 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50, HTML_MESSAGE autolearn=disabled version=3.3.2 X-Scan-Signature: b9b1c9e65b7efdd462b0181dba6609f6 Subject: Re: [hrpc] Summary ID on Human Rights presentation & next steps X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 19:56:44 -0000 This is a multi-part message in MIME format. --------------080102090506000309090306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mallory, Corinne et all Very thankful for the feedback and indeed every help is very welcome. I'll quickly convene with Niels and Avri to double check if we can extract a list of small activities to perform the first steps mentioned bellow: "a) improving the list of RFCs that possibly have attributes to the right to freedom of expression and association; b) conduct interviews at the Dallas meeting to further understand the intention that Area Directors and RFC authors have with specific protocols and how rights play a role in that; c) set a common template to analyze standards and protocols describing the exact features, functions, characteristics or entities that allow a more defined understanding on the relation between them and the right to freedom of expression and association." and I would say that it would be great if we could set a little task force to cover then according to your availabilities. If we manage to do so, we can hav work flowing until Dallas, while we also keep reporting our progresses and asking for comments in this list as it evolves. Are you up for a call to coordinate? best joana --=20 -- Joana Varon @joana_varon https://antivigilancia.wiki.br Fingerprint=20 239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73 On 20-01-2015 15:21, Mallory Knodel wrote: > Hi joana > > Congrats on sparking an interesting debate at the IETF in Hawaii. I > found all comments in the transcript useful, even those that > questioned the foundation of the research. In particular, I thought > the suggestion to analyze RFCs carefully for assumptions of rights is > a better approach than searching for overt mentions of rights. > Interviews in Dallas could certainly give more weight to the findings > if we take this approach. > > Questioning the apolitics of protocols is really a fundamental goal of > this work. I think while difficult, it would also be extremely > productive to continue to engage with folks in the community who feel > technology should strive to be apolitical, thereby developing a very > strong counterposition. > > Very happy to lend a hand with this work, > -Mallory > > On 01/20/2015 10:34 AM, Joana Varon wrote: >> Dear all, >> >> Happy 2015! We hope it will bring us the opportunity for enlightening >> and rich debates on human rights and protocols over here. >> >> For the purpose of doing so, this is an attempt to summarize and and >> structure our work. So, please, find underneath (a) the summary of >> the session at IETF91 where we presented the Internet Draft on Human >> Rights considerations for Internet protocols and (b) a brainstorming >> of some research priorities for the coming time. >> >> At the bottom you can also find the links for the records of the >> session and related documents. The full transcription of the Q&A are >> also here attached. >> >> All comments, questions and suggestions for research methods and >> angles are very welcome. We are also looking for more help of >> researchers who are interested in helping us with researching >> specific RFCs to help us refine the methodology. Please, feel free to >> ping us on or offlist. >> >> Best, >> >> Joana and Niels >> >> * >> **a) Summary of the Session* >> >> An active debate about standards, protocols and human rights took >> place during the meeting of the Security Area Advisory Group -- SAAG >> at IETF 91, Hawaii. The discussion was framed by the Internet Draft >> "Proposal for research on human rights protocol considerations". [1] >> >> The Draft departs from the work that has been done by IETF on privacy >> and Internet protocols, such as RFC 6973 on Privacy Consideration >> guidelines [2], suggesting that some standards and protocols can >> solidify, enable or threaten human rights, such as freedom of >> expression and the right to association online. The proposal aims to >> establish a research group under the IRTF to study the structural >> relationship and impact between Internet standards and protocols and >> freedom of expression and association. >> >> A deeper rationale for presenting such proposal was explained during >> the presentation at SAAG. The presenters, who are also the authors of >> this note highlighted that the Internet was designed with freedom and >> openness of communications as core values, but were also questioning >> whether this a structural value that can or needs to be preserved on >> a technical level. As the politicization of the Internet management >> space increases, it is argued that IETF should have an active role to >> promote a more structured and holistic approach. This would allow >> sustained future proofing of standards and protocols to avoid ad hoc >> decisions following incidents or disclosures at a variety of other >> foras and actors. >> >> The proposal raised some eyebrows and concerns about the >> politicization of the work of the community. Dan Harkins posed that: >> "doing the human rights study will likely politicize protocols. Not >> want the technology to have political context. I want technology to >> be so unpolitical as possible." This sparked a discussion with a >> rapid follow up by Justin, who stated that "we have to stop >> pretending that technology is a non-political decision", a remark >> that was followed by a round of applause. One of the presenters >> responded that the research proposal was exactly aimed at avoiding >> further politicization of protocols or the community, but rather give >> the community time in a proper process to define its position. >> >> Both John Levine and Alissa Cooper remarked that it is crucial to >> start of with a focus on specific human rights, because it will help >> keep the research manageable and help start the thinking about the >> balancing of different rights. The presenters reaffirmed that the >> primary focus will indeed be on the rights to freedom of expression >> and right to association. Alissa Cooper mentioned the IAB ID on >> filtering considerations [3] and the RFC Policy Considerations for >> Internet Protocols [4] as relevant sources for research. >> >> Several RFCs already make quite explicit statement about the >> objectives of the Internet, such as RFC1958 which mentions 'the >> community believes that the goal [of the Internet] is connectivity, >> the tool is the Internet Protocol'. It continues a bit further: 'The >> current exponential growth of the network seems to show that >> connectivity is its own reward, and is more valuable than any >> individual application such as mail or the World-Wide Web.' This >> marks the intrinsic value of connectivity which is facilitated by the >> Internet, both in principle, and in practice. This shows that the >> underlying principles of the Internet aim to preserve connectivity, >> which is fundamental and similar to the part of article 19 of the >> Universal Declaration of Human Rights, which defines a right to >> receive and to impart information. >> >> But there are also protocols that enable freedom of expression and >> access to information in an unprecedented way, such as HTTP. Even >> though there is not an explicit reference to rights in RFC7230, it >> does form the basis for a rights enabling architecture. The challenge >> of the research would be to seek out the specific protocol >> attribute(s) that enable that protocol to affect a specific human righ= t. >> >> The major challenge as next step would be to developed to develop an >> appropriate methodology to research the existing implicit safeguards >> in current standards and protocols, and making them explicit. Open >> discussions already gave some insights for possible methodological >> approaches. Richard Barnes suggests: "seems that you are reading RFCs >> and that you are looking for statement on rights and human rights >> that are laid out in RFCs. You might risk irritating people at least >> by reading reading technical documents as political statements. I >> think it might be more useful to use RFCs as a window into the rights >> that the community that developed these RFCs presumes." Mark >> Nottingham also proposed a perspective of stakeholder prioritization >> as described in ID Representing Stakeholder Rights in Internet >> Protocols [5] which is as already implemented at the W3C. >> >> Other very useful remarks were made during and after the session, as >> well on the mailinglist [6] which are currently being used to improve >> the next version of the draft, possibly, to be further discussed at a >> Birds of Feather session in Dallas. >> * >> **b) Research priorities and next steps* >> >> The proceedings of this session lead the presenters and authors of >> the ID to conclude that the subject and the research raised interest >> in the community. Their aim is to continue the research work an >> produce an updated ID before the Dallas meeting. >> >> The research in the coming time will focus on documenting the >> specific protocol attributes that explicitly or implicitly affect >> specific human rights. For achieving that, a research methodology >> will be further developed; suggestions for the first steps consist of:= >> >> a) improving the list of RFCs that possibly have attributes to the >> right to freedom of expression and association; >> >> b) conduct interviews at the Dallas meeting to further understand the >> intention that Area Directors and RFC authors have with specific >> protocols and how rights play a role in that; >> >> c) set a common template to analyze standards and protocols >> describing the exact features, functions, characteristics or entities >> that allow a more defined understanding on the relation between them >> and the right to freedom of expression and association. >> >> Nevertheless, these are just our suggestions to keep developing the >> ID and the work ahead of it. Comments, suggestions, hints are more >> then welcome and very much appreciated. >> >> >> *References* >> [1] Proposal for research on human rights protocol considerations, >> http://www.ietf.org/id/draft-doria-hrpc-proposal-00.txt >> >> [2] RFC 6973 on Privacy Considerations for Internet Protocols >> https://www.rfc-editor.org/rfc/rfc6973.txt >> >> [3] Technical Considerations for Internet Service Blocking and Filter= ing >> http://www.ietf.org/archive/id/draft-iab-filtering-considerations-06.= txts >> >> [4] Policy Considerations for Internet Protocols >> https://tools.ietf.org/html/draft-morris-policy-cons-00 >> >> [5] Representing Stakeholder Rights in Internet Protocols, >> https://tools.ietf.org/id/draft-nottingham-stakeholder-rights-00.txt >> >> [6] https://lists.ghserv.net/mailman/listinfo/hrpc >> >> * Other relevant links and information* >> IETF91 SAAG Agenda: >> http://www.ietf.org/proceedings/91/agenda/agenda-91-saag >> IETF 91 SAAG minutes: >> http://www.ietf.org/proceedings/91/minutes/minutes-91-saag >> IETF 91 SAAG audio recording: >> http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1300-pm1.mp3 >> Presentation starts at 40:15 >> Presentation: >> http://www.ietf.org/proceedings/91/slides/slides-91-saag-6.pdf >> --=20 >> -- >> Joana Varon >> @joana_varon >> https://antivigilancia.org >> Fingerprint=20 >> 239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73 >> >> >> _______________________________________________ >> hrpc mailing list >> hrpc@article19.io >> https://lists.ghserv.net/mailman/listinfo/hrpc > > --=20 > Mallory Knodel > Association for Progressive Communications :: apc.org = > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > > _______________________________________________ > hrpc mailing list > hrpc@article19.io > https://lists.ghserv.net/mailman/listinfo/hrpc --------------080102090506000309090306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Dear Mallory, Corinne et all

Very thankful for the feedback and indeed every help is very welcome. I'll quickly convene with Niels and Avri to double check if we can extract a list of small activities to perform the first steps mentioned bellow:

"a) improving the list of RFCs that possibly have attributes to the right to freedom of expression and association;

b) conduct interviews at the Dallas meeting to further understand the intention that Area Directors and RFC authors have with specific protocols and how rights play a role in that;

c) set a common template to analyze standards and protocols describing the exact features, functions, characteristics or entities that allow a more defined understanding on the relation between them and the right to freedom of expression and association."

and I would say that it would be great if we could set a little task force to cover then according to your availabilities. If we manage to do so, we can hav work flowing until Dallas, while we also keep reporting our progresses and asking for comments in this list as it evolves. Are you up for a call to coordinate?

best

joana

-- 
--
Joana Varon
@joana_varon
https://antivigilancia.wiki.br
Fingerprint 
239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73

On 20-01-2015 15:21, Mallory Knodel wrote:

Hi joana

Congrats on sparking an interesting debate at the IETF in Hawaii. I found all comments in the transcript useful, even those that questioned the foundation of the research. In particular, I thought the suggestion to analyze RFCs carefully for assumptions of rights is a better approach than searching for overt mentions of rights. Interviews in Dallas could certainly give more weight to the findings if we take this approach.

Questioning the apolitics of protocols is really a fundamental goal of this work. I think while difficult, it would also be extremely productive to continue to engage with folks in the community who feel technology should strive to be apolitical, thereby developing a very strong counterposition.

Very happy to lend a hand with this work,
-Mallory

On 01/20/2015 10:34 AM, Joana Varon wrote:
Dear all,

Happy 2015! We hope it will bring us the opportunity for enlightening and rich debates on human rights and protocols over here.

For the purpose of doing so, this is an attempt to summarize and and structure our work. So, please, find underneath (a) the summary of the session at IETF91 where we presented the Internet Draft on Human Rights considerations for Internet protocols and (b) a brainstorming of some research priorities for the coming time.

At the bottom you can also find the links for the records of the session and related documents. The full transcription of the Q&A are also here attached.

All comments, questions and suggestions for research methods and angles are very welcome. We are also looking for more help of researchers who are interested in helping us with researching specific RFCs to help us refine the methodology. Please, feel free to ping us on or offlist.

Best,

Joana and Niels

a) Summary of the Session

An active debate about standards, protocols and human rights took place during the meeting of the Security Area Advisory Group – SAAG at IETF 91, Hawaii. The discussion was framed by the Internet Draft “Proposal for research on human rights protocol considerations”. [1]

The Draft departs from the work that has been done by IETF on privacy and Internet protocols, such as RFC 6973 on Privacy Consideration guidelines [2], suggesting that some standards and protocols can solidify, enable or threaten human rights, such as freedom of expression and the right to association online. The proposal aims to establish a research group under the IRTF to study the structural relationship and impact between Internet standards and protocols and freedom of expression and association.

A deeper rationale for presenting such proposal was explained during the presentation at SAAG. The presenters, who are also the authors of this note highlighted that the Internet was designed with freedom and openness of communications as core values, but were also questioning whether this a structural value that can or needs to be preserved on a technical level. As the politicization of the Internet management space increases, it is argued that IETF should have an active role to promote a more structured and holistic approach. This would allow sustained future proofing of standards and protocols to avoid ad hoc decisions following incidents or disclosures at a variety of other foras and actors.

The proposal raised some eyebrows and concerns about the politicization of the work of the community. Dan Harkins posed that: “doing the human rights study will likely politicize protocols. Not want the technology to have political context. I want technology to be so unpolitical as possible.” This sparked a discussion with a rapid follow up by Justin, who stated that “we have to stop pretending that technology is a non-political decision”, a remark that was followed by a round of applause. One of the presenters responded that the research proposal was exactly aimed at avoiding further politicization of protocols or the community, but rather give the community time in a proper process to define its position.

Both John Levine and Alissa Cooper remarked that it is crucial to start of with a focus on specific human rights, because it will help keep the research manageable and help start the thinking about the balancing of different rights. The presenters reaffirmed that the primary focus will indeed be on the rights to freedom of expression and right to association. Alissa Cooper mentioned the IAB ID on filtering considerations [3] and the RFC Policy Considerations for Internet Protocols [4] as relevant sources for research.

Several RFCs already make quite explicit statement about the objectives of the Internet, such as RFC1958 which mentions 'the community believes that the goal [of the Internet] is connectivity, the tool is the Internet Protocol'. It continues a bit further: 'The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web.' This marks the intrinsic value of connectivity which is facilitated by the Internet, both in principle, and in practice. This shows that the underlying principles of the Internet aim to preserve connectivity, which is fundamental and similar to the part of article 19 of the Universal Declaration of Human Rights, which defines a right to receive and to impart information.

But there are also protocols that enable freedom of expression and access to information in an unprecedented way, such as HTTP. Even though there is not an explicit reference to rights in RFC7230, it does form the basis for a rights enabling architecture. The challenge of the research would be to seek out the specific protocol attribute(s) that enable that protocol to affect a specific human right.

The major challenge as next step would be to developed to develop an appropriate methodology to research the existing implicit safeguards in current standards and protocols, and making them explicit. Open discussions already gave some insights for possible methodological approaches. Richard Barnes suggests: “seems that you are reading RFCs and that you are looking for statement on rights and human rights that are laid out in RFCs. You might risk irritating people at least by reading reading technical documents as political statements. I think it might be more useful to use RFCs as a window into the rights that the community that developed these RFCs presumes.” Mark Nottingham also proposed a perspective of stakeholder prioritization as described in ID Representing Stakeholder Rights in Internet Protocols [5] which is as already implemented at the W3C.

Other very useful remarks were made during and after the session, as well on the mailinglist [6] which are currently being used to improve the next version of the draft, possibly, to be further discussed at a Birds of Feather session in Dallas.

b) Research priorities and next steps

The proceedings of this session lead the presenters and authors of the ID to conclude that the subject and the research raised interest in the community. Their aim is to continue the research work an produce an updated ID before the Dallas meeting.

The research in the coming time will focus on documenting the specific protocol attributes that explicitly or implicitly affect specific human rights. For achieving that, a research methodology will be further developed; suggestions for the first steps consist of:

a) improving the list of RFCs that possibly have attributes to the right to freedom of expression and association;

b) conduct interviews at the Dallas meeting to further understand the intention that Area Directors and RFC authors have with specific protocols and how rights play a role in that;

c) set a common template to analyze standards and protocols describing the exact features, functions, characteristics or entities that allow a more defined understanding on the relation between them and the right to freedom of expression and association.

Nevertheless, these are just our suggestions to keep developing the ID and the work ahead of it. Comments, suggestions, hints are more then welcome and very much appreciated.

References
[1] Proposal for research on human rights protocol considerations,
http://www.ietf.org/id/draft-doria-hrpc-proposal-00.txt

[2] RFC 6973 on Privacy Considerations for Internet Protocols
https://www.rfc-editor.org/rfc/rfc6973.txt

[3] Technical Considerations for Internet Service Blocking and Filtering
http://www.ietf.org/archive/id/draft-iab-filtering-considerations-06.txts

[4] Policy Considerations for Internet Protocols
https://tools.ietf.org/html/draft-morris-policy-cons-00

[5] Representing Stakeholder Rights in Internet Protocols,
https://tools.ietf.org/id/draft-nottingham-stakeholder-rights-00.txt

[6] https://lists.ghserv.net/mailman/listinfo/hrpc

Other relevant links and information
IETF91 SAAG Agenda: http://www.ietf.org/proceedings/91/agenda/agenda-91-saag
IETF 91 SAAG minutes:
http://www.ietf.org/proceedings/91/minutes/minutes-91-saag
IETF 91 SAAG audio recording:
http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1300-pm1.mp3
Presentation starts at 40:15
Presentation: http://www.ietf.org/proceedings/91/slides/slides-91-saag-6.pdf
-- 
--
Joana Varon
@joana_varon
https://antivigilancia.org
Fingerprint 
239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73
_______________________________________________
hrpc mailing list
hrpc@article19.io
https://lists.ghserv.net/mailman/listinfo/hrpc
--
Mallory Knodel
Association for Progressive Communications :: apc.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
_______________________________________________
hrpc mailing list
hrpc@article19.io
https://lists.ghserv.net/mailman/listinfo/hrpc

--------------080102090506000309090306-- From niels@article19.org Thu Jan 22 17:43:37 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEKr3-0006wp-Jx for hrpc@article19.io; Thu, 22 Jan 2015 17:43:37 +0100 Received: from smarthost1.greenhost.nl ([195.190.28.81]) by mx1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEKr3-0006og-Hs for hrpc@article19.io; Thu, 22 Jan 2015 17:43:37 +0100 Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEKqw-0004uf-Sa for hrpc@article19.io; Thu, 22 Jan 2015 17:43:37 +0100 Message-ID: <54C128AA.4030708@article19.org> Date: Thu, 22 Jan 2015 16:43:22 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: hrpc@article19.io References: <54BE7578.3010503@varonferraz.com> <54BE8E9B.2090207@apc.org> <54BEB2F1.4050406@varonferraz.com> In-Reply-To: <54BEB2F1.4050406@varonferraz.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 3eba33aa13262785abdb786b3645e2c2473cfc72 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 722402151f1a4d14534bd153d43c793f Subject: Re: [hrpc] Summary ID on Human Rights presentation & next steps X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 16:43:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Thanks for the feedback and the enthusiasm! While we're trying to secure a session at the IETF in Dallas it might be useful to have a joint look at one RFC and see how we can establish it's impact on human rights. I have setup this sheet: https://www.ethercalc.org/tdeh4wx2zo, but this is hardly enough of a template/lens/methodology to analyze the RFCs. So perhaps we could all have a look at RFC7230 [0] and see how we can define its impact on human rights. Once we have done that, we might be able to distill from this a loose methodology that we can then test on other RFCs. I specifically chose an RFC that doesn't (more or less) explicitly reference rights (such as RFC1958 and RFC4924), because in my humble opinion we should try to establish the link between actual protocols and standards and their impact on rights. If we could share our reflections here that could form a useful start for a discussion. What do you think? A call will be hard to plan for me in the coming week because of travel. Looking forward to read your contemplations. Best, Niels [0] https://tools.ietf.org/html/rfc7230 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 01/20/2015 07:56 PM, Joana Varon wrote: > Dear Mallory, Corinne et all > > Very thankful for the feedback and indeed every help is very > welcome. I'll quickly convene with Niels and Avri to double check > if we can extract a list of small activities to perform the first > steps mentioned bellow: > > "a) improving the list of RFCs that possibly have attributes to > the right to freedom of expression and association; > > b) conduct interviews at the Dallas meeting to further understand > the intention that Area Directors and RFC authors have with > specific protocols and how rights play a role in that; > > c) set a common template to analyze standards and protocols > describing the exact features, functions, characteristics or > entities that allow a more defined understanding on the relation > between them and the right to freedom of expression and > association." > > and I would say that it would be great if we could set a little > task force to cover then according to your availabilities. If we > manage to do so, we can hav work flowing until Dallas, while we > also keep reporting our progresses and asking for comments in this > list as it evolves. Are you up for a call to coordinate? > > best > > joana > > -- -- Joana Varon @joana_varon https://antivigilancia.wiki.br > Fingerprint 239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73 > > > On 20-01-2015 15:21, Mallory Knodel wrote: >> Hi joana >> >> Congrats on sparking an interesting debate at the IETF in Hawaii. >> I found all comments in the transcript useful, even those that >> questioned the foundation of the research. In particular, I >> thought the suggestion to analyze RFCs carefully for assumptions >> of rights is a better approach than searching for overt mentions >> of rights. Interviews in Dallas could certainly give more weight >> to the findings if we take this approach. >> >> Questioning the apolitics of protocols is really a fundamental >> goal of this work. I think while difficult, it would also be >> extremely productive to continue to engage with folks in the >> community who feel technology should strive to be apolitical, >> thereby developing a very strong counterposition. >> >> Very happy to lend a hand with this work, -Mallory >> >> On 01/20/2015 10:34 AM, Joana Varon wrote: >>> Dear all, >>> >>> Happy 2015! We hope it will bring us the opportunity for >>> enlightening and rich debates on human rights and protocols >>> over here. >>> >>> For the purpose of doing so, this is an attempt to summarize >>> and and structure our work. So, please, find underneath (a) the >>> summary of the session at IETF91 where we presented the >>> Internet Draft on Human Rights considerations for Internet >>> protocols and (b) a brainstorming of some research priorities >>> for the coming time. >>> >>> At the bottom you can also find the links for the records of >>> the session and related documents. The full transcription of >>> the Q&A are also here attached. >>> >>> All comments, questions and suggestions for research methods >>> and angles are very welcome. We are also looking for more help >>> of researchers who are interested in helping us with >>> researching specific RFCs to help us refine the methodology. >>> Please, feel free to ping us on or offlist. >>> >>> Best, >>> >>> Joana and Niels >>> >>> * **a) Summary of the Session* >>> >>> An active debate about standards, protocols and human rights >>> took place during the meeting of the Security Area Advisory >>> Group � SAAG at IETF 91, Hawaii. The discussion was framed by >>> the Internet Draft �Proposal for research on human rights >>> protocol considerations�. [1] >>> >>> The Draft departs from the work that has been done by IETF on >>> privacy and Internet protocols, such as RFC 6973 on Privacy >>> Consideration guidelines [2], suggesting that some standards >>> and protocols can solidify, enable or threaten human rights, >>> such as freedom of expression and the right to association >>> online. The proposal aims to establish a research group under >>> the IRTF to study the structural relationship and impact >>> between Internet standards and protocols and freedom of >>> expression and association. >>> >>> A deeper rationale for presenting such proposal was explained >>> during the presentation at SAAG. The presenters, who are also >>> the authors of this note highlighted that the Internet was >>> designed with freedom and openness of communications as core >>> values, but were also questioning whether this a structural >>> value that can or needs to be preserved on a technical level. >>> As the politicization of the Internet management space >>> increases, it is argued that IETF should have an active role >>> to promote a more structured and holistic approach. This would >>> allow sustained future proofing of standards and protocols to >>> avoid ad hoc decisions following incidents or disclosures at a >>> variety of other foras and actors. >>> >>> The proposal raised some eyebrows and concerns about the >>> politicization of the work of the community. Dan Harkins posed >>> that: �doing the human rights study will likely politicize >>> protocols. Not want the technology to have political context. I >>> want technology to be so unpolitical as possible.� This sparked >>> a discussion with a rapid follow up by Justin, who stated that >>> �we have to stop pretending that technology is a non-political >>> decision�, a remark that was followed by a round of applause. >>> One of the presenters responded that the research proposal was >>> exactly aimed at avoiding further politicization of protocols >>> or the community, but rather give the community time in a >>> proper process to define its position. >>> >>> Both John Levine and Alissa Cooper remarked that it is crucial >>> to start of with a focus on specific human rights, because it >>> will help keep the research manageable and help start the >>> thinking about the balancing of different rights. The >>> presenters reaffirmed that the primary focus will indeed be on >>> the rights to freedom of expression and right to association. >>> Alissa Cooper mentioned the IAB ID on filtering considerations >>> [3] and the RFC Policy Considerations for Internet Protocols >>> [4] as relevant sources for research. >>> >>> Several RFCs already make quite explicit statement about the >>> objectives of the Internet, such as RFC1958 which mentions >>> 'the community believes that the goal [of the Internet] is >>> connectivity, the tool is the Internet Protocol'. It continues >>> a bit further: 'The current exponential growth of the network >>> seems to show that connectivity is its own reward, and is more >>> valuable than any individual application such as mail or the >>> World-Wide Web.' This marks the intrinsic value of >>> connectivity which is facilitated by the Internet, both in >>> principle, and in practice. This shows that the underlying >>> principles of the Internet aim to preserve connectivity, which >>> is fundamental and similar to the part of article 19 of the >>> Universal Declaration of Human Rights, which defines a right >>> to receive and to impart information. >>> >>> But there are also protocols that enable freedom of expression >>> and access to information in an unprecedented way, such as >>> HTTP. Even though there is not an explicit reference to rights >>> in RFC7230, it does form the basis for a rights enabling >>> architecture. The challenge of the research would be to seek >>> out the specific protocol attribute(s) that enable that >>> protocol to affect a specific human right. >>> >>> The major challenge as next step would be to developed to >>> develop an appropriate methodology to research the existing >>> implicit safeguards in current standards and protocols, and >>> making them explicit. Open discussions already gave some >>> insights for possible methodological approaches. Richard Barnes >>> suggests: �seems that you are reading RFCs and that you are >>> looking for statement on rights and human rights that are laid >>> out in RFCs. You might risk irritating people at least by >>> reading reading technical documents as political statements. I >>> think it might be more useful to use RFCs as a window into the >>> rights that the community that developed these RFCs presumes.� >>> Mark Nottingham also proposed a perspective of stakeholder >>> prioritization as described in ID Representing Stakeholder >>> Rights in Internet Protocols [5] which is as already >>> implemented at the W3C. >>> >>> Other very useful remarks were made during and after the >>> session, as well on the mailinglist [6] which are currently >>> being used to improve the next version of the draft, possibly, >>> to be further discussed at a Birds of Feather session in >>> Dallas. * **b) Research priorities and next steps* >>> >>> The proceedings of this session lead the presenters and authors >>> of the ID to conclude that the subject and the research raised >>> interest in the community. Their aim is to continue the >>> research work an produce an updated ID before the Dallas >>> meeting. >>> >>> The research in the coming time will focus on documenting the >>> specific protocol attributes that explicitly or implicitly >>> affect specific human rights. For achieving that, a research >>> methodology will be further developed; suggestions for the >>> first steps consist of: >>> >>> a) improving the list of RFCs that possibly have attributes to >>> the right to freedom of expression and association; >>> >>> b) conduct interviews at the Dallas meeting to further >>> understand the intention that Area Directors and RFC authors >>> have with specific protocols and how rights play a role in >>> that; >>> >>> c) set a common template to analyze standards and protocols >>> describing the exact features, functions, characteristics or >>> entities that allow a more defined understanding on the >>> relation between them and the right to freedom of expression >>> and association. >>> >>> Nevertheless, these are just our suggestions to keep developing >>> the ID and the work ahead of it. Comments, suggestions, hints >>> are more then welcome and very much appreciated. >>> >>> >>> *References* [1] Proposal for research on human rights protocol >>> considerations, >>> http://www.ietf.org/id/draft-doria-hrpc-proposal-00.txt >>> >>> [2] RFC 6973 on Privacy Considerations for Internet Protocols >>> https://www.rfc-editor.org/rfc/rfc6973.txt >>> >>> [3] Technical Considerations for Internet Service Blocking and >>> Filtering >>> http://www.ietf.org/archive/id/draft-iab-filtering-considerations-06.txts >>> >>> >>> [4] Policy Considerations for Internet Protocols >>> https://tools.ietf.org/html/draft-morris-policy-cons-00 >>> >>> [5] Representing Stakeholder Rights in Internet Protocols, >>> https://tools.ietf.org/id/draft-nottingham-stakeholder-rights-00.txt >>> >>> >>> [6] https://lists.ghserv.net/mailman/listinfo/hrpc >>> >>> * Other relevant links and information* IETF91 SAAG Agenda: >>> http://www.ietf.org/proceedings/91/agenda/agenda-91-saag IETF >>> 91 SAAG minutes: >>> http://www.ietf.org/proceedings/91/minutes/minutes-91-saag IETF >>> 91 SAAG audio recording: >>> http://www.ietf.org/audio/ietf91/ietf91-coral3-20141113-1300-pm1.mp3 >>> >>> Presentation starts at 40:15 >>> Presentation: >>> http://www.ietf.org/proceedings/91/slides/slides-91-saag-6.pdf >>> -- -- Joana Varon @joana_varon https://antivigilancia.org >>> Fingerprint 239D E977 32D0 28BC 297F 64B6 3B69 BDE4 016B 8E73 >>> >>> >>> _______________________________________________ hrpc mailing >>> list hrpc@article19.io >>> https://lists.ghserv.net/mailman/listinfo/hrpc >> >> -- Mallory Knodel Association for Progressive Communications :: >> apc.org gpg fingerprint :: E3EB 63E0 65A3 B240 >> BCD9 B071 0C32 A271 BD3C C780 >> >> >> _______________________________________________ hrpc mailing >> list hrpc@article19.io >> https://lists.ghserv.net/mailman/listinfo/hrpc > > > > _______________________________________________ hrpc mailing list > hrpc@article19.io https://lists.ghserv.net/mailman/listinfo/hrpc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUwSimAAoJEAi1oPJjbWjp4OwH/1BOqBjWT60t+mSg9715yHVU SI3UIUXC/ygdAZXl1Xtv7jXkJHyOUcICVQHld6djk/wPr8e1QJat62FP+N/etGxc 591xAq6WD3ZZ0/3GG/GMecYTEuq/y/4+kiI4GxM2QxX1fO21O2w76+kXJIE3fWP5 oKQfqSyUccKMueJ5JVEkut9a5a2rvqfFYYPH8IgZywFqKQ80BonKbQfcLh8N/X39 A3ePsDiLA7sM6XR5y1FspaturqD8yiGpj7nLc2Sr3L9TcgZZXj856j8qnh/rChK2 PUsADohmLlr4kI4p9jyJrCbYmOY5RQQJuWkWH4dKwPGg9B5XuHeJW8BsPRjykPY= =ovUy -----END PGP SIGNATURE----- From avri@acm.org Fri Jan 23 14:22:58 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEeCQ-00009n-Rh for hrpc@article19.io; Fri, 23 Jan 2015 14:22:58 +0100 Received: from atl4mhob02.myregisteredsite.com ([209.17.115.40]) by mx2.greenhost.nl with esmtp (Exim 4.72) (envelope-from ) id 1YEeBD-0002qi-To for hrpc@article19.io; Fri, 23 Jan 2015 14:22:58 +0100 Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t0NDLeKF014450 for ; Fri, 23 Jan 2015 08:21:40 -0500 Received: (qmail 28488 invoked by uid 0); 23 Jan 2015 13:21:40 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 23 Jan 2015 13:21:40 -0000 Message-ID: <54C24AE3.1010508@acm.org> Date: Fri, 23 Jan 2015 08:21:39 -0500 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Eggert, Lars" Content-Type: multipart/alternative; boundary="------------000705030003060805000307" X-Antivirus: avast! (VPS 150122-2, 01/22/2015), Outbound message X-Antivirus-Status: Not-Tested X-Spam-Level: + X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_SOFTFAIL autolearn=disabled version=3.3.2 X-Spam-Score: 1.5 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: cd688a2151aac0590452c2fa0bd26a10 Cc: hrpc@article19.io, Kathleen Moriarty Subject: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:22:59 -0000 This is a multi-part message in MIME format. --------------000705030003060805000307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I don't know whether it is a BoF or there is some other designation for an IRTF session for a 'RG in possible formation.' In any case, following up on the interest in the SAAG session, and afterwards, we (Joana, Niels and I) would like to request such a session. At the end of the requested session, the goal would be to discuss the formation of a RG. But we would like to make it substantive and include the following discussion items: 1) Continue the discussion on the interrelation between protocols, architectures and rights 2) Enable broad community engagement in this discussion as was discussed in Hawaii. 3) Allow this discussion to happen before politicization related to human rights and the Internet occurs. A major premise of our research goals is future-proofing protocols in relation to their effect on human rights. If we can discover a reliable set of considerations, we may avoid needing to fix as many protocols retroactively going forward. We believe that our goal, consistent with RFC1958, is for the Internet to continue to serve as a tool enabling connectivity among all people. Attacks on the Internet's ability to do this are increasing and worrisome. I think we could use a full session for the discussion, but one of the shorter slots would probably work. Lars, please let us know of any specific information you need or specific steps you would like us to take in following up on this request.= We would also be intersted in hearing from the list as to other things that might be worth adding to the such a discussion so that we can adjust the proposed 'agenda' to suit. Optimally we can evolve from the 3 of us trying to get this going to a group working on moving it forward.=20 But time was getting late for requesting a slot and we felt we needed to get this moving. Thanks avri with Joana and Niels --------------000705030003060805000307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by atl4mhob02.myregisteredsite.com id t0NDLeKF014450 Hi,

I don't know whether it is a BoF or there is some other designation for an IRTF session for a 'RG in possible formation.'=C2= =A0 In any case, following up on the interest in the SAAG session, and afterwards, we (Joana, Niels and I) would like to request such a session.

At the end of the requested session, the goal would be to discuss the formation of a RG.=C2=A0 But we would like to make it substanti= ve and include the following discussion items:

1) Continue the discussio= n on the interrelation between protocols, architectures and rights

2) Enable broad community engagement in this discussion as was discussed in Hawaii.

3) Allow this discussion to happen before politicization related to human rights and the Internet occurs.

A major premise of our research goals is future-proofing protocols in relation to their effect on human rights. If we can discover a reliable set of considerations, we may avoid needing to fix as many protocols retroactively going forward. We believe that our goal, consistent with RFC1958, is for the Internet to continue to serve as a tool enabling connectivity among all people. Attacks on the Internet's ability to do this are increasing and worrisome.

I think we could use a full session for the discussion, but one of the shorter slots would probably work.

Lars, please let us know of any specific information you need or specific steps you would like us to take in following up on this request.

We would also be intersted in hearing from the list as to other things that might be worth adding to the such a discussion so that we can adjust the proposed 'agenda' to suit. Optimally we can evolve from the 3 of us trying to get this going to a group working on moving it forward.=C2=A0 But time was getting late for requesting a slot and we felt we needed to get this moving.

Thanks

avri
with Joana and Niels
--------------000705030003060805000307-- From avri@acm.org Fri Jan 23 14:58:36 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEeku-0000Cw-2n for hrpc@article19.io; Fri, 23 Jan 2015 14:58:36 +0100 Received: from atl4mhob02.myregisteredsite.com ([209.17.115.40]) by mx1.greenhost.nl with esmtp (Exim 4.72) (envelope-from ) id 1YEeki-0003OZ-2u for hrpc@article19.io; Fri, 23 Jan 2015 14:58:36 +0100 Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob02.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t0NDwKM6024721 for ; Fri, 23 Jan 2015 08:58:20 -0500 Received: (qmail 27734 invoked by uid 0); 23 Jan 2015 13:58:20 -0000 X-TCPREMOTEIP: 68.15.42.104 X-Authenticated-UID: avri@ella.com Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 23 Jan 2015 13:58:19 -0000 Message-ID: <54C2537A.2010803@acm.org> Date: Fri, 23 Jan 2015 08:58:18 -0500 From: Avri Doria User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Eggert, Lars" References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> In-Reply-To: <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> Content-Type: multipart/alternative; boundary="------------080404070601000704060800" X-Antivirus: avast! (VPS 150122-2, 01/22/2015), Outbound message X-Antivirus-Status: Not-Tested X-Spam-Level: + X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_SOFTFAIL autolearn=disabled version=3.3.2 X-Spam-Score: 1.5 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 3a195eeb8bac4edf9758d037a4331094 Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:58:36 -0000 This is a multi-part message in MIME format. --------------080404070601000704060800 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =20 Hi, Thanks for the really fast response. I really appreciate the approach you take on 'proposed RG's, and really did not want to have to work on a charter just yet. My first approach at answers regarding the session. * what kind of meeting do you want to hold in Dallas (on the agenda, or o= ff) On the agenda, as I think it would be good to reach out to other who might be interested. I think a 90 minute slot would be good for this first session. I have personal conflict I would like to avoid in scheduling, the IANA transiton subject. Additionally we should avoid conflict with the SAAG meeting as there is where we found many interested in the discussion at the last meeting and any meetings dealing with privacy consideration issues. We can build a conflict list over the next days if people need to add some. * do you have a mailing list? Yes, hrpc@article19.io * do you have a group of people with energy to make the group successful?= Not sure yet. There are at least 3 of us committed to the work and a bunch of others who have shown interest. There appeared to be interest in continuing the discussion at the SAAG meeting, but it is still early to know. What I do believe is that we need to continue the approach that started there and see if we can build something. * do you have some description of the group? (below is an OK start) I would use this as a start. A major premise of our research goals is future-proofing protocols in relation to their effect on human rights. If we can discover a reliable set of considerations, we may avoid needing to fix as many protocols retroactively going forward. We believe that our goal, consistent with RFC1958, is for the Internet to continue to serve as a tool enabling connectivity among all people. Attacks on the Internet's ability to do this are increasing and worrisome. Some of the topics we want to discuss: 1) Continue the discussion on the interrelation between protocols, architectures and rights 2) Enable broad community engagement in this discussion as was discussed in Hawaii. 3) Allow this discussion to happen before politicization related to human rights and the Internet occurs. 4) Discuss methods for doing the work. Thanks avri On 23-Jan-15 08:31, Eggert, Lars wrote: > Hi, > > On 2015-1-23, at 14:21, Avri Doria wrote: >> I don't know whether it is a BoF or there is some other designation for an IRTF session for a 'RG in possible formation.' In any case, following up on the interest in the SAAG session, and afterwards, we (Joana, Niels and I) would like to request such a session. > > I'm happy to have that discussion. I do note that we will need to conclude this in the next few days, because scheduling for rooms for Dallas will begin. > >> At the end of the requested session, the goal would be to discuss the formation of a RG. > > That's not quite how I handle this in the IRTF. For folks that come with an idea for a new RG, I'm willing to give them meeting rooms at IETF meetings for a year, and (if they like) have the meeting listed on the agenda as a "proposed RG" meeting. (It is also possible to have some of these meetings off the agenda, i.e., with invitations handled by the proponents of the group.) The instructions to the proponents are basically "go and pretend you are an RG", in other words, invite the people you want to invite, have the discussions you want to have and don't worry about the charter text. > > After that year has passed, I sit down with the proponents, the IRSG and IAB and we discuss if the proposed group is off to a good start. > > The reason I'm doing it this way is that I've seen to many new RGs in the past focus on charter text, get it perfect and then die on the starting line because of lack of energy or lack of community building by the proponents. So I've decided to front-load that, and fine tune the charter afterwards. > > Of course you will need some sort of text to explain the group to new people, so they can determine if it's for them, but it doesn't need to be as formal as a charter. > > So: > > * what kind of meeting do you want to hold in Dallas (on the agenda, or off) > > * do you have a mailing list? > > * do you have a group of people with energy to make the group successfu= l? > > * do you have some description of the group? (below is an OK start) > > >> But we would like to make it substantive and include the following discussion items: >> >> 1) Continue the discussion on the interrelation between protocols, architectures and rights >> >> 2) Enable broad community engagement in this discussion as was discussed in Hawaii. >> >> 3) Allow this discussion to happen before politicization related to human rights and the Internet occurs. >> >> A major premise of our research goals is future-proofing protocols in relation to their effect on human rights. If we can discover a reliable set of considerations, we may avoid needing to fix as many protocols retroactively going forward. We believe that our goal, consistent with RFC1958, is for the Internet to continue to serve as a tool enabling connectivity among all people. Attacks on the Internet's ability to do this are increasing and worrisome. >> >> I think we could use a full session for the discussion, but one of the shorter slots would probably work. > > If you want an "on the agenda" meeting, you need to determine how many hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine your list of conflicts with other RGs and WGs. > > If you want an "off the agenda" meeting, those are not scheduled in parallel to WG and RG sessions, so it would need to be breakfast, lunch or evening time. > >> Lars, please let us know of any specific information you need or specific steps you would like us to take in following up on this request.= > > See above. > >> We would also be intersted in hearing from the list as to other things that might be worth adding to the such a discussion so that we can adjust the proposed 'agenda' to suit. Optimally we can evolve from the 3 of us trying to get this going to a group working on moving it forward. But time was getting late for requesting a slot and we felt we needed to get this moving. > > Heads up: I may not make it to Dallas for personal reasons. I should know for sure in a few weeks. But since we're not deciding on the formal chartering of the group in Dallas, that's OK. I will be able to go to your future meetings. > > Lars > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) =20 iQEcBAEBAgAGBQJUwlN5AAoJEOo+L8tCe36HxhIIAJ/7D9whDcXOb29m2jCMAODJ 1ISwRBuMydLshS2ZlqiwMs5v9uU4vxk0fKC5o2X08EJ95yTwNtZ11I2Pj8Vt8w4d hiXvKbSW+7N0W2SncuVcf69HjMcsCzXh8n0QAwW99efqtSuYBhLstFfZzMKia2CF q0gRqTUqY7wwv+tAgv9M8GhFnMmUH/3UKz5eceOG7Dli3urAbasUFkObNIkhYH5x /GFIFj8UDyY0Jkw/xEvVMesQaoqERMe5+5A9oF53aYhJ/QT0C5J1O6sDsB9gvjNK ijNSjocbKWpNKywdH8+l1wx+dR/6Sw7eDW1RBtAQFyz83Go8yGp0ivqin/iu9lo=3D =3DT48r -----END PGP SIGNATURE----- --------------080404070601000704060800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by atl4mhob02.myregisteredsite.com id t0NDwKM6024721
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=A0
Hi,

Thanks for the really fast response.=A0 I really appreciate the approach you take on 'proposed RG's, and really did not want to have to work on a charter just yet.

My first approach at answers regarding the session.

* what kind of meeting do you want to hold in Dallas (on the agenda, or off)

On the agenda, as I think it would be good to reach out to other who might be interested.

I think a 90 minute slot would be good for this first session.

I have personal conflict I would like to avoid in scheduling, the IANA transiton subject.=A0 Additionally we should avoid conflict with the SAAG meeting as there is where we found many interested in the discussion at the last meeting and any meetings dealing with privacy consideration issues.=A0 We can build a conflict list over the next days if people need to add some.

* do you have a mailing list?

Yes, hrpc@article19.io <hrpc@article19.io>

* do you have a group of people with energy to make the group successful?

Not sure yet.=A0 There are at least 3 of us committed to the work and a bunch of others who have shown interest.=A0 There appeared to be interest in continuing the discussion at the SAAG meeting, but it is still early to know.=A0 What I do believe is that we need to continue the approach that started there and see if we can build something.
* do you have some description of the group? (below is an OK start)
I would use this=A0 as a start.

A major premise of our research goals is future-proofing protocols in relation to their effect on human rights. If we can discover a reliable set of considerations, we may avoid needing to fix as many protocols retroactively going forward. We believe that our goal, consistent with RFC1958, is for the Internet to continue to serve as a tool enabling connectivity among all people. Attacks on the Internet's ability to do this are increasing and worrisome.

Some of the topics we want to discuss:

1) Continue the discussion on the interrelation between protocols, architectures and rights

2) Enable broad community engagement in this discussion as was discussed in Hawaii.

3) Allow this discussion to happen before politicization related to human rights and the Internet occurs.

4) Discuss methods for doing the work.

Thanks

avri

On 23-Jan-15 08:31, Eggert, Lars wrote:
> Hi,
>
> On 2015-1-23, at 14:21, Avri Doria <avri@acm.org> wrote:
>> I don't know whether it is a BoF or there is some other designation for an IRTF session for a 'RG in possible formation.'=A0 In any case, following up on the interest in the SAAG session, and afterwards, we (Joana, Niels and I) would like to request such a session.
>
> I'm happy to have that discussion. I do note that we will need to conclude this in the next few days, because scheduling for rooms for Dallas will begin.
>
>> At the end of the requested session, the goal would be to discuss the formation of a RG.
>
> That's not quite how I handle this in the IRTF. For folks that come with an idea for a new RG, I'm willing to give them meeting rooms at IETF meetings for a year, and (if they like) have the meeting listed on the agenda as a "proposed RG" meeting. (It is also possible to have some of these meetings off the agenda, i.e., with invitations handled by the proponents of the group.) The instructions to the proponents are basically "go and pretend you are an RG", in other words, invite the people you want to invite, have the discussions you want to have and don't worry about the charter text.
>
> After that year has passed, I sit down with the proponents, the IRSG and IAB and we discuss if the proposed group is off to a good start.
>
> The reason I'm doing it this way is that I've seen to many new RGs in the past focus on charter text, get it perfect and then die on the starting line because of lack of energy or lack of community building by the proponents. So I've decided to front-load that, and fine tune the charter afterwards.
>
> Of course you will need some sort of text to explain the group to new people, so they can determine if it's for them, but it doesn't need to be as formal as a charter.
>
> So:
>
> * what kind of meeting do you want to hold in Dallas (on the agenda, or off)
>
> * do you have a mailing list?
>
> * do you have a group of people with energy to make the group successful?
>
> * do you have some description of the group? (below is an OK start)
>
>
>>=A0 But we would like to make it substantive and include th= e following discussion items:
>>
>> 1) Continue the discussion on the interrelation between protocols, architectures and rights
>>
>> 2) Enable broad community engagement in this discussion as was discussed in Hawaii.
>>
>> 3) Allow this discussion to happen before politicization related to human rights and the Internet occurs.
>>
>> A major premise of our research goals is future-proofing protocols in relation to their effect on human rights. If we can discover a reliable set of considerations, we may avoid needing to fix as many protocols retroactively going forward. We believe that our goal, consistent with RFC1958, is for the Internet to continue to serve as a tool enabling connectivity among all people. Attacks on the Internet's ability to do this are increasing and worrisome.<= br> >>
>> I think we could use a full session for the discussion, but one of the shorter slots would probably work.
>
> If you want an "on the agenda" meeting, you need to determine how many hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine your list of conflicts with other RGs and WGs.
>
> If you want an "off the agenda" meeting, those are not scheduled in parallel to WG and RG sessions, so it would need to be breakfast, lunch or evening time.
>
>> Lars, please let us know of any specific information you need or specific steps you would like us to take in following up on this request.
>
> See above.
>
>> We would also be intersted in hearing from the list as to other things that might be worth adding to the such a discussion so that we can adjust the proposed 'agenda' to suit. Optimally we can evolve from the 3 of us trying to get this going to a group working on moving it forward.=A0 But time was getting late for requesting a slot and we felt we needed to get this moving.
>
> Heads up: I may not make it to Dallas for personal reasons. I should know for sure in a few weeks. But since we're not deciding on the formal chartering of the group in Dallas, that's OK. I will be able to go to your future meetings.
>
> Lars
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
=A0
iQEcBAEBAgAGBQJUwlN5AAoJEOo+L8tCe36HxhIIAJ/7D9whDcXOb29m2jCMAODJ
1ISwRBuMydLshS2ZlqiwMs5v9uU4vxk0fKC5o2X08EJ95yTwNtZ11I2Pj8Vt8w4d
hiXvKbSW+7N0W2SncuVcf69HjMcsCzXh8n0QAwW99efqtSuYBhLstFfZzMKia2CF
q0gRqTUqY7wwv+tAgv9M8GhFnMmUH/3UKz5eceOG7Dli3urAbasUFkObNIkhYH5x
/GFIFj8UDyY0Jkw/xEvVMesQaoqERMe5+5A9oF53aYhJ/QT0C5J1O6sDsB9gvjNK
ijNSjocbKWpNKywdH8+l1wx+dR/6Sw7eDW1RBtAQFyz83Go8yGp0ivqin/iu9lo=3D
=3DT48r
-----END PGP SIGNATURE-----

--------------080404070601000704060800-- From lars@netapp.com Fri Jan 23 14:32:52 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEeM0-0000Ap-SC for hrpc@article19.io; Fri, 23 Jan 2015 14:32:52 +0100 Received: from mx142.netapp.com ([216.240.21.19]) by mx2.greenhost.nl with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YEeL9-00039e-9S for hrpc@article19.io; Fri, 23 Jan 2015 14:32:52 +0100 X-IronPort-AV: E=Sophos;i="5.09,453,1418112000"; d="asc'?scan'208";a="16346581" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 23 Jan 2015 05:31:55 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 23 Jan 2015 05:31:55 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Fri, 23 Jan 2015 05:31:55 -0800 From: "Eggert, Lars" To: Avri Doria Thread-Topic: Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration Thread-Index: AQHQNw+Lbi/pjRLIh0izuhYIBsonqpzOOeQA Date: Fri, 23 Jan 2015 13:31:54 +0000 Message-ID: <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> References: <54C24AE3.1010508@acm.org> In-Reply-To: <54C24AE3.1010508@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.4) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4B15F533-E4EB-4728-A6FE-0B08382BBC11"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Spam-Level: ---- X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_HI, SPF_PASS, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.3 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 8c99c374a8d12108ecfc332d37a9628a X-Mailman-Approved-At: Fri, 23 Jan 2015 15:16:29 +0100 Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 13:32:53 -0000 --Apple-Mail=_4B15F533-E4EB-4728-A6FE-0B08382BBC11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2015-1-23, at 14:21, Avri Doria wrote: > I don't know whether it is a BoF or there is some other designation = for an IRTF session for a 'RG in possible formation.' In any case, = following up on the interest in the SAAG session, and afterwards, we = (Joana, Niels and I) would like to request such a session. I'm happy to have that discussion. I do note that we will need to = conclude this in the next few days, because scheduling for rooms for = Dallas will begin. > At the end of the requested session, the goal would be to discuss the = formation of a RG. That's not quite how I handle this in the IRTF. For folks that come with = an idea for a new RG, I'm willing to give them meeting rooms at IETF = meetings for a year, and (if they like) have the meeting listed on the = agenda as a "proposed RG" meeting. (It is also possible to have some of = these meetings off the agenda, i.e., with invitations handled by the = proponents of the group.) The instructions to the proponents are = basically "go and pretend you are an RG", in other words, invite the = people you want to invite, have the discussions you want to have and = don't worry about the charter text. After that year has passed, I sit down with the proponents, the IRSG and = IAB and we discuss if the proposed group is off to a good start. The reason I'm doing it this way is that I've seen to many new RGs in = the past focus on charter text, get it perfect and then die on the = starting line because of lack of energy or lack of community building by = the proponents. So I've decided to front-load that, and fine tune the = charter afterwards. Of course you will need some sort of text to explain the group to new = people, so they can determine if it's for them, but it doesn't need to = be as formal as a charter. So: * what kind of meeting do you want to hold in Dallas (on the agenda, or = off) * do you have a mailing list? * do you have a group of people with energy to make the group = successful? * do you have some description of the group? (below is an OK start) > But we would like to make it substantive and include the following = discussion items: >=20 > 1) Continue the discussion on the interrelation between protocols, = architectures and rights >=20 > 2) Enable broad community engagement in this discussion as was = discussed in Hawaii. >=20 > 3) Allow this discussion to happen before politicization related to = human rights and the Internet occurs. >=20 > A major premise of our research goals is future-proofing protocols in = relation to their effect on human rights. If we can discover a reliable = set of considerations, we may avoid needing to fix as many protocols = retroactively going forward. We believe that our goal, consistent with = RFC1958, is for the Internet to continue to serve as a tool enabling = connectivity among all people. Attacks on the Internet's ability to do = this are increasing and worrisome. >=20 > I think we could use a full session for the discussion, but one of the = shorter slots would probably work. If you want an "on the agenda" meeting, you need to determine how many = hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine your = list of conflicts with other RGs and WGs. If you want an "off the agenda" meeting, those are not scheduled in = parallel to WG and RG sessions, so it would need to be breakfast, lunch = or evening time. > Lars, please let us know of any specific information you need or = specific steps you would like us to take in following up on this = request. See above. > We would also be intersted in hearing from the list as to other things = that might be worth adding to the such a discussion so that we can = adjust the proposed 'agenda' to suit. Optimally we can evolve from the 3 = of us trying to get this going to a group working on moving it forward. = But time was getting late for requesting a slot and we felt we needed to = get this moving. Heads up: I may not make it to Dallas for personal reasons. I should = know for sure in a few weeks. But since we're not deciding on the formal = chartering of the group in Dallas, that's OK. I will be able to go to = your future meetings. Lars --Apple-Mail=_4B15F533-E4EB-4728-A6FE-0B08382BBC11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVMJNStZcnpRveo1xAQITwQP/cp8y+KZUu1lwkUi5uqByaTBIygoaXN/J 9D9iy8oJbasUAHxcs3FuVi+4BKFhgTFzmJHlhmI7V9ry3ejvuum92ACOayDQLr6j d5u36tGKNrOQnT8WjwkIE9bXPLBmc6U4/dXJVmNeza4eEP48lVHO7I1YJLKATJYF qbWkMhB/yPs= =aeV8 -----END PGP SIGNATURE----- --Apple-Mail=_4B15F533-E4EB-4728-A6FE-0B08382BBC11-- From lars@netapp.com Fri Jan 23 15:26:14 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEfBe-0000GJ-JW for hrpc@article19.io; Fri, 23 Jan 2015 15:26:14 +0100 Received: from mx143.netapp.com ([216.240.21.24]) by mx1.greenhost.nl with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YEfB8-0004TR-JE for hrpc@article19.io; Fri, 23 Jan 2015 15:26:14 +0100 X-IronPort-AV: E=Sophos;i="5.09,454,1418112000"; d="asc'?scan'208,217";a="16971100" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 23 Jan 2015 06:25:40 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 23 Jan 2015 06:25:39 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Fri, 23 Jan 2015 06:25:39 -0800 From: "Eggert, Lars" To: Avri Doria Thread-Topic: Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration Thread-Index: AQHQNw+Lbi/pjRLIh0izuhYIBsonqpzOOeQAgAAHYACAAAehAA== Date: Fri, 23 Jan 2015 14:25:39 +0000 Message-ID: References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> In-Reply-To: <54C2537A.2010803@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.4) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_B7C82F61-40C2-4ACC-B7FC-21DCC7A2ABD0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Spam-Level: ---- X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_50, HTML_MESSAGE, RCVD_IN_DNSWL_HI, SPF_PASS, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.3 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 9318004691e4a668603df0d3bd1fe54e Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 14:26:15 -0000 --Apple-Mail=_B7C82F61-40C2-4ACC-B7FC-21DCC7A2ABD0 Content-Type: multipart/alternative; boundary="Apple-Mail=_65A60C89-89AE-45A6-98A9-E2634E0C5C1F" --Apple-Mail=_65A60C89-89AE-45A6-98A9-E2634E0C5C1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Avri, in order for me to set this up in the datatracker (so you can request a = session), please send me this information: * group name * group acronym * chairs other than you * how to subscribe to the list (URL) * any other URLs for the proposed group Lars On 2015-1-23, at 14:58, Avri Doria wrote: >=20 >=20 > Signed PGP part > Hi, >=20 > Thanks for the really fast response. I really appreciate the approach > you take on 'proposed RG's, and really did not want to have to work on = a > charter just yet. >=20 > My first approach at answers regarding the session. >=20 > * what kind of meeting do you want to hold in Dallas (on the agenda, = or off) >=20 > On the agenda, as I think it would be good to reach out to other who > might be interested. >=20 > I think a 90 minute slot would be good for this first session. >=20 > I have personal conflict I would like to avoid in scheduling, the IANA > transiton subject. Additionally we should avoid conflict with the = SAAG > meeting as there is where we found many interested in the discussion = at > the last meeting and any meetings dealing with privacy consideration > issues. We can build a conflict list over the next days if people = need > to add some. >=20 > * do you have a mailing list? >=20 > Yes, hrpc@article19.io > >=20 > * do you have a group of people with energy to make the group = successful? >=20 > Not sure yet. There are at least 3 of us committed to the work and a > bunch of others who have shown interest. There appeared to be = interest > in continuing the discussion at the SAAG meeting, but it is still = early > to know. What I do believe is that we need to continue the approach > that started there and see if we can build something. >=20 > * do you have some description of the group? (below is an OK start) >=20 > I would use this as a start. >=20 > A major premise of our research goals is future-proofing protocols in > relation to their effect on human rights. If we can discover a = reliable > set of considerations, we may avoid needing to fix as many protocols > retroactively going forward. We believe that our goal, consistent with > RFC1958, is for the Internet to continue to serve as a tool enabling > connectivity among all people. Attacks on the Internet's ability to do > this are increasing and worrisome. >=20 > Some of the topics we want to discuss: >=20 > 1) Continue the discussion on the interrelation between protocols, > architectures and rights >=20 > 2) Enable broad community engagement in this discussion as was = discussed > in Hawaii. >=20 > 3) Allow this discussion to happen before politicization related to > human rights and the Internet occurs. >=20 > 4) Discuss methods for doing the work. >=20 > Thanks >=20 > avri >=20 >=20 > On 23-Jan-15 08:31, Eggert, Lars wrote: > > Hi, > > > > On 2015-1-23, at 14:21, Avri Doria > wrote: > >> I don't know whether it is a BoF or there is some other designation > for an IRTF session for a 'RG in possible formation.' In any case, > following up on the interest in the SAAG session, and afterwards, we > (Joana, Niels and I) would like to request such a session. > > > > I'm happy to have that discussion. I do note that we will need to > conclude this in the next few days, because scheduling for rooms for > Dallas will begin. > > > >> At the end of the requested session, the goal would be to discuss = the > formation of a RG. > > > > That's not quite how I handle this in the IRTF. For folks that come > with an idea for a new RG, I'm willing to give them meeting rooms at > IETF meetings for a year, and (if they like) have the meeting listed = on > the agenda as a "proposed RG" meeting. (It is also possible to have = some > of these meetings off the agenda, i.e., with invitations handled by = the > proponents of the group.) The instructions to the proponents are > basically "go and pretend you are an RG", in other words, invite the > people you want to invite, have the discussions you want to have and > don't worry about the charter text. > > > > After that year has passed, I sit down with the proponents, the IRSG > and IAB and we discuss if the proposed group is off to a good start. > > > > The reason I'm doing it this way is that I've seen to many new RGs = in > the past focus on charter text, get it perfect and then die on the > starting line because of lack of energy or lack of community building = by > the proponents. So I've decided to front-load that, and fine tune the > charter afterwards. > > > > Of course you will need some sort of text to explain the group to = new > people, so they can determine if it's for them, but it doesn't need to > be as formal as a charter. > > > > So: > > > > * what kind of meeting do you want to hold in Dallas (on the agenda, > or off) > > > > * do you have a mailing list? > > > > * do you have a group of people with energy to make the group = successful? > > > > * do you have some description of the group? (below is an OK start) > > > > > >> But we would like to make it substantive and include the following > discussion items: > >> > >> 1) Continue the discussion on the interrelation between protocols, > architectures and rights > >> > >> 2) Enable broad community engagement in this discussion as was > discussed in Hawaii. > >> > >> 3) Allow this discussion to happen before politicization related to > human rights and the Internet occurs. > >> > >> A major premise of our research goals is future-proofing protocols = in > relation to their effect on human rights. If we can discover a = reliable > set of considerations, we may avoid needing to fix as many protocols > retroactively going forward. We believe that our goal, consistent with > RFC1958, is for the Internet to continue to serve as a tool enabling > connectivity among all people. Attacks on the Internet's ability to do > this are increasing and worrisome. > >> > >> I think we could use a full session for the discussion, but one of > the shorter slots would probably work. > > > > If you want an "on the agenda" meeting, you need to determine how = many > hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine your > list of conflicts with other RGs and WGs. > > > > If you want an "off the agenda" meeting, those are not scheduled in > parallel to WG and RG sessions, so it would need to be breakfast, = lunch > or evening time. > > > >> Lars, please let us know of any specific information you need or > specific steps you would like us to take in following up on this = request. > > > > See above. > > > >> We would also be intersted in hearing from the list as to other > things that might be worth adding to the such a discussion so that we > can adjust the proposed 'agenda' to suit. Optimally we can evolve from > the 3 of us trying to get this going to a group working on moving it > forward. But time was getting late for requesting a slot and we felt = we > needed to get this moving. > > > > Heads up: I may not make it to Dallas for personal reasons. I should > know for sure in a few weeks. But since we're not deciding on the = formal > chartering of the group in Dallas, that's OK. I will be able to go to > your future meetings. > > > > Lars > > --Apple-Mail=_65A60C89-89AE-45A6-98A9-E2634E0C5C1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Avri,

in= order for me to set this up in the datatracker (so you can request a = session), please send me this information:

* group name

* = group acronym

* chairs other than you

* how to subscribe to the list (URL)

* = any other URLs for the proposed group

Lars

On = 2015-1-23, at 14:58, Avri Doria <avri@acm.org> wrote:

Signed PGP part
Hi,

Thanks for the really = fast response.  I really appreciate the = approach
you take on 'proposed RG's, and really did not = want to have to work on a
charter just yet.

My first approach at answers regarding the = session.

* what kind of meeting do you want = to hold in Dallas (on the agenda, or off)

On = the agenda, as I think it would be good to reach out to other who
might be interested.

I think a = 90 minute slot would be good for this first session.

I have personal conflict I would like to avoid in scheduling, = the IANA
transiton subject.  Additionally we should = avoid conflict with the SAAG
meeting as there is where we = found many interested in the discussion at
the last = meeting and any meetings dealing with privacy consideration
issues.  We can build a conflict = list over the next days if people need
to add some.

* do you have a mailing list?

Yes, hrpc@article19.io <hrpc@article19.io>

* do you have a group of people with energy to = make the group successful?

Not sure = yet.  There are at least 3 of us = committed to the work and a
bunch of others who have shown = interest.  There appeared to be = interest
in continuing the discussion at the SAAG meeting, = but it is still early
to know.  What I do believe is that = we need to continue the approach
that started there and = see if we can build something.

* do you = have some description of the group? (below is an OK start)

I would use this  as a start.
A major premise of our research goals is future-proofing = protocols in
relation to their effect on human rights. If = we can discover a reliable
set of considerations, we may = avoid needing to fix as many protocols
retroactively going = forward. We believe that our goal, consistent with
RFC1958, = is for the Internet to continue to serve as a tool enabling
connectivity among all people. Attacks on the Internet's = ability to do
this are increasing and worrisome.

Some of the topics we want to discuss:

1) Continue the discussion on the = interrelation between protocols,
architectures and = rights

2) Enable broad community engagement = in this discussion as was discussed
in Hawaii.

3) Allow this discussion to happen before = politicization related to
human rights and the Internet = occurs.

4) Discuss methods for doing the = work.

Thanks

avri

On 23-Jan-15 = 08:31, Eggert, Lars wrote:
> Hi,
>
> On = 2015-1-23, at 14:21, Avri Doria <avri@acm.org> wrote:
>> I = don't know whether it is a BoF or there is some other designation
for an IRTF session for a 'RG in possible formation.'  In any case,
following up on the interest in the SAAG session, and = afterwards, we
(Joana, Niels and I) would like to request = such a session.
>
> I'm happy to have that = discussion. I do note that we will need to
conclude this = in the next few days, because scheduling for rooms for
Dallas will begin.
>
>> At = the end of the requested session, the goal would be to discuss the
formation of a RG.
>
> That's not quite how I = handle this in the IRTF. For folks that come
with an idea = for a new RG, I'm willing to give them meeting rooms at
IETF= meetings for a year, and (if they like) have the meeting listed on
the agenda as a "proposed RG" meeting. (It is also possible = to have some
of these meetings off the agenda, i.e., with = invitations handled by the
proponents of the group.) The = instructions to the proponents are
basically "go and = pretend you are an RG", in other words, invite the
people = you want to invite, have the discussions you want to have and
don't worry about the charter text.
>
> After = that year has passed, I sit down with the proponents, the IRSG
and IAB and we discuss if the proposed group is off to a good = start.
>
> The reason I'm doing it = this way is that I've seen to many new RGs in
the past = focus on charter text, get it perfect and then die on the
starting line because of lack of energy or lack of community = building by
the proponents. So I've decided to front-load = that, and fine tune the
charter afterwards.
>
> Of course you will need = some sort of text to explain the group to new
people, so = they can determine if it's for them, but it doesn't need to
be as formal as a charter.
>
> So:
>
> * what kind of meeting do = you want to hold in Dallas (on the agenda,
or off)
>
> * do you have a mailing = list?
>
> * do you have a group of = people with energy to make the group successful?
>
> * do = you have some description of the group? (below is an OK start)
>
>
>>  But we would like to make = it substantive and include the following
discussion = items:
>>
>> 1) Continue the discussion = on the interrelation between protocols,
architectures and = rights
>>
>> 2) Enable broad community = engagement in this discussion as was
discussed in = Hawaii.
>>
>> 3) Allow this discussion to = happen before politicization related to
human rights and = the Internet occurs.
>>
>> A major premise of our = research goals is future-proofing protocols in
relation to = their effect on human rights. If we can discover a reliable
set of considerations, we may avoid needing to fix as many = protocols
retroactively going forward. We believe that our = goal, consistent with
RFC1958, is for the Internet to = continue to serve as a tool enabling
connectivity among = all people. Attacks on the Internet's ability to do
this = are increasing and worrisome.
>>
>> I = think we could use a full session for the discussion, but one of
the shorter slots would probably work.
>
> If you = want an "on the agenda" meeting, you need to determine how many
hours it should be (1h, 1.5h, 2h, 2.5h) and you need to = determine your
list of conflicts with other RGs and = WGs.
>
> If you want an "off the = agenda" meeting, those are not scheduled in
parallel to WG = and RG sessions, so it would need to be breakfast, lunch
or = evening time.
>
>> Lars, please let us know of = any specific information you need or
specific steps you = would like us to take in following up on this request.
>
> See above.
>
>> We would also be intersted = in hearing from the list as to other
things that might be = worth adding to the such a discussion so that we
can = adjust the proposed 'agenda' to suit. Optimally we can evolve from
the 3 of us trying to get this going to a group working on = moving it
forward.  But time was getting late = for requesting a slot and we felt we
needed to get this = moving.
>
> Heads up: I may not make it = to Dallas for personal reasons. I should
know for sure in = a few weeks. But since we're not deciding on the formal
chartering of the group in Dallas, that's OK. I will be able = to go to
your future meetings.
>
> Lars
>

= --Apple-Mail=_65A60C89-89AE-45A6-98A9-E2634E0C5C1F-- --Apple-Mail=_B7C82F61-40C2-4ACC-B7FC-21DCC7A2ABD0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVMJZ4NZcnpRveo1xAQKcaAP/fvYeZCtd+QmJdV1Vee5OiTfaZ4Ua/4zb 0aD5Qf+tXpZRn+SinNSBIJ83AzzAjYFkGgbJvk7Let8b0m/1z8V4ZRE2n4S2973v xmaIc7ggfN5InCmz9td6fCzIirAG3bwscDoZ2Pq6WxfaUUkCwE6QujEITsSFUKdF bg7Cn5uJAsM= =xJre -----END PGP SIGNATURE----- --Apple-Mail=_B7C82F61-40C2-4ACC-B7FC-21DCC7A2ABD0-- From stephen.farrell@cs.tcd.ie Fri Jan 23 15:35:44 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEfKp-0000Hy-Tn for hrpc@article19.io; Fri, 23 Jan 2015 15:35:43 +0100 Received: from mercury.scss.tcd.ie ([134.226.56.6]) by mx2.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEfJy-0005aY-Ic for hrpc@article19.io; Fri, 23 Jan 2015 15:35:43 +0100 Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 222D9BEF1; Fri, 23 Jan 2015 14:34:49 +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 ZVA2UTSiwsq9; Fri, 23 Jan 2015 14:34:49 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3C200BEAA; Fri, 23 Jan 2015 14:34:43 +0000 (GMT) Message-ID: <54C25C02.3020500@cs.tcd.ie> Date: Fri, 23 Jan 2015 14:34:42 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Eggert, Lars" , Avri Doria References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Level: / X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: 0.8 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 4c6e9116b9ad1e3c2304ae6adbe1e50f Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 14:35:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/01/15 14:25, Eggert, Lars wrote: > Hi Avri, > > in order for me to set this up in the datatracker (so you can > request a session), please send me this information: > > * group name * group acronym * chairs other than you * how to > subscribe to the list (URL) * any other URLs for the proposed > group There's an I-D isn't there? I'd include that URL too:-) S > > Lars > > > On 2015-1-23, at 14:58, Avri Doria wrote: >> >> >> Signed PGP part Hi, >> >> Thanks for the really fast response. I really appreciate the >> approach you take on 'proposed RG's, and really did not want to >> have to work on a charter just yet. >> >> My first approach at answers regarding the session. >> >> * what kind of meeting do you want to hold in Dallas (on the >> agenda, or off) >> >> On the agenda, as I think it would be good to reach out to other >> who might be interested. >> >> I think a 90 minute slot would be good for this first session. >> >> I have personal conflict I would like to avoid in scheduling, the >> IANA transiton subject. Additionally we should avoid conflict >> with the SAAG meeting as there is where we found many interested >> in the discussion at the last meeting and any meetings dealing >> with privacy consideration issues. We can build a conflict list >> over the next days if people need to add some. >> >> * do you have a mailing list? >> >> Yes, hrpc@article19.io >> > >> >> * do you have a group of people with energy to make the group >> successful? >> >> Not sure yet. There are at least 3 of us committed to the work >> and a bunch of others who have shown interest. There appeared to >> be interest in continuing the discussion at the SAAG meeting, but >> it is still early to know. What I do believe is that we need to >> continue the approach that started there and see if we can build >> something. >> >> * do you have some description of the group? (below is an OK >> start) >> >> I would use this as a start. >> >> A major premise of our research goals is future-proofing >> protocols in relation to their effect on human rights. If we can >> discover a reliable set of considerations, we may avoid needing >> to fix as many protocols retroactively going forward. We believe >> that our goal, consistent with RFC1958, is for the Internet to >> continue to serve as a tool enabling connectivity among all >> people. Attacks on the Internet's ability to do this are >> increasing and worrisome. >> >> Some of the topics we want to discuss: >> >> 1) Continue the discussion on the interrelation between >> protocols, architectures and rights >> >> 2) Enable broad community engagement in this discussion as was >> discussed in Hawaii. >> >> 3) Allow this discussion to happen before politicization related >> to human rights and the Internet occurs. >> >> 4) Discuss methods for doing the work. >> >> Thanks >> >> avri >> >> >> On 23-Jan-15 08:31, Eggert, Lars wrote: >>> Hi, >>> >>> On 2015-1-23, at 14:21, Avri Doria >> > wrote: >>>> I don't know whether it is a BoF or there is some other >>>> designation >> for an IRTF session for a 'RG in possible formation.' In any >> case, following up on the interest in the SAAG session, and >> afterwards, we (Joana, Niels and I) would like to request such a >> session. >>> >>> I'm happy to have that discussion. I do note that we will need >>> to >> conclude this in the next few days, because scheduling for rooms >> for Dallas will begin. >>> >>>> At the end of the requested session, the goal would be to >>>> discuss the >> formation of a RG. >>> >>> That's not quite how I handle this in the IRTF. For folks that >>> come >> with an idea for a new RG, I'm willing to give them meeting rooms >> at IETF meetings for a year, and (if they like) have the meeting >> listed on the agenda as a "proposed RG" meeting. (It is also >> possible to have some of these meetings off the agenda, i.e., >> with invitations handled by the proponents of the group.) The >> instructions to the proponents are basically "go and pretend you >> are an RG", in other words, invite the people you want to invite, >> have the discussions you want to have and don't worry about the >> charter text. >>> >>> After that year has passed, I sit down with the proponents, the >>> IRSG >> and IAB and we discuss if the proposed group is off to a good >> start. >>> >>> The reason I'm doing it this way is that I've seen to many new >>> RGs in >> the past focus on charter text, get it perfect and then die on >> the starting line because of lack of energy or lack of community >> building by the proponents. So I've decided to front-load that, >> and fine tune the charter afterwards. >>> >>> Of course you will need some sort of text to explain the group >>> to new >> people, so they can determine if it's for them, but it doesn't >> need to be as formal as a charter. >>> >>> So: >>> >>> * what kind of meeting do you want to hold in Dallas (on the >>> agenda, >> or off) >>> >>> * do you have a mailing list? >>> >>> * do you have a group of people with energy to make the group >>> successful? >>> >>> * do you have some description of the group? (below is an OK >>> start) >>> >>> >>>> But we would like to make it substantive and include the >>>> following >> discussion items: >>>> >>>> 1) Continue the discussion on the interrelation between >>>> protocols, >> architectures and rights >>>> >>>> 2) Enable broad community engagement in this discussion as >>>> was >> discussed in Hawaii. >>>> >>>> 3) Allow this discussion to happen before politicization >>>> related to >> human rights and the Internet occurs. >>>> >>>> A major premise of our research goals is future-proofing >>>> protocols in >> relation to their effect on human rights. If we can discover a >> reliable set of considerations, we may avoid needing to fix as >> many protocols retroactively going forward. We believe that our >> goal, consistent with RFC1958, is for the Internet to continue to >> serve as a tool enabling connectivity among all people. Attacks >> on the Internet's ability to do this are increasing and >> worrisome. >>>> >>>> I think we could use a full session for the discussion, but >>>> one of >> the shorter slots would probably work. >>> >>> If you want an "on the agenda" meeting, you need to determine >>> how many >> hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine >> your list of conflicts with other RGs and WGs. >>> >>> If you want an "off the agenda" meeting, those are not >>> scheduled in >> parallel to WG and RG sessions, so it would need to be breakfast, >> lunch or evening time. >>> >>>> Lars, please let us know of any specific information you need >>>> or >> specific steps you would like us to take in following up on this >> request. >>> >>> See above. >>> >>>> We would also be intersted in hearing from the list as to >>>> other >> things that might be worth adding to the such a discussion so >> that we can adjust the proposed 'agenda' to suit. Optimally we >> can evolve from the 3 of us trying to get this going to a group >> working on moving it forward. But time was getting late for >> requesting a slot and we felt we needed to get this moving. >>> >>> Heads up: I may not make it to Dallas for personal reasons. I >>> should >> know for sure in a few weeks. But since we're not deciding on the >> formal chartering of the group in Dallas, that's OK. I will be >> able to go to your future meetings. >>> >>> Lars >>> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUwlv+AAoJEC88hzaAX42iXyQH/0EblWb4DdVJzdnchZUl8t6Z OvUcrG3yLBQCEVvU4XaZBMweuGTl4iuhbg3nMnMDNyQI9A3QxXHly6jUcJQKElod ZPxi8D9TBJpOwlHhrVI85PSISHUudcoX+i2AyeDV5PAKctMNLmljp9NtJadalsrC HmN+h/BzOkrbeLu10hAZ1zMWhOPYmYdTGkLvnOeOIoAFEkvT97P292Abe8duuYRq CDcDGbPvSosD9pg8MksdpDtJhoOMc4hlelnIdcM3hbk7K6octAWNhhEXn1lNT3WI vuDdWspLZ4s7QRQcvrlVHeJlx4u6Z0pJlNhCPp9JsmOc2PTjOiVbec6j32cXEgs= =O1Bu -----END PGP SIGNATURE----- From niels@article19.org Fri Jan 23 16:03:24 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEflb-0000M4-Tn for hrpc@article19.io; Fri, 23 Jan 2015 16:03:23 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEflA-0005xj-K8 for hrpc@article19.io; Fri, 23 Jan 2015 16:03:23 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 555F419C00B for ; Fri, 23 Jan 2015 15:03:37 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aBwKYTjmXlXn; Fri, 23 Jan 2015 15:03:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 2B47D19C00A; Fri, 23 Jan 2015 15:03:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 yKUoUkGzWPfE; Fri, 23 Jan 2015 15:03:34 +0000 (UTC) Received: from [192.168.200.131] (unknown [110.55.115.58]) by mail.article19.io (Postfix) with ESMTPSA id A9FF019C007; Fri, 23 Jan 2015 15:03:31 +0000 (UTC) Message-ID: <54C26294.8080800@article19.org> Date: Fri, 23 Jan 2015 15:02:44 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: "Eggert, Lars" , Avri Doria References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 6819b1e11a0bfca853cb5292ba4954a6 Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:03:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Lars, Please find underneath the information you requested. * group name Human Rights Protocol Considerations * group acronym hrpc * chairs other than you Joana Varon, Niels ten Oever * how to subscribe to the list (URL) https://lists.ghserv.net/mailman/listinfo/hrpc * any other URLs for the proposed group https://tools.ietf.org/html/draft-doria-hrpc-proposal-00 Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 01/23/2015 02:25 PM, Eggert, Lars wrote: > Hi Avri, > > in order for me to set this up in the datatracker (so you can > request a session), please send me this information: > > * group name * group acronym * chairs other than you * how to > subscribe to the list (URL) * any other URLs for the proposed > group > > Lars > > > On 2015-1-23, at 14:58, Avri Doria > wrote: >> >> >> Signed PGP part Hi, >> >> Thanks for the really fast response. I really appreciate the >> approach you take on 'proposed RG's, and really did not want to >> have to work on a charter just yet. >> >> My first approach at answers regarding the session. >> >> * what kind of meeting do you want to hold in Dallas (on the >> agenda, or off) >> >> On the agenda, as I think it would be good to reach out to other >> who might be interested. >> >> I think a 90 minute slot would be good for this first session. >> >> I have personal conflict I would like to avoid in scheduling, the >> IANA transiton subject. Additionally we should avoid conflict >> with the SAAG meeting as there is where we found many interested >> in the discussion at the last meeting and any meetings dealing >> with privacy consideration issues. We can build a conflict list >> over the next days if people need to add some. >> >> * do you have a mailing list? >> >> Yes, hrpc@article19.io >> > >> >> * do you have a group of people with energy to make the group >> successful? >> >> Not sure yet. There are at least 3 of us committed to the work >> and a bunch of others who have shown interest. There appeared to >> be interest in continuing the discussion at the SAAG meeting, but >> it is still early to know. What I do believe is that we need to >> continue the approach that started there and see if we can build >> something. >> >> * do you have some description of the group? (below is an OK >> start) >> >> I would use this as a start. >> >> A major premise of our research goals is future-proofing >> protocols in relation to their effect on human rights. If we can >> discover a reliable set of considerations, we may avoid needing >> to fix as many protocols retroactively going forward. We believe >> that our goal, consistent with RFC1958, is for the Internet to >> continue to serve as a tool enabling connectivity among all >> people. Attacks on the Internet's ability to do this are >> increasing and worrisome. >> >> Some of the topics we want to discuss: >> >> 1) Continue the discussion on the interrelation between >> protocols, architectures and rights >> >> 2) Enable broad community engagement in this discussion as was >> discussed in Hawaii. >> >> 3) Allow this discussion to happen before politicization related >> to human rights and the Internet occurs. >> >> 4) Discuss methods for doing the work. >> >> Thanks >> >> avri >> >> >> On 23-Jan-15 08:31, Eggert, Lars wrote: >>> Hi, >>> >>> On 2015-1-23, at 14:21, Avri Doria > > wrote: >>>> I don't know whether it is a BoF or there is some other >>>> designation >> for an IRTF session for a 'RG in possible formation.' In any >> case, following up on the interest in the SAAG session, and >> afterwards, we (Joana, Niels and I) would like to request such a >> session. >>> >>> I'm happy to have that discussion. I do note that we will need >>> to >> conclude this in the next few days, because scheduling for rooms >> for Dallas will begin. >>> >>>> At the end of the requested session, the goal would be to >>>> discuss the >> formation of a RG. >>> >>> That's not quite how I handle this in the IRTF. For folks that >>> come >> with an idea for a new RG, I'm willing to give them meeting rooms >> at IETF meetings for a year, and (if they like) have the meeting >> listed on the agenda as a "proposed RG" meeting. (It is also >> possible to have some of these meetings off the agenda, i.e., >> with invitations handled by the proponents of the group.) The >> instructions to the proponents are basically "go and pretend you >> are an RG", in other words, invite the people you want to invite, >> have the discussions you want to have and don't worry about the >> charter text. >>> >>> After that year has passed, I sit down with the proponents, the >>> IRSG >> and IAB and we discuss if the proposed group is off to a good >> start. >>> >>> The reason I'm doing it this way is that I've seen to many new >>> RGs in >> the past focus on charter text, get it perfect and then die on >> the starting line because of lack of energy or lack of community >> building by the proponents. So I've decided to front-load that, >> and fine tune the charter afterwards. >>> >>> Of course you will need some sort of text to explain the group >>> to new >> people, so they can determine if it's for them, but it doesn't >> need to be as formal as a charter. >>> >>> So: >>> >>> * what kind of meeting do you want to hold in Dallas (on the >>> agenda, >> or off) >>> >>> * do you have a mailing list? >>> >>> * do you have a group of people with energy to make the group >> successful? >>> >>> * do you have some description of the group? (below is an OK >>> start) >>> >>> >>>> But we would like to make it substantive and include the >>>> following >> discussion items: >>>> >>>> 1) Continue the discussion on the interrelation between >>>> protocols, >> architectures and rights >>>> >>>> 2) Enable broad community engagement in this discussion as >>>> was >> discussed in Hawaii. >>>> >>>> 3) Allow this discussion to happen before politicization >>>> related to >> human rights and the Internet occurs. >>>> >>>> A major premise of our research goals is future-proofing >>>> protocols in >> relation to their effect on human rights. If we can discover a >> reliable set of considerations, we may avoid needing to fix as >> many protocols retroactively going forward. We believe that our >> goal, consistent with RFC1958, is for the Internet to continue to >> serve as a tool enabling connectivity among all people. Attacks >> on the Internet's ability to do this are increasing and >> worrisome. >>>> >>>> I think we could use a full session for the discussion, but >>>> one of >> the shorter slots would probably work. >>> >>> If you want an "on the agenda" meeting, you need to determine >>> how many >> hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine >> your list of conflicts with other RGs and WGs. >>> >>> If you want an "off the agenda" meeting, those are not >>> scheduled in >> parallel to WG and RG sessions, so it would need to be breakfast, >> lunch or evening time. >>> >>>> Lars, please let us know of any specific information you need >>>> or >> specific steps you would like us to take in following up on this >> request. >>> >>> See above. >>> >>>> We would also be intersted in hearing from the list as to >>>> other >> things that might be worth adding to the such a discussion so >> that we can adjust the proposed 'agenda' to suit. Optimally we >> can evolve from the 3 of us trying to get this going to a group >> working on moving it forward. But time was getting late for >> requesting a slot and we felt we needed to get this moving. >>> >>> Heads up: I may not make it to Dallas for personal reasons. I >>> should >> know for sure in a few weeks. But since we're not deciding on the >> formal chartering of the group in Dallas, that's OK. I will be >> able to go to your future meetings. >>> >>> Lars >>> > > > > _______________________________________________ hrpc mailing list > hrpc@article19.io https://lists.ghserv.net/mailman/listinfo/hrpc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUwmKUAAoJEAi1oPJjbWjpLcQH/1ZnCoEMr7uKZbyPinLrBnF2 KNNp2dM5qeV8bwW9KaRmP26mCicUvQJkJxFP8O5GunhiQPqe1eYqMUbkQwTh/MFI rxca11wd3wdBAu2slAkyKitThqZ3p0zx0syfaZ+TukIW70IwV6f4I4ZKb7/kADup C9xUOnD4UsmXSU1ky53v24bP+u+CSGg5GFJIEcCOsjN5lg78xF0BSzlxReZWBwdu Lz2y00r1ynh7pKLNqlj6fl/zOON5Yz0HLVY+lMfb0XPMwuYp59+N0JYlfyDzhmYi 4ubryooFfcYAiDjkXzfwZy8uFUtUOalkQeTQcI8+Yw1dto0/3Ay8xNOCizMhBpQ= =28Uz -----END PGP SIGNATURE----- From lars@netapp.com Fri Jan 23 16:05:36 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEfnk-0000Mh-9l for hrpc@article19.io; Fri, 23 Jan 2015 16:05:36 +0100 Received: from mx141.netapp.com ([216.240.21.12]) by mx2.greenhost.nl with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YEfnQ-0006yW-Lv for hrpc@article19.io; Fri, 23 Jan 2015 16:05:36 +0100 X-IronPort-AV: E=Sophos;i="5.09,454,1418112000"; d="asc'?scan'208";a="17305863" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx141-out.netapp.com with ESMTP; 23 Jan 2015 07:05:13 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 23 Jan 2015 07:05:13 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Fri, 23 Jan 2015 07:05:13 -0800 From: "Eggert, Lars" To: Niels ten Oever Thread-Topic: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration Thread-Index: AQHQNw+Lbi/pjRLIh0izuhYIBsonqpzOOeQAgAAHYACAAAehAIAACmAAgAAArgA= Date: Fri, 23 Jan 2015 15:05:12 +0000 Message-ID: <9118BDDC-9292-4182-BD56-08FC75F0A434@netapp.com> References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> <54C26294.8080800@article19.org> In-Reply-To: <54C26294.8080800@article19.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.4) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_2A4F5477-B82F-4701-9A91-476C07235D57"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Spam-Level: ---- X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_HI, SPF_PASS, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.3 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: b6240588abfaeb0bdffc9b6551375bec Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:05:36 -0000 --Apple-Mail=_2A4F5477-B82F-4701-9A91-476C07235D57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2015-1-23, at 16:02, Niels ten Oever wrote: > Please find underneath the information you requested. >=20 > * group name > Human Rights Protocol Considerations >=20 > * group acronym > hrpc >=20 > * chairs other than you > Joana Varon, Niels ten Oever Three chairs is a bit uncommon. I'd prefer two, if that is possible. = (How you organize the work is up to you.) > * how to subscribe to the list (URL) > https://lists.ghserv.net/mailman/listinfo/hrpc >=20 > * any other URLs for the proposed group > https://tools.ietf.org/html/draft-doria-hrpc-proposal-00 Thanks, Lars >=20 > Best, >=20 > Niels >=20 > Niels ten Oever > Head of Digital >=20 > Article 19 > www.article19.org >=20 > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 >=20 > On 01/23/2015 02:25 PM, Eggert, Lars wrote: > > Hi Avri, > > > > in order for me to set this up in the datatracker (so you can > > request a session), please send me this information: > > > > * group name * group acronym * chairs other than you * how to > > subscribe to the list (URL) * any other URLs for the proposed > > group > > > > Lars > > > > > > On 2015-1-23, at 14:58, Avri Doria > > wrote: > >> > >> > >> Signed PGP part Hi, > >> > >> Thanks for the really fast response. I really appreciate the > >> approach you take on 'proposed RG's, and really did not want to > >> have to work on a charter just yet. > >> > >> My first approach at answers regarding the session. > >> > >> * what kind of meeting do you want to hold in Dallas (on the > >> agenda, or off) > >> > >> On the agenda, as I think it would be good to reach out to other > >> who might be interested. > >> > >> I think a 90 minute slot would be good for this first session. > >> > >> I have personal conflict I would like to avoid in scheduling, the > >> IANA transiton subject. Additionally we should avoid conflict > >> with the SAAG meeting as there is where we found many interested > >> in the discussion at the last meeting and any meetings dealing > >> with privacy consideration issues. We can build a conflict list > >> over the next days if people need to add some. > >> > >> * do you have a mailing list? > >> > >> Yes, hrpc@article19.io > >> > > >> > >> * do you have a group of people with energy to make the group > >> successful? > >> > >> Not sure yet. There are at least 3 of us committed to the work > >> and a bunch of others who have shown interest. There appeared to > >> be interest in continuing the discussion at the SAAG meeting, but > >> it is still early to know. What I do believe is that we need to > >> continue the approach that started there and see if we can build > >> something. > >> > >> * do you have some description of the group? (below is an OK > >> start) > >> > >> I would use this as a start. > >> > >> A major premise of our research goals is future-proofing > >> protocols in relation to their effect on human rights. If we can > >> discover a reliable set of considerations, we may avoid needing > >> to fix as many protocols retroactively going forward. We believe > >> that our goal, consistent with RFC1958, is for the Internet to > >> continue to serve as a tool enabling connectivity among all > >> people. Attacks on the Internet's ability to do this are > >> increasing and worrisome. > >> > >> Some of the topics we want to discuss: > >> > >> 1) Continue the discussion on the interrelation between > >> protocols, architectures and rights > >> > >> 2) Enable broad community engagement in this discussion as was > >> discussed in Hawaii. > >> > >> 3) Allow this discussion to happen before politicization related > >> to human rights and the Internet occurs. > >> > >> 4) Discuss methods for doing the work. > >> > >> Thanks > >> > >> avri > >> > >> > >> On 23-Jan-15 08:31, Eggert, Lars wrote: > >>> Hi, > >>> > >>> On 2015-1-23, at 14:21, Avri Doria >> > wrote: > >>>> I don't know whether it is a BoF or there is some other > >>>> designation > >> for an IRTF session for a 'RG in possible formation.' In any > >> case, following up on the interest in the SAAG session, and > >> afterwards, we (Joana, Niels and I) would like to request such a > >> session. > >>> > >>> I'm happy to have that discussion. I do note that we will need > >>> to > >> conclude this in the next few days, because scheduling for rooms > >> for Dallas will begin. > >>> > >>>> At the end of the requested session, the goal would be to > >>>> discuss the > >> formation of a RG. > >>> > >>> That's not quite how I handle this in the IRTF. For folks that > >>> come > >> with an idea for a new RG, I'm willing to give them meeting rooms > >> at IETF meetings for a year, and (if they like) have the meeting > >> listed on the agenda as a "proposed RG" meeting. (It is also > >> possible to have some of these meetings off the agenda, i.e., > >> with invitations handled by the proponents of the group.) The > >> instructions to the proponents are basically "go and pretend you > >> are an RG", in other words, invite the people you want to invite, > >> have the discussions you want to have and don't worry about the > >> charter text. > >>> > >>> After that year has passed, I sit down with the proponents, the > >>> IRSG > >> and IAB and we discuss if the proposed group is off to a good > >> start. > >>> > >>> The reason I'm doing it this way is that I've seen to many new > >>> RGs in > >> the past focus on charter text, get it perfect and then die on > >> the starting line because of lack of energy or lack of community > >> building by the proponents. So I've decided to front-load that, > >> and fine tune the charter afterwards. > >>> > >>> Of course you will need some sort of text to explain the group > >>> to new > >> people, so they can determine if it's for them, but it doesn't > >> need to be as formal as a charter. > >>> > >>> So: > >>> > >>> * what kind of meeting do you want to hold in Dallas (on the > >>> agenda, > >> or off) > >>> > >>> * do you have a mailing list? > >>> > >>> * do you have a group of people with energy to make the group > >> successful? > >>> > >>> * do you have some description of the group? (below is an OK > >>> start) > >>> > >>> > >>>> But we would like to make it substantive and include the > >>>> following > >> discussion items: > >>>> > >>>> 1) Continue the discussion on the interrelation between > >>>> protocols, > >> architectures and rights > >>>> > >>>> 2) Enable broad community engagement in this discussion as > >>>> was > >> discussed in Hawaii. > >>>> > >>>> 3) Allow this discussion to happen before politicization > >>>> related to > >> human rights and the Internet occurs. > >>>> > >>>> A major premise of our research goals is future-proofing > >>>> protocols in > >> relation to their effect on human rights. If we can discover a > >> reliable set of considerations, we may avoid needing to fix as > >> many protocols retroactively going forward. We believe that our > >> goal, consistent with RFC1958, is for the Internet to continue to > >> serve as a tool enabling connectivity among all people. Attacks > >> on the Internet's ability to do this are increasing and > >> worrisome. > >>>> > >>>> I think we could use a full session for the discussion, but > >>>> one of > >> the shorter slots would probably work. > >>> > >>> If you want an "on the agenda" meeting, you need to determine > >>> how many > >> hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine > >> your list of conflicts with other RGs and WGs. > >>> > >>> If you want an "off the agenda" meeting, those are not > >>> scheduled in > >> parallel to WG and RG sessions, so it would need to be breakfast, > >> lunch or evening time. > >>> > >>>> Lars, please let us know of any specific information you need > >>>> or > >> specific steps you would like us to take in following up on this > >> request. > >>> > >>> See above. > >>> > >>>> We would also be intersted in hearing from the list as to > >>>> other > >> things that might be worth adding to the such a discussion so > >> that we can adjust the proposed 'agenda' to suit. Optimally we > >> can evolve from the 3 of us trying to get this going to a group > >> working on moving it forward. But time was getting late for > >> requesting a slot and we felt we needed to get this moving. > >>> > >>> Heads up: I may not make it to Dallas for personal reasons. I > >>> should > >> know for sure in a few weeks. But since we're not deciding on the > >> formal chartering of the group in Dallas, that's OK. I will be > >> able to go to your future meetings. > >>> > >>> Lars > >>> > > > > > > > > _______________________________________________ hrpc mailing list > > hrpc@article19.io https://lists.ghserv.net/mailman/listinfo/hrpc > > >=20 --Apple-Mail=_2A4F5477-B82F-4701-9A91-476C07235D57 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVMJjJtZcnpRveo1xAQLlAQP/RfVMxzbnwO8kq4y3pA8qoVyxjvGY5s+X YY7wASb7OXBCi3y8iVqoom39HVi7sZGRkYBuuPm/BUGbVmdvyNQ+ppX2+/DIbSiu xUWTzvwVpwirzZw8a6J2yABrnV33tpNiWpojGjkUWJQ0Q4bdvhVh+XpgWvCfUnBi CVKdmWGIYQ4= =rt3v -----END PGP SIGNATURE----- --Apple-Mail=_2A4F5477-B82F-4701-9A91-476C07235D57-- From lars@netapp.com Fri Jan 23 16:12:27 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEfuN-0000NS-Kr for hrpc@article19.io; Fri, 23 Jan 2015 16:12:27 +0100 Received: from mx143.netapp.com ([216.240.21.24]) by mx1.greenhost.nl with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YEftX-0006Mr-J7 for hrpc@article19.io; Fri, 23 Jan 2015 16:12:27 +0100 X-IronPort-AV: E=Sophos;i="5.09,454,1418112000"; d="asc'?scan'208";a="16991642" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 23 Jan 2015 07:11:29 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 23 Jan 2015 07:11:29 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d8c:be2b:9e16:f915%21]) with mapi id 15.00.0995.031; Fri, 23 Jan 2015 07:11:29 -0800 From: "Eggert, Lars" To: Niels ten Oever Thread-Topic: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration Thread-Index: AQHQNw+Lbi/pjRLIh0izuhYIBsonqpzOOeQAgAAHYACAAAehAIAACmAAgAAArgCAAAHBgA== Date: Fri, 23 Jan 2015 15:11:28 +0000 Message-ID: References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> <54C26294.8080800@article19.org> <9118BDDC-9292-4182-BD56-08FC75F0A434@netapp.com> In-Reply-To: <9118BDDC-9292-4182-BD56-08FC75F0A434@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.4) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_4DACA0A3-51D5-4534-AC96-FCA20C3669F5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Spam-Level: ---- X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_HI, SPF_PASS, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.3 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: dfea3049d3b923820beb462d65569822 Cc: "hrpc@article19.io" , Kathleen Moriarty Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:12:28 -0000 --Apple-Mail=_4DACA0A3-51D5-4534-AC96-FCA20C3669F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, there is now https://datatracker.ietf.org/rg/hrpc/charter/ I made Avri and Niels chairs, mostly because Joana didn't have a = datatracker account. (We can change this.) This should either of you request an on-the-agenda session for Dallas = via https://datatracker.ietf.org/secr/sreq/ Please note = http://www.ietf.org/meeting/important-dates-2015.html#ietf92; the = deadline for requests is 2015-02-06. Lars --Apple-Mail=_4DACA0A3-51D5-4534-AC96-FCA20C3669F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVMJkn9ZcnpRveo1xAQKgBgP/d5tTnBIh2vemGl1BnegC+zD7trg5Z8su nB2DhRbYeJLkt0kQB2hoPuq7WQ2bS4mloF2+SXvz6i8CjVWwsKg20gf0+lREuFWO HqlP9UVJTaWAGHUa3k5Qo535bbswwMMyZSVCTMnZzYykIgOBJ33Fy9yMFhUNUGjI Jclk6lRaHjM= =bbEd -----END PGP SIGNATURE----- --Apple-Mail=_4DACA0A3-51D5-4534-AC96-FCA20C3669F5-- From niels@article19.org Fri Jan 23 16:32:17 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEgDZ-0000PP-D8 for hrpc@article19.io; Fri, 23 Jan 2015 16:32:17 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEgDO-0007EJ-OQ for hrpc@article19.io; Fri, 23 Jan 2015 16:32:17 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 925FE19C02C for ; Fri, 23 Jan 2015 15:32:47 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PAUHKHyLGtqJ for ; Fri, 23 Jan 2015 15:32:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 5A81619C039 for ; Fri, 23 Jan 2015 15:32:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 AkYWwUj9qjjm for ; Fri, 23 Jan 2015 15:32:45 +0000 (UTC) Received: from [192.168.200.131] (unknown [110.55.115.58]) by mail.article19.io (Postfix) with ESMTPSA id E0C9919C02C for ; Fri, 23 Jan 2015 15:32:43 +0000 (UTC) Message-ID: <54C2696C.8050900@article19.org> Date: Fri, 23 Jan 2015 15:31:56 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: hrpc@article19.io References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> In-Reply-To: <54C2537A.2010803@acm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 5c4dd3f97b5f9360f98ddb363e9ef1fb Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:32:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I was wondering whether a longer session might be beneficial as well. So we get to discuss and further some ideas, and not only comment on them? Or would that need more of a workshop set-up? I would propose going for 120 minutes, we can always stop earlier, no ? I like this description: > A major premise of our research goals is future-proofing protocols > in relation to their effect on human rights. If we can discover a > reliable set of considerations, we may avoid needing to fix as many > protocols retroactively going forward. We believe that our goal, > consistent with RFC1958, is for the Internet to continue to serve > as a tool enabling connectivity among all people. Attacks on the > Internet's ability to do this are increasing and worrisome. But are we not politicizing this issue with the last sentence? It can also be said that recent attacks have not been on connectivity but on privacy, no? Just thinking in terms of strategy and inclusion of the community in this discussion. Furthermore, we haven't formally established the relationship between Freedom of Expression and connectivity yet. Or is this something we can simply assume? Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 01/23/2015 01:58 PM, Avri Doria wrote: >=20 > Hi, >=20 > Thanks for the really fast response. I really appreciate the > approach you take on 'proposed RG's, and really did not want to > have to work on a charter just yet. >=20 > My first approach at answers regarding the session. >=20 > * what kind of meeting do you want to hold in Dallas (on the > agenda, or off) >=20 > On the agenda, as I think it would be good to reach out to other > who might be interested. >=20 > I think a 90 minute slot would be good for this first session. >=20 > I have personal conflict I would like to avoid in scheduling, the > IANA transiton subject. Additionally we should avoid conflict with > the SAAG meeting as there is where we found many interested in the > discussion at the last meeting and any meetings dealing with > privacy consideration issues. We can build a conflict list over > the next days if people need to add some. >=20 > * do you have a mailing list? >=20 > Yes, hrpc@article19.io >=20 > * do you have a group of people with energy to make the group > successful? >=20 > Not sure yet. There are at least 3 of us committed to the work and > a bunch of others who have shown interest. There appeared to be > interest in continuing the discussion at the SAAG meeting, but it > is still early to know. What I do believe is that we need to > continue the approach that started there and see if we can build > something. >=20 > * do you have some description of the group? (below is an OK > start) >=20 > I would use this as a start. >=20 > A major premise of our research goals is future-proofing protocols > in relation to their effect on human rights. If we can discover a > reliable set of considerations, we may avoid needing to fix as many > protocols retroactively going forward. We believe that our goal, > consistent with RFC1958, is for the Internet to continue to serve > as a tool enabling connectivity among all people. Attacks on the > Internet's ability to do this are increasing and worrisome. >=20 > Some of the topics we want to discuss: >=20 > 1) Continue the discussion on the interrelation between protocols,=20 > architectures and rights >=20 > 2) Enable broad community engagement in this discussion as was > discussed in Hawaii. >=20 > 3) Allow this discussion to happen before politicization related > to human rights and the Internet occurs. >=20 > 4) Discuss methods for doing the work. >=20 > Thanks >=20 > avri >=20 >=20 > On 23-Jan-15 08:31, Eggert, Lars wrote: >> Hi, >=20 >> On 2015-1-23, at 14:21, Avri Doria wrote: >>> I don't know whether it is a BoF or there is some other >>> designation > for an IRTF session for a 'RG in possible formation.' In any > case, following up on the interest in the SAAG session, and > afterwards, we (Joana, Niels and I) would like to request such a > session. >=20 >> I'm happy to have that discussion. I do note that we will need >> to > conclude this in the next few days, because scheduling for rooms > for Dallas will begin. >=20 >>> At the end of the requested session, the goal would be to >>> discuss the > formation of a RG. >=20 >> That's not quite how I handle this in the IRTF. For folks that >> come > with an idea for a new RG, I'm willing to give them meeting rooms > at IETF meetings for a year, and (if they like) have the meeting > listed on the agenda as a "proposed RG" meeting. (It is also > possible to have some of these meetings off the agenda, i.e., with > invitations handled by the proponents of the group.) The > instructions to the proponents are basically "go and pretend you > are an RG", in other words, invite the people you want to invite, > have the discussions you want to have and don't worry about the > charter text. >=20 >> After that year has passed, I sit down with the proponents, the >> IRSG > and IAB and we discuss if the proposed group is off to a good > start. >=20 >> The reason I'm doing it this way is that I've seen to many new >> RGs in > the past focus on charter text, get it perfect and then die on the=20 > starting line because of lack of energy or lack of community > building by the proponents. So I've decided to front-load that, and > fine tune the charter afterwards. >=20 >> Of course you will need some sort of text to explain the group to >> new > people, so they can determine if it's for them, but it doesn't need > to be as formal as a charter. >=20 >> So: >=20 >> * what kind of meeting do you want to hold in Dallas (on the >> agenda, > or off) >=20 >> * do you have a mailing list? >=20 >> * do you have a group of people with energy to make the group >> successful? >=20 >> * do you have some description of the group? (below is an OK >> start) >=20 >=20 >>> But we would like to make it substantive and include the >>> following > discussion items: >>>=20 >>> 1) Continue the discussion on the interrelation between >>> protocols, > architectures and rights >>>=20 >>> 2) Enable broad community engagement in this discussion as was > discussed in Hawaii. >>>=20 >>> 3) Allow this discussion to happen before politicization >>> related to > human rights and the Internet occurs. >>>=20 >>> A major premise of our research goals is future-proofing >>> protocols in > relation to their effect on human rights. If we can discover a > reliable set of considerations, we may avoid needing to fix as many > protocols retroactively going forward. We believe that our goal, > consistent with RFC1958, is for the Internet to continue to serve > as a tool enabling connectivity among all people. Attacks on the > Internet's ability to do this are increasing and worrisome. >>>=20 >>> I think we could use a full session for the discussion, but one >>> of > the shorter slots would probably work. >=20 >> If you want an "on the agenda" meeting, you need to determine how >> many > hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine > your list of conflicts with other RGs and WGs. >=20 >> If you want an "off the agenda" meeting, those are not scheduled >> in > parallel to WG and RG sessions, so it would need to be breakfast, > lunch or evening time. >=20 >>> Lars, please let us know of any specific information you need >>> or > specific steps you would like us to take in following up on this > request. >=20 >> See above. >=20 >>> We would also be intersted in hearing from the list as to >>> other > things that might be worth adding to the such a discussion so that > we can adjust the proposed 'agenda' to suit. Optimally we can > evolve from the 3 of us trying to get this going to a group working > on moving it forward. But time was getting late for requesting a > slot and we felt we needed to get this moving. >=20 >> Heads up: I may not make it to Dallas for personal reasons. I >> should > know for sure in a few weeks. But since we're not deciding on the > formal chartering of the group in Dallas, that's OK. I will be able > to go to your future meetings. >=20 >> Lars >=20 >=20 >=20 >=20 >=20 > _______________________________________________ hrpc mailing list=20 > hrpc@article19.io https://lists.ghserv.net/mailman/listinfo/hrpc >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUwmlsAAoJEAi1oPJjbWjpp1cH/172/3oWSoDtGpRTQ3Q/Fx9P YL7OgY2YaoMaZVze7QP9mzpG03Usg2X8aPSMN/WTpNZEQ8hKUA5gkPchkfgZgS2L EjwWus7uS0S1Y8f/UWLEq+oyCoYchXltBWnsM21yrDKTfcNE9piF/1cw/rflLMNt q3zz5TKzddzH41+0r7RfA3hmXvsETA0k8CrNr0IuoSJVaW714tBPaPdM9rX9JuB4 Gsig7T8B/IPb/s+gAE+Y3HPuUbAdppwRzlOt5rjzb34wRwYZKBLRkwll8kPfWyPT NU2wP0M2gP6mpHLZLlrx99gDoVyhB9cJmUJK8XjIdpON/CXJ95UpL6BuDEDm0S4=3D =3DbGEd -----END PGP SIGNATURE----- From niels@article19.org Fri Jan 23 16:32:17 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YEgDZ-0000PU-K4 for hrpc@article19.io; Fri, 23 Jan 2015 16:32:17 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YEgDP-0007EN-NO for hrpc@article19.io; Fri, 23 Jan 2015 16:32:17 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 868AA19C039 for ; Fri, 23 Jan 2015 15:32:48 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=unavailable autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id j-XNmm1HbxuO for ; Fri, 23 Jan 2015 15:32:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 2E6F419C032 for ; Fri, 23 Jan 2015 15:32:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 dKmn5aCy2CZ0 for ; Fri, 23 Jan 2015 15:32:45 +0000 (UTC) Received: from [192.168.200.131] (unknown [121.96.255.162]) by mail.article19.io (Postfix) with ESMTPSA id D19C42F00CB for ; Fri, 23 Jan 2015 15:32:43 +0000 (UTC) Message-ID: <54C2696C.2090705@article19.org> Date: Fri, 23 Jan 2015 15:31:56 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: hrpc@article19.io References: <54C24AE3.1010508@acm.org> <9B2D62E6-8B59-4CBC-8F55-8BC2F6B6E5A8@netapp.com> <54C2537A.2010803@acm.org> In-Reply-To: <54C2537A.2010803@acm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 5c4dd3f97b5f9360f98ddb363e9ef1fb Subject: Re: [hrpc] Request to session IRTF slot in Dallas for Human Rights and Protocol Consideration X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:32:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I was wondering whether a longer session might be beneficial as well. So we get to discuss and further some ideas, and not only comment on them? Or would that need more of a workshop set-up? I would propose going for 120 minutes, we can always stop earlier, no ? I like this description: > A major premise of our research goals is future-proofing protocols > in relation to their effect on human rights. If we can discover a > reliable set of considerations, we may avoid needing to fix as many > protocols retroactively going forward. We believe that our goal, > consistent with RFC1958, is for the Internet to continue to serve > as a tool enabling connectivity among all people. Attacks on the > Internet's ability to do this are increasing and worrisome. But are we not politicizing this issue with the last sentence? It can also be said that recent attacks have not been on connectivity but on privacy, no? Just thinking in terms of strategy and inclusion of the community in this discussion. Furthermore, we haven't formally established the relationship between Freedom of Expression and connectivity yet. Or is this something we can simply assume? Best, Niels Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 On 01/23/2015 01:58 PM, Avri Doria wrote: >=20 > Hi, >=20 > Thanks for the really fast response. I really appreciate the > approach you take on 'proposed RG's, and really did not want to > have to work on a charter just yet. >=20 > My first approach at answers regarding the session. >=20 > * what kind of meeting do you want to hold in Dallas (on the > agenda, or off) >=20 > On the agenda, as I think it would be good to reach out to other > who might be interested. >=20 > I think a 90 minute slot would be good for this first session. >=20 > I have personal conflict I would like to avoid in scheduling, the > IANA transiton subject. Additionally we should avoid conflict with > the SAAG meeting as there is where we found many interested in the > discussion at the last meeting and any meetings dealing with > privacy consideration issues. We can build a conflict list over > the next days if people need to add some. >=20 > * do you have a mailing list? >=20 > Yes, hrpc@article19.io >=20 > * do you have a group of people with energy to make the group > successful? >=20 > Not sure yet. There are at least 3 of us committed to the work and > a bunch of others who have shown interest. There appeared to be > interest in continuing the discussion at the SAAG meeting, but it > is still early to know. What I do believe is that we need to > continue the approach that started there and see if we can build > something. >=20 > * do you have some description of the group? (below is an OK > start) >=20 > I would use this as a start. >=20 > A major premise of our research goals is future-proofing protocols > in relation to their effect on human rights. If we can discover a > reliable set of considerations, we may avoid needing to fix as many > protocols retroactively going forward. We believe that our goal, > consistent with RFC1958, is for the Internet to continue to serve > as a tool enabling connectivity among all people. Attacks on the > Internet's ability to do this are increasing and worrisome. >=20 > Some of the topics we want to discuss: >=20 > 1) Continue the discussion on the interrelation between protocols,=20 > architectures and rights >=20 > 2) Enable broad community engagement in this discussion as was > discussed in Hawaii. >=20 > 3) Allow this discussion to happen before politicization related > to human rights and the Internet occurs. >=20 > 4) Discuss methods for doing the work. >=20 > Thanks >=20 > avri >=20 >=20 > On 23-Jan-15 08:31, Eggert, Lars wrote: >> Hi, >=20 >> On 2015-1-23, at 14:21, Avri Doria wrote: >>> I don't know whether it is a BoF or there is some other >>> designation > for an IRTF session for a 'RG in possible formation.' In any > case, following up on the interest in the SAAG session, and > afterwards, we (Joana, Niels and I) would like to request such a > session. >=20 >> I'm happy to have that discussion. I do note that we will need >> to > conclude this in the next few days, because scheduling for rooms > for Dallas will begin. >=20 >>> At the end of the requested session, the goal would be to >>> discuss the > formation of a RG. >=20 >> That's not quite how I handle this in the IRTF. For folks that >> come > with an idea for a new RG, I'm willing to give them meeting rooms > at IETF meetings for a year, and (if they like) have the meeting > listed on the agenda as a "proposed RG" meeting. (It is also > possible to have some of these meetings off the agenda, i.e., with > invitations handled by the proponents of the group.) The > instructions to the proponents are basically "go and pretend you > are an RG", in other words, invite the people you want to invite, > have the discussions you want to have and don't worry about the > charter text. >=20 >> After that year has passed, I sit down with the proponents, the >> IRSG > and IAB and we discuss if the proposed group is off to a good > start. >=20 >> The reason I'm doing it this way is that I've seen to many new >> RGs in > the past focus on charter text, get it perfect and then die on the=20 > starting line because of lack of energy or lack of community > building by the proponents. So I've decided to front-load that, and > fine tune the charter afterwards. >=20 >> Of course you will need some sort of text to explain the group to >> new > people, so they can determine if it's for them, but it doesn't need > to be as formal as a charter. >=20 >> So: >=20 >> * what kind of meeting do you want to hold in Dallas (on the >> agenda, > or off) >=20 >> * do you have a mailing list? >=20 >> * do you have a group of people with energy to make the group >> successful? >=20 >> * do you have some description of the group? (below is an OK >> start) >=20 >=20 >>> But we would like to make it substantive and include the >>> following > discussion items: >>>=20 >>> 1) Continue the discussion on the interrelation between >>> protocols, > architectures and rights >>>=20 >>> 2) Enable broad community engagement in this discussion as was > discussed in Hawaii. >>>=20 >>> 3) Allow this discussion to happen before politicization >>> related to > human rights and the Internet occurs. >>>=20 >>> A major premise of our research goals is future-proofing >>> protocols in > relation to their effect on human rights. If we can discover a > reliable set of considerations, we may avoid needing to fix as many > protocols retroactively going forward. We believe that our goal, > consistent with RFC1958, is for the Internet to continue to serve > as a tool enabling connectivity among all people. Attacks on the > Internet's ability to do this are increasing and worrisome. >>>=20 >>> I think we could use a full session for the discussion, but one >>> of > the shorter slots would probably work. >=20 >> If you want an "on the agenda" meeting, you need to determine how >> many > hours it should be (1h, 1.5h, 2h, 2.5h) and you need to determine > your list of conflicts with other RGs and WGs. >=20 >> If you want an "off the agenda" meeting, those are not scheduled >> in > parallel to WG and RG sessions, so it would need to be breakfast, > lunch or evening time. >=20 >>> Lars, please let us know of any specific information you need >>> or > specific steps you would like us to take in following up on this > request. >=20 >> See above. >=20 >>> We would also be intersted in hearing from the list as to >>> other > things that might be worth adding to the such a discussion so that > we can adjust the proposed 'agenda' to suit. Optimally we can > evolve from the 3 of us trying to get this going to a group working > on moving it forward. But time was getting late for requesting a > slot and we felt we needed to get this moving. >=20 >> Heads up: I may not make it to Dallas for personal reasons. I >> should > know for sure in a few weeks. But since we're not deciding on the > formal chartering of the group in Dallas, that's OK. I will be able > to go to your future meetings. >=20 >> Lars >=20 >=20 >=20 >=20 >=20 > _______________________________________________ hrpc mailing list=20 > hrpc@article19.io https://lists.ghserv.net/mailman/listinfo/hrpc >=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUwmlsAAoJEAi1oPJjbWjpp1cH/172/3oWSoDtGpRTQ3Q/Fx9P YL7OgY2YaoMaZVze7QP9mzpG03Usg2X8aPSMN/WTpNZEQ8hKUA5gkPchkfgZgS2L EjwWus7uS0S1Y8f/UWLEq+oyCoYchXltBWnsM21yrDKTfcNE9piF/1cw/rflLMNt q3zz5TKzddzH41+0r7RfA3hmXvsETA0k8CrNr0IuoSJVaW714tBPaPdM9rX9JuB4 Gsig7T8B/IPb/s+gAE+Y3HPuUbAdppwRzlOt5rjzb34wRwYZKBLRkwll8kPfWyPT NU2wP0M2gP6mpHLZLlrx99gDoVyhB9cJmUJK8XjIdpON/CXJ95UpL6BuDEDm0S4=3D =3DbGEd -----END PGP SIGNATURE----- From niels@article19.org Tue Feb 03 17:52:47 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YIgiV-0007f2-0T for hrpc@article19.io; Tue, 03 Feb 2015 17:52:47 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YIgiU-0004z8-By for hrpc@article19.io; Tue, 03 Feb 2015 17:52:46 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 85BC5CC03D for ; Tue, 3 Feb 2015 16:53:48 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id a9JBVSAMyZCm for ; Tue, 3 Feb 2015 16:53:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 0D4CFCC03E for ; Tue, 3 Feb 2015 16:53:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 RZQqHhdEcX4w for ; Tue, 3 Feb 2015 16:53:46 +0000 (UTC) Received: from [192.168.0.4] (121-82-193-89f1.kyt1.eonet.ne.jp [121.82.193.89]) by mail.article19.io (Postfix) with ESMTPSA id 42561CC03D for ; Tue, 3 Feb 2015 16:53:45 +0000 (UTC) Message-ID: <54D0FCD7.60302@article19.org> Date: Tue, 03 Feb 2015 16:52:39 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: "hrpc@article19.io" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 00ca572c58d2a72aaa1283be2358df10 Subject: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:52:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, I went through RFC7230 [0] over the last days and found some hooks that might be interesting. This is by no means a full analysis, but I hope it can form an input for the discussion. A thought that stuck with me after reading the first chapter of Laura Denardis' book Protocol Politics is the feature of IP which she calls 'disinterestness', but we can also find this in RFC1958 which says that the intelligence of the network is found in the endpoints, rather than in the network. The network is there to transport datagrams (packets), nothing more, nothing less. This is relevant for our research because it helps us to look at both what is organized in protocols, but maybe even more, in what is not regulated or standardize which is what makes the Internet an enabling environment for freedom of expression. 1. In the abstract, HTTP is described as a protocol for distributed and collaborative information systems. This has clear technical implications, but it could also described equality of nodes, which might make this translatable in rights implications. I'm especially thinking about the right to receive and impart information and ideas through any media and regardless of frontiers. A distributed system affirms and enables that by design. Perhaps a good start is to note the words that keep on coming back in a rights context, and word mine all RFCs for these words? Some of these words could be: connectivity, distributed, collabarative, reliable, scalable, caching This could be one way of selecting new and more RFCs, and perhaps auto-grouping them per theme. 2. [self-descriptive message payloads] -> This means that both content and description are to defined by the author/host system, so people can categorize, frame and describe their content themselves, instead of it being auto categorized. 3. [QUOTE] Likewise, servers do not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. [/QUOTE] This supports innovation, development, and flexibility. Would this have any rights implications? Or is this just very practical way of defining a broadly used protocol? Could be linked to 'IP disinterestness' (as mentioned above), which creates space for freedom of expression and freedom of assembly, by supplying tools but not defining the way in which it needs to be done. 4. [QUOTE] An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. [/QUOTE] Interestingly, as interaction starts with the request from a client. The primacy of every action lies with the client. Which could point to souvereignty, autonomy and/or freedom of choice. Are all services based on a request? Are all protocols initiated by request? Would be interesting to have a statement about the primacy of the client. How does this relate to cookies, consent, etc? In other words: does all automation start with clients? Obviously not, because one can scan for open ports, ping user agents, etc. But then one can configure a user agent to respond to this or not (like putting robots.txt on your webserver signals that you don't want your site to be indexed by Google). This seems to point to deepening of this topic: [QUOTE] The implementation diversity of HTTP means that not all user agents can make interactive suggestions to their user or provide adequate warning for security or privacy concerns. [/QUOTE] Eventhough security and privacy concerns are valid (one does not want to give away more information than necessary), this could also fit within a freedom of expression context where a user is free to hold an opinions (and thus not hold or impart others!). 5. In the client request Accept-Languages are defined. Perhaps we can relate this to the research into IDNs (see draft) and/or use this [QUOTE] to show the ambition of the Internet community to reflect the diversity of users and to be in line with Article 2 of the Universal Declaration of Human Rights which clearly stipulates that 'everyone is entitles to all rights and freedoms [..], without distinction of any kind, such as [..] language [..]. [/QUOTE from ID] 6. Caching is crucial for enabling better access to information in areas with slow connection. Could we state that through caching access to information is improved? Further research to be done in RFC7234. 7. What (social) requirements could be meant here? : [QUOTE] Additional (social) requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication. [/QUOTE] 8. Strong point for slow and/or instable connections, support connectivity where there is bad connection. Excellent protection of the right to receive and impart info. I think we could frame this under connecivity as well. [QUOTE] 6.3.1. Retrying Requests Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from asynchronous close events. [/QUOTE] Looking forward to discuss! Best, Niels [0] https://tools.ietf.org/html/rfc7230 - --=20 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJU0PzWAAoJEAi1oPJjbWjpU9AH/3ROPlwEq6Yvt4FxSsTltXkV ESIATnAYmSRVSD/u5MCPGm45WuM+sYhUpD9IGbxRrpKIOAotm331vBqCl2XEdQpk NA1cFbsTgPBfvtcwWoWrAhBJwv1WLW1T7g5G82zsSE9rx2hPL8pCaitV1UqSdFaa G25Z2j7I++86jmDsdw6RTbfxkumlPSoRMcn0hpXxkG7MOAAAvqG+EkwgGxjxfh+T cuGVm6ZDuvWbZvlPI+UF5adHEFFBFFk84sewD5rt/5nuYbtBnLDS5hlL0EDVaRep frakByy8mjwW6DYsIM+Vq/LYHjL3XwLqphVIo9kd+Iz6VYYvzTjnRDh2kXHRm9k=3D =3DNBg3 -----END PGP SIGNATURE----- From dkg@fifthhorseman.net Wed Feb 04 04:57:43 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YIr5y-0008PU-Sr for hrpc@article19.io; Wed, 04 Feb 2015 04:57:42 +0100 Received: from che.mayfirst.org ([209.234.253.108]) by mx2.greenhost.nl with esmtp (Exim 4.72) (envelope-from ) id 1YIr5w-00066d-LR for hrpc@article19.io; Wed, 04 Feb 2015 04:57:42 +0100 Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id D0EAFF986 for ; Tue, 3 Feb 2015 22:57:34 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A67122002B; Tue, 3 Feb 2015 18:20:45 -0500 (EST) From: Daniel Kahn Gillmor To: hrpc@article19.io In-Reply-To: <54D0FCD7.60302@article19.org> References: <54D0FCD7.60302@article19.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 03 Feb 2015 18:20:45 -0500 Message-ID: <87siem8tv6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Level: ++ X-Spam-Status: No, score=2.4 required=5.0 tests=BAYES_50, DATE_IN_PAST_03_06 autolearn=disabled version=3.3.2 X-Spam-Score: 2.4 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: ff2974bc666473b4fc0321629ce2ea1e Subject: Re: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 03:57:43 -0000 Hi Niels-- Thanks for this effort! A few thoughts from me below, spurred by your initial commentary. I apologize in advance that (when trying to read critically at least) i adopt something of a devil's advocate position. My comments are supportive in that i'd like to see this HR analysis proceed from a strong and well-thought-through perspective. On Tue 2015-02-03 11:52:39 -0500, Niels ten Oever wrote: > I went through RFC7230 [0] over the last days and found some hooks > that might be interesting. [...] > This is relevant for our research because it helps us to look at both > what is organized in protocols, but maybe even more, in what is not > regulated or standardize which is what makes the Internet an enabling > environment for freedom of expression. The idea here i think might be framed as the network being "content-neutral". This is supported in some sense by the satirical April Fools' Day RFC 3514, which introduces the "evil bit": https://tools.ietf.org/html/rfc3514 >> Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil >> bit on such packets. "Transparent" http and email proxies SHOULD se= t >> the evil bit on their reply packets to the innocent client host. There are more serious RFCs that take the idea of a content-neutral or content-agnostic network as a given too (for one thing, it's a common engineering practice to layer designs by introducing deliberate agnosticism about the layers above or below the system being specified) Unfortunately, not all proposed standards hold this line on content neutrality: https://tools.ietf.org/html/draft-nottingham-safe-hint-05 (of course, the above draft isn't an official RFC yet -- should we be comparing drafts-that-didn't make it with drafts that ended up becoming RFCs?) With a corpus as large as the RFCs, how should this project avoid confirmation bias? If we look for the things we want to find, it seems like we should probably also make sure to look for things we *don't* want to find, to see whether they're there too. (see also: Biblical Exegesis =E2=98=BA) > 1. > In the abstract, HTTP is described as a protocol for distributed and > collaborative information systems. This has clear technical > implications, but it could also described equality of nodes, which > might make this translatable in rights implications. I'm especially > thinking about the right to receive and impart information and ideas > through any media and regardless of frontiers. A distributed system > affirms and enables that by design. > > Perhaps a good start is to note the words that keep on coming back in > a rights context, and word mine all RFCs for these words? > > Some of these words could be: connectivity, distributed, > collabarative, reliable, scalable, caching > > This could be one way of selecting new and more RFCs, and perhaps > auto-grouping them per theme. > > 2. > [self-descriptive message payloads] -> This means that both content > and description are to defined by the author/host system, so people > can categorize, frame and describe their content themselves, instead > of it being auto categorized. i find it a bit funny that in 1. above you're proposing auto-grouping the RFCs themselves (presumably after fetching them via HTTP), and in 2. here you're saying that the protocol is designed in opposition to "auto categorization". I'm wary of the term "auto" in places like this, because i think it removes agency. who is doing the categorization? even if it's "automatic", it's under the control of someone. I think the point you're trying to make is that the definition of HTTP represents a communication between peers, and peers get to have the conversation without having to talk to (or get approval from) anyone else if they don't want to. (technically, this might not be entirely true: DNS and (for HTTPS) the X.509 certificate authority cartel are in some ways mandatory "brokers" when negotiating the creation of an HTTP session, even if they don't get a say about the content of the communication once the session is created) > 3. > [QUOTE] > Likewise, servers do not need to be aware of each client's purpose: = an HTTP request can be > considered in isolation rather than being associated with a specific= type of client > or a predetermined sequence of application steps. > [/QUOTE] > > This supports innovation, development, and flexibility. Would this > have any rights implications? Or is this just very practical way of > defining a broadly used protocol? Could be linked to 'IP > disinterestness' (as mentioned above), which creates space for freedom > of expression and freedom of assembly, by supplying tools but not > defining the way in which it needs to be done. This property is usually called "statelessness" for the server (and not in a "smash the state" sense!). Statelessness a useful property from a technical perspective because it means you can have the server crash and not have to worry about what happens to the client when it comes back up (the client can just carry on as it was). In practice, of course, everyone wants to introduce state because it makes certain kinds of workflows (e.g. multipage forms, logged-in accounts, widespread user surveillance) much more convenient. Hence cookies and other similar mechanisms. But the point of defining HTTP as a stateless protocol is so that servers *can* be implemented statelessly, for those who have engineering constraints that preclude keeping state on the server side (e.g. a machine with no way to write internal storage). NFS (the "network filesystem") is another protocol that has jumped through many hoops to keep "statelessness" for the server. see: https://tools.ietf.org/html/rfc1094#section-1.3 However, NFS as of version 4 has gradually acquired server-side state (that is, state shared between the client and the server), while retaining some mechanisms aimed at easing this requirement for servers that fit certain profiles: https://tools.ietf.org/html/rfc3530#section-8.14 otoh, aiming for statelessness itself doesn't have to be motivated purely by technical goals. For example, if you design a protocol that *requires* the server to maintain state about its users (e.g. internet relay chat (IRC) servers retain state about who is connected and what channels they're connected to), you make it impossible for someone who *doesn't* want to track their users to implement the protocol in a non-tracking way. Whether the push for statelessness in some internet protocols derives in part from this urge to safeguard against ubiquitous surveillance is pretty hard to say, of course. > 4. > [QUOTE] > An HTTP "client" is a > program that establishes a connection to a server for the purpose of > sending one or more HTTP requests. > [/QUOTE] > > Interestingly, as interaction starts with the request from a client. > The primacy of every action lies with the client. Which could point to > souvereignty, autonomy and/or freedom of choice. Are all services > based on a request? Are all protocols initiated by request? Would be > interesting to have a statement about the primacy of the client. How > does this relate to cookies, consent, etc? In other words: does all > automation start with clients? I'm not sure this is anything but a technical label. In the client/server network communications model, the server is defined as being the "listener". the client is the one that initiates a connection. Not all protocols are client/server, though the stuff in the IETF tends to be client-server because it's simpler to describe. peer-to-peer protocols like bittorrent aren't client/server, for example. But i don't think the IETF has ever even tried to standardize bittorrent. And while the protocol at a high level might not be client/server, each individual communication that happens during a bittorrent session (i'm not sure i'm using the right BT terms here -- i don't know much about the protocol) is probably using a client/server model, where one peer (the client at that moment) sends a message to another peer (the server at that moment). TCP itself supports a "simultaneous open" mode, where neither side is the client or the server: https://tools.ietf.org/html/rfc793#page-32 But there are very few attempts to use simultaneous open in the wild (i think that STUN or TURN might use it, but i don't recall the details) Some lower-level protocols like Ethernet (also not standardized by the IETF) are by definition broadcast -- everyone in a given broadcast domain receives every message, and the recipients are just expected to filter out traffic that isn't aimed at them. The IETF has some protocols like IP multicast that enable subscription mechanisms that might take advantage of this lower-level broadcast technique: https://tools.ietf.org/html/rfc1112 > Obviously not, because one can scan for open ports, ping user agents, > etc. by scanning for open ports, you're acting as a (TCP or UDP) client. I'm not sure what you mean by "ping user agents". the traditional ping (ICMP echo request) happens at the IP layer, from host to host, where "user agent" has no definition that i know of. > But then one can configure a user agent to respond to this or not > (like putting robots.txt on your webserver signals that you don't want > your site to be indexed by Google). i think this text might confuse some people because of the terms used. in a googlebot=E2=86=92webserver connection, the "user agent" is googlebo= t, and the "origin server" is the web server. Putting robots.txt in your web server is a configuration of the origin server. And robots.txt is purely advisory, encouraging (hoping?) that the connecting user agents will respect the request. > This seems to point to deepening of this topic: > > [QUOTE] > The implementation diversity of HTTP means that not all user agents > can make interactive suggestions to their user or provide adequate > warning for security or privacy concerns. > [/QUOTE] > > Eventhough security and privacy concerns are valid (one does not want > to give away more information than necessary), this could also fit > within a freedom of expression context where a user is free to hold an > opinions (and thus not hold or impart others!). If we're reading this in respect to human rights, i'd be more inclined to take it from a disability rights perspective; you can't specify something into the protocol that assumes that the end user has a visual display that works for them, or is physically capable of selecting choices from a presented menu, etc. > 5. > In the client request Accept-Languages are defined. Perhaps we can > relate this to the research into IDNs (see draft) and/or use this > [QUOTE] to show the ambition of the Internet community to > reflect the diversity of users and to be in line with Article 2 of > the Universal Declaration of Human Rights which clearly stipulates > that 'everyone is entitles to all rights and freedoms [..], without > distinction of any kind, such as [..] language [..]. > [/QUOTE from ID] I agree with this view. You can also argue it from the reverse, which is that traditionally, Internet protocols concerned themselves only with characters expressable by US-ASCII (which limits to languages that use the latin alphabet), and the story of protocol development has been one of expansion that covers more of the diversity of human communications for the content that the protocol transmits. Interestingly, though, most protocols retain the ASCII-only simplicity for protocol messages themselves. For example, HTTP headers are all defined in ASCII. HTML tags are all named in ASCII, even when the content of the page is entirely in ideograms. And the framing messages (e.g. EHLO, DATA, etc) in SMTP are still ASCII and will probably always be. There's a subtle substrate of linguistic dominance threaded in there if you want to go looking for it. For that matter, the RFCs themselves are all written in English (or some weird and formalized approximation thereof). > 6. > Caching is crucial for enabling better access to information in areas > with slow connection. Could we state that through caching access to > information is improved? Further research to be done in RFC7234. Caching is also a place where intermediaries are introduced into what would otherwise be a peering relationship, though. Caching proxies can modify content, spoof content outright, or refuse to serve content. the httpbis working group regularly fends off proposals for machine-in-the-middle (MitM) caching proxies for https, which come complete with arguments very similar to "enabling better access to information": https://tools.ietf.org/html/draft-loreto-httpbis-explicitly-auth-proxy actually says "possibility to enhance delivery performance" :/ I consider these arguments to be dangerous to the idea of network security, and i'm glad that the IETF has avoided standardizing this sort of thing so far. > 7. > What (social) requirements could be meant here? : > > [QUOTE] > Additional (social) requirements are placed on implementations, > resource owners, and protocol element registrations when they apply > beyond the scope of a single communication. > [/QUOTE] i'm having a hard time parsing this myself, but i think they're saying "most of the requirements we state in this document have to do with what happens explicitly in a single connection. some other requirements, though, have scope larger than a single communication, such as how to add a new element to this protocol, whether clients should open multiple connections to a given server, or whether a server should publish URIs for its own resources that it would fail to parse on subsequent connections." These larger-scoped requirements are the "social" requirements. > 8. > Strong point for slow and/or instable connections, support > connectivity where there is bad connection. Excellent protection of > the right to receive and impart info. I think we could frame this > under connecivity as well. > > [QUOTE] > 6.3.1. Retrying Requests > > Connections can be closed at any time, with or without intention. > Implementations ought to anticipate the need to recover from > asynchronous close events. > [/QUOTE] this is definitely about the ethic of trying to connect, and robust communications in general. Without this baseline assumption, most internet standards be even worse than the (admittedly not very good) experience we've come to expect. But it's not necessarily about supporting connections where the underlying links might be bad. I'd argue that it's more about responsible handling (and awareness) of error conditions. Postel's law, which was taken as gospel for many years (and is named after Jon Postel, the first RFC editor, and the author of numerous early RFCs), emphasizes connectivity in a formulation that usually runs something like this : "Be liberal in what you receive, and conservative in what you send". But within the tech security community, Postel's law is now under attack (or at least, heavy revision). In particular, it is understood to often lead to buggy, non-predictable implementations that are likely to harbor security vulnerabilities (e.g. imagine if a TCP implementation accepted packets that had a "close enough" sequence number, instead of requiring a correct match). Modern security-conscious standards are much more likely to adopt Postel's law in a more minimalist form, encouraging implementors to drop or reject ill-formed input, while dealing gracefully with the resulting failure conditions. This results in less "papering over" of failures from the remote peer, while still providing robust communications. Maybe the underlying ethics here are (a) transparency and (b) robustness? Both of these are user-centric notions -- the user should not be misled by the tools, and the tools should not disobey the user. --dkg From stephen.farrell@cs.tcd.ie Wed Feb 04 11:07:21 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YIwrh-0000oZ-Np for hrpc@article19.io; Wed, 04 Feb 2015 11:07:21 +0100 Received: from mercury.scss.tcd.ie ([134.226.56.6]) by mx2.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YIwre-00050V-On for hrpc@article19.io; Wed, 04 Feb 2015 11:07:21 +0100 Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4E151BF0D; Wed, 4 Feb 2015 10:07:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 sLexXEc81oyQ; Wed, 4 Feb 2015 10:07:48 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.17.67]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E3963BEFB; Wed, 4 Feb 2015 10:07:47 +0000 (GMT) Message-ID: <54D1EF53.60209@cs.tcd.ie> Date: Wed, 04 Feb 2015 10:07:15 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , hrpc@article19.io References: <54D0FCD7.60302@article19.org> <87siem8tv6.fsf@alice.fifthhorseman.net> In-Reply-To: <87siem8tv6.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Level: / X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_NONE, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: 0.8 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 51a43cd7ff6838d9e9bce89dbcde6c26 Subject: Re: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:07:22 -0000 One snippet... On 03/02/15 23:20, Daniel Kahn Gillmor wrote: > Unfortunately, not all proposed standards hold this line on content > neutrality: > > https://tools.ietf.org/html/draft-nottingham-safe-hint-05 > > (of course, the above draft isn't an official RFC yet -- should we be > comparing drafts-that-didn't make it with drafts that ended up becoming > RFCs?) AFAIK that draft is not continuing to publication. The IESG ballot positions are at [1]. I don't know if the author plans to bring it back or somewhere else in the same or some other form. So I'd not concentrate on that, unless you're interested in how the IETF process has (so far) stopped a bad idea from becoming an RFC and proposed standard. If you are interested in the latter, then I'm happy to help explain some of the minutiae, e.g. that 10 yes or no-objections IESG ballots are needed for a proposed standard. (This was the first time I've ever seen 6 abstain ballots on a draft in my 4 years on the IESG.) S. [1] https://datatracker.ietf.org/doc/draft-nottingham-safe-hint/ballot/ From dkg@fifthhorseman.net Wed Feb 04 16:19:14 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YJ1jW-0001J3-Kv for hrpc@article19.io; Wed, 04 Feb 2015 16:19:14 +0100 Received: from che.mayfirst.org ([209.234.253.108]) by mx1.greenhost.nl with esmtp (Exim 4.72) (envelope-from ) id 1YJ1jV-0005Zx-PT for hrpc@article19.io; Wed, 04 Feb 2015 16:19:14 +0100 Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B08D4F984; Wed, 4 Feb 2015 10:19:08 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 332211FF68; Wed, 4 Feb 2015 10:19:08 -0500 (EST) From: Daniel Kahn Gillmor To: Stephen Farrell , hrpc@article19.io In-Reply-To: <54D1EF53.60209@cs.tcd.ie> References: <54D0FCD7.60302@article19.org> <87siem8tv6.fsf@alice.fifthhorseman.net> <54D1EF53.60209@cs.tcd.ie> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 04 Feb 2015 10:19:08 -0500 Message-ID: <87pp9p7lhv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Level: / X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 X-Spam-Score: 0.8 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 2394e6fd9f1e9f86011669f8146dc264 Subject: Re: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:19:15 -0000 On Wed 2015-02-04 05:07:15 -0500, Stephen Farrell wrote: > One snippet... > > On 03/02/15 23:20, Daniel Kahn Gillmor wrote: >> Unfortunately, not all proposed standards hold this line on content >> neutrality: >> >> https://tools.ietf.org/html/draft-nottingham-safe-hint-05 >> >> (of course, the above draft isn't an official RFC yet -- should we be >> comparing drafts-that-didn't make it with drafts that ended up becoming >> RFCs?) > > AFAIK that draft is not continuing to publication. The IESG > ballot positions are at [1]. I don't know if the author plans to > bring it back or somewhere else in the same or some other form. I'm happy to hear this -- i think that draft represents a serious possibility of chilling effects on speech (not to mention removal of power from the hands of the end user), without much of a benefit in other areas. for example, i don't believe the existence of the RFC would have actually stopped any would-be filter/censor from trying to MitM HTTP or HTTPS connections. > So I'd not concentrate on that, unless you're interested in how > the IETF process has (so far) stopped a bad idea from becoming > an RFC and proposed standard. For the purposes of looking for human rights leads, i think the process itself would be useful as background, but in particular it could be useful to read the comments in drafts that did not make it to RFC status, to see how those arguments are presented. I think the question we're asking is something like "in what ways do RFCs reflect a human rights agenda?" It would be instructive to observe how things that *do not become* RFCs get shot down or set aside, since that filtering process could also reflect a human rights agenda. I don't know how to structure this research, though -- i'll leave that to the experts :) --dkg From bortzmeyer@nic.fr Wed Feb 04 16:45:02 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YJ28U-0001LC-GT for hrpc@article19.io; Wed, 04 Feb 2015 16:45:02 +0100 Received: from mx4.nic.fr ([192.134.4.12]) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YJ28T-0006GF-Qy for hrpc@article19.io; Wed, 04 Feb 2015 16:45:02 +0100 Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 37AE9280385; Wed, 4 Feb 2015 16:45:01 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 32DC328012B; Wed, 4 Feb 2015 16:45:01 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id 3084B4C0029; Wed, 4 Feb 2015 16:44:31 +0100 (CET) Date: Wed, 4 Feb 2015 16:44:31 +0100 From: Stephane Bortzmeyer To: Daniel Kahn Gillmor Message-ID: <20150204154431.GA12839@nic.fr> References: <54D0FCD7.60302@article19.org> <87siem8tv6.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87siem8tv6.fsf@alice.fifthhorseman.net> X-Operating-System: Debian GNU/Linux 8.0 X-Kernel: Linux 3.16.0-4-686-pae i686 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Level: ---- X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.2 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: a07cf4f22b7e0347d98fbeb4081a69be Cc: hrpc@article19.io Subject: Re: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:45:03 -0000 On Tue, Feb 03, 2015 at 06:20:45PM -0500, Daniel Kahn Gillmor wrote a message of 283 lines which said: > Interestingly, though, most protocols retain the ASCII-only > simplicity for protocol messages themselves. For example, HTTP > headers are all defined in ASCII. HTML tags are all named in ASCII, > even when the content of the page is entirely in ideograms. And the > framing messages (e.g. EHLO, DATA, etc) in SMTP are still ASCII and > will probably always be. There's a subtle substrate of linguistic > dominance threaded in there if you want to go looking for it. The rationale for this choice is RFC 2277. To summarize it: "protocol elements", never seen by the ordinary user (such as GET and POST in HTTP) are in ASCII. Text elements have to be in Unicode. [BTW, HTML is not an IETF standard.] From niels@article19.org Mon Feb 09 08:01:25 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YKiLV-00018B-QG for hrpc@article19.io; Mon, 09 Feb 2015 08:01:25 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YKiLU-0003Vj-CK for hrpc@article19.io; Mon, 09 Feb 2015 08:01:25 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 74A1414002F for ; Mon, 9 Feb 2015 07:02:37 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lIgSxqCmLUyb for ; Mon, 9 Feb 2015 07:02:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 05937140031 for ; Mon, 9 Feb 2015 07:02:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 yRHxoI9UEwU1 for ; Mon, 9 Feb 2015 07:02:34 +0000 (UTC) Received: from [10.196.197.150] (86-193.icannmeeting.org [199.91.193.86]) by mail.article19.io (Postfix) with ESMTPSA id 6546814002F for ; Mon, 9 Feb 2015 07:02:33 +0000 (UTC) Message-ID: <54D85B3A.2050106@article19.org> Date: Mon, 09 Feb 2015 07:01:14 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: hrpc@article19.io References: <54D0FCD7.60302@article19.org> <87siem8tv6.fsf@alice.fifthhorseman.net> In-Reply-To: <87siem8tv6.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 6fdd8fc92e0876959553adcced2c9235 Subject: Re: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 07:01:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi dkg, Thanks for your elaborate response. No problems with a critical stance, even for the sake of the argument, there is no progress without critical thinking. Please be harsh :) Further reaction inline: On 02/03/2015 11:20 PM, Daniel Kahn Gillmor wrote: > Hi Niels-- >=20 > Thanks for this effort! A few thoughts from me below, spurred by > your initial commentary. I apologize in advance that (when trying > to read critically at least) i adopt something of a devil's > advocate position. My comments are supportive in that i'd like to > see this HR analysis proceed from a strong and well-thought-through > perspective. >=20 > On Tue 2015-02-03 11:52:39 -0500, Niels ten Oever wrote: >> I went through RFC7230 [0] over the last days and found some >> hooks that might be interesting. > [...] >> This is relevant for our research because it helps us to look at >> both what is organized in protocols, but maybe even more, in what >> is not regulated or standardize which is what makes the Internet >> an enabling environment for freedom of expression. >=20 > The idea here i think might be framed as the network being=20 > "content-neutral". This is supported in some sense by the > satirical April Fools' Day RFC 3514, which introduces the "evil > bit": >=20 > https://tools.ietf.org/html/rfc3514 >=20 >>> Because NAT [RFC3022] boxes modify packets, they SHOULD set the >>> evil bit on such packets. "Transparent" http and email proxies >>> SHOULD set the evil bit on their reply packets to the innocent >>> client host. >=20 > There are more serious RFCs that take the idea of a content-neutral > or content-agnostic network as a given too (for one thing, it's a > common engineering practice to layer designs by introducing > deliberate agnosticism about the layers above or below the system > being specified) This is a great lead. Do you have any leads on where content-agnosticism has been the best described in an RFC ? Content agnosticism, together with connectivity could be the basis of enabling of freedom of expression on the network. >=20 > Unfortunately, not all proposed standards hold this line on > content neutrality: >=20 > https://tools.ietf.org/html/draft-nottingham-safe-hint-05 >=20 > (of course, the above draft isn't an official RFC yet -- should we > be comparing drafts-that-didn't make it with drafts that ended up > becoming RFCs?) >=20 I agree that it would be interesting to also look at RFCs that did not make it, or ones that are still drafts, but I would like to keep that for later and first see what we can still from the existing body of RFCs, because that is already a lot. Are there any RFCs that you know of that breach content agnosticism? I imagine this could happen in congestion protocols, no? Or would that be on the implementation level? > With a corpus as large as the RFCs, how should this project avoid=20 > confirmation bias? If we look for the things we want to find, it > seems like we should probably also make sure to look for things we > *don't* want to find, to see whether they're there too. (see also: > Biblical Exegesis =E2=98=BA) >=20 I completely agree. But knowing what we are looking for, will also help us finding the things we don't want to see. >=20 >> 1. In the abstract, HTTP is described as a protocol for >> distributed and collaborative information systems. This has clear >> technical implications, but it could also described equality of >> nodes, which might make this translatable in rights implications. >> I'm especially thinking about the right to receive and impart >> information and ideas through any media and regardless of >> frontiers. A distributed system affirms and enables that by >> design. >>=20 >> Perhaps a good start is to note the words that keep on coming >> back in a rights context, and word mine all RFCs for these >> words? >>=20 >> Some of these words could be: connectivity, distributed,=20 >> collabarative, reliable, scalable, caching >>=20 >> This could be one way of selecting new and more RFCs, and >> perhaps auto-grouping them per theme. Adding stateless, statefull, content-neutral, transparent, robust, user-centric and content agnostic to this list and removing caching (as per discussion below). New list: connectivity, distributed, collaborative, reliable, scalable, stateless, statefull, content-neutral, content agnostic, transparent, robust, robustness, user-centric. >>=20 >> 2. [self-descriptive message payloads] -> This means that both >> content and description are to defined by the author/host system, >> so people can categorize, frame and describe their content >> themselves, instead of it being auto categorized. >=20 > i find it a bit funny that in 1. above you're proposing > auto-grouping the RFCs themselves (presumably after fetching them > via HTTP), and in 2. here you're saying that the protocol is > designed in opposition to "auto categorization". >=20 > I'm wary of the term "auto" in places like this, because i think > it removes agency. who is doing the categorization? even if it's=20 > "automatic", it's under the control of someone. Of course, just meant it to make it easier for us to select relevant RFCs, and overcoming the confirmation bias to some level. >=20 > I think the point you're trying to make is that the definition of > HTTP represents a communication between peers, and peers get to > have the conversation without having to talk to (or get approval > from) anyone else if they don't want to. >=20 > (technically, this might not be entirely true: DNS and (for HTTPS) > the X.509 certificate authority cartel are in some ways mandatory=20 > "brokers" when negotiating the creation of an HTTP session, even > if they don't get a say about the content of the communication once > the session is created) >=20 >=20 >> 3. [QUOTE] Likewise, servers do not need to be aware of each >> client's purpose: an HTTP request can be considered in isolation >> rather than being associated with a specific type of client or a >> predetermined sequence of application steps. [/QUOTE] >>=20 >> This supports innovation, development, and flexibility. Would >> this have any rights implications? Or is this just very practical >> way of defining a broadly used protocol? Could be linked to 'IP=20 >> disinterestness' (as mentioned above), which creates space for >> freedom of expression and freedom of assembly, by supplying tools >> but not defining the way in which it needs to be done. >=20 > This property is usually called "statelessness" for the server (and > not in a "smash the state" sense!). Statelessness a useful > property from a technical perspective because it means you can have > the server crash and not have to worry about what happens to the > client when it comes back up (the client can just carry on as it > was). >=20 > In practice, of course, everyone wants to introduce state because > it makes certain kinds of workflows (e.g. multipage forms, > logged-in accounts, widespread user surveillance) much more > convenient. Hence cookies and other similar mechanisms. >=20 > But the point of defining HTTP as a stateless protocol is so that=20 > servers *can* be implemented statelessly, for those who have > engineering constraints that preclude keeping state on the server > side (e.g. a machine with no way to write internal storage). >=20 > NFS (the "network filesystem") is another protocol that has jumped=20 > through many hoops to keep "statelessness" for the server. see: >=20 > https://tools.ietf.org/html/rfc1094#section-1.3 Fascinating that the argument for statelessness is reliability and stability and introducing the concept of 'idempotence'. I would almost like to ask the same questions as before: is there a description of engineering standards (preferably in an RFC) that says that a protocol should be stateless unless there are other compelling reasons not to? >=20 > However, NFS as of version 4 has gradually acquired server-side > state (that is, state shared between the client and the server), > while retaining some mechanisms aimed at easing this requirement > for servers that fit certain profiles: >=20 > https://tools.ietf.org/html/rfc3530#section-8.14 >=20 >=20 Under 8.14.1 it is mentioned that the transition needs to be done transparent for the client, but transparency doesn't necessary imply consent, right? Might be interesting to dig a bit deeper in what transparency means on this level (and how it relates to consent). > otoh, aiming for statelessness itself doesn't have to be motivated=20 > purely by technical goals. For example, if you design a protocol > that *requires* the server to maintain state about its users (e.g. > internet relay chat (IRC) servers retain state about who is > connected and what channels they're connected to), you make it > impossible for someone who *doesn't* want to track their users to > implement the protocol in a non-tracking way. >=20 > Whether the push for statelessness in some internet protocols > derives in part from this urge to safeguard against ubiquitous > surveillance is pretty hard to say, of course. >=20 I could imagine there are also plenty of other reasons to be for a more stateless architecture (like the ones mentioned in the NFS RFC), all seem equally valid to me, am not sure intentionality is crucial here. >=20 >> 4. [QUOTE] An HTTP "client" is a program that establishes a >> connection to a server for the purpose of sending one or more >> HTTP requests. [/QUOTE] >>=20 >> Interestingly, as interaction starts with the request from a >> client. The primacy of every action lies with the client. Which >> could point to souvereignty, autonomy and/or freedom of choice. >> Are all services based on a request? Are all protocols initiated >> by request? Would be interesting to have a statement about the >> primacy of the client. How does this relate to cookies, consent, >> etc? In other words: does all automation start with clients? >=20 > I'm not sure this is anything but a technical label. In the=20 > client/server network communications model, the server is defined > as being the "listener". the client is the one that initiates a=20 > connection. >=20 OK, that makes my remarks a tautology, thanks for the clarification! > Not all protocols are client/server, though the stuff in the IETF > tends to be client-server because it's simpler to describe. >=20 > peer-to-peer protocols like bittorrent aren't client/server, for=20 > example. But i don't think the IETF has ever even tried to > standardize bittorrent. And while the protocol at a high level > might not be client/server, each individual communication that > happens during a bittorrent session (i'm not sure i'm using the > right BT terms here -- i don't know much about the protocol) is > probably using a client/server model, where one peer (the client at > that moment) sends a message to another peer (the server at that > moment). >=20 > TCP itself supports a "simultaneous open" mode, where neither side > is the client or the server: >=20 > https://tools.ietf.org/html/rfc793#page-32 >=20 > But there are very few attempts to use simultaneous open in the > wild (i think that STUN or TURN might use it, but i don't recall > the details) >=20 > Some lower-level protocols like Ethernet (also not standardized by > the IETF) are by definition broadcast -- everyone in a given > broadcast domain receives every message, and the recipients are > just expected to filter out traffic that isn't aimed at them. >=20 > The IETF has some protocols like IP multicast that enable > subscription mechanisms that might take advantage of this > lower-level broadcast technique: >=20 > https://tools.ietf.org/html/rfc1112 >=20 We have been thinking of including multicast in the research, but it seems (but correct me if I am wrong) that multicast does not see a lot of implementation in the wild, or am I overseeing something? <> >> This seems to point to deepening of this topic: >>=20 >> [QUOTE] The implementation diversity of HTTP means that not all >> user agents can make interactive suggestions to their user or >> provide adequate warning for security or privacy concerns.=20 >> [/QUOTE] >>=20 >> Eventhough security and privacy concerns are valid (one does not >> want to give away more information than necessary), this could >> also fit within a freedom of expression context where a user is >> free to hold an opinions (and thus not hold or impart others!). >=20 > If we're reading this in respect to human rights, i'd be more > inclined to take it from a disability rights perspective; you can't > specify something into the protocol that assumes that the end user > has a visual display that works for them, or is physically capable > of selecting choices from a presented menu, etc. >=20 Probably you're right, so probably we should keep this aside for a moment so we keep the focus on Freedom of Expression and Freedom of Assembly. >=20 >> 5. In the client request Accept-Languages are defined. Perhaps we >> can relate this to the research into IDNs (see draft) and/or use >> this [QUOTE] to show the ambition of the Internet community to=20 >> reflect the diversity of users and to be in line with Article 2 >> of the Universal Declaration of Human Rights which clearly >> stipulates that 'everyone is entitles to all rights and freedoms >> [..], without distinction of any kind, such as [..] language >> [..]. [/QUOTE from ID] >=20 > I agree with this view. You can also argue it from the reverse, > which is that traditionally, Internet protocols concerned > themselves only with characters expressable by US-ASCII (which > limits to languages that use the latin alphabet), and the story of > protocol development has been one of expansion that covers more of > the diversity of human communications for the content that the > protocol transmits. >=20 > Interestingly, though, most protocols retain the ASCII-only > simplicity for protocol messages themselves. For example, HTTP > headers are all defined in ASCII. HTML tags are all named in > ASCII, even when the content of the page is entirely in ideograms. > And the framing messages (e.g. EHLO, DATA, etc) in SMTP are still > ASCII and will probably always be. There's a subtle substrate of > linguistic dominance threaded in there if you want to go looking > for it. >=20 > For that matter, the RFCs themselves are all written in English (or > some weird and formalized approximation thereof). >=20 Excellent points, adding this to the analysis of Article 2 issues. >=20 >> 6. Caching is crucial for enabling better access to information >> in areas with slow connection. Could we state that through >> caching access to information is improved? Further research to be >> done in RFC7234. >=20 > Caching is also a place where intermediaries are introduced into > what would otherwise be a peering relationship, though. Caching > proxies can modify content, spoof content outright, or refuse to > serve content. >=20 > the httpbis working group regularly fends off proposals for=20 > machine-in-the-middle (MitM) caching proxies for https, which come=20 > complete with arguments very similar to "enabling better access to=20 > information": >=20 > https://tools.ietf.org/html/draft-loreto-httpbis-explicitly-auth-proxy > > actually says "possibility to enhance delivery performance" :/ >=20 > I consider these arguments to be dangerous to the idea of network=20 > security, and i'm glad that the IETF has avoided standardizing this > sort of thing so far. >=20 Good point, will probably be too hard to balance rights here, so dropping caching. >=20 >> 7. What (social) requirements could be meant here? : >>=20 >> [QUOTE] Additional (social) requirements are placed on >> implementations, resource owners, and protocol element >> registrations when they apply beyond the scope of a single >> communication. [/QUOTE] >=20 > i'm having a hard time parsing this myself, but i think they're > saying "most of the requirements we state in this document have to > do with what happens explicitly in a single connection. some other > requirements, though, have scope larger than a single > communication, such as how to add a new element to this protocol, > whether clients should open multiple connections to a given server, > or whether a server should publish URIs for its own resources that > it would fail to parse on subsequent connections." These > larger-scoped requirements are the "social" requirements. >=20 Interesting understanding of the phrase :), might be interesting to quizz Mark Notthingham about this. >> 8. Strong point for slow and/or instable connections, support=20 >> connectivity where there is bad connection. Excellent protection >> of the right to receive and impart info. I think we could frame >> this under connecivity as well. >>=20 >> [QUOTE] 6.3.1. Retrying Requests >>=20 >> Connections can be closed at any time, with or without >> intention. Implementations ought to anticipate the need to >> recover from asynchronous close events. [/QUOTE] >=20 > this is definitely about the ethic of trying to connect, and > robust communications in general. Without this baseline > assumption, most internet standards be even worse than the > (admittedly not very good) experience we've come to expect. But > it's not necessarily about supporting connections where the > underlying links might be bad. I'd argue that it's more about > responsible handling (and awareness) of error conditions. >=20 > Postel's law, which was taken as gospel for many years (and is > named after Jon Postel, the first RFC editor, and the author of > numerous early RFCs), emphasizes connectivity in a formulation that > usually runs something like this : "Be liberal in what you receive, > and conservative in what you send". >=20 > But within the tech security community, Postel's law is now under > attack (or at least, heavy revision). In particular, it is > understood to often lead to buggy, non-predictable implementations > that are likely to harbor security vulnerabilities (e.g. imagine if > a TCP implementation accepted packets that had a "close enough" > sequence number, instead of requiring a correct match). Modern > security-conscious standards are much more likely to adopt Postel's > law in a more minimalist form, encThisouraging implementors to drop > or reject ill-formed input, while dealing gracefully with the > resulting failure conditions. >=20 > This results in less "papering over" of failures from the remote > peer, while still providing robust communications. Maybe the > underlying ethics here are (a) transparency and (b) robustness? > Both of these are user-centric notions -- the user should not be > misled by the tools, and the tools should not disobey the user. >=20 This might be an interesting point for research as well, since it is about balancing fault tolerance (connectivity) and security. Am definitely adding user-centric, robustness and transparency to the list of topics to look for. It seems that we are slowly coming up with relevant technical concepts that impact rights online, so this is really helpful. Looking at RFCs through the lens of these concepts might be methodology we are looking for. > --dkg Best, Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJU2Fs6AAoJEAi1oPJjbWjpWIAH/RO1nRiKM+Y0JjxdUyhHXI5C lmkP34pyp9Nz9Ug0CQ+SczArh7JbKPe0xW8EPHEilN+SiAgpDI9DvZPdXT+n2MDq F9Fv+kHIMdkzokyjE7SMhDfrbB8T2buS2oVqUQ2zFA3qIiaV2uLM/wSK0d3OvXhT OJnwH8L0VZ/gCZSWIfJpX9DQKPdGWNC5o2qiC1GtPqhaqDFKRAK4Y14ONkS1dlWn qRVVcd1tZ8ASiCuz8/uQ4+QdT0sXeUKWZuFw4EcDaskDqaRZ3FA+I9y7pUOop3kI fnjAN+58mTdjq2Y5ZygWmZnXlQXB4NyaWyWIqZxr4qrF0GCHQdoSVc1FEhY/skY=3D =3DC35E -----END PGP SIGNATURE----- From dkg@fifthhorseman.net Mon Feb 09 08:48:34 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YKj58-0001B8-3m for hrpc@article19.io; Mon, 09 Feb 2015 08:48:34 +0100 Received: from che.mayfirst.org ([209.234.253.108]) by mx2.greenhost.nl with esmtp (Exim 4.72) (envelope-from ) id 1YKj57-0007V4-HX for hrpc@article19.io; Mon, 09 Feb 2015 08:48:34 +0100 Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2E59BF984; Mon, 9 Feb 2015 02:48:29 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 207E21FF47; Mon, 9 Feb 2015 02:48:25 -0500 (EST) From: Daniel Kahn Gillmor To: Niels ten Oever , hrpc@article19.io In-Reply-To: <54D85B3A.2050106@article19.org> References: <54D0FCD7.60302@article19.org> <87siem8tv6.fsf@alice.fifthhorseman.net> <54D85B3A.2050106@article19.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 09 Feb 2015 02:48:25 -0500 Message-ID: <87vbjbv83a.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Level: / X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 X-Spam-Score: 0.8 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 488b5a33f748713be529de57fa847022 Subject: Re: [hrpc] first screening of RFC7230 for Human Rights leads X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 07:48:34 -0000 On Mon 2015-02-09 02:01:14 -0500, Niels ten Oever wrote: > This is a great lead. Do you have any leads on where > content-agnosticism has been the best described in an RFC ? Content > agnosticism, together with connectivity could be the basis of > enabling of freedom of expression on the network. I can't think of any such RFCs off the top of my head. TCP is a classic protocol example of a "layered" approach, where it is relatively agnostic about what happens in the layers above and below it: https://tools.ietf.org/html/rfc793 But i don't think the RFC makes any explicit claims to that agnosticism. You can see in that early RFC, though, that the authors don't even take IP for granted (as the layer "below" TCP), stating: The interface between TCP and lower level protocol is essentially unspecified except that it is assumed there is a mechanism whereby the two levels can asynchronously pass information to each other. Typically, one expects the lower level protocol to specify this interface. TCP is designed to work in a very general environment of interconnected networks. The lower level protocol which is assumed throughout this document is the Internet Protocol [2]. for the layer "above" TCP, the RFC frames it simply as: The data that flows on a connection may be thought of as a stream of octets. Though it does also take some pains to mark out "urgent mode", which can identify some parts of a TCP stream as higher-priority than others. I'm unaware of anyone actually using TCP's "urgent mode", though. Perhaps others with more TCP knowledge can weigh in on this. Urgent mode appears to be deprecated in https://tools.ietf.org/html/rfc6093, which i have not read fully. > Fascinating that the argument for statelessness is reliability and > stability and introducing the concept of 'idempotence'. I would > almost like to ask the same questions as before: is there a > description of engineering standards (preferably in an RFC) that > says that a protocol should be stateless unless there are other > compelling reasons not to? i don't know of such a reference :( hopefully someone with more knowledge of the RFCs can dig something up. > We have been thinking of including multicast in the research, but it > seems (but correct me if I am wrong) that multicast does not see a lot > of implementation in the wild, or am I overseeing something? i think you're correct that multicast hasn't seen wide adoption. Regards, --dkg From niels@article19.org Tue Feb 10 07:25:51 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YL4Gd-0002sO-8k for hrpc@article19.io; Tue, 10 Feb 2015 07:25:51 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YL4Gc-0000yw-R5 for hrpc@article19.io; Tue, 10 Feb 2015 07:25:51 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id C36D2130028 for ; Tue, 10 Feb 2015 06:27:05 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Gy6kCB32-OwT for ; Tue, 10 Feb 2015 06:27:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 3F452130029 for ; Tue, 10 Feb 2015 06:27:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 4IxalqANQyPi for ; Tue, 10 Feb 2015 06:27:04 +0000 (UTC) Received: from [10.196.197.150] (33-193.icannmeeting.org [199.91.193.33]) by mail.article19.io (Postfix) with ESMTPSA id 2E7D5130028 for ; Tue, 10 Feb 2015 06:27:02 +0000 (UTC) Message-ID: <54D9A466.7030108@article19.org> Date: Tue, 10 Feb 2015 06:25:42 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: "hrpc@article19.io" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: e3f2e3bd4740624ec693f7a12728aa38 Subject: [hrpc] interviews @ IETF meeting in Dallas X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 06:25:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, To increase our understanding of the perception of human rights and user rights among authors we thought it might be a good idea to interview RFC authors and main actors in the IETF. Since the Dallas meeting is coming up quickly, and these are busy people I thought it might be a good idea to already ask people for a timeslot of ~30 minutes. I was thinking of the following people: - - Head of IAB Russ Housley - - Chair of IETF Jari Arkko - - Area Directors (https://www.ietf.org/iesg/members.html) (one per area, but allow them to self-select) Applications area Barry Leiba Pete Resnick Internet Area Brian Haberman Ted Lemon Real-time Applications and Infrastructure Ricard Barnes Alissa Cooper Routing Area Alia Atlas Adrian Farrel Security Area Stephen Farrel Kathleen Moriarty Transport Area Spencer Dawkins Martin Stiemerling - - Chairs of WGs httpbis Mark Nottingham Do you think this is a good list to start with? I also drafted some questions for the interview, please let me know if you think these are the questions that will give us the best results. 1. What is your current role in the IETF, IRTF and/or surrounding environment and how has it changed over the years? # Of course this is part of our pre-research, but it's always interesting to hear how people self-define their position. 2. Which RFCs that you (co-)authorted do you deem the most relevant ones? 3. How useful do you think security considerations are in RFCs, and why are they important? 4. Do you see any relationship between security and human rights? Please elaborate. 5. Do you think the RFCs you (co-)authored could impact users rights, especially freedom of expression of freedom of assembly in a postive or negative way? 6. Do you think freedom of expression could be protected or enhanced on a protocol and/or standard level? If so, how? If not, why not? 7. Do you think the protocol and/or standard making process can be improved to safeguard the right to freedom of expression and/or the right to association? If so, how? 8. Can you point us at an RFC that you think is especially relevant for this research? 9. Do you have any suggestions on how we could proceed with this research= ? Looking forward to your comments. =09 Best, Niels - --=20 Niels ten Oever Head of Digital Article 19 www.article19.org PGP fingerprint 8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 68E9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJU2aRmAAoJEAi1oPJjbWjpXu4H+QGYgbWly5MKB/PJvMKLQGNA 8ubODHYTC8urH16+p90xr849oFPISOFgcZt3PxYQnNIrS/8j9iOV+QhSbM1vKmMs bvaTefJg9aQs6VqdhgA6hkFgaMfB7mFF/DQLfpk5tFbWwWiifm2qKAjTXYQH9Wh9 Ts0leAG8E4AkVG0XpDVnanXxpXOzNb4jbtCP/j5fUs+tzZhlGdJTiLZwFKrb7iCr 9PqVyCv/noPbZiu0J6t1PegC/Nza8LQ2450fv8TJmO26DqwWp5KIsyBDnVzWWfLu ndypqEhYnN2NSMu6mIkPqHbzwgXG6VjxCvSmJbVlCZ4GhZN9AAU2w9nCuDZi3aw=3D =3Dj5G+ -----END PGP SIGNATURE----- From lars@netapp.com Tue Feb 10 09:51:33 2015 Received: from [10.10.12.45] (helo=mx2.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YL6Xc-0003BI-LW for hrpc@article19.io; Tue, 10 Feb 2015 09:51:32 +0100 Received: from mx144.netapp.com ([216.240.21.25]) by mx2.greenhost.nl with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YL6Xb-0004Kv-PF for hrpc@article19.io; Tue, 10 Feb 2015 09:51:32 +0100 X-IronPort-AV: E=Sophos;i="5.09,549,1418112000"; d="asc'?scan'208";a="22344839" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx144-out.netapp.com with ESMTP; 10 Feb 2015 00:51:25 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 10 Feb 2015 00:51:23 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.0995.031; Tue, 10 Feb 2015 00:51:23 -0800 From: "Eggert, Lars" To: Niels ten Oever Thread-Topic: [hrpc] interviews @ IETF meeting in Dallas Thread-Index: AQHQRPqDmfbtpdtIvkaIN3G/v1mjMZzqGaEA Date: Tue, 10 Feb 2015 08:51:23 +0000 Message-ID: <8F374B80-84A7-44B7-B6AE-35BF216FAF26@netapp.com> References: <54D9A466.7030108@article19.org> In-Reply-To: <54D9A466.7030108@article19.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_7B18136B-0422-444D-BE73-2E2916FDEBD7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Spam-Level: ---- X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_HI, SPF_PASS, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.3 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: 8b3222cd26cce149ddb9ffa05c4da76e Cc: "hrpc@article19.io" Subject: Re: [hrpc] interviews @ IETF meeting in Dallas X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 08:51:33 -0000 --Apple-Mail=_7B18136B-0422-444D-BE73-2E2916FDEBD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2015-2-10, at 07:25, Niels ten Oever wrote: > - Head of IAB > - Chair of IETF > - Area Directors >=20 > Do you think this is a good list to start with? these folks are typically extremely busy during an IETF week, so you may = not be able to schedule time with very many of them. Can you do the interview by email? Lars --Apple-Mail=_7B18136B-0422-444D-BE73-2E2916FDEBD7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVNnGiNZcnpRveo1xAQJ8LAP/R9Ilen8SuYOagYL2Zn1K5z0juPY80m4l IeGBESJ1yE5HO0m/alg1oZnrR/ce9bQwQGbkXTqBrq/fPI2fhu2yL2cOmnnbpiNw tApsCmoPnVy9R2jU4ujwf0How8OXzRUgtqux94eRmHS2TjV58DAOMQ5sIzdBNAiU hfJd3o2buAI= =XmN5 -----END PGP SIGNATURE----- --Apple-Mail=_7B18136B-0422-444D-BE73-2E2916FDEBD7-- From niels@article19.org Tue Feb 10 09:58:57 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YL6en-0003D5-1J for hrpc@article19.io; Tue, 10 Feb 2015 09:58:57 +0100 Received: from vps784.greenhost.nl ([213.108.108.114] helo=mail.article19.io) by mx1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YL6em-0004Xq-OD for hrpc@article19.io; Tue, 10 Feb 2015 09:58:56 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id E8B42130028 for ; Tue, 10 Feb 2015 09:00:11 +0000 (UTC) X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.article19.io ([127.0.0.1]) by localhost (mail.article19.io [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Obz_wHhnl23L for ; Tue, 10 Feb 2015 09:00:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTP id 45F0914002F for ; Tue, 10 Feb 2015 09:00:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.article19.io 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 DlpZHYEMVT1I for ; Tue, 10 Feb 2015 09:00:11 +0000 (UTC) Received: from [10.196.197.150] (33-193.icannmeeting.org [199.91.193.33]) by mail.article19.io (Postfix) with ESMTPSA id 4CF03130028 for ; Tue, 10 Feb 2015 09:00:09 +0000 (UTC) Message-ID: <54D9C849.6060503@article19.org> Date: Tue, 10 Feb 2015 08:58:49 +0000 From: Niels ten Oever User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: "hrpc@article19.io" References: <54D9A466.7030108@article19.org> <8F374B80-84A7-44B7-B6AE-35BF216FAF26@netapp.com> In-Reply-To: <8F374B80-84A7-44B7-B6AE-35BF216FAF26@netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Level: + X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50, SPF_NEUTRAL autolearn=disabled version=3.3.2 X-Spam-Score: 1.6 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: dfea3049d3b923820beb462d65569822 Subject: Re: [hrpc] interviews @ IETF meeting in Dallas X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 08:58:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/10/2015 08:51 AM, Eggert, Lars wrote: > Hi, >=20 > On 2015-2-10, at 07:25, Niels ten Oever > wrote: >> - Head of IAB - Chair of IETF - Area Directors >>=20 >> Do you think this is a good list to start with? >=20 > these folks are typically extremely busy during an IETF week, so > you may not be able to schedule time with very many of them. >=20 > Can you do the interview by email? The initial idea was to film the interviews, which is of course not possible if we do it per email. Perhaps we could try to schedule the interview, and if they're unavailable do it per email? Best, Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJU2chJAAoJEAi1oPJjbWjp+SUIAKFVJYp8gxGq0wHdK9DQm7G3 uDWYT1wif4tWNsaHNpcPYptYqXTXUn/89WZRQoVveRV7Gkg7HHRUBlwwbF6Gpz1q AYmYB82S1B3cLaUOgd5oFGUNoNAV+foEIgBq3HEpe5QdQlQsdkqt4rLoeHhAnkNB fMWTdbB+sYnndRbKc+OevK75hgXg58yuFD8MIJnMM0IeFcgqZ0tUerv12r5Uai1D IB7wlkq4kk7rVLlfkskNDDJD1e3XukOjEQv9kubbIjxSVLcPFsLyzvOdBoqXRhz0 /iPO1AqBJh0+f4MjS1gYUK5BPgpXxYwynGUqq4GcZGTc7enX7LiP9Cjn4Q4FInc=3D =3DViDc -----END PGP SIGNATURE----- From lars@netapp.com Tue Feb 10 11:11:22 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from ) id 1YL7ms-0003M4-RI for hrpc@article19.io; Tue, 10 Feb 2015 11:11:22 +0100 Received: from mx141.netapp.com ([216.240.21.12]) by mx1.greenhost.nl with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YL7mp-0007jP-1C for hrpc@article19.io; Tue, 10 Feb 2015 11:11:22 +0100 X-IronPort-AV: E=Sophos;i="5.09,549,1418112000"; d="asc'?scan'208";a="22900266" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx141-out.netapp.com with ESMTP; 10 Feb 2015 02:11:16 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 10 Feb 2015 02:11:15 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.0995.031; Tue, 10 Feb 2015 02:11:15 -0800 From: "Eggert, Lars" To: Niels ten Oever Thread-Topic: [hrpc] interviews @ IETF meeting in Dallas Thread-Index: AQHQRPqDmfbtpdtIvkaIN3G/v1mjMZzqGaEAgAACF4CAABQ8AA== Date: Tue, 10 Feb 2015 10:11:14 +0000 Message-ID: <431A8C49-EB38-48F7-B9D1-CAA0ED784109@netapp.com> References: <54D9A466.7030108@article19.org> <8F374B80-84A7-44B7-B6AE-35BF216FAF26@netapp.com> <54D9C849.6060503@article19.org> In-Reply-To: <54D9C849.6060503@article19.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_B9DBA9C6-A326-4D2A-A6E9-4276D72E5039"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Spam-Level: ---- X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_50, RCVD_IN_DNSWL_HI, SPF_PASS, T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 X-Spam-Score: -4.3 X-Virus-Scanned: by Greenhost Virus Scanner X-Scan-Signature: a350ae07b5350cdad28cef237d2e7179 Cc: "hrpc@article19.io" Subject: Re: [hrpc] interviews @ IETF meeting in Dallas X-BeenThere: hrpc@article19.io X-Mailman-Version: 2.1.13 Precedence: list List-Id: Human Rights Protocol Consideration Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 10:11:23 -0000 --Apple-Mail=_B9DBA9C6-A326-4D2A-A6E9-4276D72E5039 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2015-2-10, at 09:58, Niels ten Oever wrote: > > The initial idea was to film the interviews, which is of course not > possible if we do it per email. You might be able to record Skype or Webex interviews. Lars --Apple-Mail=_B9DBA9C6-A326-4D2A-A6E9-4276D72E5039 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVNnZQtZcnpRveo1xAQIAvwQAhkU5aM/uEfaaqRBf5tU2QtVIrJttfIlp gnJvD6VvrxlYjUWspXzmbQ7LPeTzSMrsTnZp7yWp7AxIoqKlpVTxHprGgpl0yQ4T kET4wntZSN7zmvKJ8DHDJ5hk1iK/Y+0CNCFwdbYXxuokCnNqITmUtkaLZBV511YZ sOIhlIdhmAE= =ladF -----END PGP SIGNATURE----- --Apple-Mail=_B9DBA9C6-A326-4D2A-A6E9-4276D72E5039-- From avri@acm.org Thu Feb 26 06:40:58 2015 Received: from mx1.lan ([10.10.12.44] helo=mx1.greenhost.nl) by mailman.lan with esmtp (Exim 4.72) (envelope-from