Subject: [hrpc] Fwd: New Version Notification for draft-nottingham-for-the-users-01.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2015 11:27:58 +1100

FYI, I've been working on this for a little while. 

I'm not sure HPRC is the right place for this to end up; talking to some people "in the know", it seems like this might need to go through the GEN area if we want it to stick. However, I'd love to hear feedback from HPRC folks.

Also, a possibly more friendly HTML version is at:
  http://mnot.github.io/I-D/for-the-users/

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-for-the-users-01.txt
> Date: 8 October 2015 11:24:12 am AEDT
> To: "Mark Nottingham" <[email-masked]>, "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-for-the-users-01.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-for-the-users
> Revision:	01
> Title:		The Internet is for End Users
> Document date:	2015-10-08
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-for-the-users-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-01
> 
> Abstract:
>   Internet standards serve and are used by a variety of communities.
>   This document contains guidelines for explicitly identifying them,
>   serving them, and determining how to resolve conflicts between their
>   interests, when necessary.
> 
>   It also mandates end users as the highest priority concern for
>   Internet standards.
> 
> Note to Readers
> 
>   The issues list for this draft can be found at
>   https://github.com/mnot/I-D/labels/for-the-users .
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Oct 2015 11:30:27 +1100

Sorry, HRPC :)

> On 8 Oct 2015, at 11:27 am, Mark Nottingham <[email-masked]> wrote:
> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 8 Oct 2015 02:00:24 +0100

Good stuff.

I'm not sure end-user is the right term but I do think there's
a valuable thing in your draft. I hope you persevere with it.

More or less random comments, for none of which I have an
answer to suggest, sorry.

- I don't know how a routing person could use this as a guide
for how to act - perhaps this is really an application layer
concept, or maybe there's a good generalisation that could be
made, I'm not sure. But considering that seems like a thing
that ought be done. (You may have done it, but that's not
visible in the draft.)
- If end-users like something that's not really good for them
(e.g. handing over all their personal information to a few
mega-companies) then are we supposed to prioritise things based
on how they behave or how we think they ought behave? (Or even
on how we think we ought behave..)
- The set of identifiable parties doesn't only include those
who benefit from our standards, but also those who lose, e.g.
hopefully criminals and spooks will lose, but so will some
companies with some business models, and so will some sets
of people. That can be important when considering trade-offs
in that the delta in outcome for a losing class of persons
may be a good, or a bad, thing.
- If we achieve rough consensus on this text, are we then
saying that this newly BCP'd principle trumps rough consensus?
- "core values" - I'm not sure we have one set of those that we
all agree to, and perhaps we don't need that if we have a scheme
like rough consensus (see previous point)
- "Extensions to existing standards MUST document..." - that's
not going to happen and, I suspect, if ever reduced to concrete
steps would end up as mere pointless bureaucracy,
- The use of "MAY estimate" puzzles me - what does it mean?
- "informed consent" - I think that's a fiction and a damaging
one, being impossible and yet used to justify lots of things, at
least as mostly used.
- I'm not sure the HTTPS as a two party protocol is a good way
to look at things. Today, a web transaction often involves a user,
operating system, browser, network operator, maybe some proxies, a
data centre/hosting/cloudy provider, a web server operator, and only
then we get to what the user may perceive as being the 2nd party.
(Which party can also be a whole menagerie of entities, an inbound
proxy or load balancer, a web front-end, ...) And all of that
omits the DNS entities, the spooks listening in and probably more.
- I'm really unsure this is something on which we could reach rough
consensus, but tha's the kind of thing I think is worth finding out.
Later though.
- In the meantime, I hope this is on some agenda in Yokohama and for
discussion over some beers.

More nitty things:

- I don't think the code-regulates quote is useful, personally I
find it problematic, and all you need to say is that the code that
implements RFCs has obvious impact
- It's somehow cute that you choose 6525 as an example of harm;-)
- This really reads like something that a functioning IAB would
produce, I'm not sure what conclusion to draw from the fact that
this is being offered for discussion to a list that is not even
a formally chartered IRTF RG. Mostly, I guess that's good. But
maybe it'd be better if the IAB were emitting such drafts. (Well,
so long as the content wasn't mad of course:-)

Cheers,
S.

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 08 Oct 2015 16:34:38 +0200

Hi Mark et all,

Thanks for posting this here. I think this is a valuable place to
discuss this draft because we're working on similar issues here,
things that might eventually converge (since human rights are
individual rights), but where it's home should be, I leave it to you.

I would be more than happy to add a discussion of this draft (no
strings attached) to the agenda of the hrpc session in Yokohama.

