20190608 IAB Mail exchange on the "End User" Draft

(Please note that some typos have been corrected)

This debate is in relation with the IAB Adoption of [ draft-nottingham-for-the-users]

1. Introduction

Many who participate in the IETF are most comfortable making what we believe to be purely technical decisions; our process is defined to favor technical merit, through our well-known mantra of "rough consensus and running code." Nevertheless, the running code that results from our process (when things work well) inevitably has an impact beyond technical considerations, because the underlying decisions afford some uses while discouraging others; while we believe we are making purely technical decisions, in reality, we are defining what is possible on the Internet itself.

This impact has become significant. As the Internet increasingly mediates essential functions in societies, it has unavoidably become profoundly political; it has helped people overthrow governments and revolutionize social orders, control populations, collect data about individuals, and reveal secrets. It has created wealth for some individuals and companies while destroying others'.

All of this raises the question: Who do we go through the pain of gathering rough consensus and writing running code for?

After all, there are a variety of identifiable parties in the broader Internet community that standards can provide benefit to, such as (but not limited to) end users, network operators, schools, equipment vendors, specification authors, specification implementers, content owners, governments, non-governmental organisations, social movements, employers, and parents.

Successful specifications will provide some benefit to all of the relevant parties because standards do not represent a zero-sum game.

However, there are sometimes situations where there is a need to balance the benefits of a decision between two (or more) parties.

In these situations, when one of those parties is an "end user" of the Internet - for example, a person using a Web browser, mail client, or another agent that connects to the Internet - the Internet Architecture Board argues that the IETF should protect their interests over those of parties.

Section 2 explains what is meant by "end users"; Section 3 outlines why they should be prioritised in IETF work, and Section 4 describes how that can be done.

2. What Are "End Users"?

In this document, "end users," means non-technical users whose activities IETF protocols are designed to support, sometimes indirectly. Thus, the end user of a protocol to manage routers is not a router administrator; it is the people using the network that the router operates within.

End users are not necessarily a homogenous group; they might have different views of how the Internet should work (from their viewpoint) and might occupy several roles, such as a seller, buyer, publisher, reader, service provider and consumer. An end user might be browsing the Web, monitoring remote equipment, playing a game, video conferencing with colleagues, sending messages to friends, or performing an operation in a remote surgery theatre.

Likewise, an individual end user might have many interests (e.g., privacy, security, flexibility, reachability) that are sometimes in tension.

A person whose interests we need to consider might not directly be using a specific system connected to the Internet. For example, if a child is using a browser, the interests of that child's parents or guardians may be relevant; if a person is pictured in a photograph, that person may have an interest in systems that process that photograph, or if a person entering a room triggers sensors that send data to the Internet than that person's interests may be involved in our deliberations about how those sensor readings are handled.

While such less-direct interactions between people and the Internet may be harder to evaluate, such people are nonetheless included in this document's concept of end-user.

3. Why End Users Should Be Prioritised

While focused on technical matters, the IETF is not neutral about the purpose of its work in developing the Internet; in "A Mission Statement for the IETF" [RFC3935], the definitions include:

The IETF community wants the Internet to succeed because we believe that the existence of the Internet, and its influence on economics, communication, and education, will help us to build a better human society.

and later in Section 2.1, "The Scope of the Internet" it says:

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.

In other words, the IETF is concerned with developing and maintaining the Internet to promote the social good, and the society that the IETF is attempting to improve is composed of end users, along with groups of them forming businesses, governments, clubs, civil society organizations, and other institutions.

Merely advancing the measurable success of the Internet (e.g., deployment size, bandwidth, latency, number of users) is not adequate; doing so ignores how technology so often used as a lever to assert power over users, rather than empower them.

Beyond fulfilling the IETF's mission, prioritising end users also helps to ensure the long-term health of the Internet. Many aspects of the Internet are user-focused, and it will (deservedly) lose their trust if prioritises others' interests. Because one of the primary mechanisms of the Internet is the "network effect", such trust is crucial to maintain; the Internet itself depends upon it.

4. How End Users are Prioritised

The IETF community does not have any unique insight into what is "good for end users." To inform its decisions, it has a responsibility to analyse and consider the impacts of its work, as well as, where needed, interact with the greater Internet community, soliciting input from others and considering the issues raised.

End users are typically not technical experts; their experience of the Internet is often based upon inadequate models of its properties, operation, and administration. Therefore, the IETF should primarily engage with those who understand how changes to it will affect end users; in particular civil society organisations, as well as governments, businesses and other groups representing some aspect of end-user interests.

