Subject: Re: [hrpc] draft ID Human Rights Protocol Considerations Glossary (hrpcg)

From: Niels ten Oever <[email-masked]>
Date: Wed, 01 Jul 2015 21:54:37 +0200

Hi Adamantia,

Thank you for your extensive email and sorry for my late response.
Please allow me to reply in line:

On 06/26/2015 09:24 PM, Adamantia Rachovitsa wrote:ank
> Hi all. Thanks for all this work. A few thoughts on the documents
> and emails that Niels circulated:
> 
> 
> 
> 1. I don’t think that the (theoretical) debate on encoding values
> into protocols is very useful as a starting point. It is of course 
> informative for members of the technical, social and legal
> communities in order to have a broader perspective on things. But
> my understanding is that for the purposes of the present work
> nobody is talking about encoding values into protocols. It would be
> a mistake to frame it as such and to promote it like this to the
> technical community. The issue at stake is what is the impact of
> protocols on human rights (interaction, enable, hinder etc). In
> other words we are trying to enable the technical community to
> recognize (adverse) human rights impacts. When they are in position
> to do that they will be able to take this impact into consideration
> when creating and updating protocols alongside many other factors
> with possible ‘’trade-offs’’. Therefore this discussion is not
> about encoding freedom of association or freedom of expression into
> the protocols but rather taking into account the possible impact of
> the protocols to human rights. The critical question is can, and
> should, the engineers do this? The answer is simply yes: Internet
> standards are adopted not only on the basis of their technical 
> quality but also following an assessment of the interests of all 
> affected parties as well as the specification’s contribution to
> the Internet [e.g. S. Bradner, (October 1996), The Internet
> Standards Process – Revision 3, RFC 2026, Best Current Practice 9,
> at 2].
> 
> 
> 
> The momentum of this work is great following the privacy
> considerations. I do think however that things with privacy were
> easier in the sense that engineers were already aware of its value
> to their work. Things with other human rights could be trickier and
> so we need to be convincing about the impact | link | relevance to
> the interests of all affected parties and the contribution to the
> Internet.
> 

Was this a direct reaction to the draft or to the minutes? I don't
think we disagree.

I hope that the methodology that Joana and Corinne have been working
on can also shed more light on this.

> 
> 
> 2. Developing a vocabulary and language
> 
> 
> 
> I agree that there is a need for a basic vocabulary before
> developing considerations. We should not see this exhaustively
> however. I think there will be lots of work in progress while
> developing the considerations and subsequently.
> 
> 
> 
> I understand that the aim is to give the engineers the language to
> talk about rights. But what do you mean in the minutes by
> ''reverse translation''? Translating the technical concepts outside
> the technical community? If yes, it opens up the scope of work a
> lot but there might be a good point. I am not sure if it is
> possible to develop a shared vocabulary unless we try to
> ‘translate’ both ways.
> 
> 

That is exactly what was meant with reverse translating.

> 
> I agree in general with the visualization of what the freedom of 
> expression is in page 4 of the Glossary draft. There are however
> many nuances within this sketch. I hope this is the starting point
> of the discussion. For example, freedom of expression as a human
> right is not entirely ‘content agnostic’. In principle, all types
> of speech fall within the scope of the freedom of expression
> (commercial speech, political speech, pornography, hate speech) but
> they are accorded different levels of protection subject to whether
> legitimate, necessary and proportionate limitations come into play.
> 
Agree, but can this ever be decided technically? If not, the system
should not make a decision, hence this technical definition.

But I might agree with you that this is not a definition, but rather a
pre-condition.

> Also, in the online environment privacy mostly ensures freedom of
> expression

Disagree, please elaborate.

> – but we cannot deny that there can be tensions between the two. In
> this sense the sketch describes an ideal condition but we need to
> elaborate further in order to contextualize the vocabulary both
> from a human rights and a technical point of view.
> 

Excellent, looking forward to suggestions.

> 
> I include in the document attached some other possible concepts | 
> keywords for the RFC’s analysis and some terms and notes that I
> keep in my record that could be relevant to developing the
> glossary.
> 

Thanks for this as well. I added the concepts under 1. to the RFC
search list

I am not sure what you would like me to do with the concepts mentioned
under 2., since I think these are mostly quotes from RFC, right? Is
your suggestions that we add Interoperability, Quality, Relevance,
Evolving System and Internet Standards as an Arena for Conflict to the
glossary?

I think it will be hard to define some of these terms, but we can give
it a try. Would you help us start off with some definitions for these
terms?

