Thursday, July 13, 2006

.

IETF 66, Montréal, partie deux

A church in Vieux MontrĂ©alHere's the second and last highlight review of meetings from the IETF 66th meeting in Montréal, along with a photo of a church in the "Vieux Montréal" section (click to enlarge). Today's entry covers Wednesday and Thursdsay.

DKIM — Domain Keys Identified Mail

I gave a very brief view of Tuesday's DKIM session already, but here's the executive summary we presented at the Secutiry Area general meeting. Jabber logs are here for Tuesday and Wednesday.

The working group chairs had asked for help from the DNS directorate about whether DKIM needs to define a new DNS RR or it's ok to use thecurrent approach of a TXT record for distributing the public key. The feedback is that although there's some unhappiness with the TXT approach, in this case it appears to work. So the approach for the base specification will be to include the TXT record definition and not to define a new RR for public keys.

The base spec is in working-group last call, ending on 21 July. Almost all issues are closed or should be closed in a draft-ietf-dkim-base-04 document to be posted this week. The main issue remaining is whether ornot the "relaxed" body canonicalization should remain in thebase document; we don't yet have rough consensus on this. We plan to try to sort that out on the mailing list.

We started discussion of Sender Signing Policy/Practice, which is intended to allow signers to announce their DKIM-related practices. A couple of drafts exist that outline proposals. Discussion here is just at the very start and there were some requests that we try to establish concrete requirements before going futher.

We now have a draft of the DKIM Overview document, intended to be informational, which is also up for discussion.

Paul Hoffman announced the formation of an industry group called the Domain Assurance Council (DAC), which will rely on DKIM for its work.

Atompub

The atompub work is essentially done, and this meeting was quite routine. It started with an overview of the group's work, and a brief explanation of the atom protocol, extensions, and status. There was discussion of how atom can be used in other work, with a presentation of use of atom over XMPP. You can see the jabber log, but there's not much there.

DMSP — Distributed Multimodal Synchronization Protocol

At IETF 65 in Dallas, we had a presentation at the Applications Area general session about DMSP; this time, there was a BOF session for the group (jabber log). The goal is to standardize a protocol (for which a version already exists) to allow applications to synchronize DOM objects.

The presenters demonstrated a use model wherein a mobile phone browser is used in conjunction with a voice server, allowing mixed interaction with the application, both through normal browser actions and through voice. There was discussion about what they're trying to standardize, why Widget Description Exchange Service (WIDEX) isn't adequate for their needs, and whether there are enough IETF participants interested in doing this to form a working group. In the end, no one in the room except the presenters were willing to commit to working on it. The question will be taken back to the mailing list, but it currently looks like they might best try submitting it as an individual submission, rather than going through a working group.

Operations and Administration Plenary

The O&A Plenary is where the IETF Chair says things, and the host company says things, and the various sub-organizations say things, and there isn't really much to be said about all that. We then have an open-mic period. In this case, before the open-mic time we had a presentation by the IETF Chair, with subsequent discussion, about whether we should work on changing the IETF standards process.

The IETF current uses a three-stage standards process: documents are submitted as Internet drafts, and the fist stage of the standards track is when an Internet draft gets an RFC number and becomes a Proposed Standard. After a time, along with the demonstration of at least two independent interoperable implementations, the proposed standard can progress to Draft Standard (which should not be confused with Internet drafts). Finally, mature, widely deployed Draft Standards can progress to Standard (also called "Full Standard", to make it clear).

The reality is that there are a great many mature, widely deployed standards that remain forever at Proposed Standard. There's little incentive to expend the effort needed to move standards through the process, and some think the process should be changed. Brian presented three alternatives (with an implicit fourth of "do nothing"), and there was much discussion, but no resolution.

Technical Plenary

The technical plenary is the Internet Architecture Board's (IAB) time to talk to us. The IAB oversees the Internet Research Task Force (IRTF), and this meeting started with a report by the IRTF chair, followed by a more detailed presentation by the chair of the IRTF's Scalable Adaptive Multicast (SAM) reseach group. The IAB chair then gave us this year's IAB presentaion, and the IAB members took the stage for an open-mic panel discussion.

Discussion included some IETF process issues, including decision appeals, RFC editor functions, and the like. It also included, yet again, Internationalization issues. The discussion on the appeals process went on for a while — and gave us the interesting information that our appeals process exists because getting insurance required that we have one. Hm.

There was also a good bit of discussion about what Internet issues exist now, what's coming in the next few years, and what role the IETF can play. Discussion went not just to Internet protocols, but issues of net neutrality, eavesdropping, and other such things.

For the last item, there was a brief presentation and an open-mic discussion of the IETF process for independent submissions, where the IETF publishes, but does not take responsibility for, a document.

No comments: