Re: graveyard: deprecate->historic

> On Jan 1, 2020, at 17:01, Benjamin Kaduk <[email protected]> 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