Sean,
Thanks for the review.
Below are some comments on the draft. I also submitted my nits to the
editors.
0) Based on the assumption that draft-newton-sidr-policy-qualifiers
will be adopted because that's what the RIRs want should s1.2 or 1.5
also include some information about where it can be found? This
information would be identical to the URI included in the policy
qualifier?
1) s1.6: CP - Is it worth nothing that there might be another CP for
the BPKI?
I added the following ext:
If a BPKI is employed by a CA, it may have its own CP, separate from the
RPKI CP.
2) s4.6.1: Not sure if this needs to go here but don't we need to say
something about not renewing certificates forever?
I am reluctant to point out one example of a bad PKI practice, when
there are so many more ...
3) draft-ietf-sidr-rtr-keying describes the procedures for operator
generated keys (i.e., those that are not router generated). A couple
of questions come to mind:
a) Should the CPS point to that draft in s6.1.2 or will the CPS be
updated when draft-ietf-sidr-rtr-keying is published?
We could update the CPS with a pointer to rtr-keying when it is
published. It would be a very minor update,
as an informational reference. If the chairs prefer, we can add a
reference to the I-D, and have this doc held
in the RFC Editor's queue waiting for that doc to be approved.
b) draft-ietf-sidr-rtr-keying allows operators sign the private keys
they generate and subsequently send back to the router. Should this be
explicitly called out in s4.5.1. For s.4.5.2, is the returned
signed-key an RPKI-Signed Object?
The first comment does not seem to apply to 4.5.1/2. Could you clarify?
The returned signed-key is not an RPKI signed object, as defined in RFC
6488. Such objects are stored in the
repository system, not just passed between a local operator's system and
a router.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
