Re: [sidr] sidr-arch-09 refresh cycle time

To: sidr <sidr at ietf.org>
Subject: Re: [sidr] sidr-arch-09 refresh cycle time
From: Randy Bush <randy at psg.com>
Date: Thu, 29 Oct 2009 08:32:23 +0900
Delivered-to: sidr at core3.amsl.com
In-reply-to: <4AE854D9.8040103 at ripe.net>
List-archive: <http://www.ietf.org/mail-archive/web/sidr>
List-help: <mailto:sidr-request@ietf.org?subject=help>
List-id: Secure Interdomain Routing <sidr.ietf.org>
List-post: <mailto:sidr@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
References: <4AE6160D.8000503 at bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E at apnic.net> <4AE75809.4050808 at bbn.com> <4AE854D9.8040103 at ripe.net>
User-agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)

folk going down this rathole might consider two things

  rpki-rtr suggests that the number of global fetchers will be radically
  lest than the number of global asns

  there might be ca chain depth of 3-6 for which a 24 hour cycle would
  mean a three day delay, making operators remember curtis unfondly

randy

Follow-Ups:
- Re: [sidr] sidr-arch-09 refresh cycle time
  - From: Robert Kisteleki
- Re: [sidr] sidr-arch-09 refresh cycle time
  - From: George Michaelson

References:
- [sidr] Updates: sidr-arch-09 and roa-format-06
  - From: Matt Lepinski
- [sidr] sidr-arch-09 refresh cycle time
  - From: Geoff Huston
- Re: [sidr] sidr-arch-09 refresh cycle time
  - From: Matt Lepinski
- Re: [sidr] sidr-arch-09 refresh cycle time
  - From: Robert Kisteleki

Prev by Date: Re: [sidr] Request for WGLC
Next by Date: Re: [sidr] sidr-arch-09 refresh cycle time
Previous by thread: Re: [sidr] sidr-arch-09 refresh cycle time
Next by thread: Re: [sidr] sidr-arch-09 refresh cycle time
Index(es):
- Date
- Thread

Re: [sidr] sidr-arch-09 refresh cycle time

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.