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

From: "Terry Manderson" <[email-masked]>
Date: Tue, 17 Jan 2017 22:29:50 -0800

Terry Manderson has entered the following ballot position for
draft-ietf-sidr-publication-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-publication/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Updating after reading sidr-oob-setup-06.

I see that the publisher wins as per Section 5.2.4
<repository_response/>

My original discuss us below, so you may omit the concern about
negotiating the URI. The remainder stands.

Thanks
T.

=-=-=-=-=-=-=-=-
Thanks for finally bringing this protocol forward.

I support Alissa's and Alexey's concerns.

I only have one discuss for this draft.

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

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? There might be a deeper
problem here regarding any potential collisions and negotiation of the
URI space between the certificate authority operator and the publication
repository operator. (sure, in a situation where Alice does both, no
problem.) So you may wish to address issues like that in the operational
considerations section as opposed to dealing with RSYNC (in)efficiencies.

---

From: Rob Austein <[email-masked]>
Date: Mon, 30 Jan 2017 23:23:23 -0500

At Tue, 17 Jan 2017 22:29:50 -0800, Terry Manderson wrote:
...
> 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
> 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).

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

---

From: Terry Manderson <[email-masked]>
Date: Wed, 1 Feb 2017 02:44:36 +0000

Hi Rob,

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

    

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.

    

    

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.

Right, which is the tango held in sidr-oob-setup-06 where both parties agree to the URI.

Thanks
Terry

---

From: Rob Austein <[email-masked]>
Date: Tue, 31 Jan 2017 23:23:06 -0500

At Wed, 1 Feb 2017 02:44:36 +0000, Terry Manderson wrote:
...
> The layering of XML, within CMS, within HTTP is certainly tedious.

Agreed, but...copied from RFC 6492, trying not to reinvent wheels.

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

Not that I recall.  Fairly high degree of code reuse from RFC 6492.

...
...
> Yes. Please cut the text from this Document.

(Will be) gone in -11.

Thanks!

---

From: Terry Manderson <[email-masked]>
Date: Wed, 1 Feb 2017 06:03:04 +0000

No, Thank you!

I will clear my DISCUSS when -11 is posted.

Cheers
Terry

On 1/02/2017, 2:23 PM, "iesg on behalf of Rob Austein" <[email-masked] on behalf of [email-masked]> wrote:

    

    ...
    ...
    
    (Will be) gone in -11.
    
    Thanks!