First, many thanks to the editors of the architecture document. For
as dense as it is, it's readable.
There are a couple of "gotta-fix" nits, as well as a broader concern
that lead me to say "not yet" to this doc.
The fix-it items:
Section 4.3 (access protocols): the rsync item, as noted by others.
4.3 also uses 2119 language to specify requirements for (current and
future) access protocols. I'm not convinced that language is
appropriate for these requirements.
5 (Manifests) allows an EE cert to sign multiple manifests. That
seems inconsistent with section 2.3 re: one-to-one correspondence.
The broader concern:
I continue to lack confidence that our validation algorithm is
complete, particularly when we look at incremental deployment. That
leads me to wonder whether changes to the validation model will lead
us to changes in the data. There's a reason the architecture doc has
normative references to so many other active sidr docs, including ones
that aren't yet to the point of WGLC, and I'm uneasy about pushing
this doc out until I'm more confident about the validation model.
This doc doesn't talk in depth about incremental deployment. Instead,
it uses 2119 MUSTs to describe a full-deployment world (e.g., in
7.2.3, "A holder of a portable IP address space allocation MUST
authorize one or more ASes to originate routes to these prefixes.")
I'd prefer to see this doc acknowledge the existence of partial
deployment and explain how it will work. (Will it? If so, how?) For
example: the document never clearly states what (if anything) signals
that the set of ROAs for a given address block is complete. Maybe we
need to say "we're not yet defining a signal for 'this is the complete
set of ROAs'; that's be in a different doc", but it's a glaring
omission.
This document also asks IANA to issue RPKI certs. I'm leery of asking
them to do that when I still have doubts about the completeness of the
architecture. Should we be pushing out the doc calling on IANA to
deploy when the other bits aren't done yet?
And the little stuff:
3.2 "There is no independent method of invoking a ROA."
s/invoking/revoking/, perhaps?
Section 7.1: "However, if the certificates for these allocations
contain different validity intervals, creating a certificate that
combines them might create problems, and thus is NOT RECOMMENDED."
Doesn't this problem arise when the underlying validity (e.g. the
validity of the assignment/allocation/etc.) intervals vary, rather
than the cert validity intervals? Perhaps this could be clearer.
7.2 "Furthermore, a relying party must fetch new ROAs from the
repository system before taking any routing action in response to a
ROA revocation." Is this reflected in the validation drafts? It
should be likely be repeated in section 3 or 4 of the ROA format doc.
-- Sam
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
