Subject: [ietf-dkim] Collecting re-chartering questions

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Jan 2010 17:02:29 -0500

Stephen and I apologize for having let this slip since the last IETF
meeting, but we're ready to get back to the discussion of
rechartering.

Specifically, we would like to present the list of points discussed so
far, at least as I've managed to distill them (and so if I've missed
your favourite, it was not on purpose, so assume nothing from that and
tell me about the omission).  We've had lots of discussion in
September and October, and I don't want to revisit that.  What I want
to do here is take a poll.

Please look at the following list, and respond to this thread (please
do not change the subject, so the votes stay in one thread).  In your
response, say which items, by number, you would like to see included
in a new charter, and which items, by number, you would oppose having
in a new charter.  (In the case that we choose item 10, go dormant, we
wouldn't actually put that in a charter, but vote on it as if we
would.)

Please do NOT include discussion of any of the items.  If you need to
clarify your vote, include a VERY BRIEF comment to that effect.

If you see a need to have any more discussion of these items at this
time, post a new message to the mailing list, starting a new thread.

We'll collect the votes over the next two weeks, and report back here
with results after the close on 5 Feb.

The list, as I've been able to distill it out of the lengthy discussions:

1. Advance DKIM base to Draft Standard

2. 3rd-party authorization label:
https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-label/
If you have not read this draft, please do; we'd like to get a good
sense of whether to work on this.

3. Other 3rd-party signing issues (New protocol?  Info doc?)

4. Mailing list cohabitation ("dkim=except-mlist")

5. Other mailing list issues (info doc)

6. Specifying ADSP/forwarder guidelines for re-signing (is this
different from mailing list issues?)

7. Collect data on deployment and effectiveness of DKIM base

8. Collect data on deployment and effectiveness of ADSP, and consider
future of ADSP

9. Update overview and deployment/operations documents (info), as new
data are collected.

10. Go dormant for a while, and revisit these questions in 8 to 12 months.

Let the polling begin.

Barry (and Stephen), as chairs
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 22 Jan 2010 03:25:23 -0000

YES to 1, 7, 8.  NO to everything else.

(I.e., do find out what people are doing, do not invent new unlikely
to be used mechanisms.  Not opposed to 9, but seems contingent on 7
and 8 happening first.)

R's,
John

---

From: Daniel Black <[email-masked]>
Date: Fri, 22 Jan 2010 17:17:07 +1100

Happy new year,

In favour of:

8.
3, 4, 
2.
6.
9.

opposed to:

(nothing)

Daniel Black

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 22 Jan 2010 10:49:49 +0000

Support:
1.
5. Any help that list managers can get would be good.
7.
8.
9. - no point collecting data if nothing is done with it.

Opposed to:
10 - implicit by support of any of the other proposals, surely!

Confused by:
2. On the one hand it could solve a myriad of problems, and permit 
widespread ADSP. On the other hand, I don't like adding layers of 
complexity.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Fri, 22 Jan 2010 11:03:14 -0500 (EST)

> to be used mechanisms.  Not opposed to 9, but seems contingent on 7

+1. No new features before we have real-world experience.

	Wietse

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jan 2010 09:39:12 -0800

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Barry Leiba
> Sent: Thursday, January 21, 2010 2:02 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Collecting re-chartering questions
> 

Yea.

> sense of whether to work on this.

Nay until presented with evidence that this is an actual pain point.

> 3. Other 3rd-party signing issues (New protocol?  Info doc?)

Yea on the informational document, pending evidence that an actual protocol is needed.  (I always support more informational documents, in the constant presence of evidence that the industry as a whole doesn't fully understand all the implications of DKIM and its related work.)

Nay on the protocol until presented with evidence that this is an actual pain point.

> 4. Mailing list cohabitation ("dkim=except-mlist")

Nay until presented with evidence that this is an actual pain point.

> 5. Other mailing list issues (info doc)

Yea.

> different from mailing list issues?)

Yea.  (3, 5 and 6 can all be combined into a single document, I would imagine.)

> 7. Collect data on deployment and effectiveness of DKIM base

Yea.

> 8. Collect data on deployment and effectiveness of ADSP, and consider

Yea.

> 9. Update overview and deployment/operations documents (info), as new

Yea.

> 10. Go dormant for a while, and revisit these questions in 8 to 12

I'd be fine with this if we decide more time has to pass before the above are practical.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 22 Jan 2010 10:14:48 -0800

> 1. Advance DKIM base to Draft Standard

  and perhaps

> 8. Collect data on deployment and effectiveness of ADSP, and consider

However,

> 9. Update overview and deployment/operations documents (info), as new

Can't "update" something that hasn't been released yet.

d/
-- 

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jan 2010 18:40:48 +0100

> +1. No new features before we have real-world experience.

I'd go for 1, 5, 7, and 8.  That is - mailing lists needs to be further
explored.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 22 Jan 2010 10:27:49 -0800

(responding in-thread because this has two vote-changes.  but I also raise 
questions for which responses should be on new threads. /d)

On 1/22/2010 9:39 AM, Murray S. Kucherawy wrote:
> Yea on the informational document, pending evidence that an actual protocol
> is needed.  (I always support more informational documents, in the constant
> presence of evidence that the industry as a whole doesn't fully understand
> all the implications of DKIM and its related work.)
>

+1 on 3 as a discussion effort, rather than specification effort.  (I had missed 
the distincton.)

However, what is needed, beyond the Section 5.5 discussion already in

    <http://www.ietf.org/id/draft-ietf-dkim-deployment-10.txt>?

That is, this effort would need very clear goals.  (Obviously discussion needs 
to be on separate thread.)

>> 6. Specifying ADSP/forwarder guidelines for re-signing (is this different
>> from mailing list issues?)
>

Perhaps, but again, what is insufficient about Section 7.3 of the Deployment doc?

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Fri, 22 Jan 2010 10:01:18 -0800

> to be used mechanisms.  Not opposed to 9, but seems contingent on 7

+1. No new features without some real world experience and a non-theoretical,
non-niche requirement.

Cheers,
  Steve

---

From: Jon Callas <[email-masked]>
Date: Fri, 22 Jan 2010 11:14:39 -0800

> 1. Advance DKIM base to Draft Standard

This is *the* priority.

> 5. Other mailing list issues (info doc)

If it's an info doc, yes.

Stragegically, there has to be cooperation between DKIM and the mailing list people, because much of the problem could be fixed with some changes to mailing list software, there's a minimizing function to cause the fewest changes in each place with the most benefit.

Explorations with ADSP are also goodness, but 1 is *the* priority.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Jan 2010 15:59:24 -0800

> Nay until presented with evidence that this is an actual pain point.
Yes, of course, being in support of 2.  For example, extending the 
current RBL approach confronts difficulties when scaling to support 
IPv6. The application of 3rd-party labels would assist in a transition 
toward positive reputations.

3rd party labels would permit DKIM signatures to better correspond with 
providers, rather than the much larger number of their customer's 
domains.   In this way, the 3rd party label authorization scheme greatly 
expands the percentage of author domains assured by valid DKIM 
signatures.  By allowing DKIM to quickly and economically offer 
assurances for the bulk of the email carried, while still allowing 
customers an ability to employ any desired provider, DKIM could thereby 
establish a basis for acceptance.

A 3rd-party label should help prevent the number of DKIM signatures from 
exploding along with the growing number of domains soon to come into 
existence, that will likely be leveraged by spammers.  DKIM signatures 
could instead reflect a much smaller number of providers offering email 
services.  The stability this would provide should help minimize 
difficulties when confronting the massive IPv6 address space and rapidly 
expanding number of domains.
> Nay on the protocol until presented with evidence that this is an actual pain point.
While the 3rd party label draft might seem overly complex, it was to 
minimize the number of transactions needed to support an authorization 
scheme at any scale.  There does not appear to be any need to change 
DKIM to offer 3rd-party authorizations.  It should become clear soon 
enough, acceptance based principally upon IP addresses will become 
increasingly problematic.

