...
I can appreciate that this document represents some long standing
thought and effort. However, the fact that I believe there is a
flaw does not seem to need the support of an alternate design,
right? I'm pointing out an operational misalignment in _this_
design. I think to offer an alternative at the same time as we are
discussing a shortcoming here would be an inappropriate conflation
(i.e. I think that would confuse this issue with another).
The authors do not agree that the global coordination requirement is a flaw.
So, more specifically: I think that trying to mandate global
coordination at this scale is an operational non-starter. Why can't
the design be made to accommodate different choices of algorithms
and different operational schedules? I think this is actually a
requirement: that operational entities be able to choose their own
schedules and make their own configuration choices.
If there is not a schedule when old algs die and new ones MUST be
supported, then one at least doubles the size of the repository
system, and imposes a burden on all CAs and RPs to support old algs
forever.
> 2- Not exactly. The milestones, as well as the alg suite spec,
will appear in a revised version of draft-ietf-sidr-rpki-algs. Any
operational problem that requires a delay in any transition phase
would be brought to the attention of the IESG (if the SIDR WG is no
longer active) requesting that a this RFC be re-issued, with new
milestone values for the affected phase(s).
I'm sorry, but I really think this is likely to have trouble in a
real operational setting. I don't think anyone would claim that the
IETF's processes operate at the same pace as operations. For
instance, if there is an emergency at the last minute of this roll,
can the working group be expected to mint a new RFC and disseminate
in short order (say, days)? There is a vey fundamental misalignment
here: creating standards and managing operations are very loosely
coupled. I think this is a very inappropriate place to try to
enforce operational schedules.
I think you overstate the problem. The intervals for each phase are
not expected to be short, and there are phases that accommodate both
old and new als in a fashion that allows considerable CA and RP
flexibility.
Nonetheless, I think Terry's suggestion has merit. I can imagine
having the milestone RFC be coordinated through the NRO and IANA, and
published by the IETF, to help ensure that there is appropriate ISP
input to the milestone
development.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
