Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

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