Subject: Re: [hrpc] hrpc Digest, Vol 14, Issue 6

From: Dessalegn Yehuala <[email-masked]>
Date: Fri, 6 May 2016 11:00:21 +0300

I have been a silent subscriber of the mailing list for some time, having
read the Internet drafts published recently I thought it would be good to
forward one item that can provide a new dimension to the ongoing work. It
has been repeatedly said that access to the Internet is becoming more and
more a human right issue- I feel the working group approach need to be
beyond the protection of freedom of speech, as it has tried to be to an
extent in the case of making the Internet environment accessible for people
with disability. The large chunks of population in developing countries or
countries in the global south are disconnected and the accessibility issue
also need to be one of the targets in the design of a protocol that
addresses human rights related issue.

Dessalegn.

On Thu, May 5, 2016 at 10:00 PM, <[email-masked]> wrote:

> Send hrpc mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.irtf.org/mailman/listinfo/hrpc
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hrpc digest..."
>
> Today's Topics:
>
>    1. Re: New Version Notification for
>       draft-tenoever-hrpc-research-00.txt (Niels ten Oever)
>    2. Re: New Version Notification for
>       draft-tenoever-hrpc-research-00.txt (Joseph Lorenzo Hall)
>
>
> ---------- Forwarded message ----------
> From: Niels ten Oever <[email-masked]>
> To: Joseph Lorenzo Hall <[email-masked]>, Jeroen van der Ham <[email-masked]>
> Cc: [email-masked]
> Date: Thu, 5 May 2016 12:54:59 +0200
> Subject: Re: [hrpc] New Version Notification for
> draft-tenoever-hrpc-research-00.txt
> Hi Joe,
>
> Sorry for the delay, there were some building issues, and as you know
> kramdown-rfc2629 is not always as verbose as one wants to be :)
>
> Please find a new version here:
> https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/
>
> Comment and questions on the list, suggestions also very much welcome as
> pull requests here (preferably with a short describption in a mail to
> the list):
>
> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
>
> 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote:
> > I'm aware of that. It would be good to build RFC txt too, if that's
> > not difficult (happy to craft a PR)
> >
> > On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham <[email-masked]>
> wrote:
> >> Hi Joe,
> >> Md is the Markdown format, which is basically plain text. You can get
> the raw format here:
> >>
> >>
> https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md
> >>
> >> Jeroen.
> >>
> >>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall <[email-masked]> wrote:
> >>>
> >>> Point of order: should we reivew the 00 document or is there a
> >>> readable version in the repo we should look at? (i.e., if you could
> >>> transform a working copy of the md into txt that would be wonderful).
> >>> best, Joe
> >>>
> >>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever <[email-masked]>
> wrote:
> >>>> Hi Avri,
> >>>>
> >>>> We're working hard on resolving some of these questions and making a
> big
> >>>> review. Much of the work can be followed in realtime here:
> >>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
> >>>>
> >>>> Some replies inline to your email while I was drafting:
> >>>>
> >>>>> On 04/04/2016 09:52 PM, avri doria wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I did a read through but have not had a chance to write up the
> comments
> >>>>> in a legible manner.
> >>>>>
> >>>>> These are some general comments
> >>>>>
> >>>>> - the discussion centers around general behaviors and there is very
> >>>>> little discussion of protocol element.
> >>>>
> >>>> Will take this into account while re-writing. I am also trying to
> focus
> >>>> on which behavior a protocol allows and disallows (or even
> stimulates).
> >>>> I think that is inherent part of the protocols
> >>>>
> >>>>>
> >>>>> - Many of the effects seem more related to IP issues (e.g. visible
> SRC &
> >>>>> DST) than to elements of the specific protocol itself.
> >>>>
> >>>> IP is also a protocol, right?
> >>>>
> >>>>> In a sense they
> >>>>> seem to be larger architectural issues (also a part of the RG's
> work) as
> >>>>> opposed to protocol issues.
> >>>>
> >>>> Not sure if it is either/or.
> >>>>
> >>>>> But they are not broken out that way.
> >>>>> Might be worth differentiating between the architectural issues and
> the
> >>>>> protocol issues.
> >>>>
> >>>> Have been thinking about this and having a hard time coming up with a
> >>>> clear difference between the two. Would you have suggestions that can
> >>>> help us further?
> >>>>
> >>>>>
> >>>>> - Much on the comment of the protocols is more about how people can
> >>>>> misuse the protocols and not abut protocol elements that enable bad
> or
> >>>>> good behavior.
> >>>>>
> >>>>> - also, so much of the discussion seems to circle around
> implementation
> >>>>> and not the protocols themselves.
> >>>>
> >>>> Will try to add more concrete protocol examples, but I think there are
> >>>> also a lot of examples that show how protocol design allows for
> misuse,
> >>>> I think that should also be addressed at protocol level (as for
> instance
> >>>> done in html2)
> >>>>
> >>>>> - I think the discussion needs to take some of the work that is going
> >>>>> into protecting these protocols into account (e.g. HTTP -> HTTPS).
> The
> >>>>> draft did this for P2P but not for many of other discussions.
> >>>>
> >>>> Working on it.
> >>>>
> >>>>
> >>>>> - much of the discussion focuses on privacy elements, which are
> already
> >>>>> covered and not on other aspects of FoE and FoA.  Ie. something is a
> >>>>> problem because the lack of privacy affects the FoE or FoA.  This is
> >>>>> good point, but is it specific to the protocols?
> >>>>
> >>>> Working on it.
> >>>>
> >>>>> - I think the consideration questions at the end are good questions,
> but
> >>>>> I am not sure I see how they all come from the issues discussion in
> many
> >>>>> cases.  Might be good to link questions to specifics discussed
> earlier
> >>>>> in the draft.
> >>>>
> >>>> Working on it.
> >>>>
> >>>>> Sorry to be so last minute and somewhat less than fully coherent
> about
> >>>>> these.
> >>>>
> >>>> They're great and very useful. Always happy to discuss.
> >>>>
> >>>> Best,
> >>>>
> >>>> Niels
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> hrpc mailing list
> >>>> [email-masked]
> >>>> https://www.irtf.org/mailman/listinfo/hrpc
> >>>
> >>>
> >>>
> >>> --
> >>> Joseph Lorenzo Hall
> >>> Chief Technologist, Center for Democracy & Technology [
> https://www.cdt.org]
> >>> 1401 K ST NW STE 200, Washington DC 20005-3497
> >>> e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> >>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
> >>>
> >>> _______________________________________________
> >>> hrpc mailing list
> >>> [email-masked]
> >>> https://www.irtf.org/mailman/listinfo/hrpc
> >>
> >
> >
> >
>
>
>
> ---------- Forwarded message ----------
> From: Joseph Lorenzo Hall <[email-masked]>
> To: Niels ten Oever <[email-masked]>
> Cc: [email-masked], Jeroen van der Ham <[email-masked]>
> Date: Thu, 5 May 2016 08:02:24 -0700
> Subject: Re: [hrpc] New Version Notification for
> draft-tenoever-hrpc-research-00.txt
> Thanks a ton, Niels! I am way too familiar with vagaries of group
> kramdown building... so very much appreciate this. More soon!
>
> On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever <[email-masked]>
> wrote:
> > Hi Joe,
> >
> > Sorry for the delay, there were some building issues, and as you know
> > kramdown-rfc2629 is not always as verbose as one wants to be :)
> >
> > Please find a new version here:
> > https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/
> >
> > Comment and questions on the list, suggestions also very much welcome as
> > pull requests here (preferably with a short describption in a mail to
> > the list):
> >
> > https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
> >
> > 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 05/04/2016 07:24 PM, Joseph Lorenzo Hall wrote:
> >> I'm aware of that. It would be good to build RFC txt too, if that's
> >> not difficult (happy to craft a PR)
> >>
> >> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham <[email-masked]>
> wrote:
> >>> Hi Joe,
> >>> Md is the Markdown format, which is basically plain text. You can get
> the raw format here:
> >>>
> >>>
> https://raw.githubusercontent.com/nllz/IRTF-HRPC/blob/master/draft-research.md
> >>>
> >>> Jeroen.
> >>>
> >>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall <[email-masked]> wrote:
> >>>>
> >>>> Point of order: should we reivew the 00 document or is there a
> >>>> readable version in the repo we should look at? (i.e., if you could
> >>>> transform a working copy of the md into txt that would be wonderful).
> >>>> best, Joe
> >>>>
> >>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever <[email-masked]>
> wrote:
> >>>>> Hi Avri,
> >>>>>
> >>>>> We're working hard on resolving some of these questions and making a
> big
> >>>>> review. Much of the work can be followed in realtime here:
> >>>>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md
> >>>>>
> >>>>> Some replies inline to your email while I was drafting:
> >>>>>
> >>>>>> On 04/04/2016 09:52 PM, avri doria wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I did a read through but have not had a chance to write up the
> comments
> >>>>>> in a legible manner.
> >>>>>>
> >>>>>> These are some general comments
> >>>>>>
> >>>>>> - the discussion centers around general behaviors and there is very
> >>>>>> little discussion of protocol element.
> >>>>>
> >>>>> Will take this into account while re-writing. I am also trying to
> focus
> >>>>> on which behavior a protocol allows and disallows (or even
> stimulates).
> >>>>> I think that is inherent part of the protocols
> >>>>>
> >>>>>>
> >>>>>> - Many of the effects seem more related to IP issues (e.g. visible
> SRC &
> >>>>>> DST) than to elements of the specific protocol itself.
> >>>>>
> >>>>> IP is also a protocol, right?
> >>>>>
> >>>>>> In a sense they
> >>>>>> seem to be larger architectural issues (also a part of the RG's
> work) as
> >>>>>> opposed to protocol issues.
> >>>>>
> >>>>> Not sure if it is either/or.
> >>>>>
> >>>>>> But they are not broken out that way.
> >>>>>> Might be worth differentiating between the architectural issues and
> the
> >>>>>> protocol issues.
> >>>>>
> >>>>> Have been thinking about this and having a hard time coming up with a
> >>>>> clear difference between the two. Would you have suggestions that can
> >>>>> help us further?
> >>>>>
> >>>>>>
> >>>>>> - Much on the comment of the protocols is more about how people can
> >>>>>> misuse the protocols and not abut protocol elements that enable bad
> or
> >>>>>> good behavior.
> >>>>>>
> >>>>>> - also, so much of the discussion seems to circle around
> implementation
> >>>>>> and not the protocols themselves.
> >>>>>
> >>>>> Will try to add more concrete protocol examples, but I think there
> are
> >>>>> also a lot of examples that show how protocol design allows for
> misuse,
> >>>>> I think that should also be addressed at protocol level (as for
> instance
> >>>>> done in html2)
> >>>>>
> >>>>>> - I think the discussion needs to take some of the work that is
> going
> >>>>>> into protecting these protocols into account (e.g. HTTP -> HTTPS).
> The
> >>>>>> draft did this for P2P but not for many of other discussions.
> >>>>>
> >>>>> Working on it.
> >>>>>
> >>>>>
> >>>>>> - much of the discussion focuses on privacy elements, which are
> already
> >>>>>> covered and not on other aspects of FoE and FoA.  Ie. something is a
> >>>>>> problem because the lack of privacy affects the FoE or FoA.  This is
> >>>>>> good point, but is it specific to the protocols?
> >>>>>
> >>>>> Working on it.
> >>>>>
> >>>>>> - I think the consideration questions at the end are good
> questions, but
> >>>>>> I am not sure I see how they all come from the issues discussion in
> many
> >>>>>> cases.  Might be good to link questions to specifics discussed
> earlier
> >>>>>> in the draft.
> >>>>>
> >>>>> Working on it.
> >>>>>
> >>>>>> Sorry to be so last minute and somewhat less than fully coherent
> about
> >>>>>> these.
> >>>>>
> >>>>> They're great and very useful. Always happy to discuss.
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Niels
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> hrpc mailing list
> >>>>> [email-masked]
> >>>>> https://www.irtf.org/mailman/listinfo/hrpc
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Joseph Lorenzo Hall
> >>>> Chief Technologist, Center for Democracy & Technology [
> https://www.cdt.org]
> >>>> 1401 K ST NW STE 200, Washington DC 20005-3497
> >>>> e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> >>>> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
> >>>>
> >>>> _______________________________________________
> >>>> hrpc mailing list
> >>>> [email-masked]
> >>>> https://www.irtf.org/mailman/listinfo/hrpc
> >>>
> >>
> >>
> >>
> >
>
>
>
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org
> ]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>
>
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>
>

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 6 May 2016 14:03:14 +0200

