Re: [Sidrops] Éric Vyncke's No Objection on draft-ietf-sidrops-cms-signing-time-06: (with COMMENT)

Job Snijders <job@fastly.com> Tue, 16 April 2024 15:40 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 B7F39C14CF01 for <sidrops@ietfa.amsl.com>; Tue, 16 Apr 2024 08:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 jZLkOxwy8VVn for <sidrops@ietfa.amsl.com>; Tue, 16 Apr 2024 08:40:15 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 D759DC14F700 for <sidrops@ietf.org>; Tue, 16 Apr 2024 08:40:15 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a5200202c1bso600715566b.0 for <sidrops@ietf.org>; Tue, 16 Apr 2024 08:40:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1713282014; x=1713886814; darn=ietf.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=NUdZIABHFqGAhrNWrGmzNaPlXxk+kZcudHQ6cJKjzQA=; b=TBF1UCrSEU0ebddORq1YW1AtXhbauGYjpKfQIHccSTzwlYoIdkKUGtCd+l7Dg6XZR6 LVdngJV6Wz0u5NLn/jCqeLU4m6ogqYygYIr2hSFfddEAA5PWFIYC30EmPzfRQXFGE3pf EszooMcOjoNpsUo45Tgx4c0gSer0wFtIuP0Tk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713282014; x=1713886814; h=in-reply-to:content-transfer-encoding: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=NUdZIABHFqGAhrNWrGmzNaPlXxk+kZcudHQ6cJKjzQA=; b=sa7kqXK1nP5eZcduZJhk4C3YM3Nj+7KD932HULtEjxMlSVzJcx2CgEeLMRk9iKsdjp gVSF65msI8zgYO7v+4LpqiZZez7oXl2AVznjz1i1miOQdBxVS8MfgNrawaKu2MynF6xa Wyv5QWvGV9bT7coOX5/gXmunk+HUDMeKrL9TUO7SPlQ7k27ZhIE4GQCltV1jmVlV5b0F TFeszUprUTL5RzHLEyM5mMrdZ/hGoXbxc29KTCiSTChKeJIKvxaqwRjBGCduenZcZRbZ AVGL1Mm26rPYjF9Bc6ihVw6w+i/pjHpzD5Ajcc6IScVq/pOyYYdSjCdjsF20XN/kP+Ng z0Cg==
X-Forwarded-Encrypted: i=1; AJvYcCWd4WUc5yfB3ll+FHoufOT6izO5Cwb1N4h5PhNg+KHkc9wn1YxRpZ8vuMbkFByvRvJTk3lxWiYa9i5lu5cDr44J
X-Gm-Message-State: AOJu0Yz2k6grbanSWbKm6YWtktAW5Sbu0vOoHzUZcQ/+D2/f78BP55v0 UXZ0AyT37gk5rdFvU1mFOV2FE1qWmNJTcZ6oNA4ViQ04bUFn5blHMMFouk6zmCk=
X-Google-Smtp-Source: AGHT+IG7NyOCpyXOq1XVbpFDN7g+xaTwDCbYbxgOj//4tGzHAjFUZXUKXcb8mFGknBQEG7Okfh0NWw==
X-Received: by 2002:a17:906:c116:b0:a52:35d2:2e72 with SMTP id do22-20020a170906c11600b00a5235d22e72mr12861588ejc.68.1713282013737; Tue, 16 Apr 2024 08:40:13 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id qw24-20020a1709066a1800b00a52277726b3sm6571885ejc.201.2024.04.16.08.40.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 08:40:13 -0700 (PDT)
Date: Tue, 16 Apr 2024 17:40:11 +0200
From: Job Snijders <job@fastly.com>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidrops-cms-signing-time@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, housley@vigilsec.com
Message-ID: <Zh6b2z6B5RsWV7t7@snel>
References: <171325541487.8844.4871280122802368618@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <171325541487.8844.4871280122802368618@ietfa.amsl.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7O05l6OIg-ZOu3iQNetLXF8BZmM>
Subject: Re: [Sidrops] Éric Vyncke's No Objection on draft-ietf-sidrops-cms-signing-time-06: (with COMMENT)
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: Tue, 16 Apr 2024 15:40:20 -0000

Dear Éric,

Thank you for your review!

On Tue, Apr 16, 2024 at 01:16:54AM -0700, Éric Vyncke via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the work done on this document.
> 
> Minor regret about the shepherd's write-up as it lacks the
> justification for the intended status.

Intended status derives from this document updating RFC 6488, which also
is a Standards Track document.

> Like noted by other ADs: the goal of an abstract is not to repeat the
> introduction but be a concise 10-line-max summary of the document.

I've made some changes in the edit buffer to make the abstract an
abstract. Does this seem better to you?
https://github.com/job/draft-sidrops-cms-signing-time/commit/38cfc6fb6459834b1e2c461905842c661d2a1b4a

> In section 2 `Publishers and RPs SHOULD adhere to the following guidelines`
> when can this SHOULD be bypassed ? Same comment applies to many "SHOULD" in
> this document.

The document describes an optimization strategy, "do X to avoid wasting
bandwidth". The SHOULD can be 'bypassed' when the repository operator or
relying party implementation don't want to be efficient.

There is no mechanism to force participants in the ecosystem to comply
with the strategy this draft proposes, fumbling the 'last modified'
timestamps doesn't impact the validity of RPKI signed objects.

I'm open to suggestions!

Kind regards,

Job