I have some similar remarks to Stephen. There are quite some
considerations in there, but not as many guidelines as one would hope.
There are MUST, SHOULDs and MAYs in there, but not as many
descriptions of how this should be done.

Where is comes to value neutrality and objective of the IETF, you
might want to refer to RFC3935 - IETFs mission statement - which reads:

[QUOTE]

   The Internet isn't value-neutral, and neither is the IETF.  We want
   the Internet to be useful for communities that share our commitment
   to openness and fairness.  We embrace technical concepts such as
   decentralized control, edge-user empowerment and sharing of
   resources, because those concepts resonate with the core values of
   the IETF community.  These concepts have little to do with the
   technology that's possible, and much to do with the technology that
   we choose to create.

[/QUOTE]

Or perhaps to RFC1958.

Some responses to Stephen comments:

On 10/08/2015 03:00 AM, Stephen Farrell wrote:
> - If end-users like something that's not really good for them (e.g.
> handing over all their personal information to a few 
> mega-companies) then are we supposed to prioritise things based on
> how they behave or how we think they ought behave? (Or even on how
> we think we ought behave..)

Prioritize things on how we think the interests of the user are best
protected (as described in IETF standards), which they can choose to
ignore. The other way around is much harder, no?

> - The set of identifiable parties doesn't only include those who
> benefit from our standards, but also those who lose, e.g. hopefully
> criminals and spooks will lose, but so will some companies with
> some business models, and so will some sets of people. That can be
> important when considering trade-offs in that the delta in outcome
> for a losing class of persons may be a good, or a bad, thing.

+100. If one reaches a decision, all parts of the decision making
process should be made transparent. This will make future decision
making much easier as well.

> - If we achieve rough consensus on this text, are we then saying
> that this newly BCP'd principle trumps rough consensus?

Depends how these would be formulated, right? As guidelines, need for
documentation, tool in the decision making process, or preconditions
for new RFCs.

If it would be the latter, if would be a criterium for IESG review, righ
t?

But I guess it's more likely to take the form of (several of) the former
.

> - "core values" - I'm not sure we have one set of those that we all
> agree to, and perhaps we don't need that if we have a scheme like
> rough consensus (see previous point)

There definitely are values, also expressed in RFCs. Do you think that
consensus also trumps those? That would make rough consensus 'the
ultimate value / touchstone'.

> - "Extensions to existing standards MUST document..." - that's not
> going to happen and, I suspect, if ever reduced to concrete steps
> would end up as mere pointless bureaucracy, - The use of "MAY
> estimate" puzzles me - what does it mean? - "informed consent" - I
> think that's a fiction and a damaging one, being impossible and yet
> used to justify lots of things, at least as mostly used.

+100. Informed consent is inherently broken (and "I have read and
agree with the terms and conditions' is the most prevalent lie on the
Internet) as shown in several articles:

Prof. Daniel Solove's article on why consent is broken
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171018

Lorrie Cranor & Aleecia MacDonald article on how it would take 76
days to read privacy policies for services an average user uses
(old but gold) -
http://lorrie.cranor.org/pubs/readingPolicyCost-authorDraft.pdf

> - I'm not sure the HTTPS as a two party protocol is a good way to
> look at things. Today, a web transaction often involves a user, 
> data centre/hosting/cloudy provider, a web server operator, and
> only then we get to what the user may perceive as being the 2nd
> party. (Which party can also be a whole menagerie of entities, an
> inbound proxy or load balancer, a web front-end, ...) And all of
> that omits the DNS entities, the spooks listening in and probably
> more. - I'm really unsure this is something on which we could reach
> rough consensus, but tha's the kind of thing I think is worth
> finding out. Later though.

Yes.

> - In the meantime, I hope this is on some agenda in Yokohama and
> for discussion over some beers.
> 

As said, happy to put it on the agenda of the hrpc session.

> implements RFCs has obvious impact

And you could illustrate that with the IETF statements, which probably
makes it stronger in IETF fora.

> - It's somehow cute that you choose 6525 as an example of harm;-) -
> This really reads like something that a functioning IAB would 
> this is being offered for discussion to a list that is not even a
> formally chartered IRTF RG. Mostly, I guess that's good. But maybe
> it'd be better if the IAB were emitting such drafts. (Well, so long
> as the content wasn't mad of course:-)
> 

Not sure if I understand this process suggestion since Mark is not in
the IAB, right?

> Cheers, S.

Cheers,

