Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt

Russ Housley <housley@vigilsec.com> Fri, 01 October 2021 19:30 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74F13A0772 for <sidrops@ietfa.amsl.com>; Fri, 1 Oct 2021 12:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 PnOTeOhoKIt8 for <sidrops@ietfa.amsl.com>; Fri, 1 Oct 2021 12:30:15 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1DA3A0654 for <sidrops@ietf.org>; Fri, 1 Oct 2021 12:30:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6F832300C17 for <sidrops@ietf.org>; Fri, 1 Oct 2021 15:30:15 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R1Ly4tC32NIG for <sidrops@ietf.org>; Fri, 1 Oct 2021 15:30:13 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EC183300233; Fri, 1 Oct 2021 15:30:12 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <F069C65C-2BD2-4DD7-9CDB-96DBAA122CD1@nlnetlabs.nl>
Date: Fri, 01 Oct 2021 15:30:09 -0400
Cc: Ben Maddison <benm@workonline.africa>, SIDR Operations WG <sidrops@ietf.org>, Steve Kent <stephen.kent@verizon.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF18F2E7-D16D-4352-8D2C-E9B6D2DE9271@vigilsec.com>
References: <162730591845.29690.12178353991713962835@ietfa.amsl.com> <2457bdd2-de07-241f-b8e4-87206dabcf16@verizon.net> <28F0ACCE-4D0C-4D80-B4C5-4E8B9D05760F@nlnetlabs.nl> <51acd845-d937-34a1-359b-7379b45e3fe3@verizon.net> <49e73d37-6d26-7715-da60-c2411020d595@verizon.net> <20210930171302.m7b5utqceotecooc@benm-laptop> <B2E57F08-CA61-4713-BFAE-6D36B20EA1D2@vigilsec.com> <20210930205213.kzwpn3e4ft3q33a6@benm-laptop> <F32DADF2-48C1-4CE7-AC4F-5ADB01C0C224@vigilsec.com> <F069C65C-2BD2-4DD7-9CDB-96DBAA122CD1@nlnetlabs.nl>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sAgZCmqHNST5DVIehvJUT8R87rI>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2021 19:30:21 -0000


> On Oct 1, 2021, at 2:47 AM, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
> 
> Hi,
> 
> I saw this:
> 
>> On 30 Sep 2021, at 23:11, Russ Housley <housley@vigilsec.com> wrote:
>> 
>>     version        [0] INTEGER DEFAULT 0,
> 
> This is how it was done, and also what the e.g. the ROA profile uses.
> 
> However, reading the ASPA profile I came across another way, like:
> 
>     version        [0] VERSION DEFAULT v0,
> 
>     VERSION ::= INTEGER { v0(0) }
> 
> 
> This does not change the profile really afaik, but I believe this
> explicitly limits the available options of 'version' to just 'v0',
> i.e. an INTEGER with value 0. So, this may be a bit better in that
> regard.


Tim:

These produce the same bits on the wire.  The difference is that the various versions have names ifor each of the integer version values.  In that case, the name is "v0".

When v1 gets defined, the definition needs to be expanded to:

   VERSION ::= INTEGER { v0(0), v1(1) }

For example, RFC 5652 has:

  CMSVersion ::= INTEGER  { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }


Russ