Subject: [ietf-dkim] Summary of jabber meeting on 2006-05-25

From: Barry Leiba <[email-masked]>
Date: Thu, 25 May 2006 16:18:24 -0400

Before I get into the summary of the jabber meeting, I want to say this:

We finished getting through the open issues, and there are just a few 
that need more discussion on the list.  I've asked Eric to work on 
getting an -03 version out, after mailing list discussion of those few 
issues, within two weeks.  That means that (1) everyone MUST read -02 
and make sure that it's ready (modulo these few open items), and (2) we 
must get these last few items discussed and sorted through, and we must 
all focus on resolving our differences on them and finding a consensus 
that we think works.  Please hold to hard lines at this point only when 
compromising on that item will truly be harmful.  I know we can get this 
wrapped up and ready for Working Group Last Call on the -03 version of 
the document!

-------------------------------------------------------------------

We called today's jabber session to order today at 15:00 UTC, and went 
through the remainder of Eric's issues list, starting where we left off 
last week.  Eric's list does mostly match with Eliot's, and we referred 
to Eliot's for the details of the issues.  For reference, some pointers:

Last week's log:
  http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html
This week's log:
  http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-25.html
Eric's issues list:
  http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html

In attendance:
Barry Leiba, Stephen Farrell, Paul Hoffman, Doug Otis, Peter Koch, Eric 
Allman, Mike Thomas, Jim Fenton, Dave Crocker, Tony Hansen, Bill Oxley.

The bits in quotes at each issue title are quoted from Eric's list.

Issue 1263: "(get rid of x=): I /think/ this has been resolved."
Participants did, indeed think it has been resolved; issue should be closed.

Issue 1264: "(proposed fingerprint tag description)."
This was proposed by Murray, who wasn't on the jabber chat, and the 
participants didn't know enough about it to discuss it in Murray's 
absence.  Issue remains open; push it back to the mailing list.

Issue 1265: "(signing by parent domains)."
Some see potential issues with the ability to say something like 
"d=example.com" and "i=sub.example.com".  In particular, there's the 
danger of something like "d=com; i=example.com".  Some think there's 
little benefit to allowing it, and closing the hole would be better. 
Others see a great benefit, allowing example.com to have one place to go 
for keys, while signing for many subdomains.  Eric suggests this: 
"thought: a domain could use a CNAME for _domainkey.<dept>.example.com 
that would point up the tree." Jim Fenton will start a thread about this 
on the mailing list.  No resolution for now; leave open, discuss on 
mailing list.

Issue 1266: "(sec 5.2 move recommendations for key retention to a BCP)."
Lots of discussion about whether to specify a length of time or be vague 
about it, whether being vague is of any value to implementors, and 
whether it even makes sense to try to tell verifiers what they MAY or 
SHOULD do, since they can (and will) do whatever they want anyway.  In 
the end it seems that a modification of Doug's proposed rewording can be 
acceptable to all, so Eric is going to do another pass on the wording 
and post it to the mailing list.  Issue remains open until then.

Issue 1267: "(expiry based on received time rather than current time)."
Doug is happy with what's in the -02 draft on this, and no one else 
voiced any concern.  Close.

Issue 1268: "(format of t=)."
The issue is whether to leave this as an integer representing seconds 
since 1970, or whether to change it to some more readable version, which 
might be easier to compare with other fields in the message.  Brief 
discussion, which included a "not broke, don't fix it" comment.  Chairs 
agree and suggest no change unless there's a "really good reason to 
change it." Much agreement, and no "really good reason," so issue is 
closed with no change to the spec.

Issue 1269: "(body length mechanism rejections)."
Looks like we're happy with what's in -02, but just as we start to move 
on there's more discussion along the "can't tell verifiers what to do" 
line.  The original issue was an objection to advising verifiers to 
"reject", and the consensus on that, as advice, stays.  In particular, 
we want to advise verifiers on determining whether a signature is 
*valid*, but leave the "what to do with it" part for another document 
(or local policy).  Tony doesn't like the advice to ignore the 
signature.  Others clarified that what we're really saying is to look at 
the other sigs in that case.  Most accept current wording, but there's 
some unhappiness all 'round, so it's not optimal.  Dave and Eric will 
collaborate on another iteration of this text, to try to resolve that 
and to make it clear what's normative and what's a recommendation. 
Issue remains open.

Issue 1270 is an error -- title duplicates 1269, content duplicates 1271.
Should be deleted.

Issue 1271: "(Binary algorithms and algorithm spoofing during a 
transition.)"
Little discussion, no support for Doug's position ("No one else thinks 
this is a problem.").  Close.

Issue 1272: "(when i= domain != d= domain)."
Everyone is happy with Doug's proposed change, but Jim points out that 
issue 1265 affects this.  Consensus to accept this now, with the 
realization that the whole text may change again depending upon what we 
decide about 1265.  Eric notes that this change is already in -02.

Issue 1274: "(r= for instilling good domain-name practices)."
Consensus that (1) there's no support on the list (nor on the jabber 
chat) for this, and (2) it can be added later if we decide it's needed, 
so it needn't be done for -base.  Mostly, there was some sympathy for 
wanting a distinction between "I vouch for it," and "It came from my 
domain, but I don't vouch for it." It's just that there's skepticism 
about whether it belongs here, as opposed to in a reputation service. 
Close this one.

The jabber meeting was adjourned at 16:02 UTC, with thanks to all for 
participating.
We're planning another for next Thursday, same Bat time, same Bat 
channel.  We'll review, at that time, progress on the issues that have 
been sent back to the mailing list, and see where we are on preparing 
-03 for WGLC.

-------------------------------------------------------------------

Barry Leiba, DKIM Working Group Chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html