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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
