Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT)

Tero Kivinen <kivinen@iki.fi> Fri, 02 September 2016 13:42 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 915C212D89B; Fri, 2 Sep 2016 06:42:02 -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 AXwPuOaY9MVO; Fri, 2 Sep 2016 06:42:01 -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 A8B3712D87D; Fri, 2 Sep 2016 06:41:59 -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 u82Dft0L012091 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Sep 2016 16:41:55 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u82Dfr35013948; Fri, 2 Sep 2016 16:41:53 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22473.33185.527507.419009@fireball.acr.fi>
Date: Fri, 02 Sep 2016 16:41:53 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: kathleen.moriarty.ietf@gmail.com
In-Reply-To: <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com>
References: <147269503033.31834.10513562338482321120.idtracker@ietfa.amsl.com> <52A62106-3A93-4511-9FAD-4641BDDFA4CA@gmail.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 23 min
X-Total-Time: 23 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/6vgGX5Ww6A30Gg5F9_nzKkhT-pQ>
Cc: ipsec@ietf.org, Ben Campbell <ben@nostrum.com>, ipsecme-chairs@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-10-01: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 02 Sep 2016 13:42:02 -0000

kathleen.moriarty.ietf@gmail.com writes:
> Could you respond on the timeline and if you think it's reasonable
> and why or if it should be changed. 

Sure.

Out of the nine documents to be published, there is two which are
already going out from the WG, i.e., which are already submitted for
publication (DDoS and curve25519). Two more are almost ready (4307bis
and 7321bis), and those are updating the MTI requirements, thus there
is not that much of protocol work, we just need to agree what is
suitable level for each algorithm.

This means that four of the documents should be out from the WG hands
before the next IETF, and hopefully published as RFC on first half of
2017...

Then there is EdDSA which is mostly waiting for the curdle-pkix to
agree on the OIDS to be used for the EdDSA, and then it should be
ready soon after that is done (it is 2 page document just saying we do
what draft-irtf-cfrg-eddsa and draft-ietf-curdle-pkix do).

For the rest of the items, we have quite stable drafts for three of
them (tcp-encp, split-dns, and implicit IV), so after we get those
first drafts out, we should get them done during the winter.

Only thing that still requires more work is the quantum resistant
version of the IKEv2, and even for that, I think we already have the
idea how it will be done, and it should not take too long.

Also I would assume that during 2017 we most likely will get some new
work items that will start working on, thus we will most likely want
to do recharter by the end of 2017 anyways. And if there is nothing
new to be done, and we have only 1-2 items left, we can continue
working them without WG if needed.

Year ago (IETF 93, July 2015) we had started charter dicussion last
time, i.e., during the meeting we discussed whether we should close
down the WG, or recharter and continue. Then we decided to keep the
WG, and recharter, but the recharter discussion took some time, and as
we did not meet in Yokohama IETF 94, the discussion on charter started
on the IETF 95 in Buenos Aires, and finalized during the IETF 96 in
Berlin.
-- 
kivinen@iki.fi