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

[Job Snijders <[e-mail]>]

Dear Roman,

On Mon, Apr 15, 2024 at 11:42:18AM -0700, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Gyan Mishra for the GENART review.
> 
> ** Section 2.*
> 
> -- Section 2
>    When the content of a file is unchanged,
>    Publishers SHOULD ensure that the last modification timestamp of the
>    file remains unchanged as well.
> 
> -- Section 2.2
>    When serializing RPKI Signed Objects retrieved via RRDP to a
>    filesystem hierarchy, the mod-time of the file containing the Signed
>    Object SHOULD be set to the value of the CMS signing-time attribute
>    contained within the Signed Object.
> 
> How does this mechanism work if the timestamp is not set per the above
> guidance?  Why not MUST?

If the timestamp is not set per above guidance, a needless re-transfer
of previously distributed data will happen. It results in a waste of
bandwidth, that's all. I think 'SHOULD' is more appropriate because
there is no enforcement mechanism: for example, the timestamp does not
impact the validity of the RPKI objects.

I also don't want to put existing operations in a state of
'non-compliance', and erred to the side of softer guidance. This
document describes an optional optimization strategy.

> ** Section 2.  Editorial.
>    As described in [I-D.ietf-sidrops-prefer-rrdp], all modern RP
>    implementations will first attempt synchronization via RRDP.
> 
> Is “modern” characterization that will age well in an RFC?

Good point. I changed wording in the edit buffer, please review
https://github.com/job/draft-sidrops-cms-signing-time/commit/e3879df7dd3d06b574df7b3620fbeafe0de1c9cc

> ** Section 2.2.  Section 2 says the “Publishers and RPs SHOULD adhere to the
> following guidelines”, where these guidelines are Section 2.*.  Later, in
> Section 2.2, there appears be guidance around the specific invocation of
> [rsync] and [openrsync].  Hence, both of these references need to be normative.

OK. Done
https://github.com/job/draft-sidrops-cms-signing-time/commit/36e31f8cb298ef3e4770a306a88edc665f00c4b9

> ** Thanks for the analysis in Section 3.

You are welcome, I burned a fair bit of CPU cycles on parsing old RPKI
data :-)

Kind regards,

Job