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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Job,

Thanks for your reply.

Indeed, the proposed abstract sounds more like a real abstract.

About the SHOULD, it can possibly be linked to “if the publisher wants to scale and reduce its load” in the same sentence or prefix the whole section with a similar “context setting”; I agree that the whole document is about performance but let’s be clear with the use of SHOULD

Regards

-éric

From: Job Snijders <[e-mail]>
Date: Tuesday, 16 April 2024 at 17:40
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-sidrops-cms-signing-time-06: (with COMMENT)
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