Re: [Sidrops] WG Last Call for draft-ietf-sidrops-signed-tal-14

Job Snijders <job@fastly.com> Sun, 25 February 2024 09:51 UTC

Return-Path: <job@fastly.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 95FDCC14F6AB for <sidrops@ietfa.amsl.com>; Sun, 25 Feb 2024 01:51:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 (1024-bit key) header.d=fastly.com
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 xH9vSLEmAkOG for <sidrops@ietfa.amsl.com>; Sun, 25 Feb 2024 01:51:18 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 0166CC14F68C for <sidrops@ietf.org>; Sun, 25 Feb 2024 01:51:17 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5640fef9fa6so2754238a12.0 for <sidrops@ietf.org>; Sun, 25 Feb 2024 01:51:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1708854676; x=1709459476; darn=ietf.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=dz72oCqbdtuAQNDUALAHe7Fo4oVbVmtprXswfiiANoM=; b=TKt5yySOUmT6lBaX8VHCjdFTz3TMiD5u7Q1xslKJQ6xEwCEXVa5A6BV9IEhecR4/j8 yNt66lOiF1LceXC9jsuKXULKQVgVJZDDDWECvJHtHqMlhMDq763nO2KmvMz36Jpgp3av abd/FHbwMEAFFYwO0hRQNOrzt+/XcwqTjP+5Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708854676; x=1709459476; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dz72oCqbdtuAQNDUALAHe7Fo4oVbVmtprXswfiiANoM=; b=RRHN08YhItgRSc9YhQvr575Ru9eN0S+BS3hdkBv2Ir1wjgKg0MYfJplvTVJTu+eAv2 30rnFZNzv+p6rLo57Lv2wi6IAd7nYOTwwPNmXc2kYs79XBg4OK2U7f2C6apQYxzUc0jt xkWa+HHJx0RpxUvFLggnX1AagNG3GJW6kAje6Kls6TZcUxcNtoEUCrroUT0UtEREY4Rt jUBqTJaAbGbqWcm710IxXvdQuoWloqMJJ5eqStfkeC5XmcDLTnDu7oANTrog+vmmcvP9 Q8LrYZX5dpz56mPivZVyTtY/Y3Iz9qvpTTfQ1A7hV79VzWas1tWVYo3/mlySDT72Itz/ TkhA==
X-Gm-Message-State: AOJu0YzYzAT3ME1Biq07QZIMTb0J3BBg9E9rsIm44x2K2xRkpt/HgRLx TO/tBL1mU9zPaCj2VUetJKNwTDVoPnbJbSyohZf3dhNyNQVCZyeEYNeV13hqh4nOcC6Y5jNMl0W SRqc=
X-Google-Smtp-Source: AGHT+IGLsJ8oPUE7Br1m9hSZKkbLlbpynP6GgjnN2UK3hqbpbTylIV3potaIfPcRGqiEv20AebZgtg==
X-Received: by 2002:aa7:df83:0:b0:564:ded0:6072 with SMTP id b3-20020aa7df83000000b00564ded06072mr3159397edy.1.1708854676210; Sun, 25 Feb 2024 01:51:16 -0800 (PST)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id i14-20020aa7c9ce000000b00565b7d10d4csm978712edt.37.2024.02.25.01.51.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Feb 2024 01:51:15 -0800 (PST)
Date: Sun, 25 Feb 2024 10:51:14 +0100
From: Job Snijders <job@fastly.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IETF SIDRops <sidrops@ietf.org>
Message-ID: <ZdsNkkdU3E9fkhWS@snel>
References: <C61AE8CA-3692-43E0-ACE4-8BB0DEDB6D8B@vigilsec.com> <FBBB194A-4173-4BA1-90B4-300E3F2BD01C@vigilsec.com> <ZckQPu8XZIeQV0lT@snel> <197F876A-4E55-47DE-9D88-D15D73829F2E@vigilsec.com> <6DA529FA-9F54-4030-BEEB-F08F9551CFD8@vigilsec.com> <ZdsJjqxhTRC6xiFC@snel>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZdsJjqxhTRC6xiFC@snel>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ky8B9vnSlgfFGEafml_Y3wZxJsA>
Subject: Re: [Sidrops] WG Last Call for draft-ietf-sidrops-signed-tal-14
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: Sun, 25 Feb 2024 09:51:21 -0000

On Sun, Feb 25, 2024 at 10:34:06AM +0100, Job Snijders wrote:
> On Sat, Feb 24, 2024 at 03:34:50PM -0500, Russ Housley wrote:
> > >> Some time ago I implemented support for validating Signed TAL
> > >> (.tak) objects in OpenBSD's rpki-client validator. I found the
> > >> availability of a testbed as provided by the authors of this
> > >> document very helpful. 
> > > 
> > > Are you aware of any other implementations? Did you do
> > > interoperability testing. This information will be useful for the
> > > shepherd write-up.
> > 
> > I should have also said that I am aware of the information of Section
> > 13 of the draft. I am asking whether there is anything additional
> > since the draft was published in September 2023.
> 
> I did interop testing between the APNIC and rpki-client implementations.
> Back in 2022, Tom Harrison and myself went back and forth a few times to
> ensure our respective implementations and the draft were all aligned.
> 
> I'm not aware of new Signed TAL developments since September 2023 (I
> think it was around that time the suggestion was brought forward to
> start a WGLC), but perhaps the draft authors know more than I do?

Russ, should the SIDROPS chairs not be entirely convinced enough
implementation work was done to comply with Standards Track
implementation requirement, the draft's status could be marked as
"Waiting for Implementation"

>From https://datatracker.ietf.org/doc/help/state/draft-stream-ietf/

    """
    Waiting for Implementation

    In some areas, it can be desirable to wait for multiple interoperable
    implementations before progressing a draft to be an RFC, and in some
    WGs this is required. This state should be entered after WG Last
    Call has completed.
    """

It might be good to hear back from at least one other implementation
effort.

Kind regards,

Job