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]
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
