Randy,
> the point of the history lesson of the rirs blocking the definition and
> documentation of transfer is that it seems to be the only serious reason
> for the change those very same rirs are proposing. so, if you want your
> proposal to change rfced running code to be taken seriously, you had
> best document it technically, not just throw perjoratives and hyperbole.
Transfer for APNIC is defined and documented:
http://www.apnic.net/policy/transfer-policy
… which you are no doubt familiar with, having contributed actively to its
development. The point is resource transfer is documented as a number registry
policy process, not as a technical process. Of course, the RPKI very
conveniently requires that CA certification actions follow registry actions, so
when one uses an RIR's policy for transfer to enact a transfer, certificates
are updated without any extra technical process needed.
The RPKI, as Sandy has indirectly suggested, is a view of the resource
allocation hierarchy. Defining technical processes for changing the contents
of the RPKI does not make sense, as the RPKI does not change, the resource
allocation hierarchy does.
If 'make before break' semantics are important when a certificate is revoked
and reissued following a registry action, the WG could certainly produce
something there - perhaps 4.5.9 of the CPS draft is a possible place to do
this? As a bonus, addressing the consequences of "partial revocation" (RFC6484
4.9.1 requires revoke+reissue to remove some INRs from a certificate, which is
a hack around the all-or-nothing nature of 3779 validation) also deals with
returns, exchanges, and plain old human or software error.
Assuming, of course, that transient certificate errors are a problem that we
should avoid :-)
--
bje, speaking as an individual
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
