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
- Re: Last Call: Change the status of ADSP (RFC 561… John Levine
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- RE: Last Call: Change the status of ADSP (RFC 561… ietfdbh
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Alessandro Vesely
- Re: Last Call: Change the status of ADSP (RFC 561… Scott Kitterman
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Douglas Otis
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- How to protect DKIM signatures: Moving ADSP to Hi… Hector Santos
- Re: How to protect DKIM signatures: Moving ADSP t… Barry Leiba
- Re: How to protect DKIM signatures: Moving ADSP t… Hector Santos
- Re: How to protect DKIM signatures: Moving ADSP t… Douglas Otis
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Re: How to protect DKIM signatures: Moving ADSP t… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Alexey Melnikov
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Bob Braden
- Re: Last Call: Change the status of ADSP (RFC 561… Eliot Lear
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Eliot Lear
- Re: Last Call: Change the status of ADSP (RFC 561… Ted Lemon
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Hector Santos
- Re: Last Call: Change the status of ADSP (RFC 561… Bradner, Scott
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Bradner, Scott
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… Murray S. Kucherawy
- Procedural Changes through side-effect (was: Re: … John C Klensin
- Re: Last Call: Change the status of ADSP (RFC 561… Dave Crocker
- Re: Procedural Changes through side-effect (was: … S Moonesamy
- Spontaneous Procedure Invention ( was Re: Procedu… Dave Crocker
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… S Moonesamy
- Re: Last Call: Change the status of ADSP (RFC 561… Barry Leiba
- Re: Last Call: Change the status of ADSP (RFC 561… S Moonesamy