IETF 75, Stockholm

The 75th IETF meeting was held last week in Stockholm, Sweden — a nice place for an IETF meeting. The weather was pleasant, the conference center was a very workable venue, there are lots of reasonable places to eat in the area, and there’s a good choice of hotels. The meeting itself was not in a hotel, and that’s sometimes a disadvantage, but the many hotels in the area and the good weather made that situation work fine this time.

The city of Stockholm was apparently very pleased to have us there, and they paid the significant cost for the opening reception, for which they had us come over to the Stockholm City Hall (Stadshuset). The mayor addressed us in the room where the Nobel prize banquet is held — the “Blue Room”, which is not blue — and we had a chance to see the “Gold Room” — which is gold, or, more correctly, heavily decorated with gold.

The Tuesday night social event — the only time during the week that many of us have to escape, though, well, even there we tend to talk about work — was at the fascinating Vasa Museum, a maritime museum that displays a 17-century ship that sank on its maiden voyage.

This meeting included about 1100 attendees from 50 countries, and nearly a quarter of those present were from Asia. And I got two new IETF jobs at this meeting: the IAB appointed me as liaison to the Messaging Anti-Abuse Working Group (MAAWG), and the Applications Area Directors appointed me as working group secretary for the Message ORGanization (morg) working group, asking me to help keep the work moving and shepherd some of the documents.

A few photos of the venue; click to enlarge:

The convention center — Scandinavian design.	Restaurants and shops around the corner.	City Hall on an overcast Sunday afternoon. There are better photos on Wikipedia and at the Stockholm site.	The Gold Room (Gyllene Salen) at City Hall.

 

As usual, I’m keeping the detailed meeting report off the front page (unless you’re reading the RSS/Atom feed). Click here to read the detailed report.

Detailed report...

The calsify and lemonade working groups did not meet this time. Both are winding down, and much of the current work of calsify has shifted to the CalConnect organization. The new oauth group did not officially meet, but held an informal breakfast BOF to discuss its status and issues (see below). The httpbis group did meet, but I wasn’t able to attend because of a schedule conflict — only one schedule conflict isn’t bad for a busy IETF meeting.

apparea — Applications Area general session

The apparea general session is meant to give an overview of Applications Area meetings for the week and to cover items of interest to people who follow the area in general. This time, in addition to the introductions to the BOFs, both formal (OGPX) and informal, we had brief looks at these items:

1. Issues with using FTP in a mixed IPv6 and IPv4 environment, especially considering using translators as a last resort for clients or servers that don’t support the EPSV and EPRT commands.
2. An introduction to SCTP, with the idea of promoting it as an alternative to TCP for some applications (such as HTTP).
3. A proposal to pull the vendor name registry from the ACAP protocol specification, so it can be used more generally. Brief discussion here as to whether we need to use readable names (and if so, what characters should be valid), or whether the enterprise numbers that are already extensively registered would be preferable.
4. Continuing the discussion on a timezone registry and protocol, which came up in the vcarddav session at IETF 74, and which I wrote an initial draft of at that time. This may turn into a working group, because of the potential complexity.
5. Suggestion to move the SPF and Sender ID specifications, currently “experimental”, to “historic” status. It seems clear, after the discussion, that the consensus is against any such idea.
6. A proposal to create an Abuse Reporting Format (ARF) working group, based on the Email Feedback Reports draft.
7. An introduction to my proposed Message Recall draft, which will be discussed in more detail in the morg working group session.
8. An introduction to Zhipeng Zhou’s DRM Proxy Architecture draft, which I presented in Zhipeng’s absence. No one expressed interest during the meeting, but someone approached me afterward, and I put him in touch with Zhipeng.

idnabis — Internationalized Domain Names in Applications, update

The idnabis group had scheduled two sessions at this meeting, but finished its work in the first one. This is a group with a potential to debate minor issues and edge conditions endlessly, and the chair necessarily called the discussion, declared consensus on what we have, and moved toward wrapping up the documents and closing the working group.

A main point, here, comes from the chair’s slides: “No amount of mapping, contexting or restricting will absolutely prevent phishing or confusion. Nor can those measures force absolute consistency among system or between applications on the same system.” In other words, we need to do the necessary fixes and updates, but can’t argue forever about character combinations that could confuse people if they’re abused — it’s an unfortunate side effect of the character-set flexibility that’s very much wanted in this space, and it’s up to the registries to handle some of the issues through policy.

The principal remaining issue that was discussed was that of normalization of text, to avoid comparison problems with different encodings of the same character. The desire, here is to avoid having a user type exactly what she sees, but not have it match because the encoding differs.

eai — Email Address Internationalization

The main point in eai is to finish the remaining documents — primarily the unicode IMAP and POP specifications — and to collect the implementation experience and prepare to move the documents from experimental to standards track.

The primary issue with the POP document is whether commands that return message sizes, in bytes, can return inexact sizes. The sense is that these sizes are mostly used to set thresholds, and not to download too-large messages without warning the user, or some such. Terminating the actual RETR command is done by looking for the ending delimiter, regardless of the expected message size. The reason to allow inexact sizes is to defer a possibly expensive conversion until the message is actually retrieved — it could be a serious performance hit to have to convert 1000 messages for a LIST command, when only one or two winds up being downloaded. Consensus is to allow the sizes to be inexact, with warnings in the spec about its effect on clients that might not be carefully and defensively written.

Some basic testing has been done with the SMTP extensions, but the working group has no real experience with downgrading unicode addresses. Still undecided is whether we should retain the downgrade capability and get some experience with it, or drop downgrade and move to standards track without it.

Also uncertain at this point is how the mailto URL and mailing lists will fall out. These issues remain open to ongoing discussion.

dkim — Domain Keys Identified Mail

The DKIM working group’s chartered work is nearly done (the last document is in working-group last call, and two others are now in the RFC Editor queue), so the goal of this meeting was to discuss implementation reports and draft-standard progression for the base protocol.

Dave Crocker has posted implementation surveys to the mailing list, but has so far gotten few replies. Working group participants were urged to complete them, and to pass them on to others. I will pass them to MAAWG and urge response, as IETF liaison to MAAWG. I would also like to collect data not only on feature use by signers and verifiers, but also on what use the verifiers make of the results.

There was much discussion about dropping unused or little-used features in the process of going to draft standard. We noted that RFC 2026 requires dropping features that are truly unused, but whether to drop others is a different question. Several opinions were given about keeping all features, because, while there’s plenty of experience with signing and verifying, knowledge of usage of the result of verifying is still limited. We don’t yet know what verifiers will decide is important, over time. Counter-argument: history shows that when we learn that, we’ll find that the features we kept purely speculatively will be the wrong ones anyway.

Informal vote showed approximately a 2-to-1 preference for keeping all features, versus removing some. The chairs don’t consider that to be sufficient for “rough consensus”, so it will be discussed on the mailing list. Pasi Eronen pointed out, and the chairs agree, that because we had consensus on these to start with, the default action, lacking clear consensus to remove a feature, is to keep it.

There was also discussion indicating that documenting DKIM use cases could be helpful. Perhaps more of these could be added to the “deployment” document (in working-group last call now), or perhaps they could be recorded in an easily updated wiki.

ogpx — Open Grid Protocol BOF

This BOF session was a follow-on to the MMOX BOF at IETF 74. That one explored topics and interest in standardizing virtual-world protocols, and its result was clear direction to narrow the focus to something manageable — which led to this. OGP is a specific protocol proposed by Linden Research that will bite off just a small piece of the cake by allowing defined communication between worlds that are similar to Second Life.

After an introduction to the concept of OGP — which was itself interrupted by a great deal of discussion — the main goal was to bash out the charter. Apart from some obvious edits that will be needed, like listing explicitly the drafts that will be used as starting points for the work, a firmer and clearer list of deliverables, and so on, a few significant issues arose:

1. Several participants thought that the terminology was unclear to those who have not already been working on it. The charter should try to fix that to a reasonable extent.
2. Several participants were confused by the reference to “grid”, expecting to see something related to what’s normally called “grid computing”. A new name will be chosen.
3. While “the protocol allows virtual words to interoperate” is a good, broad statement, several participants argued for more specificity. The charter should be clear about what, exactly, interoperates, and what doesn’t.

The result of this BOF session was a strong consensus to do this work on the IETF, and what seemed to be a sufficient number of people actually interested in working on it (writing and reviewing documents) to make a go of a working group. Joshua Bell quickly posted a “charter issues” list to the ogpx mailing list, and it is being discussed. Their goal is to have the charter updated, with consensus behind it, within the next couple of weeks.

vcarddav — vCard update and CardDAV protocol

In vcarddav, the CardDAV documents are nearing completion, some ready for shepherd write-up and others with just minor issues remaining. For vCard, the main issues involve the timezone and vendor registries. For vendor registry, consensus is to start with the enterprise number.

