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

[Job Snijders <[e-mail]>]

Dear Orie Steel,

Thank you for taking the time to read and review this internet-draft!

On Mon, Apr 08, 2024 at 01:36:26PM -0700, Orie Steele via Datatracker wrote:
> ## Comments
> 
> ```
> 129        Publishers SHOULD ensure that the last modification timestamp of the
> 130        file remains unchanged as well.
> ```
> 
> Why not MUST? What happens if they do not?

If publishers do not ensure the last modification timestamp of the file
remains unchanged, the file might be needlessly re-transmitted. This
potentially results some waste of bandwidth, but but does not impact the
validity of the Signed Objects.

The internet-draft outlines an optimization, it does not describe a
'without this, RPKI wont work'-concept

> ```
> 156        In order to reduce the burden of the rsync synchronization (following
> 157        an RRDP failure), Publishers and RPs SHOULD adhere to the following
> 158        guidelines.
> ```
> 
> Why not MUST? Perhaps this sentence is not needed.

The authors thought it might be helpful to explain why the guidelines
are useful to implement, what the benefits are if advantage of the
optimization is taken. But again, if publishers don't follow this
guidance the end result is inefficient, but still functional transfers
of RPKI data.

> ```
> 162        When serializing RPKI Signed Objects to a filesystem hierarchy for
> 163        publication via rsync, the mod-time of the file containing the Signed
> 164        Object SHOULD be set to the value of the CMS signing-time attribute
> 165        contained within the Signed Object.
> ```
> 
> Why not MUST? What happens if the mod-time is set to something else?
> Does this guidance also apply to publishers that support RRDP in
> addition to rsync?

if the mod-time is set to something else, the data might needlessly be
retransferred. The guidance applies to all publishers, including the
ones that support RRDP. Every publisher MUST support rsync, which is
where these guidelines are recommended.

> ```
> 169        When serializing RPKI Signed Objects retrieved via RRDP to a
> 170        filesystem hierarchy, the mod-time of the file containing the Signed
> 171        Object SHOULD be set to the value of the CMS signing-time attribute
> 172        contained within the Signed Object.
> ```
> 
> Why not MUST?
> 
> The amount of redundancy between this section and previous section, is
> confusing. I would assume publishing and consuming would both need guidance on
> CMS signing-time, regardless of if rsync or RRDP was used.

The above section is for Relying Party implementers (the counterpart to
the publisher side). I made an attempt by splitting the different
instructions for publishers and relying parties into 2 sections:
"2.1 Guidance for Publishers" and "2.2 Guidance for Relying Parties".
Do you have suggestions to resolve the potential for confusion?

As to your question about MUST, if Relying Party implementers ignore
this internet-draft, those implementations might be more wasteful in
terms of bandwidth, but still will be functional. So softer guidance
seemed appropriate.

All in all this document is "do X if you want maximum efficiency", but
if publishers or relying parties don't read this draft, it's not the end
of the world. Hope this clarifies where we're coming from!

Thanks & kind regards,

Job