Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt

Martin Hoffmann <martin@nlnetlabs.nl> Thu, 29 June 2023 09:58 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 6651CC151534 for <sidrops@ietfa.amsl.com>; Thu, 29 Jun 2023 02:58:19 -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 CGr2VrTShySs for <sidrops@ietfa.amsl.com>; Thu, 29 Jun 2023 02:58:15 -0700 (PDT)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a10:de80:1:4091:b9e9:2214: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 EAF16C14CEED for <sidrops@ietf.org>; Thu, 29 Jun 2023 02:58:14 -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)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 4QsDR73vvlzCw; Thu, 29 Jun 2023 09:58:11 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4QsDR71BL4zFB; Thu, 29 Jun 2023 09:58:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1688032691; bh=G8eIXKzSB7l9queQvT9HeFtuMbGiXyOAt1cwC0uuFVg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aStG6PiH2C03hSA3/srKnfVytqgTKt7uybQJ+UJC1lipvQCirIDA9/eRwcQO9Y1WU eWfc1veeYW/HE9YKyeuKkeyIXIULpGHpDO7IK6lnCXSmvlta6bLHz3H9ctjgX8HZyO rQ89j10QuEvu1OQO9wlUTt6AJzd7fb7BbE/3s9euyF5SrU86xrdhQc8ILop8z1/fUy OABo883bmpLjI8zFZND5+Jt5IrZpzfhi47iFtBg+pKu/JSYL623DFvqCOY3K4SPQtA 1ciFuyV81+yMW4QKjuC6lWKutJo2yvXSe60dhA8RpWZQ3gwNzuMryBuDa1XZnXPNMy 7wmJaHNUWZ61A==
Date: Thu, 29 Jun 2023 11:58:10 +0200
X-Soverin-Authenticated: true
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
Cc: sidrops@ietf.org
Message-ID: <20230629115810.1c65c0c8@glaurung.nlnetlabs.nl>
In-Reply-To: <ZJxXjg1NNdgVRP50@snel>
References: <168621843689.33017.6897451444105786551@ietfa.amsl.com> <ZIGogKIH4Srb8Nxt@snel> <20230628173307.29fefec2@glaurung.nlnetlabs.nl> <ZJxXjg1NNdgVRP50@snel>
Organization: NLnet Labs
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/D85gkhiBuh_qv68o3M1mYPysU1A>
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 <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: Thu, 29 Jun 2023 09:58:19 -0000

Job Snijders wrote:
> On Wed, Jun 28, 2023 at 05:33:07PM +0200, Martin Hoffmann wrote:
> 
> > 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.  
> 
> 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.
> 
> 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.

I’d 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’t 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.

I’m a bit worried with having version 1 in a newly published
standard. It’ll 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 ...

  -- Martin