Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-publication-10: (with DISCUSS)

[Rob Austein <[e-mail]>]

At Tue, 17 Jan 2017 22:29:50 -0800, Terry Manderson wrote:
...
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Looking at section 4, operational considerations I was expecting to see a
> review of any considerations as to how this protocol works, the
> interaction between the layers of HTTP, CMS, and XML and any
> implementation differences/difficulties that exist between the 2 known
> implementations.

Interop report not written, would be a separate document in any case.

Don't really understand what you were looking for with the rest of
this, the layering is tedious but straightforward so don't really
understand what "interactions" you thought would be described here.

I am guessing that this part is not the substance of the DISCUSS.
If there's something you really need us to do here, please explain.

> Instead there is a discussion on laying out the
> repository structure under the mandatory to implement _retrieval_
> mechanism (RSYNC) and the nuances of RSYNC itself.

Yes.  Taking it a piece at a time:

- This is present in this document because in this protocol the CA
  engine explicitly specifies the rsync URI at which each object
  should be published.  Thus, if there are considerations for what
  those URIs should be, this seemed like as good a place as we had for
  writing them down.

- I could see a case that the WG should have written some entirely
  different document about URI structure, but, as you no doubt recall,
  this has always been a vexed subject, with a "structure matters for
  efficiency" camp and an "anybody who doesn't like the structure we
  picked can jump in a lake" camp.  This is why none of the language
  in this section is normative: the WG never reached consensus (well,
  I don't think it did, ask a chair if you want an official opinion)
  on this, so we wrote down what we knew about the issue for people
  who want to try to do the efficient thing and left it at that.

- The timing of all of this is a bit odd, since we are finally, with
  RRDP (draft-ietf-sidr-delta-protocol), hoping to get away from all
  this rsync madness, thereby we hope eventually rendering this entire
  topic moot.  But we're not there yet, and rsync is still the
  mandatory to implement protocol.

Now, given all that, I could see an argument for dropping this
discussion out of sidr-publication on the grounds that it will be
totally out of place if RRDP takes over.  Would that be satisfactory?

> This appears to be misplaced as the protocol (HTTP/CMS/XML)
> interactions here are simply about publication from a certificate
> authority operator to a repository operator, and in that space
> surely the publication protocol (this doc) is agnostic to the exact
> repo structure.

Yes and no. Yes, but it's still the client who picks the URIs (subject
to veto by the server, but if publication succeeds at all it's with a
URI supplied by the client).

> In both a database world (not a file based one) and where multiple RPKI
> fetch mechanisms (rsync, http, torrent, etc ...) are used, how is the
> exact URI meaningful for sidr-publication?

At the moment, even a database-based server still has to enforce the
rule that each object has a unique rsync URI.  We expect that
restriction to remain in place until rsync is declared irrelevant.