This is a service protocol for people who are in a relationship about RPKI objects, and want to commission and operate publication through the parent who signs over them, and their products. The bPKI is not RPKI, its discrete, and separate. So the intrusion of this protocol into SIDR is about its consequence, not it, as a protocol itself. It could be in a PKIX class generic WG. Meh. It doesn't matter, its here, and we can move it.
It feels to me like its good-enough: it protects the payload, it identifies each side, it is transactional (all-or-nothing) so the partial failure consequences simply don't arise in a bulk operation: either get it all right, or nothing changes. Managing a bPKI is a nightmare all in itself. I like that this discretely side-steps the question, because its really not material: If you trust each other anyway because of outside process to use certs, then this protocol lets a server-client pair talk and get a job done. Don't big the role up. Focus. This document is focussed and brief. That works. Ship it. PS my sense of 'why have repositories' is orthogonal to this question. Given they exist, they need to be managed, and thats a service function which should operate in an open specification. I will be recommending operational people in APNIC to consider this for implementation, if there is a driver for (re)publication through APNIC to reduce repository count overall. G On Thu, Sep 22, 2016 at 8:40 AM, Rob Austein <s...@hactrn.net> wrote: > Updated per request from WG chairs. No changes to protocol syntax or > semantics since version that went through WGLC. > > Other than refreshing the I-D (the old one-D was about to expire), the > only change was a minor tweak to the RelaxNG schema, to better enforce > syntactic constraints already present in the normative text. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
