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

[Orie Steele <[e-mail]>]

Inline:

On Tue, Apr 9, 2024 at 9:32 AM Job Snijders <[e-mail]> wrote:

> 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
>

I see that's what it says above this sentence, but again, why not:

To avoid needless re-transfers of unchanged files in consecutive
rsync synchronizations, [I-D.timbru-sidrops-publication-server-bcp]
publishers MUST ensure that the last modification timestamp of the file
remains unchanged as well,
and MUST use the so-called 'deterministic' (normalized)
timestamps for files.

In other words, answer what MUST a publisher do to avoid the unoptimized
outcome, even if the optimized outcome is not required.


> > ```
> > 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.
>

Ok, this makes sense, and also aligns with your comment above.


>
> > ```
> > 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.
>

Consider phrasing it like:

All publishers that support rsync and RRDP MUST set 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, in order to
reduce the change of needlessly retransferring data.

Essentially you are saying: these optimizations are not required, but
SHOULD be used, in order to achieve them, this is what MUST happen.


> > ```
> > 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!
>

Yes, this clarifies things, I think your intention could be conveyed more
directly / strongly with:

Implementations SHOULD follow these guidelines, in order to avoid
unnecessary data transfer. (you say this already)

In order to avoid unnecessary data transfer the following actions MUST
occur. (you could say this, instead of repeating SHOULD)

However, it might be worth waiting for additional reviews, before taking
any action.


>
> Thanks & kind regards,
>

Thanks again for this document.


>
> Job
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>