On Mon, Dec 30, 2019 at 09:41:11PM -0500, Paul Wouters wrote: > On Mon, 23 Dec 2019, Benjamin Kaduk wrote: > > > "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. > > Changed, see > https://tools.ietf.org/rfcdiff?url2=draft-pwouters-ikev1-ipsec-graveyard-04.txt > > Paul > > >> requests IANA to close all IKEv1 registries. > >> > >> 2: Change section title > >> > >> 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. > > 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.
I guess it's not entirely clear. https://ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ implies that "Historic" is for technology that is "retired", but in some usage, "deprecated" has more of a connotation of "not the best choice right now" which is not necessarily fully "retired". We can leave it as-is for now. -Ben _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
