Subject: [Sidrops] agenda

From: Randy Bush <[email-masked]>
Date: Sat, 18 Apr 2020 12:26:42 -0700

while the agenda for monday's meeting is a sweet tribute to biff:

    Agenda - Interim 04/2020

    1) CRL ? Manifest ? Hashbrowns? - guidance for chefs
    2) other ongoing work
    3) punch and pie

perhaps we have more to discuss.  i would like to solicit help to work
on the timing mess, which is already causing problems.

	From: Randy Bush <[email-masked]>
	Subject: Re: [Sidrops] rpki rp frequency
	To: Jared Mauch <[email-masked]>
	Cc: SIDR Operations WG <[email-masked]>, Di Ma <[email-masked]>
	Date: Mon, 13 Apr 2020 10:30:55 -0700

	>>>>> As often as necessary that the RP can synchronize with a repository.
	>>>> how often is 'necessary?'  in units of time, please.
	>>> I think It is the ISP who defines what is necessary.
	>> what is reasonable for the good of routing in the internet?  i suggest
	>> an hour.
	>> before notify, we tolerated dns propagation of a day, and it was very
	>> painful.  that seems primitive and silly now.
	> Most of the IRRs are mirroring at an interval of 5 minutes or so these
	> days, or that was one of the last things I asked to be changed at 2914
	> before I left to ensure regular sync.
	> I think 300s is reasonable, but 3600 (60 min) is likely the high limit.

	there are the questions of how frequently a CA publishes, how often an
	RP pulls, and how often routers pull from their RP(s).

	for CA publishing, a few seconds seems easily achieved with reasonable
	software.

	for RPs pulling, 600s may be optimistic in the short term given
	  o the load it will put on publication services
	  o and one notorious repo which is against spec
	but it should be achievable in a while.  an hour would be the longest
	acceptable in my mind today.

	for the router(s) pulling from the RP(s), 300-3600s is a wide window.
	but remember, the rpki-rtr protocol does have the equivalent of dns
	notify, where the cache tells the router that it has some nice tasty
	new data.  you're welcome :)

	i imagine that few here are old enough to remember when curtis only
	updated the backbone (there was only one) routing peering once a week
	on wednesday.

	if we want the internet to rely on this stuff, it's time to get into the
	21st century.

	randy

randy

---

From: Nathalie Trenaman <[email-masked]>
Date: Mon, 20 Apr 2020 09:51:56 +0200

Hi Randy,

Thanks for offering. We’ll add that to the agenda. Shall I add it as 'RPKI refresh timers” or do you have another suggestion? Oh, and do please send slides ;)

Nathalie

> Op 18 apr. 2020, om 21:26 heeft Randy Bush <[email-masked]> het volgende geschreven:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Apr 2020 03:10:21 -0700

mornin' nathalie,

> Thanks for offering. We’ll add that to the agenda. Shall I add it as
> 'RPKI refresh timers” or do you have another suggestion? Oh, and do
> please send slides ;)

there will be a draft, maybe in two days.  in the meantime, you can find
it at

    draft-ymbk-rpki-rov-timing
    Timing Parameters in the RPKI-based Route Origin Validation Supply
    Chain
    https://github.com/randyqx/rpki-rov-timing
    
waiting to see if co-author(s) actually author :)

after the meeting, will likely ask for WG adoption.

---

also for the agenda,

    https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/
    The Resource Public Key Infrastructure (RPKI) to Router Protocol
    Version 2

which i would hope to WGLC after discussion.  it would be good if folk
reviewed it before alvaro does for IETF LC :)

---

will have slides for you, but getting draft-ymbk-sidrops-rpki-rov-timing
in good shape comes first.

randy