Re: [hrpc] Technical remarks on draft-doria-hrpc-proposal-00

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

Dear Stephane,

Thank you very much for you reaction and excuse me for my late
response. Further reply inline:

On 11/14/2014 06:39 AM, Stephane Bortzmeyer wrote:
> [Most of the remarks here have been done AFK at the Security Area
> Open Meeting during IETF 91 in Honululu. I repeat them here
> because sometimes oral remarks, like UDP packets, are lost in
> transit.]
> 

Thanks a lot, it gave me more time to chew on this, and it's also
great for the archive and the people that were not there.

> I first suggest that this work inside IETF/IRTF is certainly
> welcome and useful but we should also clearly state in the draft
> that we recognize that, today, the problem is, most of the time,
> not in the protocols (IETF/IRTF activity) but in software,
> architecture and business. For instance, to have full access to
> email (access being a HR), whatever your native language, fully
> internationalised email addresses are certainly necessary. All the
> standards exist (RFC 6530 and its friends) but their deployment is
> very limited (except in Asia). So, there is certainly work to do,
> but it is not IETF/IRTF work, it is implementation and deployment.
> 

True, but since we're doing this at the IETF and to keep the topic
manageable, I think we'll limit ourselves to protocols and standards,
but the relation to deployment and implementation can be made.

> Section 2.1 of the draft could use some corrections. (By the way, 
> there is no section 2.2: what was the idea?)
> 

In an earlier version there were other headings and order, we'll
correct this in the next version.

> 2.1.3 is titled "HTML" why it should be "HTTP". But there is more 
> important.

Very true, we'll change this in the next version. Thanks!

> The draft observes rightly that "Websites made it extremely easy
> for individuals to publish their ideas, opinions and thoughts." But
> it does not imply that it comes from specific properties of HTTP.
> Said otherwise, if we replaced HTTP with FTP or Gopher, what would
> be different, from the point of view of HR?

HTTP is the application protocol that forms the foundation web, and is
therefore a crucial protocol for showing websites, which have become
crucial for freedom of expression.

Gopher and FTP are indeed other important protocols, that enable many
crucial services. We chose http here because it relates more to the
experience of the end-user, and relates very clearly to a service
(websites) that is a crucial enabler for freedom of expression and
access to information.

> IMHO, this is the sort of things to put in the draft, identify
> precised characteristics of protocols that "solidify, enable or
> threaten human rights". For HTTP, I would say there are none in
> most of the RFCs mentioned, but that proposals like the expired
> draft draft-tbray-http-legally-restricted-status certainly are
> interesting for the HR.
> 

I think the work of Tim Bray and the http://www.451unavailable.org/
campaign is extremely valuable. Thank you for reminding me of that
here. I think we should bring it up again in the HTTP WG.

I would definitely try to include this quite explicit reference to
human rights in the research (even though it's not a standard yet),
but I think we should also look for 'deeper layers', and implicit
mentions of or impacts on human rights enabling protocols

In that way I am also trying to see how we can approach:
- - emails (and also mailinglists)
- - VoIP (SIP)
- - chat (XMPP, IRC)

> 2.1.5 grossly exaggerates the role of IDN, which are only a very
> small component in the internationalisation of the Internet. Even
> for "having their own URLs", they are only a part of the story (an
> URL is not made of just a domain name). This reminds me of the
> governance circus, where a disproportionate amount of effort was
> put in the IDN debate. It would be more interesting to identify the
> points where protocols are not yet internationalised enough. A good
> example is the work of the PRECIS working group
> <http://tools.ietf.org/wg/precis/>, for internationalised
> identifiers.
> 

I think what we're trying to do is map how protocols and standards
that have (or had) an impact an human rights, not look at how more
work can be done to strengthen human rights online (that's another
part of my job ;) )

I will dive deeper into the work of WG PRECIS and use that to expand
the example research on the IDNs (as well as
https://tools.ietf.org/html/rfc5992 which was suggested in the session).

> I would also would like IPv6 to be mentioned: the lack of IPv4 
> addresses severely limit access for people (with CGN and stuff
> like that, you can be a passive consumer but hosting content, for
> instance, is much more complicated) and I do not find too
> far-fetched to say that the deployment of IPv6 is partly a HR
> issue.
> 

This is an excellent idea. Would you bring the IPv4 - IPv6 transition
under the right to access to information, or directly under the right
of freedom of expression? This might be an real interesting thing to
dive in, are there specific RFCs you suggest I should have a look at?
Else I'll dive in it deeply and keep people posted here about my finding.

Thanks again for these very helpful comments Stephane, looking forward
to continue the discussion.

Best,

Niels

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

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)

iQEcBAEBAgAGBQJUgK1wAAoJEAi1oPJjbWjpw0IH/A3MEB9AN1Io0IefJFRI143P
uEpY6VcZqS5Y91D1B9/5Gn7S6ZQqKl6bjTNGw3rgK0mMLLzvtLhaGTbqTzTDKSKa
unWvoPoU3qLEYJDm9Tg5kqvLc1pEVQc5K9y1n3hYF/HINiPwa9MU/JpTvtdQoOoT
0I1FFasB2gQ8YMkenqt4m62Fm0fZ+ouwwSexTPRlb5gXF7MjGxjFx/Kvh7JYgE3n
6qfGMmELGQF5a2Wo1rWv+ebEtZHn0zr6o7E3kgd7EmrTCzC1xVXALDEBjFW3c2QN
DND33Y7oPk2mMcg8eR48iHeNe1NBFZVqnuCDPzW0vHE6IcFdPM1jwI9Rr5c8Fhg=
=dkmR
-----END PGP SIGNATURE-----