About two weeks ago, I posted the following summary of things I see as
major obstacles between us and an acceptable standard-track RFC.
In <x4oen0thfg(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne
<wayne(_at_)midwestcs(_dot_)com> writes:
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
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.
4) Proposals must have IP licensing terms that allow for use in both
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
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.
-wayne