The IAB encourages the IETF to explicitly consider user impacts and points of view in any IETF work. The IAB also encourages the IETF to engage with the above parties on terms that suit them; it is not reasonable to require them to understand the mores and peculiarities of the IETF community - even though we encourage them to participate in it.

That means, when appropriate, the technical community should take the initiative to contact these communities and explain our work, solicit their feedback, and encourage their participation. In cases where it is not reasonable for a stakeholder community to engage in the IETF process, the technical community should meet with them. IAB workshops can serve this purpose and the IAB encourages suggestions for topics where this would be of benefit.

At our best, this will result in work that promotes the social good.

In some cases, we will consciously decide to be neutral and open- ended, allowing the "tussle" among stakeholders to produce a range of results (see [TUSSLE] for further discussion).

At the very least, however, we must examine our work for impact on end users, and take positive steps to avoid it where we see it. In particular, when we've identified a conflict between the interests of end users and another stakeholder, we should err on the side of finding a solution that avoids harmful consequences to end users.

Note that "harmful" is not defined in this document; that is something that the relevant body (e.g., Working Group) needs to discuss. Furthermore, harm to end users is judged just like any other decision in the IETF, with consensus gathering and the normal appeals process; merely asserting that something is harmful is not adequate. The converse is also true, though; it's not permissible to avoid identifying harms, nor is it acceptable to ignore them when brought to us.