I presented the social networking extension draft, written by Robins George and me. At the moment, it’s very preliminary, and we have to get together with the FOAF folks to refine it. An issue here is that because the old vCard format lacks a hierarchy, it’s hard to tie properties to specific social networking systems. One suggestion was to have this apply only in the XML format. Another was to allow an XML blob. This fed into a discussion of how to encode XML within the old format, resulting in consensus to have a single base64-encoded XML chunk as an “extension element”.

oauth — Open Authentication Protocol informal BOF

This is a new working group, formed after two BOFs at earlier IETF meetings. The group wasn’t able to get things going (and would be missing some critical people) for an official session at this IETF meeting, but it set up an informal early-morning meeting that drew around 15 participants.

The group had a brief, informal discussion, to be continued on the mailing list, to get started on a few issues:

1. Handling callbacks.
2. Non-HTTP use cases, such as access to shared calendars and authorization over XMPP.
3. Authentication vs authorization, and using oauth for authentication — perhaps defining new SASL mechanisms.
4. Channel bindings in oauth.
5. Distinguishing cases involving the number of “legs” in the authorization request.
6. “DKIM for the web”, using oauth’s header-signing aspects separately.
7. Extensibility.
8. Conflict between habit of oauth community to discuss on Google groups, and the IETF oauth list.

sieve — Sieve email filtering language

For the sieve working group, we have the Notary and Include drafts ready for working-group last call, Notify SIP waiting for RAI review (chairs will push for this), and IMAP-Sieve waiting for input from Ned Freed as well as review on the mailing list. Because both chairs are authors on the Include draft, a separate document shepherd is needed; I volunteered.

I worked with Alexey in the last couple of weeks on some changes to the External Lists draft, cleaning up the security considerations and implementing some changes discussed on the mailing list. Even with those changes, though, there were concerns: the main issue is how to specify the list in a portable manner, given that the Sieve engine has to know how to interact with each specific list. Jeff Hutzelman suggested using a two-part identifier, one specifying the type of list, the other specifying the name. There seems to be consensus on this, which now needs to go back to the mailing list.

There was quite a bit of discussion about reviving the Regular Expressions document. The document author will choose which RegEx syntax to use, and we discussed how it will interact with the other features and extensions.

For Robins George’s Autoreply draft, we considered having it extend Vacation to allow a “force” option so auto-replies are not limited to one per day. There appears to be consensus for that.

We discussed the interaction of Sieve with EAI, and decided, again, that we’re still waiting for EAI to move ahead before doing anything about it in Sieve. The main issue that we see is how comparisons will work with the two-part downgradable addresses.

morg — Message ORGanization extensions

Status of morg documents:

• Status In List: Mostly done. I did an editorial pass and sent the result back to Timo. I had also raised the issue of limiting LIST responses, but we’ve decided that I should post that to the list as a separate item, because it’s really an issue with LIST in general, and not with this document.
• Sort Display: The only open issue is how to handle address groups. Consensus is that the author can just “flip a coin” between using the first address in the group, or using the group name. The draft has to add DISPLAYTO and DISPLAYCC, along with DISPLAYFROM... otherwise, it appears to be done. Dave Cridland will do a formal review.
• Fuzzy Search: Also essentially done. Minor issues have recently been resolved. Some minor discussion in the meeting, but nothing significant.
• Multi-Mailbox Search: Security considerations need more work; otherwise, it needs more review before we declare it done.

I then presented the Message Recall draft, and we had a good discussion on it. There was clear agreement that, while some people appreciated the reasoning behind the two-stage hold/recall option, it caused too much complexity and was unlikely to work anyway. I’ll drop that in the next revision. The other change we agreed on was to put it on top of message tracking (RFC 3885, RFC 3886, and RFC 3887); I’ll make that change in the next version also, with help from Chris Newman in getting the security details done. Jacob Palme suggested reviving his 10-year-old “Replaces” header, which certainly could apply here. Consensus is to go with the message tracking approach instead. Consensus is also to adopt this as a working-group document; will confirm on the mailing list.

hybi — Hypertext Bidirectional informal BOF

There are a number of uses of HTTP where the server needs to push something to the client. Currently, this is often done with some sort of polling — either “short polling”, which is the normal type of polling where the client keeps asking the server for any updates, or “long polling”, where the client asks the server something and the server doesn’t answer until it has an update to give, leaving the request open for a long time. Implementers would prefer a “bidirectional HTTP” mechanism, and several approaches have been discussed.

The purpose of this informal BOF was to discuss the requirements and possible solutions, and to see if there’s interest in trying to form a working group to work on this further. This also involves coordination with the World Wide Web Consortium (W3C) — broadly, W3C owns the data format (HTML, XHTML) and the IETF owns the protocol (HTTP), but it’s not always clear what fits where, particularly as we look at proposals such as Bidirectional Web Transfer Protocol (BWTP) and Web Sockets.

The first thing that’s clear is that the work needs to be scoped with a requirements discussion followed by nailing down some design issues. There are currently too many proposals with different characteristics and different “sweet spots”. There are also political issues involved, as I said above (W3C vs IETF).

Consensus at the informal meeting was to set up a formal BOF at IETF 76, clean up the current drafts before them and get everything submitted and ready, and see if there’s enough interest at IETF 76 to work on chartering a working group.

yam — Yet Another Mail working group

This was the first formal meeting of a new working group that’s chartered to take a set of email-related documents that have draft standard status and advance them to full standard. The major documents in the list are the current versions of SMTP, Internet Message Format, and Message Submission, and the five-part MIME specification. A handful of minor documents fill out the list.

The main points of discussion for the meeting were how to approach the particular set of documents, considering the dependencies and the technical aspects of the documents on the list, and the template that Chris Newman has proposed for presenting each document to the IESG.

The most difficult issue, one that took up a good bit of time, was how to handle the formal syntax in the MIME documents. Based on the original RFC 822 format specification, they use the old ABNF from that document, and they point to specific elements defined in that document. The newer RFC 5322 document, though, uses the newer ABNF defined in RFC 5234, and fixes the definitions of some of the elements that MIME uses. Doing a complete conversion to the RFC 5234 language will be error prone, and would arguably push us to another round at draft standard (or even proposed standard) while it was tested in the field. Staying at the RFC 822 language doesn’t work, because of the corrections made in RFC 2822 and now RFC 5322.

In the end, we decided to stay with the RFC 822 syntax for elements defined in MIME, but to refer to RFC 5322 for the updated elements. And we decided to include text warning about the two slightly different ABNF formats used. Meanwhile, we will go about converting to the RFC 5234 ABNF completely, as a parallel effort. Tony Hansen and I agreed to work on that task.

IRI issues informal BOF

The purpose of this meeting was to look at issues with the current Internationalized Resource Identifier (IRI) specification, which have prompted work on an update to that specification. There was also a concern about how to proceed with getting the original RFC updated.

Consensus is that the remaining issues could be cleared up and the document could be entered as an individual submission, rather than doing it through a working group. If a working group is needed, one would have to be created for this: there’s no clear home for it.

I’ve volunteered to help with shepherding and other process issues, and the goal will be to have it ready to go as an individual submission by IETF 76. If that doesn’t work out, we can do a formal BOF at IETF 76, and proceed from there.

Technical plenary presentation on network neutrality

When I was on the IAB, I started work on a plenary presentation about network neutrality. When I left the IAB, new IAB member Marcelo Bagnulo took over the arrangements. I stayed involved, though the session developed into a very different one to what I’d intended, which had been a four- or five-speaker panel, including representatives from content providers, service providers, legislators, electronic freedom advocates, and the IETF itself.

Though the changes narrowed the scope significantly, I think it was a very successful plenary presentation. The topic was relevant to everyone in attendance, and I know a number of people who listened to the live audio feed from home, as well. Barbara van Schewick, a professor at Stanford Law School, presented some of the issues, specifically focusing on “blocking” that service providers do, “driven by their interests.” She looked at the effects that has on users’ experiences, and at the role of regulators. And she considered the concept of paying extra for higher levels of service, and the question of whether (and to what extent) that’s discriminatory.

Mark Handley then spoke about the IETF’s role, specifically looking at blocking, rate limiting, and prioritizing traffic, but considered it primarily from the perspective of security and network congestion, because that’s where he sees the IETF as having something to contribute. Providing protocols to identify and control traffic can, he posits, replace the use of deep packet inspection and other such problematic techniques. We should consider such things as improved congestion-control mechanisms and protocol-level denial-of-service-attack protection.

The lines at the floor mics were long, though it was not so much a Q&A period as it was a chance for people to go on about their views of particular aspects of the net neutrality debate. That’s where I’d have preferred my original panel format, where we could have gotten comments about the issues from the different sides. Still, the participants were all eager, and it was clear from the comments at the mic that this topic interests many people and that discussion of it belonged here.

ISOC DNSSEC presentaion

Following its successful IPv6 press event at IETF 74, the Internet Society held a press event over lunch on Tuesday to present DNSSEC status and to encourage further deployment. There were no surprises here, as this really was meant for publicity, rather than technical work. Apart from the ISOC introduction, five speakers, from ICANN and several network registries, talked about what they’ve done to secure their respective portions of the DNS, and what their plans are for the future.