Hi,
As I explained a few times, IMO, the burden should be on the proposer
to explain why ADSP investment should be abandoned, made obsolete and
replaced with DMARC as the principle alternative advocated and
pursued. There is no coincidence that that proposer is the author of
a DMARC BCP document [1].
We keep saying its unrelated, well, I hope it would be. But
unfortunately it is not. I don't see it that way. Two DMARC documents
[1] [2] goes into using ADSP as a comparison and touts it as a better
solution.
Overall, I'm all for a "better" solution, but I don't see the
difference in the overall proof of concept -- they are basically the
same and they both have the same fundamental design barrier with a
lack of Middle Ware support. This is what has hurt ADSP adoption.
With DMARC be any different? Why pull the investment plug that was
already done if the key difference is the idea that MiddleWare
operations will support DMARC?
If we are saying DMARC is better because there are key players willing
to support this, then just say so but keep in mind, there was a huge
investment in DKIM based policy security layers with at least 8-9
years of exploration and concrete proof of concept established. We
need to establish why implementators (of all sizes) should drop all
investment in ADSP and move it over to DMARC. I personally will not
authorize any more work on DKIM or augmented security layers when
DMARC has the same basic issue that ADSP did. There is an IETF
credibility problem with the next idea here to pursue. Why bother
with new work when the work can be totally lost without any real
explanation -- just like that (snapping fingers).
Kill it, make it historic whatever, but convince me why I should
invest again in new protocols which in this case, is not convincing
will be any better other than perhaps be more popular and supportive
by the key cogs involved with DKIM.
Thanks
--
HLS
[1] http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03
[2] http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01
On 11/20/2013 12:13 PM, Barry Leiba wrote:
Closing the loop on this:
I see very strong and very broad agreement with taking this action:
reclassifying ADSP (RFC 5617) as Historic.
I see two objections:
One, by Hector, is that ADSP does have a lot of deployment: there's
code out there, both open source and commercial, that implements it,
and there are enough publications of ADSP records to demonstrate that
it's in use.
Another, by John Klensin and Alessandro, that making ADSP historic is
fine, but that it should be done with a document that explains the
deployment situation and explains why the reclassification is
appropriate despite that. Alessandro also wants us to consider fixing
ADSP instead.
Hector is certainly correct that code was quickly written and shipped
to implement ADSP, so there is plenty of deployed code. The
contention, though, is that ADSP is not providing the benefits it was
intended to, and is, in fact, actually causing harm due to misuse and
misconfiguration. Those factors make it important for us to
officially recommend that it NOT be used -- hence the
reclassification. I have asked for, and not seen, any real data
showing benefits from ADSP.
John has a reasonable point about writing up an explanation, and we
have had volunteers to do so. The IESG will consider whether that is
a better approach than just changing the RFC's metadata. As to
Alessandro's point about fixing ADSP, it's clear that there is no
community interest in doing that in a way that remains compatible with
RFC 5617's specification.
I see, therefore, clear consensus to make this status change, either
through a simple metadata change or accompanied by an explanatory
document. The IESG will decide how to proceed.
Barry, Applications AD
--
HLS