Author Archives: Ted Hardie

ENAME Workshop

The IAB held a workshop on Explicit Internet Naming Systems last week in Vancouver, B.C., and there are a couple of interesting early conclusions to draw. The first conclusion is actually about the form of the workshop, which was an experiment by the IAB. While many of our workshops run like mini conferences, with paper presentations and follow-on questions, this workshop was structured as a retreat. There was a relatively small number of participants gathered around a common table space, with sessions organized as joint discussions around specific topics. Moderators kept the conversations on topic, and discussants kept it moving forward if it lagged.

The result was one of the most interactive workshops I’ve attended. While we did have to run a queue in most sessions (and the queues could get a bit long), the conversations had real give-and-take, more like an IETF hallway discussion than a series of mic line comments.
While I don’t expect that this style would be appropriate for all our workshops, it’s useful to know that this retreat style can work. I suspect we would use it again in other situations where the IAB is trying to step back from the current framing of an issue and synthesize a set of new approaches.

A second early conclusion is that the IAB was right in suspecting that its previous framing of the issues around Internet naming and internationalization wasn’t quite right. Among other things, that framing had us trying to push human interface considerations up the stack and away from the protocol mechanics that worked on what we saw as identifiers. One clear conclusion from this workshop was that the choice of identifier structure and protocol mechanics will constrain the set of possible human interfaces. When those constraints don’t match the needs of the human users, the resulting friction generates a lot of heat (and not much light). One suggestion for follow on work from the workshop will be to document the user interface considerations that arise from using different types of identifiers, so that new systems can recognize more easily the consequences of the identifier types they choose.

An additional point that came up multiple times was the role of implicit context in transforming references in speech or writing into identifiers that drive specific protocol mechanics. While the shorthand for this is “the side of the bus” problem, the space is much larger and includes heuristic search systems ranging from the educated guess through to highly personalized algorithmic responses. The participants saw a couple of possible ways in which standards developed in this area might advance how these tuples of context elements and references can be safely used to mint or manage identifiers. A first step in that will be to suggest that the IAB look at language tags, network provider identifiers, and similar common representations of context to see how they function across protocols. Follow on work from that might include developing common vocabularies, serialization formats, and analyzing privacy implications.

Like many others, I came away from the workshop with the realization that there is a dauntingly large amount of work to be done in this space. The workshop participants are drafting more than a half dozen follow-on recommendations for the IAB, as well as describing a potential research group and producing some individual drafts. Despite the amount of work facing us, I and many other participants left the room more hopeful that we came in, both that we can make progress and that some of the tools we need are already available.

If you’d like to join in the conversation, you can share your comments on Internet naming by email to architecture-discuss@ietf.org or directly with the IAB at iab@iab.org.

What does “Internet Access” mean?

On the joint day of the the recent IESG and IAB retreats, the group discussed a number of topics related to network operator activities for encrypted flows. As part of that conversation, the group looked at RFC 4084, which tackled the question what “Internet Access” means. A dozen years on, that subject probably deserves a new look, and several of the folks at the retreat agreed to draft a new version for community review.

As one of those volunteers, I’d like to dive into RFC 4084 a bit and explore what may have changed since it was published. After walking through the need to avoid pejorative terms, the RFC sets out the following types of connectivity: web connectivity; client connectivity only with no public address; client connectivity only with a public address; firewalled Internet connectivity; and full Internet connectivity.

For those who have bought enterprise connectivity recently, it’s obvious that several common categories are missing: dark fiber, lit service connectivity to a home office, managed MPLS tunnels, and so on. More importantly, though, the RFC doesn’t really touch on cellular wireless connectivity at all, which is now one of the most common ways people connect to the Internet. That means that it doesn’t touch on topics like data caps, roaming for data services, zero rating, or data compression proxies. For cellular connectivity, those can be the key to understanding the trade-offs in connectivity, privacy, and costs for a particular service offering.

Beyond that proliferation in available offerings, there has been another major change, in the ubiquity of filtering. RFC 4084 describes filtering at the ISP level in section 3 and notes “the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services”. RFC 7754 has since provided a much more detailed description of blocking and filtering, and it highlights restricting objectionable content as a category beyond blocking objectionable traffic. That blocking may be a requirement imposed by state regulators. In those jurisdictions, what RFC 4084 described as “full Internet connectivity” has disappeared, because service providers are required to prevent their customers from reaching specific Internet resources, services, or destinations. Even where blocks are not in place, regulatory increases in the amount of Internet tracking data retained and the length of time it is kept have become common. These may contribute to self-censorship in the use of some content. Put simply, firewalled Internet connectivity has become the default offering required of service providers within those territories.

Lastly, the document describes Internet connectivity in terms that apply to the services which would be consumed by a human user and, though some social networking or streaming services are not included, it is generally useful in that regard. As we move into an era in which devices talk to other devices, we also need to examine what a service provides for traffic among devices or between devices and back-end services. Is the implication of a web-only service that the Internet of Things is not supported, or is the implication that it must be reached by a web-based gateway or proxy? The difference between those two is a serious topic of contemplation now, and the architecture of a number of services will depend on it.

In many cases, the architecture of the Internet has developed in the course of a commercial dialog between network operators’ offerings and consumers’ use. Many efforts to make cellular systems walled gardens failed, for example, because the users simply weren’t willing to use them that way and wanted the broader connectivity of the Internet. As we look at this new tension among users’ desires for confidential communication, network operators’ management practices, and regulatory frameworks, a common vocabulary for the services available to the user may help us understand what architectures we can build. If you’d like to contribute to the early discussion, architecture-discuss@iab.org is one place to start.

Ted Hardie
IAB