From nobody Thu Jun 29 09:48:44 2023 Return-Path: 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 A2604C14CF1B for ; Thu, 29 Jun 2023 09:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no 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 XCSyPus-IuZm for ; Thu, 29 Jun 2023 09:48:39 -0700 (PDT) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (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 D155EC14CF17 for ; Thu, 29 Jun 2023 09:48:39 -0700 (PDT) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id D119418E861; Thu, 29 Jun 2023 12:48:38 -0400 (EDT) Received: from smtpclient.apple (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id B9B6018F7D7; Thu, 29 Jun 2023 12:48:38 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) From: Russ Housley In-Reply-To: <4301BB4A-F87D-423E-94CC-C8B3037DA232@ripe.net> Date: Thu, 29 Jun 2023 12:48:28 -0400 Cc: Martin Hoffmann , Job Snijders , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F7A7A89-E828-4E45-A7D6-1A5325EE9BBD@vigilsec.com> References: <168621843689.33017.6897451444105786551@ietfa.amsl.com> <20230628173307.29fefec2@glaurung.nlnetlabs.nl> <20230629115810.1c65c0c8@glaurung.nlnetlabs.nl> <4301BB4A-F87D-423E-94CC-C8B3037DA232@ripe.net> To: Ties de Kock X-Mailer: Apple Mail (2.3731.600.7) X-Scanned-By: mailmunge 3.11 on 66.39.134.11 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2023 16:48:43 -0000 For all of the reasons given here, I think that version=3D1 with the = current OID is a good way forward. Russ > On Jun 29, 2023, at 6:14 AM, Ties de Kock wrote: >=20 > Hi all, >=20 >> On 29 Jun 2023, at 11:58, Martin Hoffmann = wrote: >>=20 >> Job Snijders wrote: >>> On Wed, Jun 28, 2023 at 05:33:07PM +0200, Martin Hoffmann wrote: >>>=20 >>>> While we are at it, I would like to again raise the suggestion to >>>> not use a version 1 here but rather stick to 0 and use a different >>>> content type OID. The older and newer definitions are not >>>> compatible, so a new OID feels more appropriate than a version >>>> change. =20 >>>=20 >>> I can see your argument, but I'm not sure there is clear consensus = to >>> request a fresh content-type OID, and there are counter-arguments = too. >>>=20 >>> In the past the ASPA profile definition has been updated without >>> cranking the version or content-type OID. Some argue we are in a = phase >>> of 'experimentation' (since the internet-draft isn't published as >>> RFC), where some incompatibility with older revisions of the draft = is >>> to be expected and of no concern. >>=20 >> I=E2=80=99d be okay with leaving the version at 0 and using the = current OID as >> well. The old-format objects will fail to be decoded either way, so = it >> doesn=E2=80=99t really make a difference in practice. Depending on = how the >> parser works, they may be rejected even before you get to the version >> check, too. >=20 > A benefit of a separate version is a cleaner way to support both = profiles. There > is a nice natural experiment in this on how long it takes people to = switch to > compliant implementations. >=20 >>=20 >> I=E2=80=99m a bit worried with having version 1 in a newly published >> standard. It=E2=80=99ll be the only one that does that and it is very = easy to >> miss because it really is just a single digit in the text below the >> grammar. Ask me how I know ... >=20 > We have a number of test cases by now. The objects I use for interop = testing are > currently in [0] (unfortunately the URL will not be stable after = merging this). > By now we have covered quite a few variations :) >=20 > A benefit of a separate version is a cleaner way to support both = profiles. There > is a nice natural experiment in this on how long it takes people to = switch to > compliant implementations of CAs. >=20 > = https://github.com/RIPE-NCC/rpki-commons/tree/feature/aspa-profile-15/src/= test/resources/interop/aspa >=20 > If we move back to version 0, let=E2=80=99s do that with a new OID=E2=80= =A6 >=20 > As a repository operator we parse _all_ objects in repositories for = some > consistency checks, having multiple structures for the same version = complicates > things more. >=20 > Kind regards, > Ties > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops