Subject: [ietf-dkim] Ticket #11

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 Apr 2011 14:17:03 -0700

> Maybe it can be reworded:
>
>     A single domain name that is the mandatory payload output of DKIM and
>     that refers to the identity claiming responsibility for the signed
>     message introduced into the mail stream.

+1

This nicely removes reference to the act of introducing and, indeed, that act 
isn't really what DKIM covers, per se.

However I suggest adding the usual waffling qualifier:

    claiming (some) responsibility

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Apr 2011 14:19:31 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Tuesday, April 26, 2011 2:17 PM
> To: DKIM IETF WG
> Subject: [ietf-dkim] Ticket #11
> 

I think we should drop "signed" from it, since that's what the entire specification is about in the first place.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Apr 2011 14:43:05 -0700

There sure seems to be an awful lot of changes going on for a
supposed draft standard document. I for one can't keep up with
the rate of change, and I doubt anybody else can either. I really
don't care if each individual piece can -- microscopically -- be
justified within the process of draft standard:  I have no way
to determine whether these changes as a whole constitute a
compatible protocol with 4871 or not.

Bugs happen. Going from proposed to draft should be akin to
making changes to a running system -- few and only when
urgently needed. I can't believe that the bulk of the changes
are anywhere close to that threshold. And it seems to be
getting worse in the home stretch, not better. This is made
far worse because the vast majority of people who contributed
to 4871 aren't paying attention to the changes.

Mike, recycle or rollback at this point seems more fitting
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 26 Apr 2011 17:50:26 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, April 26, 2011 5:20 PM
> To: DKIM IETF WG
> Subject: Re: [ietf-dkim] Ticket #11
> 
> > From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave CROCKER
> I think we should drop "signed" from it, since that's what the entire
> specification is about in the first place.
> 

I think it is better to leave "signed" in. It is explicit and correct.
Consider the case of a signer which (intentionally) does not sign all
mail that it might.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Apr 2011 16:03:55 -0700

> [email-masked]] On Behalf Of Michael Thomas
> Sent: Tuesday, April 26, 2011 2:43 PM
> Cc: DKIM IETF WG
> Subject: [ietf-dkim] despair
> 

Barry has asked me to prepare a "diff" of sorts that compares RFC4871 with RFC4871bis so that we can all see the distillation of the proposed changes.  I'll be doing that in the next day or so.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Apr 2011 16:30:46 -0700

> Barry has asked me to prepare a "diff" of sorts that compares RFC4871 with RFC4871bis so that we can all see the distillation of the proposed changes.  I'll be doing that in the next day or so.
When you commit a 20 page diff without the benefit of a debugging
pass and dev test, how much confidence do you have in that commit?

At this point, we have no reason to believe that a new implementation
from this draft would interoperate with existing implementations.

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Apr 2011 11:35:55 +0200

> I think it is better to leave "signed" in. It is explicit and correct.

Could be more explicit:

  A single domain name that is the mandatory payload output of DKIM
  and that refers to the identity claiming some responsibility for
  the message by signing it.

(I've left off "introduced into the mail stream.")
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 09:27:07 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, April 27, 2011 2:36 AM
> To: [email-masked]

I think I could live with that.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 09:31:18 -0700

+1

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Apr 2011 09:45:13 -0700

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, April 26, 2011 4:31 PM
> To: Murray S. Kucherawy
> Cc: DKIM IETF WG
> Subject: Re: [ietf-dkim] despair
> 

I've been keeping up with the specification changes both in terms of the documentation and the impact of the changes on live source code.  That's really helped to keep us honest in terms of backward compatibility.

> from this draft would interoperate with existing implementations.

It is a useful data point to note that I haven't had to make any alterations to OpenDKIM as a result of either RFC5672 or the -bis changes.  In fact if OpenDKIM's library provided a truly strict implementation of -bis, I'd actually now be compelled to remove some things, which means it would be simpler.  And on that note, I'll be queueing up some feature requests once -bis publishes to do just that.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Apr 2011 09:53:00 -0700

On 4/27/2011 9:45 AM, Murray S. Kucherawy wrote:
> I've been keeping up with the specification changes both in terms of the
> documentation and the impact of the changes on live source code.  That's
> really helped to keep us honest in terms of backward compatibility.
...
> It is a useful data point to note that I haven't had to make any alterations
> to OpenDKIM as a result of either RFC5672 or the -bis changes.

1.  Has the working group been constantly careful to consider whether a change
was substantive and whether it might run afoul of the rules for going to Draft?

     Yes.

2.  Has the working group been reasonably diligent with develop the changes, 
including taking time to reflect on the changes and to consider criticisms of 
proposed changes?

     Yes.

3.  Are there any specific claims of non-conformance to Draft requirements that 
are unresolved by the wg?

     No.

With that sort of documented history, the responsibility to claim otherwise 
falls on the critic.  Otherwise the wg is essentially being asked to prove a 
negative and almost serves as a DOS attack...

Complaining is easy.  Trying to put the work on others is easy.  Doing 
foundational work to support a claim is not.

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Apr 2011 10:07:26 -0700

> negative and almost serves as a DOS attack...

Denial of service on what/whom? As far as I can see, the
only thing that this effort is serving is the process itself.
It certainly isn't helping DKIM.

> foundational work to support a claim is not.

This is rich coming from somebody who's never written a
DKIM stack to somebody who wrote the first.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Apr 2011 10:19:39 -0700

> I've been keeping up with the specification changes both in terms of the documentation and the impact of the changes on live source code.  That's really helped to keep us honest in terms of backwar…

Uh, this completely misses the point. It's not about you or opendkim.
It's about whether somebody starting out fresh would write a dkim
stack that interoperates with it solely from the -bis draft. Given the
rate of change, I don't have a lot of confidence in that. If 4871 were a
mess then this wholesale tinkering might be justified, but it wasn't.

The larger problem is that nobody that actually matters is paying
attention any more. Any bugs introduced here will take years to be
noticed. I had some trepidation about attempting to go to DS and
it has borne itself out.

Mike

---

From: Hector Santos <[email-masked]>
Date: Wed, 27 Apr 2011 15:04:25 -0400

+1

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Barry Leiba <[email-masked]>
Date: Wed, 27 Apr 2011 15:19:17 -0400

<chair>

> Complaining is easy.

Indeed so.  And so let's cut the meta-discussion and not go back to
throwing darts around.  To the points:

Mike's concern is valid.

Murray's and Dave's notes have addressed it.

</chair>

<participant>

I, as a participant, am satisfied with Murray's and Dave's responses
to the concern.  And I also have seen, as I've followed the changes
and discussion, that we've been careful here.

That's not an absolute assurance, but I'm not sure that exists.  I'm
sure enough to give my assent to sending it up to the IESG.

</participant>

Barry

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Apr 2011 13:50:30 -0700

> Murray's and Dave's notes have addressed it.

I don't see how getting a list of diffs after last call ends addresses it.

Mike