IETF 70, Vancouver

As I said the other day, I’ve been at the 70th IETF meeting in Vancouver, BC, Canada. As usual, here’s my summary of the meeting, hidden below the “click here if you want to read the boring, geeky bits” link. I’m going to try to keep this shorter than usual. Some of the items will just be notes, rather than complete sentences. But it’s still pretty long.

Read the rest of the post...

Apparea — Applications Area general meeting

1. Announcement of Applications Area workshop, 11/12 Feb 2008.
2. Suggestion of Applications Area interoperability testing events — perhaps a full day of interop testing attached to an IETF meeting.
3. Request for a utf-8 advisor for the nfsv4 working group.
4. Brief discussion of question of identity-based encryption (IBE) and user authentication in email protocols. Issue will be discussed further by interested parties at the bar later.
5. Discussion of BCP 56 (RFC 3205): is this still the best current practice? Specifically, advice that new services should not reuse existing ports, contrasted with the use of http/80 for many non-web-browsing purposes. Conclusion: BCP 56 was meant to make sure people think about these things before they choose. It should stand, though maybe an update would be useful.
6. Presentation of a metadata format for files (see draft-garcia-sipping-file-*).
7. Presentations from netconf participants (Operations and Management Area) about a modeling language. One presentation using XML schemas. Second presentation of a homegrown modeling language called YANG. There was extensive discussion, and some heat. Ultimate question: “If we did a bof with YANG documents and other docs (XSD based), do people think we should do that?” Strong consensus in favour.

Sieve Mail Filtering Language

1. Document status: base doc is un-stuck (had been waiting for internationalization draft), and this frees a bunch of others.
2. Document status: body, notify, notify-mailto, notify-xmpp are in IESG processing.
3. Document status: edit header, mime loops, refuse/reject, regex are still being worked on.
4. Discussion of notify: have to sort out IANA registry issues. Decision to use RFC 2434, and refer to it.
5. Discussion of notify-mailto: Discussion of mail loop issues. Prefer to have a separate document, not from this WG, on mail loop detection and avoidance. Ackowledge that this doc will block on that. Discussion of using null MAIL FROM here. Discussion of not retaining Received headers in notification message.
6. Discussion of IMAP-Sieve (lemonade doc): Main issue is per-user scripts. Probably move to extension, probably leave the feature for delivery scripts, not IMAP-event scripts.
7. Brief discussion of other docs, no substantial issues.

Calsify — Calendaring and Scheduling Standards Simplification

1. 2445bis is in PROTO-shepherd review. One issue: is it OK to have RDATE < DTSTART ? Decision to take the issue back to the mailing list.
2. 2446bis (iTIP) issues discussion. Some small items.
3. Major discussion on RANGE parameter with day changes in recurring meetings.
4. Major discussion on SEQUENCE number — what its purpose is and how it’s used.

HTTPbis — HTTP updates

There were two HTTPbis sessions, but the second one conflicted with DKIM, so I missed it.

1. Presentation of HTTP history and lessons learned.
2. Charter review. Aiming to bring HTTP to “Draft Standard” status.
3. Discussion of the partitioning of the document into 8 parts.
4. Discussion of issues...
5. Loooooooooong discussion on ABNF conversion and logical whitespace (LWS) in ABNF for headers.
6. Some discussion of header-value internationalization. Decision: document reasonable RFC 2047 usage explicitly.
7. Brief discussion of character encoding defaults — existing language conflicts with MIME specifications. Noted that “guessing” is the best mechanism in practice, but someone pointed out that guessing wrong can cause problems that include security exposures.
8. Out of time, remaining items left for second session:
   • ETag in status messages
   • Clarify “requested variant”
   • Header line folding
   • Content negotiation for media types
   • Repeating single-value headers

IPR — Intellectual Property Rights

This session moved right along and ended early. The documents are essentially done, discussion wrapped up the remaining issues, and set us up for closing the working group. There were three proposals for new work; two were soundly rejected, the third had agreement that it should be pursued as an individual submission.

DKIM — Domain Keys Identified Mail

Tony Hansen and Murray Kucherawy presented the results of a DKIMinteroperability workshop that was recently held in the Dallas area.20 companies and organizations participated, and the interoperabilityresults were generally very good. A few minor issues were uncovered:edge conditions in the “relaxed” canonicalization algorithm, an ABNFerror, and similar things. We will submit errata to correct most ofthese issues, and add text to the “deployment” document for some others.

Jim Fenton presented a status update on the SSP draft, giving a reviewof recent changes and going over the open issues. Jim used quotes fromtwo “customers” early in his presentation, which prompted Dave Crockerto comment, and there was some significant discussion of theappropriateness of optimism in this regard, of some aspects of the SSPdraft that Dave considers wrong, and of Dave’s review of SSP, which he’dposted to the DKIM and Apps-Review mailing lists earlier that day. Further discussion of the review has been taken to the DKIM list (andthat discussion has already been quite active).

