Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

Tero Kivinen <kivinen@iki.fi> Wed, 03 May 2017 09:15 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E22129479; Wed, 3 May 2017 02:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUZLdgawzLAn; Wed, 3 May 2017 02:15:16 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352AF12955F; Wed, 3 May 2017 02:12:42 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v439Caet007016 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 May 2017 12:12:36 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v439CZF3022224; Wed, 3 May 2017 12:12:35 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <22793.40707.624092.66793@fireball.acr.fi>
Date: Wed, 03 May 2017 12:12:35 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: ipsecme-chairs@ietf.org, Eric Rescorla <ekr@rtfm.com>, IPsecME WG <ipsec@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly <tpauly@apple.com>, The IESG <iesg@ietf.org>
In-Reply-To: <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net>
References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <CABcZeBMj9UpzD+CpvOMKOkUsYNSL-UQCwuYt__5XCXtH=zyesA@mail.gmail.com> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <CAKKJt-fb1vx=SzpJ_9gvtJ+SEH08nyBRGqb7F36PGw0EyJ6zmA@mail.gmail.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 14 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/bZihQtb8FCeV_B6qJvtIvK3V_0s>
Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 09:15:19 -0000

Mirja Kuehlewind (IETF) writes:
> my thinking was that the main problem is that 3947 was not obsoleted
> and I’m assuming we need a document to fix that.

This is partly issue, but it is not issue we need to solve here, as
this document is not something that should obsolete 3947.

Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
already obsoleted, so effectively RFC3947 is already obsoleted, as
there is no way to implement 3947 without implementing obsoleted
protocol...

This issue is not not important enough to require RFC now.

> In this case that document could/should also fix the IANA entry for
> the UDP port. However, I’m actually not sure what the right
> processing would be to fix this forgotten obsolete… maybe other ADs
> know better…?

For now I would just leave it as it is, but fix the references in the
IANA registry so that document will not be referenced, especially as
the original IANA reference was not to the correct RFC in the first
place. 

> Otherwise if you don’t want to do this, I don’t think it’s a good
> idea to merge kind of unrelated fixes into this spec. We can also
> fix that by using the IESG approval process (see RFC5226). I think
> that’s the better option!

That is true, but as this document already modifies the TCP/4500
reference, fixing the UDP/4500 reference at the same time is not
completely unrelated fix. 

Obsoleting RFC3947 would be unrelated fix. 
-- 
kivinen@iki.fi