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:17:15 -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:
----------------------------------------------------------------------

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.