Re: [sidr] I-D Action: draft-ietf-sidr-publication-09.txt

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 <sra@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