Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 21 April 2020 09:11 UTC

Return-Path: <tim@nlnetlabs.nl>
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 39EFE3A09C4 for <sidrops@ietfa.amsl.com>; Tue, 21 Apr 2020 02:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 6ryl7ewMeV96 for <sidrops@ietfa.amsl.com>; Tue, 21 Apr 2020 02:11:11 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 CE02A3A09C2 for <sidrops@ietf.org>; Tue, 21 Apr 2020 02:11:10 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a] (unknown [IPv6:2001:981:4b52:1:10c1:16a5:febc:ba2a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id F3DEF148CC; Tue, 21 Apr 2020 11:11:08 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1587460269; bh=PX2N0mdHIp7VmDDTX4nJEBWeehCaSg1w7CvyQewn4kU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fDGgIFnklFGA/WwOu1CndBIS6v+K5VLXGk9trWS6BFB1Y0sg87lYlbEOdzR7kGrRd lEkr4spa1p04gSLpaKkL2yhWo9oV7I1MMJF/U0nmzHyVfWQ876iloS2k6RrHaw2aaP EZONivDvVZ0v7ELjqUWJ+i+jYbx7GiYeqdJGTwug=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m2ftcxinxc.wl-randy@psg.com>
Date: Tue, 21 Apr 2020 11:11:08 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CAC15E54-012F-4178-AF07-830C0E6B5F10@nlnetlabs.nl>
References: <m2tv1ehtso.wl-randy@psg.com> <CAKr6gn33r32WS=cwgTY8GMmx9xH6Nu2aTdgjYsu01SYf51C7ow@mail.gmail.com> <CAKr6gn3pj5qT8ZA7f0j8gwkP6PESh-eJ8xku1AwVGKL9izbcYg@mail.gmail.com> <m2ftcxinxc.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/zv1BPD8pPmLgXzSpabhLupzp0FI>
Subject: Re: [Sidrops] draft-sidrops-bruijnzeels-deprecate-rsync
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: Tue, 21 Apr 2020 09:11:15 -0000

Hi,

> On 21 Apr 2020, at 04:15, Randy Bush <randy@psg.com> wrote:
> 
> look, no one likes rcynic.  but it has carried us for a decade now, so i
> treat it with respect.  it will take us another decade to completely get
> rid of it.  remember, it took me eight years to get a constant changed
> from 4k to 16k (RFC 8654).  one of the things the pandemic should be
> teaching us is patience.

For sure. And for the record: I am a big fan of rsync in other contexts. Also it was a useful start. Still, I want to move on for reasons I won't repeat here unless pushed :)

> 
> we are stewards of the internet.  we do not intentionally break it.  we
> do that enough accidentally.  luckily, we can turn preventing the latter
> into a career :).
> 
> so let us figure out the safe path to move forward, document it, and
> start moving down it.  but the goal is some time away.  and likely, by
> the time it is close, we will be discussing how to get rid of RRDP.

Fully agree.

At the moment the document is still very open about time lines and what can happen first. This was done this way because at the time it was not clear to me whether we could get CA (and Repository Server) operators to implement RRDP soon 'enough', and I did not want this to be a reason for RP implementers not to start supporting RRDP.

As it stands today I believe that Lacnic is the only major repository which does not support RRDP yet, and everyone else either supports or is running software which is capable. I don't believe that Lacnic is opposed, but I believe we should also be reasonable in our expectations especially given the pandemic that makes life hard across the globe.

So, in short I am quite open to a more clear plan where we ask all repositories to support first, then ask / demand RPs to prefer RRDP, and eventually - after measurements - make rsync optional and/or deprecate it completely.

I will reply to you (Randy) in person to see if we can revise the draft in time for Monday's meeting.

Tim


> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops