Subject: Obstacles between us and the finish line

From: wayne <[email-masked]>
Date: Thu, 01 Jul 2004 00:39:15 -0500

Deadlines for this working group are rapidly approaching.  According
to Andy's recent post, we have about 2 weeks (until 07/18) to finish
things up.

In my (oh so very humble) opinion, I see the following obstacles in
the way:

1) Proposals must have solid I-Ds

2) Proposals must have working code

3) Proposals must have been tested on real world data

4) Proposals must have IP licensing terms that allow for use in both
   commercial and GPLed MTAs.

5) Proposals must not have gratuitous incompatibilities with an
   installed base.

I have said from very early on that I think we may well need more than
one RFC to handle the various identities.  To be quite honest, I don't
care if we have a dozen overlapping proposals, I think the market can
easily decide which are useful.

As such, I see the following proposals that may be considered:
SPF-classic, CSV, Sender-ID and Unified-SPF.

It appears to DMP, FSV, and Caller-ID are no longer being pushed by
anyone.

I'm going to go over all the proposals in a sec, but I think I should
make a few comments on the requirements.

1) solid I-Ds:  Proposals must have been gone over with many eyes,
especially with developer's eyes when they are trying to implement the
proposal.  I think it is far too late to do anything with a proposal
other than use it to implement code and make adjustments based on that
experience.

2) working code, and 3) testing, I think are pretty obvious.

4) IP licensing:  I'm not dogmatic about the GPL or commercial
licenses, but there are significant MTAs and mail filters that fall
under both kinds of licenses, and several others to boot.  I think
that any proposal that has incompatible IP licensing needs to be
dropped.

5) Incompatibilities:  Proposals such as SPF have a significant install
base and doing things like moving the location of the TXT records,
dropping macros, or using a different RR, etc. make no sense to me and
will likely run into a buzz saw with SPF adopters.

Ok, so how do the current proposals stack up?

****   SPF-classic   ****

1) solid I-D:  Yes
It was supposed to have been submitted as an experiemental RFC, but I
don't know the status. 

2) working code:  Yes
Lots of working code in fact.  New announcements of commercial
products using SPF a couple of times a week.

3) Tested:  Yes
It is being used to check millions of emails per day.

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.

I think SPF-classic should certainly be *one* of the proposals put
forth by this working group.

****   CSV   ****

1) solid I-D:  pretty good
To the best of my knowledge, no one has tried to implement code based
on it, but it appears to have been well reviewed by a fair number of
people.  I think there is time to get implementation experience if the
backers hurry.

2) working code:  none

3) testing:  none

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.

I think that CSV could be one of the proposals, if its backers quickly
start creating working code and doing testing.

****   Sender-ID   ****

1) solid I-D:  No
I have looked again at the draft-ietf-marid-core-01.txt I-D, and
frankly, it is not even close to being in a state worth commenting on.
It is hugely incomplete and incompatible with SPF, which it tries to
be compatbile with.  I can't see it becoming solid in the next couple
of weeks.

Heck, it still has the XML stuff in it and the changes from the -00
version are very minor.  It appears that little work is being done on
this and it is unlikely to be ready.

The SUBMITTER I-D appears to be in better shape, but again, no one has
tried using the I-D to implement the spec, so there could be
significant errors.

2) working code:  none
In particular, the PRA and SUBMITTER are both on paper only.

3) testing:  none
I requested results of the PRA algorithm the first day that the
Caller-ID spec was proposed to this working group.  I made a point of
raising the issue at the interim meeting.  In the many months since
then, nothing has been forth coming.  I am getting seriously worried
about this.

4) IP Licensing:  problems
It appears that the Sender-ID's license is incompatible with the GPL.
This could, in theory, be fixed very quickly, but the issues of IP
disclosure and licensing problems has been known since before the
interim meeting and nothing has been done.

5) gratuitous incompatibilities:  None.
In theory, the only incompatiblity is that it tries to use existing
SPF records for 2822 checks.  Since SPF records were published with
the idea that they would be used for 2821.FROM and 2821.HELO, there
could be problems.

In practice, there are many incompatiblities with the current
Sender-ID spec and the SPF spec.

While Sender-ID appears to be the RFC-apparent for this WG, I have
very serious doubts that it will be in any shape to be advanced before
the deadlines.  I am beginning to think this proposal should be
dropped as the backers of key parts appear to be moving way too
slowly. 

****   Unified-SPF   ****

1) solid I-D:  fuzzy
As Dave Crocker pointed out in a message earlier today, there is no
Unified-SPF I-D.  This needs to be fixed ASAP or this proposal must be
dropped.  Fortunately, the differences between SPF-classic and
Unified-SPF are small enough that I think I-Ds could be written fairly
quickly and yet remain pretty solid.

2) working code:  none

3) testing:  none

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.
The Unified-SPF proposal needs to make some changes to the SPF records
in order to support the various scopes that it tries to cover.  This
can be solved several ways.

I think that Unified-SPF has a chance to be a solid proposal, but the
I-Ds need to be written and the changes to the SPF-classic code needs
to be tested.

****   DMP   ****

Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway

1) solid I-D:  Yes

2) working code:  Yes

3) testing:  Yes

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.

I think that DMP is in far better shape than most of the other
proposals that appear to be much more likely to advanced by this
working group.  *boggle*

Right now, I would say that SPF-classic and DMP are the only proposals
that are ready for RFC consideration.  For backers of other proposals:
you have two weeks to finish.

-wayne

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Jul 2004 12:59:22 +0100

> 5) gratuitous incompatibilities:  None.

Incorrect. It breaks alias-forwarding.

> 5) gratuitous incompatibilities:  None.

Correct.

> 5) gratuitous incompatibilities:  None.

Incorrect. See http://www.imc.org/ietf-mxcomp/mail-archive/msg02419.html

> 5) gratuitous incompatibilities:  None.

Incorrect for the reasons stated for SPF-classic and Sender-ID above.

> 1) solid I-D:  Yes

There appears to be a security problem caused by the way a failed MAIL
FROM check may fall back to an EHLO check, allowing unintended forgery.
Alternatively this is a source of troublesome interoperability problems
if some servers fall back to EHLO and some don't.

> 5) gratuitous incompatibilities:  None.

Wildcard MX records.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: WESTERLY 4 OR 5 BECOMING VARIABLE 3. OCCASIONAL RAIN. MODERATE WITH
FOG PATCHES.

---

From: wayne <[email-masked]>
Date: Mon, 12 Jul 2004 22:18:59 -0500

About two weeks ago, I posted the following summary of things I see as
major obstacles between us and an acceptable standard-track RFC.

> 1) Proposals must have solid I-Ds

I is my understanding that the design-team meeting last Friday made
significant progress on the RFCs.  In particular, it is my
understanding that much of marid-core has been replaced by a chopped
up version of the SPF-classic spec, which I personally think is likely
to be a huge improvement.

That said, such significant changes only a week before the IETF-60 I-D
submission deadline does not leave much time for real working group
review and changes/fixes.  I am almost certain that I will have a
number of things that I would like see changed in the SenderID
"protocol" RFC in order to deal with issues such as DDoS potentials.

> 2) Proposals must have working code

Now that XML has been eliminated, the SPF-classic
libraries/implementations can be used to check the PRA and no new code
really needs to be written.  That is, except for the code to extract
the PRA.  If the PRA RFC is going to be advanced by this working
group, those that think it is a good idea should create some working
code.  Otherwise, I don't think we will reach a rough consensus as to
whether it is a useful RFC to introduce onto such an important part of
the Internet.

> 3) Proposals must have been tested on real world data

Like 2), there is *still* zero published data on how effective the PRA
algorithm is on real world data.  I know that it would create a false
positive on the only email account that I have forwarded to my main
email address.  I know that it will break on many mailing lists.  I
don't know much more than that.

>    commercial and GPLed MTAs.

Again, the PRA RFC has IPR claims.  It is my understanding (IANAL)
that there is a very good chance that these license offered with the
PRA is incompatible with the GPL, and may have other problems.  There
are significant MTAs out there (e.g. Postfix and Exim) along with spam
filters and MUAs that the current PRA license would prevent the
implementation of SenderID.

If, indeed, the PRA license is incompatible, I do not think we should
advance it as an RFC.

> 5) Proposals must not have gratuitous incompatibilities with an

It is my understanding that most of the problems between SPF-classic
(e.g. the installed base of SPF records) and Sender-ID have been
resolved.

If forced to hum today, I would have to say that SenderID is not ready
for submission as a standard-track RFC.  We don't have much time to
fix things before IETF-60.  It is my gut feel that we will not be able
to do a working group last call until after IETF-60, pushing the whole
schedule back by several weeks or a month.

-wayne

---

From: Chuck Mead <[email-masked]>
Date: Tue, 13 Jul 2004 14:28:51 -0400

wayne wrote:

| Again, the PRA RFC has IPR claims.  It is my understanding (IANAL)
| that there is a very good chance that these license offered with the
| PRA is incompatible with the GPL, and may have other problems.  There
| are significant MTAs out there (e.g. Postfix and Exim) along with spam
| filters and MUAs that the current PRA license would prevent the
| implementation of SenderID.
|
| If, indeed, the PRA license is incompatible, I do not think we should
| advance it as an RFC.

Licenses which limit a technology make the supporting RFC a waste of
time. I won't use it... nor will I support it's use if there are
artificial limits created by licensing.

|>5) Proposals must not have gratuitous incompatibilities with an
|>   installed base.
|
|
| It is my understanding that most of the problems between SPF-classic
| (e.g. the installed base of SPF records) and Sender-ID have been
| resolved.
|
|
|
| If forced to hum today, I would have to say that SenderID is not ready
| for submission as a standard-track RFC.  We don't have much time to
| fix things before IETF-60.  It is my gut feel that we will not be able
| to do a working group last call until after IETF-60, pushing the whole
| schedule back by several weeks or a month.

I usually don't give a single ditto as it's not typically useful but in
this case I think that would be the wrong approach so... like a clarion
bell let me say as clearly as possible... ME TOO!

NB. Let's get on with it! Shall we?

- --
Chuck Mead
[email-masked]
Chief Tech @ http://moongroup.com - http://anirononline.com

---

From: Shevek <[email-masked]>
Date: Wed, 14 Jul 2004 17:43:57 +0100 (BST)

>    commercial and GPLed MTAs.

The requirement to even THINK about licensing terms when one is
implementing a "standard" internet protocol is almost unimaginable. The
IETF is supposed to promote interoperability without precondition. The
introduction of any form of license in order to use a "standard" mail
protocol raises the possibility that certain parties will not be able to
participate fully on the internet for legal reasons.

There is no precedent for such an ugly situation, and I am strongly
opposed to creating it now.

It doesn't matter what the terms are or how open or simple they are.  
Licensing terms should NOT exist for an IETF "standard" protocol.
Implementors are not lawyers, and generally have better things to do with
their time.

S.

Optional bootnote: A similar argument applies to the use of well-known
licenses for software. I believe that a large part of the reason for the
success of the GPL, BSD or Apache licenses is that the rights of the user
and developer are particularly well understood in those cases. It's
frequently simpler to pick a GPL'd package than to understand the license
of a (possibly better) package under a custom license.

The same applies here: we should be applying a standard and well 
understood set of terms to any proposed protocol, and the "standard and 
well understood" set of terms is "You can do what you like with it, and 
are beholden unto nobody."

Anything else is an obstacle and will cause division.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Jul 2004 10:44:40 -0700

At 5:43 PM +0100 7/14/04, Shevek wrote:
>implementing a "standard" internet protocol is almost unimaginable.

<snip>

>
>. I believe that a large part of the reason for the

The GPL, BSD, and Apache licenses are just as much licenses
with terms to be followed as are commercial licenses with
RAND, royalty-free, or reciprocal terms.  Asserting that
a working group should not THINK about licensing and then
recommending particular licenses is a contradiction.
More importantly, this general topic is not salient for this list. 
The IPR mailing list
exists for discussion of the IETF's IPR policy, and general discussion
belongs there. Please see the archives before posting, however, as the topics
raised here have been discussed before.

The group can discuss specific IPR issues with proposals before
the working group, but please note that while the IPR forms request
that a new IPR statement be filed for each document, it is widely understood
that successor documents are covered by the statement relating to the original
version.   Getting a new one in for each version is busywork, and 
this working group has
no time for such busywork.  Getting a final copy in  before the 
documents become
RFCs can be handled at the appropriate time, and I am recommend to the working
group that they let the chairs follow up with the editors and those 
who have filed
early statements at that time.

For those of you not familiar with the IETF's IPR declaration site, it
is at http://www.ietf.org/ipr.html.  The caller-id original
is covered in this document:

http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt

with the following licensing declaration:

       b) _X__ Royalty-Free, Reasonable and Non-Discriminatory License to  
                         All Implementers **
                             Check here if this commitment to license 
is limited solely
                             to standards-track RFCs ___  
   
I urge the working group to stop fixating on this and go back to reviewing
and contributing to the specifications.  This list is intended to focus on
the engineering needed to get its charter done, and we have enough distractions
without raising this spectre from its well-deserved grave.

			regards,
				Ted Hardie

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 14 Jul 2004 13:53:52 -0400

I second your concerns.  This is completely disturbing.  Not only do I think
the proposals are faulty, will incur a high degree of compatibility issues,
will translates to a high revamping and resign cost,  I now have to worry
about fighting what would be prior art issues anyway?

No, there is got to be a better answer to all this.  This is fast becoming a
"MICROSOFT" only solution and Bill Gates recent quote saying using security
as a "Strategic Competitive Advantage" might come back to bite him in the
anti-trust area.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Shevek <[email-masked]>
Date: Wed, 14 Jul 2004 19:43:11 +0100 (BST)

> recommending particular licenses is a contradiction.

I am sorry that you did not actually read my original mail. I will
rephrase the salient parts of it in the hope of better luck this time.

I request that any protocol standardised by the IETF be entirely free of 
license restrictions in order that implementors clearly understand their 
right to implement the protocol. I specifically oppose the adoption of 
SenderID as a standard since it imposes licensing terms on the user.

> More importantly, this general topic is not salient for this list. 

This is not a general topic. This is a specific opposition to SenderID.
SenderID has licensing terms which an implementor must spend time reading
and understanding before implementing, distributing or otherwise sneezing
on SenderID or implementations thereof.

If the implementors do not clearly understand their rights, RAND or
otherwise, then they are unlikely to implement, or implementation will be
divided. We only have to look at the three-dozen competing CDMA
specifications for an example of this.

At no point did I suggest an alternative license, and I do not do so now.  
I propose and recommend the absence of any license or restriction
whatsoever on any eventual protocol.

S.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 14 Jul 2004 15:46:36 -0400

> as a "Strategic Competitive Advantage" might come back to bite him in 

I specifically stated earlier that discussion of hidden agendas and 
similar topics is forbidden.  This statement does not constitute 
constructive technical discussion nor administrative discussion within 
the bounds of the working group's chartered scope.

This is your first and last warning.

-andy

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 14 Jul 2004 15:33:22 -0700 (PDT)

On Wed, 14 Jul 2004, Ted Hardie wrote:

> The group can discuss specific IPR issues with proposals before the working
> group, but please note that while the IPR forms request that a new IPR 
> statement be filed for each document, it is widely understood that 
> successor documents are covered by the statement relating to the original
> version.   Getting a new one in for each version is busywork, and this 
> working group has no time for such busywork.  Getting a final copy in  
> before the documents become RFCs can be handled at the appropriate time, 
> and I am recommend to the working group that they let the chairs follow 
> up with the editors and those who have filed early statements at that time.

While I agree with you in general, I do believe in our case, new IPR 
statement is appropriate. My undersnding is that before Microsoft claimed
IPR rights because of use of XML in DNS TXT records (or was it in dns in 
general? I asked that question and was promised detailed answer during 
MARID jabber session, but never got it, eventhough Microsoft people 
present were directed to work on it). We're no longer considering
use of XML in DNS and will use original SPF syntax, so my understanding 
based on previously expressed IPR claims that none should apply to now.
Perhaps I do not understand correctly and Microsoft had other IPR claims 
that dod not concern XML, in that case, Microsoft should explain more 
clearly and tell exactly what these IPR claims cover and that is why new 
statement seems appropriate.

> http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-atkinson-callerid.txt

I note that the section V(C) which from that document is which is supposed
to explain which parts of internet draft are covered by IPR is not filled
out by Microsoft nor was there patent# provided under section V(A).
 
-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 14 Jul 2004 21:19:11 -0400

Wonderful!  Now I have to deal with IETF censorship issues because I
discussed critical concerns regarding MICROSOFT IPR issues in a flawed
MARID, directly or indirectly related, which will  have an enormous cost
impact across the industry including with own company and customers
regardless of how small you may believe it is?  It is no laughing matter and
I take all this very seriously.

Rather than threaten me with censorship, clearing the air with information,
as some have done, for everyone would be better progress.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office