~n.,
>> I'm not sure HPRC is the right place for this to end up; talking
>> to some people "in the know", it seems like this might need to go
>> through the GEN area if we want it to stick. However, I'd love to
>> hear feedback from HPRC folks.
>> 
>>> From: [email-masked] Subject: New Version
>>> Notification for draft-nottingham-for-the-users-01.txt Date: 8
>>> October 2015 11:24:12 am AEDT To: "Mark Nottingham"
>>> <[email-masked]>, "Mark Nottingham" <[email-masked]>
>>> 
>>> 
>>> A new version of I-D, draft-nottingham-for-the-users-01.txt has
>>> been successfully submitted by Mark Nottingham and posted to
>>> the IETF repository.
>>> 
>>> Name:		draft-nottingham-for-the-users Revision:	01 Title:		The
>>> Internet is for End Users Document date:	2015-10-08 Group:
>>> Individual Submission Pages:		8 URL:
>>> https://www.ietf.org/internet-drafts/draft-nottingham-for-the-users-
01.txt
Status:
https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-nottingham-for-the-users-01 
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-nottingham-for-the-users-01
>>>
>>>
>>> 
Abstract:
>>> Internet standards serve and are used by a variety of
>>> communities. This document contains guidelines for explicitly
>>> identifying them, serving them, and determining how to resolve
>>> conflicts between their interests, when necessary.
>>> 
>>> Please note that it may take a couple of minutes from the time
>>> of submission until the htmlized version and diff are available
>>> at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> -- Mark Nottingham   https://www.mnot.net/
>> 
>> _______________________________________________ hrpc mailing
>> list [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>> 
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 14:41:07 +0200

On Thu, Oct 08, 2015 at 11:27:58AM +1100,
 Mark Nottingham <[email-masked]> wrote 
 a message of 64 lines which said:

> I'm not sure HPRC is the right place for this to end up;

Very good text, very useful. IMHO, HRPC is a reasonable place (but do
what you want).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 14:46:07 +0200

On Thu, Oct 08, 2015 at 02:00:24AM +0100,
 Stephen Farrell <[email-masked]> wrote 

> we think we ought behave..)

This is covered in the last paragraph of section 2. Choices like this
one must be discussed (currently, "handing over all their personal
information to a few mega-companies" is certainly not an informed
decision taken after careful examination of the pros and cons).

> criminals and spooks will lose, but so will some companies with some
> business models, and so will some sets of people. That can be

Criminals are stake-holders, too :-)

> implements RFCs has obvious impact

I like it. What is problematic in it?

> - It's somehow cute that you choose 6525 as an example of harm;-)

You mean 6265?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Oct 2015 14:38:49 +1100

Hi Stephen,

> that ought be done. (You may have done it, but that's not

I think the section on identifying / managing relevant parties should be pretty straightforward for them; an example would help.

The harder part would be showing how they prioritise the end user. I'm wondering if the "MUST give the highest priority to end users" is something that we need to keep -- if that section should just become an advisory "if you don't prioritise end users, this is what's likely to happen" rather than a MUST from above.

Thoughts?

> on how we think we ought behave..)

Indeed. Ultimately, they need to get involved in the process to have immediate effect, or refuse to adopt our protocols to have a more delayed effect. Either way implies some level of organised effort (which we do see sometimes). 

I've done some work on the intro, see:
  https://github.com/mnot/I-D/commit/e76060e5bfdb

> may be a good, or a bad, thing.

Sure. The point is to identify the actors so people can judge for themselves whether they like the outcome, and then act accordingly (when the document comes up for LC and when it comes time to adopt the technology).

> saying that this newly BCP'd principle trumps rough consensus?

That argument could be made for many documents we produce. This is a guide; the process shows us how to apply it.

> like rough consensus (see previous point)

The mission statement seems to think so.

> steps would end up as mere pointless bureaucracy,

I think this could be stated as a goal rather than an outcome -- i.e., it's something that the document shepherd would look into as part of the checklist / essay ("has the impact upon the specification's relevant parties been considered, as per BCPnnn?")

> - The use of "MAY estimate" puzzles me - what does it mean?

See (for this and the point above):
  https://github.com/mnot/I-D/commit/a54b5edeb214c3

> one, being impossible and yet used to justify lots of things, at

... which the text directly below acknowledges.

> omits the DNS entities, the spooks listening in and probably more.

That clearly talks about it as just a protocol, not the entire Web ecosystem.

> consensus, but tha's the kind of thing I think is worth finding out.

So far, the reaction has been pretty encouraging. I think we need to try.

> implements RFCs has obvious impact

I really like it, my draft so I'll keep it for now :)

> - It's somehow cute that you choose 6525 as an example of harm;-)

How so?

> so long as the content wasn't mad of course:-)

Noted.

Thanks!