Subject: [IPsec] graveyard: deprecate->historic

From: Sean Turner <[email-masked]>
Date: Tue, 17 Dec 2019 14:31:08 -0500

warning: process mumbo jumbo follows

Technically, I think that s3 of draft-pwouters-ikev1-ipsec-graveyard is trying to do is move IKEv1 to historic.  IKEv1 is already obsoleted by RFC 4036, but that’s not quite the same thing as moving what was a standards track document to “historic”.  The various way to move an RFC to historic is described in this IESG statement {0].  Since there’s already a draft going, it seems like #3 is the path.

The question is whether there should be two drafts: one that moves RFC 2409 to historic and the other deprecates the algorithms.  I wouldn’t be hard over on splitting, but it’s probably better to use the “historic” terminology in s3. I suggest the following changes:

0: Tweak abstract

OLD:

 This document deprecates Internet Key Exchange version 1 (IKEv1) and
 additionally deprecates a number of algorithms that are obsolete.

NEW:

 This document moves Internet Key Exchange version 1 (IKEv1) to
 Historic status.  It also deprecates a number of algorithms that
 are obsolete and closes all IKEv1 registries.

1: Tweak intro

OLD:

 This document specifies the deprecation of
 IKEv1, and requests IANA to close all IKEv1 registries.

NEW:

 This document moves IKEv1 to to Historic status, and
 requests IANA to close all IKEv1 registries.

2: Change section title

s/Deprecating IKEv1/RFC 2409 to Historic

spt

[0] https://ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/
[1]

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Dec 2019 10:46:51 -0800

Since we're in pedantic process mode...

>  Historic status.  It also deprecates a number of algorithms that

"this document" (i.e., the RFC-to-be) does not actually effecuate the move
to Historic status; the separate "status-change" document does so.  Looking
at a recent example in RFC 8429, we see this phrased akin to "Accordingly,
IKEv1 has been moved to Historic status" with no claim of doing so because
of the current document.

>  This document moves IKEv1 to to Historic status, and

(similar here)

> s/Deprecating IKEv1/RFC 2409 to Historic

This is probably okay to keep (I see Paul took the changes already), but
the first sentence is still "IKEv1 is deprecated", which is sending mixed
signals.  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."

-Ben

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Dec 2019 21:41:11 -0500 (EST)

> IKEv1 has been moved to Historic status" with no claim of doing so because

Changed, see https://tools.ietf.org/rfcdiff?url2=draft-pwouters-ikev1-ipsec-graveyard-04.txt

Paul

> signals.

Is it a mixed signal? I've left the sentence in for now, but I'm fine if
we decide to remove it. I can always do that after adoption when I need
to re-submit the draft under the new name anyway.

Paul