Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00
Tero Kivinen <kivinen@iki.fi> Thu, 09 February 2017 12:40 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 5527F1299DA for <ipsec@ietfa.amsl.com>; Thu, 9 Feb 2017 04:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 IFtudnp_JcpF for <ipsec@ietfa.amsl.com>; Thu, 9 Feb 2017 04:40:49 -0800 (PST)
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 2D4731299CC for <ipsec@ietf.org>; Thu, 9 Feb 2017 04:40:48 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v19Cec9B024490 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Feb 2017 14:40:38 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v19CeceM029258; Thu, 9 Feb 2017 14:40:38 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22684.25414.470545.969594@fireball.acr.fi>
Date: Thu, 09 Feb 2017 14:40:38 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: David Schinazi <dschinazi@apple.com>
In-Reply-To: <D28C9CC6-FD00-4A42-8451-F9B0AA83E4BF@apple.com>
References: <22683.8182.349840.103676@fireball.acr.fi> <D28C9CC6-FD00-4A42-8451-F9B0AA83E4BF@apple.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 11 min
X-Total-Time: 13 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/RiduXpY7Z4qRW59RF7jF4g55gRk>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00
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: Thu, 09 Feb 2017 12:40:50 -0000
Ah I noticed that my last call email had wrong draft name in the subject line and in the link. The correct draft name is of course draft-ietf-ipsecme-eddsa-00 not *-nir-* version. David Schinazi writes: > I've reviewed this draft. I support it and believe it is ready to move forward > towards becoming a standards-track RFC. Also, would it make sense to ask > IANA for early assignment of the code point? Using 0 sounds reasonable to me. As this is expert review registry there is no need to ask for early allocation, the normal process is just to fill in the IANA general request for assignments, which then goes to the IANA and they will then send it to the expert (me) for verification. If normal number (other than 0) would be given out, then I would just say yes, but allocating 0, which in registry is marked as: 0 Reserved [RFC7427] and is not part of the : 5-1023 Unassigned range, then I would be bit more hesitant to give it out, and would most likely want to poll the WG and list before making decision. I actually myself think it would be better to just allocate next free number from the unassigned space, and keep the value 0 as reserved... For example we do not use value 0 of Encryption Algorithms transform to mean ENCR_NULL, we do have separate number allocated for it. On the other hand we do have value 0 meaning NONE in the Integrity algorithm transform ID table and for diffie hellman values, but there the meaning is bit different, it means there is no value for that id, here it would be meaning that there is this identity function version of the hash function. As an expert and as a implementor I think I would prefer next free number over 0... Quite commonly in the code we use value 0 as meaning, we have not yet received anything, or we have not yet initialized this field, and having separate value for identity function might make things easier. But if others have good reasons why the value 0 is better, feel free to tell me... -- kivinen@iki.fi
- [IPsec] Working group last call for the draft-nir… Tero Kivinen
- Re: [IPsec] Working group last call for the draft… David Schinazi
- Re: [IPsec] Working group last call for the draft… Tero Kivinen
- Re: [IPsec] Working group last call for the draft… Tommy Pauly
- Re: [IPsec] Working group last call for the draft… Paul Wouters
- Re: [IPsec] Working group last call for the draft… David Schinazi
- Re: [IPsec] Working group last call for the draft… Andreas Steffen
- Re: [IPsec] Working group last call for the draft… Tero Kivinen
- Re: [IPsec] Working group last call for the draft… Daniel Migault
- Re: [IPsec] Working group last call for the draft… Yoav Nir
- Re: [IPsec] Working group last call for the draft… David Schinazi
- Re: [IPsec] Working group last call for the draft… Yoav Nir
- Re: [IPsec] Working group last call for the draft… Daniel Migault