Best,

Niels

> 
> Best,
> 
> Adamantia
> 
> 
> 
> On 21 June 2015 at 20:30, Niels ten Oever <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Dear all,
> 
> Please find one of the draft IDs on which we worked during the
> interim meeting and afterwards underneath (and also attached in
> markdown).
> 
> Happy reading and commenting. Am greatly looking forward to your 
> comments and/or additions.
> 
> Best,
> 
> Niels
> 
> --- abstract
> 
> This document presents a glossary of terms used to map between 
> concepts common in human rights discussions and engineering 
> discussions.  It is intended to facilitate work by the proposed
> Human Rights Protocol Considerations research group, as well as
> other authors within the IETF.
> 
> --- middle
> 
> 
> Introduction ============
> 
> "There's a freedom about the Internet: As long as we accept the 
> rules of sending packets around, we can send packets containing 
> anything to anywhere."
> 
> {{Berners-Lee}}
> 
> The Human Rights Protocol Consideration Proposed Research Group
> aims to research whether standards and protocols can enable,
> strengthen or threaten human rights, as defined in the Universal
> Declaration of Human Rights {{UDHR}} and the International Covenant
> ons Civil and Political Rights {{ICCPR}}, specifically, but not
> limited to the right to freedom of expression and the right to
> freedom of assembly.
> 
> Comunications between peple working on human rights and engineers 
> working on Internet protocols can be improved with a shared
> vocabulary.
> 
> This document aims to provide a shared vocabulary to facilitate 
> understanding of the intersection between human rights and
> Internet protocol design.
> 
> Glossary ========
> 
> In the analysis of existing RFCs central design and technical
> concepts have been found which impact human rights.  This is an
> initial glossary of concepts that could bridge human rights
> discourse and technical vocabulary. These definitions should be
> improved and further aligned with existing RFCs.
> 
> Accessibility : Full Internet Connectivity as described in
> {{RFC4084}} to provide unfettered access to the Internet
> 
> : The design of protocols, services or implementation that provide
> an enabling environment for people with disabilities.
> 
> : The ability to use information found on the Internet
> 
> Connectivity : The Internet is the tool for providing global
> connectivity {{RFC1958}}. It is the ability to either send and or
> receive packets.
> 
> Content-agnosticism : Treating packets identically regardless of
> their user content.
> 
> Distributed : A distributed architecture is a system in which not
> all processes reside in a single host.
> 
> Decentralized : Opportunity for implementation of standards or
> protocols without a single point of control.
> 
> Federation : The possibility of of transparently connecting
> autonomous systems into a single service
> 
> Inter-operable : A property of a documented standard or protocol
> which allows different implementations to work with each other
> without any restricted access or negotiation.
> 
> Reliable : Reliability ensures that a protocol will execute its
> function consistently and error resistant as described and function
> without unexpected result. A system that is reliable degenerates
> gracefully and will have a documented way to announce degradation.
> It also has mechanisms to recover from failure gracefully, and if
> applicable allow for partial healing.
> 
> Open standards : Conform  {{RFC2606}}: Various national and
> international standards bodies, such as ANSI, ISO, IEEE, and ITU-T,
> develop a variety of protocol and service specifications that are
> similar to Technical Specifications defined here.  National and
> international groups also publish "implementors' agreements" that
> are analogous to Applicability Statements, capturing a body of
> implementation-specific detail concerned with the practical
> application of their standards.  All of these are considered to be
> "open external standards" for the purposes of the Internet
> Standards Process.
> 
> Scalable : There should be a clear definition of its scope and
> applicability. The limits of a systems scalability should be
> defined.
> 
> Stateless / stateful : In computing, a stateless protocol is a
> communications protocol that treats each request as an independent
> transaction that is unrelated to any previous request so that the
> communication consists of independent pairs of request and
> response. A stateless protocol does not require the server to
> retain session information or status about each communications 
> partner for the duration of multiple requests. In contrast, a
> protocol which requires keeping of the internal state on the server
> is known as a stateful protocol. {{WP-Stateless}}
> 
> Transparent: : "transparency" refers to the original Internet
> concept of a single universal logical addressing scheme, and the
> mechanisms by which packets may flow from source to destination
> essentially unaltered. {{RFC2775}}
> 
> Debugging: : Debugging is a methodical process of finding and
> reducing the number of bugs, or defects, or malfunctions in a
> protocol or its implementation, thus making it behave as expected
> and analyse the consequences that might have emanated from the
> error. Debugging tends to be harder when various subsystems are
> tightly coupled, as changes in one may cause bugs to emerge in
> another. {{WP-Debugging}}
> 
> End-to-End : One of the key architectural guidelines of the
> Internet is the end-to-end principle in the papers by Saltzer,
> Reed, and Clark {{Saltzer}} {{Clark}}. The end-to-end principle was
> originally articulated as a question of where best not to put
> functions in a communication system. Yet, in the ensuing years, it
> has evolved to address concerns of maintaining openness, increasing
> reliability and robustness, and preserving the properties of user
> choice and ease of new service development as discussed by
> Blumenthal and Clark in {{Blumenthal}}; concerns that were not part
> of the original articulation of the end-to-end principle.
> {{RFC3724}}
> 
> Internationalization : The practice of the adaptation and
> facilitation of protocols, standards, and implementation to
> different languages.
> 
> Openness : The quality of the unfiltered Internet that allows for
> free access to other hosts
> 
> Permissionless innovation :  The freedom and ability of to freely
> create and deploy new protocols on top of the communications
> constructs that currently exist
> 
> Privacy : Please see {{ RFC6973 }}
> 
> Confidentiality : The non-disclosure of information to any
> unintended person or host or party
> 
> Integrity : Maintenance and assurance of the accuracy and
> consistency of data to ensure it has not been (intentionally or
> unintentionally) altered
> 
> Anonymity : The fact of not being identified
> 
> Authenticity : The act of confirming the truth of an attribute of a
> single piece of data or entity.
> 
> Robust : The resistance of protocols and their implementations to
> errors, and to involuntary, legal or malicious attempts to disrupt
> its mode of operations.
> 
> The combination of reliability, resilience, anonymity and
> authenticity is what makes up security on the Internet
> 
> ( Reliability  ) security =  (  Resilience    ) (  Integrity     ) 
> (  Authenticity  ) ( Anonymity    )
> 
> The combination of content agnosticism, connectivity, security,
> privacy (as defined in {{RFC6973}}, and open standards are the
> technical principles that underlay freedom of expression on the
> Internet.
> 
> 
> 
> (  ( End-to-End      )               ) (  (  Interoperability )
> ) (   (  Resilience       )  Connectivity  ) (   (  Reliability
> )                )   = freedom of expression (    ( Robustness
> )                 ) (              Privacy                   ) (
> Security                  ) (             Content agnosticism
> ) (            Open Standards          )
> 
> 
> 
> -- Niels ten Oever Head of Digital
> 
> Article 19 www.article19.org <http://www.article19.org>
> 
> PGP fingerprint    8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D
> 68E9
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] <mailto:[email-masked]> 
> https://www.irtf.org/mailman/listinfo/hrpc
> 
>

