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))

Russ Housley <housley@vigilsec.com> Wed, 07 June 2023 16:36 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 D6D6FC14CE2E; Wed, 7 Jun 2023 09:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham 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 MqbIyD5BpaLe; Wed, 7 Jun 2023 09:36:50 -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 5F036C14CF1D; Wed, 7 Jun 2023 09:36:50 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 8458C161A2D; Wed, 7 Jun 2023 12:36:49 -0400 (EDT)
Received: from [192.168.1.161] (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 68F0A161BA3; Wed, 7 Jun 2023 12:36:49 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <AEE28B86-CACA-4280-99C4-505EC4A16963@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A61770A9-75AC-41B9-8FFD-D82B8F08F7AD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Wed, 07 Jun 2023 12:36:49 -0400
In-Reply-To: <BLAPR09MB63223FFA678A45B6530265B49853A@BLAPR09MB6322.namprd09.prod.outlook.com>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-8210bis@ietf.org" <draft-ietf-sidrops-8210bis@ietf.org>
To: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
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>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/jtPbwW7pt5DEGK1ZYjBi-TK0nu0>
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:36:51 -0000

 Oliver:
> 
> My comment was in the context of changing a version number of a protocol due to changes on the wire where the draft itself is still not approved yet and RFC. Doing that (bumping the version number) because of changes in the very last moment in the approval process does set a wrong precedent – at least in my opinion. Therefore, I am not in favor of bumping the version number as Job suggested.

I think there is a bit of judgement that needs to be applied here.  The answers to these questions shoudl guide the decision:

1.  How many implementations are using the version number in the Internet-Draft?

2.  How much deployment of those implementations has taken place?

3.  What are the consequences if those implementations if the RFC uses the same version number with a different structure?

Russ

v2.23.0 | Report a Bug | By Email