Brian,
As I mentioned in my rely to Eric, I think this is a topic to be
addressed in an RPKI
operational considerations doc. We have draft-ietf-sidr-origin-ops-19 in
progress now,
so I suggest you discuss this with the author of that doc. Nonetheless,
I'll offer my
views on a few of the topics you mentioned:
...
What model for the processes of maintaining sync between INR and RPKI
should be followed? A high-level finite state machine (FSM) model
should be an eventual goal, so that implementors have a crystal clear
model to follow.
I rarely see FSMs in RFCs these days, although I agree that they are
valuable in many contexts. Do
we have an FSM for IRR data use by RPs?
At any point in time, what states should any particular element be
able to be in?
How should an RP interpret each of those states?
How can an RP identify the timeline it needs to follow, if it wants to
be as current as possible, with as little overhead and work required?
Clearly once-per-second polling won't scale.
As I mentioned at the SIDR interim, each manifest contains a next issue
date/time, which is a
way for the CA to tell RPs when the RPs should expect to see new objects
published. An RP could use
that value as an indication of when to check the pub point for the CA in
question (vs. using some
fixed, periodic checking interval for all CAs).
Is there any corresponding place in the RPKI that would allow an
Originator to identify expected latency between ROA issuance, and the
update towards a given RP which would guarantee that the RP will
accept an announcement (in BGPSEC)?
I don't think that the term "guarantee" is applicable here, given the
vagaries of communication :-) .
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
