The DKIM working group session was held on Monday afternoon, with Stephen Farrell 
and Barry Leiba co-chairing.  56 people signed the blue sheets.

The meeting's goals were to move the Sender Signing Practices specification 
along, and to highlight the Overview document and bring the working group's focus 
to it.  We started with a review of document status:
* DKIM base protocol specification is now RFC 4871.
* SSP requirements document is with the IESG, working out some last-call 
comments and an AD "discuss".

Jim Fenton gave a review of the SSP specification, the latest version of which 
has just been accepted as a working group document, draft-ietf-dkim-ssp-00.  Jim 
covered the principal changes to the document since the last review, in Prague, 
and discussed three main items in detail:
* Issues involving DNS wildcards.
* The SSP lookup algorithm, as documented in the current spec.
* What SSP publishers can say, outlining, in particular, a new option called 
"strong", in addition to the original "strict" (if it stays, the name will 
change).

There was some discussion of the algorithm, but most of the discussion was about 
what can be stated, and what the relative meanings of "strict" and "strong" are. 
We considered the idea that we have developed statements that we think the 
signers will need, but we have to validate them with those who will benefit the 
most from signing and declaring signing practices.  Dave Crocker and Phillip 
Hallam-Baker agreed to interface with MAAWG and APWG, respectively, to try to get 
their opinions on this.  Phill also stressed his opinion that SSP statements 
should be declarative, not imperative ("I am a financial institution," rather 
than, "I would like you to delete mail that appears to be from me that is 
suspicious.").

Tony Hansen presented the status of the DKIM Overview document, currently 
draft-ietf-dkim-overview-05, which has had a lot of work from its authors but 
which has had relatively little feedback from the working group.  The discussion 
centered on the goals of the document, and strengthened the result from the 
Prague meeting: the document should be split into multiple ones, to better 
achieve its several goals.  In particlar, there's normative text in the document 
now, which isn't appropriate for an informational document.  Some of that will be 
resolved by changes to the text, but some may be resolved by splitting a BCP or 
standards-track document off from the informational portion.  The authors will 
work on this, and we'll keep the ADs involved as we consider changes to the 
charter for this.

In the few minutes at the end, Murray Kucherawy led a brief discussion of his 
authentication-results draft, which the working group will follow, and will 
consider adding to its charter if we (and the ADs) decide it's appropriate.