Dear Dessalegn,

Thank you for your email. I think in the draft [0] we have been focusing
on topics that go beyond freedom of speech, for instance where we looked
at freedom of association, non-discrimination, equal protection,
political participation, participation in cultural life, arts and
science and the right to security.

As you say, connectivity is an inherent part of freedom as expression,
and that is also how it is defined in the draft. But I am afraid that
providing access to the Internet is not a protocol issue where is comes
to providing the actual connection and providing bandwith (please
correct me if I'm wrong!). Therefore I think it is outside of the
purview of this document and research group.

We do however have explicit references to usage of protocols on low
bandwith, high latency connections, have for instance a look at
'5.3.2.1.11.  Accessibility' and '5.3.2.1.14.  Reliability'.

Always happy to discuss.

All the best,

Niels

https://tools.ietf.org/html/draft-tenoever-hrpc-research-01

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 05/06/2016 10:00 AM, Dessalegn Yehuala wrote:
> I have been a silent subscriber of the mailing list for some time,
> having read the Internet drafts published recently I thought it would be
> good to forward one item that can provide a new dimension to the ongoing
> work. It has been repeatedly said that access to the Internet is
> becoming more and more a human right issue- I feel the working group
> approach need to be beyond the protection of freedom of speech, as it
> has tried to be to an extent in the case of making the Internet
> environment accessible for people with disability. The large chunks of
> population in developing countries or countries in the global south are
> disconnected and the accessibility issue also need to be one of the
> targets in the design of a protocol that addresses human rights related
> issue.
> 
> Dessalegn.
> 
> On Thu, May 5, 2016 at 10:00 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>             [email-masked] <mailto:[email-masked]>
> 
>             [email-masked] <mailto:[email-masked]>
> 
>             [email-masked] <mailto:[email-masked]>
> 
>     From: Niels ten Oever <[email-masked] <mailto:[email-masked]>>
>     To: Joseph Lorenzo Hall <[email-masked] <mailto:[email-masked]>>, Jeroen
>     van der Ham <[email-masked] <mailto:[email-masked]>>
>     Cc: [email-masked] <mailto:[email-masked]>
>     www.article19.org <http://www.article19.org>
> 
>     > On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >> Hi Joe,
>     >> Md is the Markdown format, which is basically plain text. You can
>     get the raw format here:
>     >>
>     >>
>     >>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>> Hi Avri,
>     >>>>
>     >>>> We're working hard on resolving some of these questions and
>     making a big
>     >>>> Will take this into account while re-writing. I am also trying
>     to focus
>     >>>>> - Many of the effects seem more related to IP issues (e.g.
>     visible SRC &
>     >>>>> seem to be larger architectural issues (also a part of the
>     RG's work) as
>     >>>>> Might be worth differentiating between the architectural
>     issues and the
>     >>>>> protocol issues.
>     >>>>
>     >>>>> misuse the protocols and not abut protocol elements that
>     enable bad or
>     >>>>> good behavior.
>     >>>>>
>     >>>>> into protecting these protocols into account (e.g. HTTP ->
>     HTTPS). The
>     >>>>> - much of the discussion focuses on privacy elements, which
>     are already
>     >>>>> I am not sure I see how they all come from the issues
>     discussion in many
>     >>>>> Sorry to be so last minute and somewhat less than fully
>     coherent about
>     >>>>> these.
>     >>>>
>     >>>> [email-masked] <mailto:[email-masked]>
>     >>> Chief Technologist, Center for Democracy & Technology
>     [https://www.cdt.org]
>     >>> e: [email-masked] <mailto:[email-masked]>, p: 202.407.8825
>     <tel:202.407.8825>, pgp: https://josephhall.org/gpg-key
>     >>> [email-masked] <mailto:[email-masked]>
>     From: Joseph Lorenzo Hall <[email-masked] <mailto:[email-masked]>>
>     To: Niels ten Oever <[email-masked] <mailto:[email-masked]>>
>     Cc: [email-masked] <mailto:[email-masked]>, Jeroen van der Ham
>     <[email-masked] <mailto:[email-masked]>>
>     On Thu, May 5, 2016 at 3:54 AM, Niels ten Oever <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Hi Joe,
>     >
>     > www.article19.org <http://www.article19.org>
>     >
>     >> On Wed, May 4, 2016 at 1:20 PM, Jeroen van der Ham <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>> Hi Joe,
>     >>> Md is the Markdown format, which is basically plain text. You
>     can get the raw format here:
>     >>>
>     >>>
>     >>>> On 04 May 2016, at 16:29, Joseph Lorenzo Hall <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>>
>     >>>>> On Wed, May 4, 2016 at 8:48 AM, Niels ten Oever
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>>> Hi Avri,
>     >>>>>
>     >>>>> We're working hard on resolving some of these questions and
>     making a big
>     >>>>>> I did a read through but have not had a chance to write up
>     the comments
>     >>>>>> in a legible manner.
>     >>>>>>
>     >>>>> Will take this into account while re-writing. I am also trying
>     to focus
>     >>>>>> - Many of the effects seem more related to IP issues (e.g.
>     visible SRC &
>     >>>>>> seem to be larger architectural issues (also a part of the
>     RG's work) as
>     >>>>>> Might be worth differentiating between the architectural
>     issues and the
>     >>>>>> protocol issues.
>     >>>>>
>     >>>>>> misuse the protocols and not abut protocol elements that
>     enable bad or
>     >>>>>> good behavior.
>     >>>>>>
>     >>>>> also a lot of examples that show how protocol design allows
>     for misuse,
>     >>>>> I think that should also be addressed at protocol level (as
>     for instance
>     >>>>> done in html2)
>     >>>>>
>     >>>>>> into protecting these protocols into account (e.g. HTTP ->
>     HTTPS). The
>     >>>>>> - much of the discussion focuses on privacy elements, which
>     are already
>     >>>>>> I am not sure I see how they all come from the issues
>     discussion in many
>     >>>>>> cases.  Might be good to link questions to specifics
>     discussed earlier
>     >>>>>> in the draft.
>     >>>>>
>     >>>>> Working on it.
>     >>>>>
>     >>>>>> Sorry to be so last minute and somewhat less than fully
>     coherent about
>     >>>>>> these.
>     >>>>>
>     >>>>> [email-masked] <mailto:[email-masked]>
>     >>>> Chief Technologist, Center for Democracy & Technology
>     [https://www.cdt.org]
>     >>>> e: [email-masked] <mailto:[email-masked]>, p: 202.407.8825
>     <tel:202.407.8825>, pgp: https://josephhall.org/gpg-key
>     >>>> [email-masked] <mailto:[email-masked]>
>     Chief Technologist, Center for Democracy & Technology
>     [https://www.cdt.org]
>     e: [email-masked] <mailto:[email-masked]>, p: 202.407.8825
>     <tel:202.407.8825>, pgp: https://josephhall.org/gpg-key
>     [email-masked] <mailto:[email-masked]>