On the open issues: there was some discussion here and there, but a lotof discussion on one issue in particular: #1399: Clarify i= vs. SSP,“...need to provide the exact semantics in SSP of how a receiverdetermines whether a DKIM signature satisfies the SSP criteria or not.” The result of the discussion is that the chairs think we need one moreround, no more than a week, of discussion on the mailing list before wedetermine a closure for this issue.

We plan to start working-group last call after issue 1399 is closed andafter discussion has finished on Dave Crocker’s comments.

Doug Otis presented a (non-WG) draft, “DKIM Third-Party Authorizationfor Sender Signer Practices”.

Murray Kucherawy presented (non-WG) drafts dealing with passingauthentication results down the line (including all the way to the MUA). There was brief discussion about his draft for using an ESMTP extensionto pass the information, in order to reduce attacks against MUAs behindnon-compliant MTAs.

Tony Hansen presented a very drief status report (and call for reviews)on the Overview document and the new spin-off, Deployment andOperations.

EAI — Email Address Internationalization

1. UTF8headers doc:
   • Issue with specificatin of NO-WS_CTL. Decision to refer to 2822, note upcoming 2822bis.
   • Issue with normalization. Decision to refer to draft-klensin-net-utf8.
2. Core docs (UTF8headers, DSN, SMTPext) now ready to go to IESG.
3. Downgrade doc:
   • Issue with simple downgrade procedure. Decision that current section 8.1 is adequate.
   • Suggestion to split appendix A into a separate doc. Take discussion to the mailing list.
   • Needs review by people who have implemented it, then it’s ready for working-group last call.
4. IMAP and POP docs
   • Should we move “upgrading” — conversion up to UTF-8 — to clients, and remove it from here? Clients are better equipped to do whatever conversions are necessary, and clients know what they want. Also, conversion breaks message signatures. Consensus to remove, let clients do it.
   • Current IMAP draft uses lemonade “ENABLE” IMAP extension.
   • Switch POP to use UTF-8 “mode”, like IMAP, instead of duplicating commands? Decision: yes.
5. Discussion of whether “mailto” URL should be adopted now. Take to the mailing list.
6. Discussion of possible interoperability tests at one of the next IETF meetings.

lemonade — Enhancements to Internet email to Support Diverse Service Environments

1. Report on second interoperability event. Good results; things that were found broken at the first event have since been fixed.
2. Mostly covered document status and minor updates.
3. Some significant discussion on CONVERT, NOTIFY, and ENABLE.
4. Most of the discussion of ENABLE involved when it was allowed. Decision: only in authenticated, non-selected state.
5. Brief review of profile-bis status.

SAVI — Source Address Validation Improvements BOF

Problem statement: IP source addresses can be spoofed. Packet delivery is based only on destination addresses, to the spoofed traffic arrives, and hurts (attacks/threatens) the destination. It’d be nice to stop the spoofing, and existing solutions aren’t sufficient.

There are product solutions for ipv4, sold by Cisco and others, that work within a single switch. The working group wants something standard.

The trouble, as I see it, is that the charter is too limited:

Specifically, the group shall define solutions such that hosts attached to the same router cannot spoof each other’s addresses. The following assumptions apply:

• The WG considers only solutions on layer-3-aware Ethernet switches
• Two solutions are needed, one for IPv4 and another one for IPv6
• The IPv4 solution depends on tracking the DHCP traffic on a port
• The IPv6 solution depends on tracking the Neighbor Discovery and DHCP traffic on a port
• All address assignment mechanisms in IPv6 need to be supported, including stateless, stateful, privacy, and so on
• The solutions are turned on for host ports by configuration, and do not apply to routers

The WG recognizes anti-spoofing deployment efforts, motivation, and best practices development in various forums around the world (including RIPE). The WG is only chartered to deliver two specific solution components that such efforts could employ. The bigger questions are out of scope.

Normally, I would worry that a charter were too broad, but this just doesn’t seem to solve a problem that I think needs a standards-track IETF solution. Any company can already sell a switch with anti-spoofing technology in it. Another company can sell another, with different technology. There’s no issue of interoperability that I can see. The most I can see a need for is a BCP to tell hosts what to do to avoid running afoul of existing anti-spoofing techniques. If there’s a need for a WG to do that, OK (but I’m not convinced). But I really don’t see a standards-track issue here.

CSI — Cga & Send extensIons BOF

I have little to say about this. They have a solid idea of what they want to do, and a good plan for it. Almost everyone agreed that a working group should be chartered for it, they had some 20 or so people who said they’d be active participants, and 8 or 10 who said they’d be document authors. This seems ready to be chartered as a working group.

Peppermint — Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF

This one is decidedly less well baked, but they said that up front. They have good preliminary ideas about what they need, and used this session to bat it around in preparation for writing a draft charter. They seem to have succeeded in that, so we now have to see what the draft charter looks like.