IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 13 May 2020 08:31 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 03A783A0FB9; Wed, 13 May 2020 01:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J874iRegrQiy; Wed, 13 May 2020 01:31:48 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0: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 88A593A0FB3; Wed, 13 May 2020 01:31:48 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589] (unknown [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 613E535738; Wed, 13 May 2020 10:31:46 +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=1589358706; bh=UlluyH+wFzqKad52Gxcs4L4MMptAxxiSFmjxvxGP5ZI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=yXNm/PMR4WYt6BjYrJSKzPrBLM3U8i1MXMDA5SiMBETRFGeGocxpL1OfAFXOCexXa cw7y3adxocrvNWKiOUGJ4/wVI7LjYNnFG3RN650m043WIatYOhQ2vjNrd0R5p/hABr cSC8/VvDK+cKHk/gh+bAosO/jyRf5yka59r3e4uY=
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: <CAEGSd=B1J6e_RbWACfSWhJ8ct5gMnFpyq9+w2LHJ2=kVxt6Xiw@mail.gmail.com>
Date: Wed, 13 May 2020 10:31:45 +0200
Cc: Melchior Aelmans <melchior@aelmans.eu>, Oleg Muravskiy <oleg@ripe.net>, SIDROps Chairs <sidrops-chairs@ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DF82E8B-5A6A-4522-8C6C-066CF6B16E4E@nlnetlabs.nl>
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> <7CF309AA-0B5F-4FE8-80E8-5E041CA21CF1@ripe.net> <CALxNLBi6X+aC+R7fQ-xyxM0HkzBjOLwEHQF4+Oeo5FWKA+NuPA@mail.gmail.com> <CAEGSd=B1J6e_RbWACfSWhJ8ct5gMnFpyq9+w2LHJ2=kVxt6Xiw@mail.gmail.com>
To: Alexander Azimov <a.e.azimov@gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/nDtNgo6utdCBK5qQJqba_i_x4AI>
Subject: Re: [Sidrops] Adopt 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: Wed, 13 May 2020 08:31:50 -0000

Hi,

> On 5 May 2020, at 22:56, Alexander Azimov <a.e.azimov@gmail.com> wrote:
> 
> I support adoption while its naming may lead to confusion. 
> As discussed during the interim, the draft does not suggest depreciation of rsync.

I think it does. But maybe the text or the presentation I did (or both) were not clear.

It currently says that rsync URIs will remain in use, because we need names. Replacing these URIs with something else that does not suggest rysnc - e.g. URNs (RFC8141) to be transport agnostic, or even https - would introduce a breaking change that will require *all* RP software to change first before any CA can start to include these alternate URI/Ns. This will make the whole thing much harder, and I am not convinced yet that that is worth is. Hence the XML NS analogy. You will see rsync URIs but they are really just name and scope (for the directories) without a guarantee that something is available.

Other than that it says that eventually the rsync repository MAY still be available. It's not a SHOULD, not even a RECOMMENDED. It simply does not forbid it and it mentions that there may still be uses for this outside of the operational validation context. In the context of RPKI validation it says clearly that it MUST NOT be depended on. However, if people here want to bury the rsync repo completely for other purposes as well then I am perfectly fine with changing that.

Tim

v2.23.0 | Report a Bug | By Email