[hrpc] new draft text for the ID

[Niels ten Oever <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

Based on the traffic on this list, some interviews and discussions I
drafted new text for the ID. The additions are to 2. research topic
and 3. Proposal. I pasted the proposed text underneath, happy to discuss.

The deadline for sending in the ID is the 9th, and since we will also
need to consolidate the comments and put the ID in XML it would be
greatly appreciated if you could comment in the coming days (before
the 7th) so we can still integrate your comments in the ID, but of
course also happy to discuss afterwards and in Dallas.

Looking forward to your comments, questions and suggestions.

Best,

Niels

PS The original ID can be found here:
https://tools.ietf.org/html/draft-doria-hrpc-proposal-00

2.  Research topic
In a manner similar to the work done for RFC 6973 [RFC6973] on Privacy
Consideration Guidelines, the premise of this research is that some
standards and protocols can solidify, enable or threaten human rights,
such as freedom of expression and the right to association and
assembly online.

RFC 6973 however asserts privacy as a subset of security, and security
aims to solely serve growth of the network and communication:

Development of security mechanisms is seen as a key factor in the
future growth of the Internet as a motor for international commerce
and communication.[RFC1984]  and according to the Danvers Doctrine,
there  is an overwhelming  consensus in the IETF that the best
security  should be used and  standardized.[RFC3365]. At the same time:

The  Internet Architecture Board (IAB) and the Internet Engineering
Steering  Group (IESG), the bodies which oversee architecture and
standards for  the Internet, are concerned by the need for increased
protection of  international commercial transactions on the Internet,
and by the need  to offer all Internet users an adequate degree of
privacy. [RFC1984]

This  shows that security and privacy are very high on the agenda of
the  IETF, but a reason for this, outside of underpinning growth and
trust of  the network, is not given. In this research it is argued
that security and privacy are (contributing to) essential human
rights; such as freedom of expression, the right to information, the
right to  privacy, and the right to security.

The Internet aims to be a global network of network that provides
connectivity to all its users, just like the Universal Declaration of
Human Rights provides rights to all citizens. This makes a clear case
that the Internet is not only an enabler of human rights, but that
human rights, lie at the basis of, and is ingrained in, the network.
Furthermore  interview will be done with  the chair of the Internet
Architecture  Board (IAB), members of the  Internet Engineering
Steering Group (IESG)  and chairs of selected  working groups and RFC
authors.

To start addressing the issue, a mapping exercise analyzing Internet
architecture and protocols features, vis-a-vis possible impact on
human rights needs to be
undertaken.

[snip, leaving the examples in place]

3.  Proposal
Mapping the relation between human rights and protocols and
architectures is a new research challenge, which will require a good
amount of cross organizational cooperation to develop a consistent
methodology.  While the authors of this first draft are involved in
both human rights advocacy and research on Internet technologies - we
believe that bringing this work into the IRTF would facilitate and
improve this work by bringing human rights experts together with the
community of researchers and developers of Internet standards and
technologies.

At this point we have created a mailing list where we would like to
encourage discussion of the issue and capture interest of the IRTF
community.  A second step would be to create a charter and ask the
IRTF for a Research group to further develop methodology and
investigate Human rights Protocol considerations.

Assuming that the research produces useful results, the objective
would evolve into the creation of a set of recommended considerations
for the protection of applicable human rights.

In the  analysis of existing RFCs central design and technical
concepts have been found which impact human rights. These concepts
will form the lens for the analysis of RFCs and will be further
described vis a vis their impact on human rights.

The current working assumption is the following:

The  combination of content agnosticism, connectivity, security (as
defined in RFC 3365) [RFC3365] and privacy (as defined in RFC 6973)
[RFC6973] are the technical principles that underly freedom of
expression on the Internet.

Privacy and security are defined, so here we focus on concepts that
have not been defined as considerations that are relevant for freedom
of expression.

This is a non-exhaustive first list of concepts, which definitions
should be improved and further aligned with existing RFCs.

Connectivity
The Internet is the tool for providing global connectivity conform
RFC1958. Therefore all protocols and standards should aim to improve
connectivity, and not to limit it.

Distributed
To  enable and strengthen connectivity, stability, and sustainability
of  the network, protocols and standards should be developed in a way
that  they can be implemented in a distributed way, if not, strong
accountability mechanism should be in place.

Inter-operable
Standards exist to design systems that allow for other systems to
interact freely and openly.

Reliable
Reliability ensures that a protocol will execute its function
consistently and  error resistant as described and function without
unexpected result, also when there is an increase or decrease of
throughput. A system that is reliable will have a documented way to
recover from failure.

Scalable
Any  solution should support growth of the network with more hosts,
users and traffic. And have clear understanding of it's scope and
ideally a proposition how it can be expanded in order to support
greater capacity.

Stateless / state-full
If  possible protocols should be implemented stateless for reliability
and privacy considerations. If not, they should keep as little state
as possible.

Content agnostic
Protocols should not treat packets/datagrams differently based on
their content.

Transparent
Protocols should be transparent in what they can do and can not do and
how it is  done. Implementation of protocols should advertise it's
policies on data retention for the service and which jurisdiction it
falls under.

Debugging
A protocol should allow a user to troubleshoot and debug possible
causes of malfunction and loss of reliability.

Robust, robustness
Protocols should be resistant to errors, involuntary legal or
malicious attempts  to disrupt its mode of operations. Protocols
should be developed in a  way that there is no (intransparent) kill
switch. There should also be a clear description on how a protocol
recovers from potential failures.

End user-centric / representing  stakeholder rights
As proposed in draft-nottingham-stakeholder-rights-00:

[QUOTE]
Protocols MUST document relevant primary stakeholders and their
interrelationships.

[..]

 End-user-facing application protocols MUST prioritise their users
higher than any other stakeholders.
Extensions to existing protocols MUST document how they interact with
the extended protocol's stakeholders.  If the extended protocol's
stakeholders are not yet documented, the extension MAY estimate its
impact, in coordination with that protocol's community and the IESG.
The burden of this documentation need not be high; if HTML can do it
in a paragraph, so can most protocols.  While it might be appropriate
in a separate document (e.g., a requirements or use cases draft) or
the protocol specification itself, documenting stakeholders in the WG
charter has considerable benefits, since it clarifies their
relationships up-front.

[/QUOTE]


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

iQEcBAEBAgAGBQJU9bXVAAoJEAi1oPJjbWjpeKEH/3MhfM1yFG2aJf4/8ZBWwQtA
rlb0iVw2mCeA9RsulzgkU7cZC3dh+24PIVsX0DmiaCJtk7YJbCzI8wQtvm8b2aD0
PnQzRbkCGHxpPKLP+GkuNr2iQCdWQ6YoY68g8up26jHco9DUaTIOw9zGFV4lApu3
d2/9DvyrF/d2lgO17c9vFVmAoE+wWdlE1CMRV2SDGcbz9Fb9xSntnJ5/+SXkNpQ+
24BaCk73xK88mRqvk/HLUO3GCoDd3ytM5KuU0X4hQOoLVWOpyQaVOadtLQbLkNNX
GB1NIalgs8ivK+8PXn4fsbKMCYLR3HcSDIzC/uiICRciznu0G82v49pZYYAVt+Y=
=DKrF
-----END PGP SIGNATURE-----