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

Hector Santos <hsantos@isdg.net> Wed, 20 November 2013 22:41 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B681AE529 for <ietf@ietfa.amsl.com>; Wed, 20 Nov 2013 14:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.137
X-Spam-Level:
X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doDOL0m5AdI0 for <ietf@ietfa.amsl.com>; Wed, 20 Nov 2013 14:41:15 -0800 (PST)
Received: from groups.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 09B411ADF98 for <ietf@ietf.org>; Wed, 20 Nov 2013 14:41:14 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3968; t=1384987260; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=iL/2tqRDipcy94NkhJhaHhkfqnE=; b=vRa4AC7yuIUX/s0q9vwP clxV/0Xow4IKX7/dPOSzmaTbLZMcXspkSSPV6EKU6gWddnuynT7Xax10fMKXt8uy raTj3OsEDdRzrJ/b4QrbCcjGDc8edxNh0kKsPfw374qUVIkmQYL1Qi1cAbHF5NPn JQs37djQuCddVFvgllOl3Sk=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Wed, 20 Nov 2013 17:41:00 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2859750444.9913.2972; Wed, 20 Nov 2013 17:40:58 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3968; t=1384986791; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=n59HEaL aa+1ccQiryS5Xy4RuctRzp5cUj/gUfGEgcaE=; b=cK8VkITR0PNvydy3mYFEPSu 1w9/7baO9QEXta5DWIE1abOib3yzD/NErebisktXvL78y9NgU58WbfiPTf9n7le4 V9G2z7r2ieNM/7OUUtydmN48/PxAjnJuAHwys7IxraE1zxDNSKonghjSAmz72w1G ELhWZ+XO4LwdE1vm9Bfs=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Wed, 20 Nov 2013 17:33:11 -0500
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2306104441.9.8612; Wed, 20 Nov 2013 17:33:10 -0500
Message-ID: <528D3A7D.6060005@isdg.net>
Date: Wed, 20 Nov 2013 17:41:01 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
Subject: Re: Last Call: Change the status of ADSP (RFC 5617) to Historic
References: <20131002145238.78084.qmail@joyce.lan> <524D846A.6030905@tana.it> <CAC4RtVBb9FVtmjK4X5hCQpMorHnjmyJLU1sYbNh==iBh8SqztQ@mail.gmail.com>
In-Reply-To: <CAC4RtVBb9FVtmjK4X5hCQpMorHnjmyJLU1sYbNh==iBh8SqztQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2013 22:41:18 -0000

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