IETF Logo Mail Archive

Re: [Sidrops] Making ASPA AFI-Agnostic - coordination (Was: WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023))

Martin Hoffmann <martin@nlnetlabs.nl> Wed, 07 June 2023 16:49 UTC

Return-Path: <martin@nlnetlabs.nl>
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 8451EC151061; Wed, 7 Jun 2023 09:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r97hxqmq2Fk3; Wed, 7 Jun 2023 09:49:33 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a10:de80:1:4092:b9e9:2292:0:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF66C1519A7; Wed, 7 Jun 2023 09:49:31 -0700 (PDT)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4Qbtbr6d4lzDy; Wed, 7 Jun 2023 16:49:28 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4Qbtbr4bD0z1g; Wed, 7 Jun 2023 16:49:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1686156568; bh=ZLHLtX/dtdu1lpeWa/x0eQwLDqcAlMizdWRl8NH6H28=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XSfHnojfdiU+W4QPHnOj3K1vZwcy/0/YV2iOIIt8DDUGVLqqEZPHPz+xoehBuDIYt h3qy32Ha0LIOZU1avV7NNW3+51X0SgKnIOE9d0Olwe2Kc07jtOxeeFvqe1FdTu3KmF Nu26NBgMFHTk+TJ8Zc9v5o8CXAd+ywi9VVIy6csMd+k49IJNPQpvD63pB0Erh538+H oFKt+PCQoj6ViDtf0KKKSKmW71iyuTUHdrnU8MC5Z0VMRkvVuuuE6aBaipW27kIsjn fBqVUA/+4VZprp2HpUOLFQZ+lcR7bq5jPbdn5Mh/iR6PzwK8xY+tI9OJ+xErOrZNdY Atuog3z5iMSXQ==
Date: Wed, 07 Jun 2023 18:49:27 +0200
X-Soverin-Authenticated: true
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: Russ Housley <housley@vigilsec.com>
Cc: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-8210bis@ietf.org" <draft-ietf-sidrops-8210bis@ietf.org>
Message-ID: <20230607184927.56a48b58@glaurung.nlnetlabs.nl>
In-Reply-To: <AEE28B86-CACA-4280-99C4-505EC4A16963@vigilsec.com>
References: <88D8A314-0D17-4EA7-9E33-424021AF0FFF@vigilsec.com> <SA1PR09MB814232A57F80E8B92637ABF684639@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB8142A3F0D8E30F4F154863A084639@SA1PR09MB8142.namprd09.prod.outlook.com> <SA1PR09MB81427668A874A3EEFDE61DAE846A9@SA1PR09MB8142.namprd09.prod.outlook.com> <20230428100855.3450881e@glaurung.nlnetlabs.nl> <SA1PR09MB8142DA858A2039F2ED7DAD2B846E9@SA1PR09MB8142.namprd09.prod.outlook.com> <20230502124540.6bc662ba@glaurung.nlnetlabs.nl> <CAL9jLaaL2vvRYL6+ftu8vP9fDWWBoF5NFCGGL_nDj+_VSc5E4Q@mail.gmail.com> <ZH+hdvAwuZ7nN3vK@snel> <4dbb0ef4-91fc-6bbd-d979-2d0b736295ac@tu-dresden.de> <ZIBJUycE10HjIfAP@diehard.n-r-g.com> <BLAPR09MB63226569F3349669ABBEA60D9853A@BLAPR09MB6322.namprd09.prod.outlook.com> <62C121A4-DD89-477A-98EC-4356420F4888@vigilsec.com> <BLAPR09MB63223FFA678A45B6530265B49853A@BLAPR09MB6322.namprd09.prod.outlook.com> <AEE28B86-CACA-4280-99C4-505EC4A16963@vigilsec.com>
Organization: NLnet Labs
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Kgp7idB1PYX9iTdFNqzsMYYCTrA>
Subject: Re: [Sidrops] Making ASPA AFI-Agnostic - coordination (Was: WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023))
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 07 Jun 2023 16:49:37 -0000

Russ Housley wrote:
> 
> 3.  What are the consequences if those implementations if the RFC
> uses the same version number with a different structure?

Hm, this raises in interesting point not about RTR but about the ASPA
profile. Have there been ASN.1 defined protocol structures where a
version change triggers an entirely different definition rather than
just extending the original? E.g., in X.509 certificates, the version
number just mandates different extensions or limits certain optional
values.

Maybe a better approach would be to use a different content type OID?

  -- Martin

v2.23.0 | Report a Bug | By Email