Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt

Randy Bush <randy@psg.com> Wed, 22 April 2020 12:29 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F473A0B1B for <sidrops@ietfa.amsl.com>; Wed, 22 Apr 2020 05:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ElzNmgYSLnq for <sidrops@ietfa.amsl.com>; Wed, 22 Apr 2020 05:29:01 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242243A0B17 for <sidrops@ietf.org>; Wed, 22 Apr 2020 05:29:01 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1jREUt-0007Hp-Hm; Wed, 22 Apr 2020 12:28:59 +0000
Date: Wed, 22 Apr 2020 05:28:59 -0700
Message-ID: <m2h7xbg0vo.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <98A4118B-83F0-4BBD-BA22-794ADA475731@nlnetlabs.nl>
References: <m2k128harb.wl-randy@psg.com> <98A4118B-83F0-4BBD-BA22-794ADA475731@nlnetlabs.nl>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/wdpU66Fj_eQ9oumy0P_S5iC68lI>
Subject: Re: [Sidrops] draft-ymbk-rpki-rov-timing-00.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2020 12:29:02 -0000

mornin' tim,

thanks for review!

> s/rcynic/rsync/g

massimiliano already beat me up on that this morning.  he had done a PR,
i merged it, and then let spell check revert it <blush>.

> Furthermore, I think the document could use some words on the chain
> before the CA. i.e. timing of creation of ROAs in the CA w.r.t.
> changes in announcements done.

i am not understanding.  do you mean possible CA to publication point
delay?

> I would say that for planned changes ROAs should be created in
> advance

yes.  this was discussed many time in the design team.  the ddos defense
folk essentially said that most of the 'customers' come running in the
door in panic and had never thought to do advanced planning.  while i
have some sympathy for that, i am not sure what we can say here other
than
  o try to constrain the propagation time
  o point out that roa creation in advance of operational changes, be it
    circuit moves, ddos sinking, ... should be done sufficiently in
    advance.

i'll try to do more.

> As a side note. We are discussing moving from rsync to RRDP in another
> thread. I believe that RRDP will help reduce propagation times.

i tried to say that.  will look again.

> I have no doubt that further improvements can be conceived in future.
> It helps to have guidance for maximum propagation times to serve as
> guidance for requirements there.

i am not understanding.  maybe some coffee will help.

thanks again.

randy