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

[Hector Santos <[e-mail]>]

I agree, the problem IMV is the illusion that DMARC will replace it 
has some domains has already done by switching their strong exclusive 
mail operations declaration from _ADSP TXT record policy to a _DMARC 
policy.  Like FACEBOOK.COM. The REJECTING/DISCARD concept is still the 
same and active, just a different TXT domain policy protocol 
describing the expected behavior.

The problem I have is the lack of confidence that DMARC will be 
supported by the main conflictive software in the entire DKIM 
deployment and service architectural picture -- the resigners (mailing 
list software).  Thats the problem ADSP had.  DMARC does not change it.

So is making ADSP historic, killing the investment done with DKIM/ADSP 
support, going to be replacing with a plug and play protocol switch 
with DMARC?

If so, I don't like that lost of investment but I can support the move 
but now, not as an early adopter and I will wait until other mailing 
list software vendors/developers add that necessary support for DMARC 
rejection policies.   Its the same proof of concept issue as it was 
with ADSP.

DMARC just add some reporting, logging and feedback concepts to the 
picture.

--
HLS

On 10/3/2013 1:09 PM, John C Klensin wrote:
>
>
> --On Thursday, October 03, 2013 16:51 +0200 Alessandro Vesely
> <[e-mail]> wrote:
>
>>> ADSP was basically an experiment that failed.  It has no
>>> significant deployment, and the problem it was supposed to
>>> solve is now being addressed in other ways.
>>
>> I oppose to the change as proposed, and support the
>> explanation called for by John Klensin instead.  Two arguments:
>>
>> 1)  The harm Barry exemplifies in the request
>> --incompatibility with     mailing list posting-- is going to
>> be a feature of at least one     of the other ways addressing
>> that problem.  Indeed, "those who     don't know history are
>> destined to repeat it", and the explanation     is needed to
>> make history known.
>>
>> 2)  A possible fix for ADSP is explained by John Levine
>> himself:
>> http://www.mail-archive.com/[e-mail]/msg16969.ht
>> ml     I'm not proposing to mention it along with the
>> explanation, but     fixing is not the same as moving to
>> historic.  It seems that it     is just a part of RFC 5617,
>> DNS records, that we want to move.
>
> Ale,
>
> Just to be clear about what I proposed because I'm not sure that
> you actually agree:  If the situation is as described in the
> write-up (and/or as described by John Levine, Murray, and some
> other documents), then I'm in favor of deprecating ADSP.  The
> _only_ issue I'm raising in this case is that I believe that
> deprecating a feature or protocol element by moving things to
> Historic by IESG action and a note in the tracker is appropriate
> only for things that have been completely ignored after an
> extended period or that have long ago passed out of public
> consciousness.   When something has been implemented and
> deployed sufficiently that the reason for deprecating it
> includes assertions that it has not worked out in practice, I
> believe that should be documented in an RFC both to make the
> historical record clear and to help persuade anyone who is still
> trying to use it to cease doing so.
>
> There may well be arguments for not deprecating the feature, for
> improving it in various ways, or for contexts in which its use
> would be appropriate, but someone else will have to make them or
> propose other remedies.  I have not done so nor am I likely to
> do so.
>
>    best,
>      john
>
>
>
>

-- 
HLS