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

[Terry Manderson <[e-mail]>]

Hi Rob,

On 31/01/2017, 2:23 PM, "Rob Austein" <[e-mail]> wrote:

    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.


The layering of XML, within CMS, within HTTP is certainly tedious.
During interop and development did any situations arise where a failure at one level caused misinterpretation at another or left something in an unclear state?
If not, then we can move past this.
    
    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?

Thank you for the summation. I feel that the discussion is out of place in this document, given the WG has never really reached consensus on the topic AND that RRDP will supersede this concern anyway.
Yes. Please cut the text from this Document.
    
    > 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).

Right, which is the tango held in sidr-oob-setup-06 where both parties agree to the URI.
    
    > 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.

Thanks
Terry