Re: [Sidrops] nlnet rp and rsync

Martin Hoffmann <> Tue, 12 May 2020 09:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E11E33A0D37 for <>; Tue, 12 May 2020 02:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 33l6IVL64eBr for <>; Tue, 12 May 2020 02:45:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 132353A0D31 for <>; Tue, 12 May 2020 02:45:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id D138D33EFF; Tue, 12 May 2020 11:45:22 +0200 (CEST)
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=none
Date: Tue, 12 May 2020 11:45:21 +0200
From: Martin Hoffmann <>
To: Russ Housley <>
Cc: SIDR Operations WG <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] nlnet rp and rsync
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2020 09:45:28 -0000

Russ Housley wrote:
> A client can use any of the protocols that it wants, but it seems
> like unnecessary fragility to pick an alternate and then refuse to
> consider rsync.  This seem counter to a graceful transition,
> especially if there is a transition from RRDP to RRDP2 in the distant
> future.

The decision to not fall back to rsync if RRDP succeeded once was
actually made with publication point operators in mind. With most
relying party software now supporting RRDP and preferring it over
rsync, an operator will see most traffic via RRDP and only very small
amounts on rsync. Given that unlike with HTTP where lots of tooling and
services for reliable, scalable operation exist, you are basically on
your own with rsync, they are likely to only provide a minimum service.
Now, if the RRDP service becomes unavailable for whatever reason, all
relying parties hitting the rsync service is not going to end well.

Since the absolute majority of these RRDP failures are of a transient
nature and will be resolved by the next validation run, just skipping
the publication point this time seems a reasonable choice. This could
probably be improved by remember how many times it failed and switching
back to rsync after, say, five failures, but I am not sure this is
worth the effort.

As an aside, switching between rsync and RRDP isn’t free. Because an
RRDP server can essentially publish objects for any rsync URI it wants,
you have to keep separate trees for rsync and each and every RRDP
server. So falling back to rsync actually means either downloading the
full copy or updating a severely outdated copy. It’s not that big a
deal in the grand scheme of things but worth noting.

Kind regards,