---

From: Tim Sammut <[email-masked]>
Date: Wed, 01 Jul 2015 23:19:42 +0100

Hi Niels, everyone.

I have included some thoughts below for your consideration. Please feel
free to question, use or ignore as you see fit. Thanks!

hope you are well
tim

-- 
Tim Sammut ~ @t1msammut ~ [email-masked]

On 06/21/2015 06:30 PM, Niels ten Oever wrote:
> Dear all,
> 
> Please find one of the draft IDs on which we worked during the interim
> meeting and afterwards underneath (and also attached in markdown).
> 
> discussions.  It is intended to facilitate work by the proposed Human
> Rights Protocol Considerations research group, as well as other
> authors within the IETF.
> 
> --- middle
> 
> 
> Introduction
> ============
> 
> The Human Rights Protocol Consideration Proposed Research Group aims
> to research whether standards and protocols can enable, strengthen or
> threaten human rights, as defined in the Universal Declaration of
> Human Rights {{UDHR}} and the International Covenant ons Civil and
> Political Rights {{ICCPR}}, specifically, but not limited to the
> right to freedom of expression and the right to freedom of assembly.
> 
> working on Internet protocols can be improved with a shared vocabulary.
> 

Sorry for the nits, "Comunications between peple" should be
"Communications between people"

> understanding of the intersection between human rights and Internet
> protocol design.
> 
> Glossary
> ========
> 
> In the analysis of existing RFCs central design and technical concepts
> have been found which impact human rights.  This is an initial glossary
> of concepts that could bridge human rights discourse and technical
> vocabulary. These definitions should be improved and further aligned
> with existing RFCs.
> 
> Accessibility
> : Full Internet Connectivity as described in {{RFC4084}} to provide
> unfettered access to the Internet
> 
> : The design of protocols, services or implementation that provide an
> enabling environment for people with disabilities.
> 

Should "use" in the last definition be a verb that doesn't require
comprehension of the information accessed? Perhaps:

    The ability to receive information available on the Internet

> Connectivity
> : The Internet is the tool for providing global connectivity
> {{RFC1958}}. It is the ability to either send and or receive packets.
> 

Would a definition like this be worth adding?

    The extent to which a device or network is able to reach other
    devices or networks to exchange data

> Content-agnosticism
> : Treating packets identically regardless of their user content.
> 

Another nit-picky comment, but I would suggest:

    Treating network traffic identically regardless of content

Packets are layer 3 entities, but we also care about frames, segments,
messages, etc, and some content may not have a user such as between two
devices

> Distributed
> : A distributed architecture is a system in which not all processes
> reside in a single host.
> 

Maybe s/processes/components/ and s/host/computer/ ?

The word "process" means something specific to technical people,
something else along-side "procedures", and I think we really mean
"something that isn't completely contained on one computer".

> Decentralized
> : Opportunity for implementation of standards or protocols without a
> single point of control.
> 

I am not sure if they are relevant here, but should we add "applications
and systems" or generalize it to "items" or "systems" ?

> Federation
> : The possibility of of transparently connecting autonomous systems into
> a single service

Is transparency a requirement for federation? I don't know that it is. I
would also suggest using "a single distributed system" instead of "a
single service".

> 
> Inter-operable
> : A property of a documented standard or protocol which allows different
> implementations to work with each other without any restricted access or
> negotiation.
> 

Perhaps, "...without restricted negotiation, access or functionality" ?

> Reliable
> : Reliability ensures that a protocol will execute its function
> consistently and error resistant as described and function without
> unexpected result. A system that is reliable degenerates gracefully and
> will have a documented way to announce degradation.  It also has
> mechanisms to recover from failure gracefully, and if applicable allow
> for partial healing.
> 
> Open standards
> : Conform  {{RFC2606}}: Various national and international standards
> bodies, such as ANSI,
>       ISO, IEEE, and ITU-T, develop a variety of protocol and service
>       specifications that are similar to Technical Specifications
>       defined here.  National and international groups also publish
>       "implementors' agreements" that are analogous to Applicability
>       Statements, capturing a body of implementation-specific detail
>       concerned with the practical application of their standards.  All
>       of these are considered to be "open external standards" for the
>       purposes of the Internet Standards Process.
> 
> Scalable
> : There should be a clear definition of its scope and applicability.
> The limits of a systems scalability should be defined.
> 

Perhaps: The ability to handle increased or decreased workloads
predictably within defined expectations.

> Stateless / stateful
> : In computing, a stateless protocol is a communications protocol that
> treats each request as an independent transaction that is unrelated to
> any previous request so that the communication consists of independent
> pairs of request and response. A stateless protocol does not require the
> server to retain session information or status about each communications
> partner for the duration of multiple requests. In contrast, a protocol
> which requires keeping of the internal state on the server is known as a
> stateful protocol. {{WP-Stateless}}
> 

Do we also need to describe stateful and stateless devices?

> Transparent:
> : "transparency" refers to the original Internet concept of a single
> universal logical addressing scheme, and the mechanisms by which packets
> may flow from source to destination essentially unaltered. {{RFC2775}}
> 
> Debugging:
> : Debugging is a methodical process of finding and reducing the number
> of bugs, or defects, or malfunctions in a protocol or its
> implementation, thus making it behave as expected and analyse the
> consequences that might have emanated from the error. Debugging tends to
> be harder when various subsystems are tightly coupled, as changes in one
> may cause bugs to emerge in another. {{WP-Debugging}}
> 

I think we should have another definition that centers on the
troubleshooting process for a single issue. Perhaps:

    The process through which people troubleshoot a technical issue,
    which may include inspection of program source code or device
    configurations.

> End-to-End
> : One of the key architectural guidelines of the Internet is the
> end-to-end principle in the papers by Saltzer, Reed, and Clark
> {{Saltzer}} {{Clark}}. The end-to-end principle was originally
> articulated as a question of where best not to put functions in a
> communication system. Yet, in the ensuing years, it has evolved to
> address concerns of maintaining openness, increasing reliability and
> robustness, and preserving the properties of user choice and ease of new
> service development as discussed by Blumenthal and Clark in
> {{Blumenthal}}; concerns that were not part of the original articulation
> of the end-to-end principle. {{RFC3724}}
> 

It doesn't feel like this explains the concept to laypeople ;). Perhaps:

    The principal of extending characteristics of a protocol or system
    as far as possible within the system. For example, end-to-end
    instant message encryption would conceal communications from one
    user's instant messaging application through any intermediate
    devices and servers all the way to the recipient's instant
    messaging application. If the message was decrypted at any
    intermediate point--for example at a service provider--then the
    property of end-to-end encryption would not be present.

> Internationalization
> : The practice of the adaptation and facilitation of protocols,
> standards, and implementation to different languages.
> 
> Openness
> : The quality of the unfiltered Internet that allows for free access to
> other hosts
> 
> Permissionless innovation
> :  The freedom and ability of to freely create and deploy new protocols
> on top of the communications constructs that currently exist
> 
> Privacy
> Confidentiality
> : The non-disclosure of information to any unintended person or host or
> party
> 
> Integrity
> : Maintenance and assurance of the accuracy and consistency of data to
> ensure it has not been (intentionally or unintentionally) altered
> 
> Anonymity
> Authenticity
> : The act of confirming the truth of an attribute of a single piece of
> data or entity.
> 
> Robust
> : The resistance of protocols and their implementations to errors, and
> to involuntary, legal or malicious attempts to disrupt its mode of
> operations.
> 
> The combination of reliability, resilience, anonymity and authenticity
> is what makes up security on the Internet

We have not defined "resilience".

> 
> 	     ( Reliability  ) 	
> security =  (  Resilience    )	
>   	    (  Integrity     )
> 	    (  Authenticity  )
> 	     ( Anonymity    )
> 
> The combination of content agnosticism, connectivity, security, privacy
> (as defined in {{RFC6973}}, and open standards are the technical
> principles that underlay freedom of expression on the Internet.
> 
> 
> 
>   (  ( End-to-End      )               )
>  (  (  Interoperability )               )
> (   (  Resilience       )  Connectivity  )
> (   (  Reliability      )                )   = freedom of expression
> (    ( Robustness      )                 )
> (              Privacy                   )
> (              Security                  )
>  (             Content agnosticism      )
>   (	       Open Standards          )
> 
> 
> 

I like the idea with the illustrations; but should we also build ones
for other rights, or perhaps include this as an explicit example?

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 03 Jul 2015 11:15:57 +0200

Hi Tim,

This is great, I made a new version (attached) and here [0]

comments inline:

[0] https://github.com/nllz/IRTF-HRPC/blob/master/draft-glossary.md

On 07/02/2015 12:19 AM, Tim Sammut wrote:
> -- Tim Sammut ~ @t1msammut ~ [email-masked] On 06/21/2015 06:30 PM,
> Niels ten Oever wrote:
>> > Dear all,
>> > 

Great, thanks!

>     The ability to receive information available on the Internet

Looks like a great addition to me.

>     devices or networks to exchange data

Much better than the current last sentence. Adding that.

> messages, etc, and some content may not have a user such as between two

Great, added.

> "something that isn't completely contained on one computer".

Not sure if I completely capture your suggestion, what would you suggest?

> and systems" or generalize it to "items" or "systems" ?

How / where would you like to add this, and why?

> would also suggest using "a single distributed system" instead of "a

Agree, added.

> Perhaps, "...without restricted negotiation, access or functionality" ?

Agree, added.

> predictably within defined expectations.

Great, added.

> Do we also need to describe stateful and stateless devices?

Perhaps we stick to protocols here?

>     which may include inspection of program source code or device

Added as another list definition.

>     property of end-to-end encryption would not be present.

Added as list definition

> We have not defined "resilience".

Will try to squeeze that in, in the next version.

> for other rights, or perhaps include this as an explicit example?

The idea is that with this glossary we can build more, especially
looking forward to do freedom of assembly next.

Thanks a million, really appreciated.

Best,

Niels

---

From: Tim Sammut <[email-masked]>
Date: Fri, 03 Jul 2015 12:13:47 +0100

Hi Niels.

Great, I am glad it helps. A couple of responses below.

> Not sure if I completely capture your suggestion, what would you suggest?

I think changing it to this would make it more clear:

    A distributed architecture is a system in which not all components
    reside in a single computer.

> How / where would you like to add this, and why?

Sorry I see now that that wasn't clear. I was suggesting to make the
definition a bit broader. Perhaps something like:

  Opportunity for implementation of standards, protocols, and systems
  without a single point of control.

> Perhaps we stick to protocols here?

Fair enough! Thanks.

hope you are well
tim

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 05 Jul 2015 01:38:26 +0700

Hello all,

Thanks for the suggestions Tim. I integrated them, added a definition
for resilience and put the terms in alphabetical order.  Please find the
draft attached.

If there are no further suggestions I will submit the draft tomorrow
evening.

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

---

From: Adamantia Rachovitsa <[email-masked]>
Date: Sun, 5 Jul 2015 10:45:36 +0300

Thanks Niels. Please find some responses below.

OK. Is this supposed to take place in the Glossary draft or another
document?

I agree - I think that decisions on a technical level can not /should not
accommodate the human rights point of view. Network remains
content-agnostic on a technical level. But this is something that should be
explained to the non-technical communities. For example, that freedom of
communications on an Internet protocols level is not subject to limitations
or 'trade-offs'.

My take on this is that offline freedom of expression and privacy are
almost always in tension (privacy as a possible limitation to expression).
Online however things are different. Privacy enhancing measures and the
IETF's contemporary work on stepping up privacy & security (authentication,
preserving anonymity, encryption etc) strengthen the effective exercise of
freedom of expression online. In this way, these technical decisions
solidify both the right to privacy and freedom of expression.
Schematically speaking the technical community decided to protect the
user's privacy in order to preserve the trust to the network and this
(unintentionally?) secures the conditions for expressing freely online.
[Privacy --- Trust --- Right to freedom of expression]. This is the
ordinary functioning of the network, as I see it.
There are instances of course that privacy may be in tension with
expression.