It would be good to offer an experimental method that might be tried as 
a way to obtain greater experiences as to practicalities of what might 
be made to work within the current DKIM infrastructure, at least cost, 
while minimizing the impact on mailing-lists.  Mailing lists might even 
benefit from a Google style ranking system that could be evidenced by 
the number of domains authorizing their service.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2010 12:19:01 +0100

> 1. Advance DKIM base to Draft Standard

I'd require Yahoo! Inc's IPR to be upgraded to the current GPL release 
before that. (See https://datatracker.ietf.org/ipr/693/)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 25 Jan 2010 16:51:48 -0000

>before that. (See https://datatracker.ietf.org/ipr/693/)

The reference to the GPL looks to me like it only covers the old
Sourceforge DK library, which I don't think anyone uses any more.  The
patent, which is what's important, is covered by a separate license
that Yahoo wrote.

Even if Yahoo were willing, this would involve negotiations with their
lawyers which always takes a long time.  What would be the advantage
to anyone of demanding license changes for obsolete code?

Signed,
Confused

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2010 19:14:26 +0100

>>before that. (See https://datatracker.ietf.org/ipr/693/)

Also https://datatracker.ietf.org/ipr/716/ ... how many are they?

> patent, which is what's important, is covered by a separate license

IANAL, but that snippet talks about "Necessary Patent Claims", which 
is described as the claims "that would necessarily be infringed by 
implementation of the technology". Apparently, that covers generating 
a key pair associated with a domain, digitally signing messages, and 
the similar claims that the patent consists of; independently of the 
code that carries those tasks out.

> lawyers which always takes a long time.

You understand this stuff far better than I. I'm not even sure of what 
it might mean to license a /patent/ under the GPL (perhaps it means 
that any implementation released under the GPL is automatically 
licensed?) However, IIRC, they made those IPRs in order to allow the 
standardization process. By the same logic, a further standardization 
round implies further IPRs. Since GPLv3 has been released meanwhile, 
the new IPRs should consider its current version, shouldn't they?

> What would be the advantage

Yes, http://domainkeys.sourceforge.net/license/patentlicense1-2.html 
looks obsolete, because its header title doesn't match the one in the 
body, and because its authoritative link doesn't work. However, the 
patent itself doesn't seem obsolete to me.

On what grounds would the new charter work?

> Confused

Thank you for your patience :-)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Jan 2010 10:20:07 -0800

> to anyone of demanding license changes for obsolete code?

It's more of an issue than that.

The licensing declaration allows anyone to use the IP contained in
Yahoos patents under one of two licenses. One is the "DomainKeys
Patent License[1]" - which only applies to implementations of DomainKeys,
and doesn't apply to any DKIM implementation, if I'm reading it correctly.
Specifically, if you're not implementing draft-delany-domainkeys-base-01.txt, it
doesn't apply.

The other is the "GNU General Public License 2.0" which can't really
be applied to an IP release in a useful manner, as it's really a source
code license (I'm allowed to use the IP, as long as I make the source code
for any changes to the IP available to any user of the IP... Uhm, what?).

OTOH, the licensing for DomainKeys has been a trainwreck since that
was put together, and Yahoo haven't sued anyone yet, nor has anyone
been seriously discouraged from implementing it, AFAIK.

Cheers,
  Steve

[1] http://domainkeys.sourceforge.net/license/patentlicense1-2.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 25 Jan 2010 13:55:10 -0500

> You understand this stuff far better than I. I'm not even sure of what it 
> might mean to license a /patent/ under the GPL (perhaps it means that any 
> implementation released under the GPL is automatically licensed?)

There's no such thing as a GPL patent license.  The FSF has a longstanding 
anti-patent policy, after all.

> Yes, http://domainkeys.sourceforge.net/license/patentlicense1-2.html looks 
> obsolete, because its header title doesn't match the one in the body, and 
> because its authoritative link doesn't work. However, the patent itself 
> doesn't seem obsolete to me.

The IPR refers to both the GPL and the patent license.  The patent license 
is fine, the typo in the header and the dead link have been there for four 
years and aren't important, since this is a document for lawyers to read, 
not code.  Really, the GPL only refers to the Sourceforge code, and nobody 
cares about that.  We should advance DKIM to draft standard now.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 25 Jan 2010 13:26:44 -0500

What John said except I would include #9 as a yes as the data becomes
available.

Mike

> [email-masked]] On Behalf Of John Levine
> Sent: Thursday, January 21, 2010 10:25 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Collecting re-chartering questions
>

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 25 Jan 2010 14:01:24 -0500

> YES to 1, 7, 8.  NO to everything else.

+1

-- 
Jeff Macdonald
Ayer, MA

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2010 20:27:43 +0100

On 25/Jan/10 19:55, John R. Levine wrote:
> Really, the GPL only refers to the Sourceforge code, and nobody

Hmm... suppose that we do, and that we manage for DKIM to be finely 
implemented at most hosts, paving the way for a spam-free world. In 
addition, suppose that Yahoo! Inc goes out of business and the domain 
keys patent is acquired by Unisys...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 25 Jan 2010 14:48:47 -0500

> implemented at most hosts, paving the way for a spam-free world. In addition, 
> suppose that Yahoo! Inc goes out of business and the domain keys patent is 
> acquired by Unisys...

Then it makes no difference at all, since the existing license is 
perpetual and sublicensable.  Really, this is not a productive line of 
argument.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Jan 2010 12:11:31 -0800

> cares about that.  We should advance DKIM to draft standard now.

The patent license does not apply to DKIM, though. It very explicitly only applies
to implementations of one particular version of DomainKeys, unless I'm
misreading it.

Given that (and the GPL silliness) any DKIM implementation using Yahoo
IP is doing so without permission, AIUI. I don't think this is an actual problem,
as the last thing Yahoo is going to do is go out and enforce it, but just brushing
the issue under the carpet doesn't seem the right thing to do.

(I've not read the Yahoo patent, so I'm only presuming they apply to DKIM -
but given DKIM is mostly just DK with a fix or two and some peripheral extras
added, I'm guessing it does).

Cheers,
 Steve

---

From: John Levine <[email-masked]>
Date: 25 Jan 2010 21:51:18 -0000

>(I've not read the Yahoo patent, so I'm only presuming they apply to
>DKIM - but given DKIM is mostly just DK with a fix or two and some
>peripheral extras added, I'm guessing it does).

The license refers to several patent applications.  As far as I can
tell there is one issued patent, 6,986,049, which probably covers DKIM
although the use of the word "domain" in the claims is confusing.

It would be nice if Yahoo offered a cleaned up version of the patent
license (unrelated to the GPL sample code) but I wouldn't wait for
them to do so.

R's,
John

---

From: <[email-masked]>
Date: Mon, 25 Jan 2010 20:50:45 -0500

IANAL but stayed at a holiday inn express in the past
The Patent covers IP that is distributed by GPLed source code. Means that Yahoo or assigns cannot enforce infringement against solutions incorporating the source code.
Doesnt mean any more or less than that
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of John Levine [[email-masked]]
Sent: Monday, January 25, 2010 4:51 PM
To: [email-masked]
Subject: Re: [ietf-dkim] IPR disclosures,       was Collecting re-chartering questions

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2010 09:32:49 +0100

On 25/Jan/10 20:48, John R. Levine wrote:
> perpetual and sublicensable.

But that's bound by, and subject to, the Specifications unspecified by 
a broken link.

> Really, this is not a productive line of argument.

Sadly agreed. Non-productivity stems from using patent encumbered 
ideas and suspecting that DKIM, much like a pigeon, can be shoot down 
as soon as it flies. Isn't there anything that the IETF can do, in 
connection with rechartering, to get out of the impasse?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 26 Jan 2010 14:07:36 -0700

YES to 1,3*,5,7,8*
NO to 2,4,6*,9,10, and anything about patents

> 3. Other 3rd-party signing issues (New protocol?  Info doc?)

Yes to an info doc collecting & discussing challenges so that any discussion of a new protocol is based on real-world data rather than wild speculation.  #6 has the same requirement.

> 8. Collect data on deployment and effectiveness of ADSP, and consider

Yes to collecting data on deployment, but it's far too early to draw any conclusions about effectiveness.

Also, FWIW: yes to meeting in Anaheim.

--
J.D. Falk <[email-masked]>
Return Path Inc