On Sun, Apr 07, 2019 at 02:11:13PM -0400, Michael Richardson wrote:
> 
> I have read draft-pwouters-ikev1-ipsec-graveyard-00.
> 
> I think that the actual words and organization of the document could use a
> bit of polish, but fundamentally it does the right thing, and sends the right 
> message.
> 
> I would like to ask the WG to adopt this document, we can sort out the
> wording afterwards, and spend (priority) WG time on this document.
> 
> I would very much like to point to a clear statement when I see IKEv1 being
> used in the field for no good reason (except that nobody thought about IKEv2).
> If it has to be in the form of an RFC, so be it: I'd like to be able to say
> to a manager, "You are not RFCZZYY compliant", and I'd like this to get
> into a variety of security audit lists.
> 
> The document likely has likely little technical impact, and I think we should
> acknowledge that this is a policy statement.
> That's okay with me, if it it is okay with the IESG.
> If there is another way to get the same impact, I'm open to hearing it.
> 
> The datatracker page for RFC2409 already says:
>    Type               RFC - Proposed Standard (November 1998; No errata)
>    Obsoleted by RFC 4306
>    Updated by RFC 4109
> 
> But, I think that the goal is to mark these documents as Historic as well.
> I didn't see that action in the document specifically (maybe I missed it).
> Many updates to the IANA registries, which we could do in other ways, I think.
> 
> As I understand it, marking something as Historic is something the IESG can
> do without publishing a document.  The changes to the IANA registries I'm
> less clear about, but I believe it could also be done without a document.

To move to historic, there should be some form of document (per
https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/) but it
need not be published as an RFC.  The past few times we've done this
everyone involved had to think for a while to remember what the right way
to wrangle the wording in the published RFC should be, but we can worry
about that later if we need to.

-Ben

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

Reply via email to