Excellent, looking forward to suggestions.
Sure. I need to see first what kind of examples you wish to discuss. I can
then try to provide context from human rights law.
That said, and since many people mention the 'balancing' buzzword, it
should be explain on the one hand how 'trade-offs' take place in
standardization process (and what are the factors considered as relevant)
and on the other hand what 'balancing' means in the human rights law
context. If you agree with this, I can try drafting something.

Right. I gave it a go but I understand that the text below is a bit
creative and not exactly a definition:

Quality of Internet standards and relevance of human rights considerations
in the standardization process

Pursuant to the principle of constant change, since the function and scope
of the Internet evolves, so does the role of the IETF in developing
standards. Internet standards are adopted on the basis of a series of
criteria, including high technical quality, support by community consensus,
and their overall benefit to the Internet. The latter calls for an
assessment of the interests of all affected parties and the specifications’
impact on the Internet’s users. In this respect, the effective exercise of
the human rights of the Internet users is a relevant consideration that
needs to be  appreciated in the standardization process insofar as it is
directly linked to the reliability and core values of the Internet.

[See B. Carpenter, ed., (June 1996), Architectural Principles of the
Internet, RFC 1958, Informational; H. Alvestrand, (October 2004), A Mission
Statement for the IETF, Best Current Practice 95, RFC 3935; S. Bradner,
(October 1996), The Internet Standards Process – Revision 3, RFC 2026, Best
Current Practice 9; J. Kempf, R. Austein, eds, (March 2004) The Rise of the
Middle and the Future of the End-to-End: Reflections on the Evolution of
the Internet Architecture, IAB, RFC 3724, Informational; B. Carpenter, ed.,
(June 1996), Architectural Principles of the Internet, RFC 1958,
Informational]

On 1 July 2015 at 22:54, Niels ten Oever <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Adamantia,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVlEV9AAoJEAi1oPJjbWjp0iMH/1RilIgk+P5yy2OiWWvJdSze
> ri+9WFNjVfTbX6JHcQBPPYx22tCu5vIcFt7hj/QydR7KLuM5X7qjudqqUlc20tWo
> CrZhANhEv5b6pteYIr7JpWg6avbPiV+Itx5g3wmj4T8iFPTO0RI0zqb1mysDHyoW
> PCccfhcLIvX4ah6JB+1TXWruIHxST0nzJIkVKCFHxun3WafgH+FfyGtKMHk1X/cH
> 9RfZk9Y2wYoXL2XgKwe9ZzLiZEbN5nLCnIv15n1pnGPgVI+xaVJWjypWiK8jkMWN
> d9GlbnAyAvEpa8XWxKitXgQIdQ0aAksegwuQELnDk9L8wnGhdXR7VtLzTRmkWvU=
> =r7Ix
> -----END PGP SIGNATURE-----
>