> On Jan 1, 2020, at 17:01, Benjamin Kaduk <ka...@mit.edu> wrote:
>
> 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
BTW - however this ends up, I hope the WG will adopt this draft.
spt
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