The IETF has already established a body of guidance for situations where this sort of conflict is common, including (but not limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding privacy considerations. When specific advice is not yet available, we try to find a different solution or another way to frame the problem, distilling the underlying principles into more general advice where appropriate.

Much of that advice has focused on maintaining the end-to-end security properties of a connection. This does not mean that our responsibility to users stops there; protocol decisions might affect users in other ways. For example, data collection by various applications even inside otherwise secure connections is a major problem in the Internet today. Also, inappropriate concentration of power on the Internet has become a concerning phenomenon - one that protocol design might have some influence upon.

When the needs of different end users conflict (for example, two sets of end users both have reasonable desires) we again should try to minimise harm. For example, when a decision improves the Internet for end users in one jurisdiction, but at the cost of potential harm to others elsewhere, that is not a good tradeoff. As such, we effectively design the Internet for the pessimal environment; if a user can be harmed, they probably will be.

There may be cases where genuine technical need requires compromise.

However, such tradeoffs are carefully examined and avoided when there are alternate means of achieving the desired goals. If they cannot be, these choices and reasoning ought to be thoroughly documented.

5. IANA Considerations

This document does not require action by IANA.

6. Security Considerations

This document does not have any direct security impact; however, failing to prioritise end users might well affect their security negatively in the long term.

7. References

7.1. Informative References

[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <https://www.rfc-editor.org/info/rfc3935>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 10.17487/RFC7288, June 2014, <https://www.rfc-editor.org/info/rfc7288>.

[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.

[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.

Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.

[TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", 2002, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/ Tussle2002.pdf>.

7.2. URIs

[1] https://github.com/mnot/I-D/labels/for-the-users [2] https://mnot.github.io/I-D/for-the-users/ [3] https://github.com/mnot/I-D/commits/gh-pages/for-the-users [4] https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ This document was influenced by many discussions, both inside and outside of the IETF and IAB. In particular, Edward Snowden's comments regarding the priority of end users at IETF 93 and the WHATWG's Priority of Constituencies for HTML were both influential.

Many people gave feedback and input, including Harald Alvestrand, Mohamed Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ Housley, Niels ten Oever, Mando Rachovitsa, Martin Thomson, Brian Trammell, John Klensin, Eliot Lear, Ted Hardie, and Jari Arkko.

---

At 18:07 08/06/2019, JFC Morfin wrote:

At 16:02 07/06/2019, John C Klensin wrote: I've looked through this document and, while I'm sympathetic to several of the concerns that have been raised (both recently and in March), I see a far more fundamental, quasi-procedural, problem.

John,

I've also looked through your response and, while I'm sympathetic to the concern you have raised that (as I understand it) might affect the pertinence of an IAB document on the matter, I am concerned in a far more fundamental, quasi-architectonical, problem I don't know if it could not, in turn, affect your concern.

An important part of the IAB's role is to give architectural advice to the IETF and the Internet community more generally.

My concern is architectonical, i.e., before any architectural issue but at the same time post-architectural. I explain: since October 1st, 2016 I consider the cyberspace to be freed from what I perceived as its 1986 de-facto innovation "internet-moratorium" that out-lawed my job, as Director, Tymnet/Extended Services.

Note:

Extended services are network services extending data transport to data processing on the fly (what [networked] OPESes could partly do). They were in opposition to the deregulation pre-requisite that transport and treatment would be separated businesses. That was to prevent cross-subsidization: at that pre-Mama Bell divestiture time, Telcos feared that Tymshare, GE, and their likes, could use cloud/time-sharing revenues to competitively cross-subsidize data transport). In addition XS can also involve the "mneme" (i.e. the present network of past traces that make the possible of something into its future, an Ampère concept that delineates the person, the impact of an event, a culture, an active repository, the contexture of the context).

Customers were Visa, Banks, TWA and airlines, etc.

Please note the term "customers" that, in turn, could service internal and external users, processes and stand-alone operations. The "end-user" in Mark Nottingham's vision can be an autonomous bot. The European Parliament has voted a demand to the Government Council to come with a legislation on this issue. In 1986 they were not ready to do so, but my deparment (and "my" PTTs) were :-) !.

Since 2016 I came back to the less internet constrained cyberspace, I tried to protect the/our future at the IETF (e.g., the langtag issue – that categorize linguistic agoras (open user classes and host groups)).

To better illustrate/make understand this, I found a deeply discussed clear explanation in the XVIIe century debate over sovereignty and state, something that rules our lives, and we are actually resuming here.

The fundamental thinkers are Machiavelli (identified multitude), Bodin (identified sovereignty) and Hobbes (identified people and the modern state we still currently live under). The Hobbes' perspective (1642) is that humanity was able to copy the art of God in creating a huge artificial and fictive man: State. Whose soul is sovereignty. That artificially fictive man/state was, in turn, able to create "the people" from the multitude of people.

Quotes detailing the reasons why are:

• "one can not say that an action made in a multitude of assembled people is the action of the multitude."
• "It turns out that the multitude is not unity and remains a summation of atomic units while the people are the retroactive outcome of the establishment of sovereignty-one."
• "The citizens, when they rebel against the State, are the multitude against the people."

This means that Lincoln’s "Government of the people, by the people, for the people, shall not perish from the Earth" is something Mark Nottingham does not rule out but want to update.

For a very simple reason: up to now we only knew a hierarchical way to build peoples, in assembling bottom-people/end-users. Now we have to introduce and document a new horizontal one: networking. And because the IETF is documenting concepts that "have little to do with the technology that's possible, and much to do with the technology that we choose to create" (RFC 3539) that "allow new networking technology to be introduced into the existing catenet while remaining functionally compatible with existing systems" (IEN 48).

And what the network technology introduce in human organigrams is people to people, pair to pair relations; and multistakeholdership. For a bunch of reasons because "the Internet is a global phenomenon. The people interested in its evolution are from every culture (including not geeks) under the sun and from all walks of life." (RFC 3935). There are no more end-users; everyone is a "core-user" of his own networking. None may know the expertise of all the others in their various networking perspectives: some bring their knowledge about technology, others about UX, others about SX (social expertise), others about semiotic multilinguistic, others about what their discipline or their surviving, or their strategy or their art expect from their networking. The internet is about ID (interdisciplinarity).

This is what the internet designers of a "large, heterogeneous collection of interconnected systems that can be used for communication [and processings from my extended services pov.] of many different types between any interested parties connected to it" (RFC 3935) must first consider. This is what the IAB has to discover for them, document to them and make sure they accept; because the inter-RFC 6852 global community technical compatibility has to be dealt through the IAB.

The value and acceptance of that advice rests solely on its quality, the quality of the explanations given for it, and, to some degree, on the professional reputations of IAB members. The main thrust of the post-Kobe POISED reforms was to deprive the IAB of any procedural authority for its architectural advice and to more clearly shift responsibility for determining IETF consensus to the IESG.

Correct. But read what Brian Carpenter and others say. They refer to their time vision of the end to end internet, so this is correct for them to speak about end-users the way they do. OSI designers (Louis Pouzin's team) were about the network to networks since 1974 (as was Vint Cerf since 1978, who was calling for an end to end able to evoluate, what the "status-quo" 1986 freeze prevented). Myself, as Tymnet, I am about agoras to agoras (whatever how many CPUs they may count from one to billions).

This document explains what the IETF does and how it makes (and should make) decisions. Such a statement should represent, and will be assumed to represent, IETF Consensus ... at least unless we have reached the point where IETF strategy is dictated top-down (and, even then, the IAB has not been the "top" for descriptions of the IETF since the IETF was merely an IAB Task Force). In recent years, the IAB has published various documents, workshop reports, and other positions with precisely the justification that it is not a consensus body and need new restrict itself to areas were IETF consensus has been, or could easily be, demonstrated. I believe that it a correct position: if the IAB is going to offer forward-looking architectural advice, it must be able to get ahead of the community and then persuade others to adopt its positions. But the IAB cannot have it both ways, both asserting that it can publish documents without IETF consensus and publishing documents that describe the beliefs of, or set strategy for, the IETF

RFC 6852 got rid of that. The IETF is part of a broad standardization collusion embracing "a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status. In this paradigm, standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally. These voluntary standards serve as building blocks for products and services targeted at meeting the needs of the market and consumer, thereby driving innovation. Innovation, in turn, contributes to the creation of new markets and the growth and expansion of existing markets."

Except that this collusion does not make sense if it does not extends to every market and therefore to every consumer who in turn is a producer. This is why there only are core-users co-standardizers of "every venue under the sun."

The value and acceptance of that advice rests solely on its quality, the quality of the explanations given for it, and, to some degree, on the professional reputations of IAB members. The main thrust of the post-Kobe POISED reforms was to deprive the IAB of any procedural authority for its architectural advice and to more clearly shift responsibility for determining IETF consensus to the IESG.

Except that, IMHO, it has not fully understood the impact of RFC 6852, if I judge from its responses to my appeals and this debate. This is why I explained that I would only consider the "catenet" layers that the internet infrastructure was able to provide me as an interconnected user ("IUser") and build my own "global community" technology over it.

As such, I am considering "sets of agoras of agoras" using the no-presentation layer "network of network". Either the IETF is neutral or favorable to me when it does help or does not endanger my informed use of its layers. It is a pain when it plans otherwise. The solution I found was the iucg@ietf.org mailing list, not for the internet users, but for the IETF users (also IUsers). Unfortunately, this list is not much active, but I would be glad transferring it to Mark Nottingham as I have much sympathy as an involved user ("IUser") in many of his points.

I believe that it a correct position: if the IAB is going to offer forward-looking architectural advice, it must be able to get ahead of the community and then persuade others to adopt its positions. But the IAB cannot have it both ways, both asserting that it can publish documents without IETF consensus and publishing documents that describe the beliefs of, or set strategy for, the IETF.

Correct!!! The IAB in this situation is in the position to offer forward-looking architectural advice about the way 2020 reading of IETF previous engagements means (so they might amend them).

This document should not be adopted by the IAB in its present form. It should either be rewritten to clearly be a description of the IAB's opinion about how the IETF should behave (in which case there is the risk that no one will care), or the IAB should propose an IRTF BOF and then a WG to consider these issues, possibly with the intention of revising or updating RFC 3935. Various questions, including those about the definition of "end user", aside, I am basically in favor of the point this I-D is trying to make. But my opinion is nor more (or less) a guarantee of IETF consensus than Mark's opinion or that of the IAB. I do have to confess that I'm a bit surprised that the IESG --which, after all, has two representatives on the IAB-- has not raised this issue.

IMHO the real question is ontological. What is the internet for who? That has become a matter that spans the entire philosophical, technological, political, economical, etc. spectrum. Because these disciplines are discussing points, they first qualify as philosophical objects, technological issues, political subjects, economic matters, etc. and that diktyological (diktyology is the name of the network discipline) spans them all.

best, john p.s. We seem to have a mini-trend of late that involves using Informational documents to clarify, supplement, or implicitly update IETF Standards and BCPs without being extremely clear about their status and relationship to authoritative IETF consensus statements and documents. I think it is very troublesome and that the community should start pushing back against it even if our leadership bodies are unwilling to do so (er even facilitating such documents).

IMHO again - this is a matter I work on for 40 years since introducing the INTLFILE that grandfathered the root file - we are dealing here with interlinked ("everything is interconnected") issues from a too limited point of view. The IAB comes from the four layers of TCP/IP. Even CCITT’s OSI 7 layers did not fulfill the job (but dramatically simplifies it with layer six, presentation). The "Tymnet/Extended Systems" with its 12+ layers helped better, But the "+" (presentation layer uniform space) is the field for interdisciplinary investigation.

Now, is everything blocked?

No. Because of Brian Carpenter RFC 1958 architectural PLUS (not the same +, the one I started to check as internet compatible at the WG/IDNA2008 - "plugged layers on the user side", continuing the network model on the receiving fringe) solution.

The RFC 3935 states: "The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes."

• This is what everyone expects from IETF and what IAB should help it to achieve.
• The fringe to fringe IUser can then take over and use the internet end-to-end datagrams as his intersem fringe-to-fringe intelligrams.

This is OK with me so far. Except that I am working on low civil society "no-budget" and I am slow at developing my intersem architecture over the internet catenet.

I hope this may help.

Best

jfc

---

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy You may remember that I already sent extensive feedback, mostly critical, when -07 was released and the same question was asked. I can say that after that, and after I had a chance to discuss this in person with an IAB member, the following versions have become noticeably better, so thanks for this. I will still state a few points for the IAB to consider when making its mind on whether to adopt this draft, and on how to develop it further.

x

1. Whose interest is it really? If this is going to be a high level policy declaration of "we do it for the general public interest", i.e. the interest of "the people" in general, this is a positive thing. However, you have to be absolutely sure that this will never be used as a way to push the standards-making process in a direction that benefits certain companies over others.

x

Especially, there is a decade-long competitive battle ongoing between companies providing services within the network and companies providing services over the network, at the endpoints of the connections. Sometimes the "end user" interest can be aligned with the former, sometimes with the latter, and sometimes (perhaps the most likely case) with neither of the two. The IETF should never make policy choices meant to be in favour of any of the two sets of businesses, but only in favour of the actual end users.

x

Even from the theoretical point of view, when individual "end users" form an organization, be it an NGO, a business or a government, the organization they form - which starts to have interests of its own - is not, in policy terms, an "end user" any more, even if it sits at the edge of the network. This is a known difference between the policy and the technology realm and should be made very clear in the conceptualization of this document.

x

2. Easy to say, hard to do The second issue is that the controversial part when doing something "in the interest of the people" is not the principle statement, but how to determine what the interest of the people actually is.

x

Currently, the IETF is spectacularly ill equipped for that, and the draft does not seem to address the problem, apart from a generic invitation to reach out to civil society organizations and other stakeholders, which however also generally do not represent the interest of "end users", but at most of subsets of them (e.g. the Electronic Frontiers Foundation and the Internet Watch Foundation are going to give you opposite advice on what is in the general public interest and "for social good", though both are civil society organizations). Again, the problem is not how to get multiple end-user interests stated, but how to decide which ones are to prevail, which is always a subjective judgement by each participant, and needs to be aggregated "fairly".

x

Mankind has worked for centuries to build complex institutional arrangements to get to determine "what's best for the people", and at least for a couple of decades to build similar arrangements specifically for the Internet. Yet there is no indication of their role in this document - it looks like, all of a sudden, the IETF (even at the individual WG level) is going to make its own policy decisions, alone, after running its own consultations with stakeholders. This looks unreliable, unaccountable, uncooperative, and unlikely to bring to any valid result. In the end, if the IETF is going to adopt this policy, I would suggest that it should also have some ideas on how to implement it and on how it would fit into the broader Internet governance institutional galaxy.

x

3. This is not (common) law The draft seems to imply that the IETF is building a corpus of principle documents that are to be used as a binding reference to put an end to any doubt on how to apply the main guideline - basically, a "constitution" of the IETF. The draft actually lists RFC7754, RFC7258, RFC7624 and others.

x

I sincerely doubt that the policy realm in which we are working is so clear, static and globally uniform that you can express such broader principles and apply them at any time and in any circumstance without further thought. Actually, I think that you need to do the opposite - start with a tentative guideline, see if it actually works in practice, be ready to adapt it to changing circumstances or to new information that shows you that what you thought would work nicely is actually creating more problems than it solves, or conflicts with one of the other guidelines.

x

And if you still want to establish policy guidelines for protocol development, I think you need to set specifically high barriers for developing them. You must be really sure that they represent broad policy consensus that goes well beyond a small number of IAB or WG members, and - as they affect the whole Internet - beyond the IETF itself.

x

This is just a set of personal opinions, building on scarce IETF experience but a long personal history in Internet policy; I hope it can contribute usefully to the discussion and I will be happy to continue if the IAB decides to adopt this document.