Re: [IPsec] graveyard: deprecate->historic

Dan Harkins <dharkins@lounge.org> Mon, 13 January 2020 15:36 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A301200F1 for <ipsec@ietfa.amsl.com>; Mon, 13 Jan 2020 07:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mmfN7pw45Gva for <ipsec@ietfa.amsl.com>; Mon, 13 Jan 2020 07:36:41 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C6B120033 for <ipsec@ietf.org>; Mon, 13 Jan 2020 07:36:41 -0800 (PST)
Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q4100BA9Y15CN@wwwlocal.goatley.com> for ipsec@ietf.org; Mon, 13 Jan 2020 09:36:41 -0600 (CST)
Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q4100726Y08Q0@trixy.bergandi.net> for ipsec@ietf.org; Mon, 13 Jan 2020 07:36:08 -0800 (PST)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 13 Jan 2020 07:36:08 -0800
Date: Mon, 13 Jan 2020 07:36:38 -0800
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <20200113063541.GB66991@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: ipsec@ietf.org
Message-id: <fdde4e33-da84-3f00-f30d-6eab2daa084f@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local)
References: <A8FABB55-C89E-4DDE-88CA-9A5839E023B2@sn3rd.com> <20191223184651.GC35479@kduck.mit.edu> <a0ac2861-d106-a464-be49-53fcc3dc802a@lounge.org> <20200113063541.GB66991@kduck.mit.edu>
X-PMAS-Software: PreciseMail V3.3 [200110] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ukyEtScJcCpy3pGYuZ_mVlLVRy8>
Subject: Re: [IPsec] graveyard: deprecate->historic
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2020 15:36:43 -0000

On 1/12/20 10:35 PM, Benjamin Kaduk wrote:
> On Fri, Jan 10, 2020 at 12:01:39AM -0800, Dan Harkins wrote:
>> On 12/23/19 10:46 AM, Benjamin Kaduk wrote:
>>> Since we're in pedantic process mode...
>> [snip]
>>> Perhaps something like "IKEv1 is no longer relevant for Internet
>>> systems" would work, though I suspect we could even get away without such
>>> an intro sentence and just dive in straight with "Systems running IKEv1
>>> should be upgraded and reconfigured to run IKEv2.
>>     See that's the thing. There is nothing compelling to force the change
>> away
>> from "no longer relevant" so people still use it. If there was something
>> compelling to make people want to change we wouldn't be forced to do this,
>> sigh, die die die nonsense. Perhaps, "we're the IETF and we are really
>> serious now". That should dispel all doubt in whoever happens to read this
>> RFC. That way we won't need a die die die die or a die die die die die die.
> I'm only aboue 95% sure I'm parsing you properly -- you're saying that if
> there was a clear reason to move from IKEv1 to IKEv2 the market would have
> done it already and we wouldn't be bothering with a doc like this?  That
> is, that what we're really doing is akin to "we're the IETF and we
> pinky-swear that we're not going to touch this anymore" as opposed to "here
> is a list of the ways that using IKEv1 is going to bite you"?

   Yes, that's what I'm saying. From discussing this over the past few 
meetings
it seems the motivation for this is because people are still getting 
pressure
in their companies to work on IKEv1 or support IKEv1 or whatever and 
people want
it to go away. But they're losing that argument at work so they want a 
document
with the imprimatur of the IETF that they can wave at the PLM person (or 
whoever)
and say, "SEE! IT'S DEAD! Finished. No more. Over. The IETF has spoken!"

   So my "we're the IETF and we're serious this time" was sarcastic (and 
that comes
out poorly in email, hence the parsing difficulty) because I don't think 
this is
what the RFC process is for.

   IKEv1 is done, it's over, it's dead. It's been like that for more 
than a decade.
We already made a statement that we won't touch IKEv1 anymore and we 
made that
statement fifteen years ago. And we're still doing "die die die" stuff 
that's now
been refashioned into a "graveyard" effort in order to address the sensitive
sensibilities of the new IETF, but it's still the same thing. It's 
trying add an
underscore and an exclamation point to a statement that was already 
made. Because
we're really serious this time-- it's in the graveyard!

   Dan.