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

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 21 July 2020 10:51 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 DC31B3A0A52; Tue, 21 Jul 2020 03:51:59 -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 1CPnmayS8XsS; Tue, 21 Jul 2020 03:51:58 -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 3FAD33A0A36; Tue, 21 Jul 2020 03:51:58 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:acdd:989a:43ea:32cc] (unknown [IPv6:2001:981:4b52:1:acdd:989a:43ea:32cc]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 53A932F45B; Tue, 21 Jul 2020 12:51:56 +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=1595328716; bh=uPZWd/Y31il+tn9NTirVApS5RWTLaGrI2OLXtx/0T/o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=sMngND7PnusglP4Sk+4MqGcmps2uq1lpfOuBgvoAsZN45SbSDDh6dQEELOkuha96f Jyu0ajn0LkTG88J5pi0CGULfuPzDdA8z0lMUs5afLKlZw8eiTWOL11tYPTHgg5Kts1 sovbe2TzUWpZeWWTAcCFFFjptjy2f2QUTRYjM7xA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <CAL9jLaZOzGFTMMkFOz5-7vi0oQuFPZjmsXRF_7j1hG4pbuL34g@mail.gmail.com>
Date: Tue, 21 Jul 2020 12:51:55 +0200
Cc: SIDROps Chairs <sidrops-chairs@ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F13C3C6-5D00-4DBD-BD6B-D4690B6F2B33@nlnetlabs.nl>
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> <CAL9jLaZOzGFTMMkFOz5-7vi0oQuFPZjmsXRF_7j1hG4pbuL34g@mail.gmail.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tWh_Nad3OQBYUrEhmwxQRmvxekA>
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: Tue, 21 Jul 2020 10:52:00 -0000

Hi Chris, WG,

I was away for the weekend and I missed the I-D cutoff. I have the renamed version ready, and will submit after 2020-07-25 23:59 UTC.

Do we need to discuss this again on during the meeting on Monday?

The issues that I think could be most controversial are:

1) rsync URIs as object identifiers (section 4)

In summary: the document proposes that we keep rsync URI as useful object identifiers even if the objects cannot be retrieved at that location. The main reason for this is pragmatism: introducing a new kind of object identifier (e.g. URN based) would introduce a breaking change and make deployment much, much harder.

2) rsync still allowed

Currently the document says (tries to say) that if operators want, they can still leave an rsync server running. While they are not required to do so, it is not forbidden either.

3) rsync URIs in RRDP - can they be trusted?

Finally, we recently had a discussion related to manifests (6484-bis) and a concern was raised that the rsync URIs in the RRDP XML cannot be trusted. I took this to the list on 25 June (subject RRDP and rsync URIs).

Essentially I argued that while any RRDP server can include any rsync URI in the <publish> and <withdraw> elements in its XML, this is not really an issue because relying parties know both the rsync URI *and* the RRDP server when validating - so they can look for the rsync URI at the relevant RRDP server only.

If desired I can include some words on this in a -01 version, after the -00 (rename only) has been submitted.


Please let me know if any of you feel that this should be discussed again during the WG session!


Tim


> On 16 Jul 2020, at 19:24, Christopher Morrow <christopher.morrow@gmail.com> wrote:
> 
> Howdy!
> It looks like this got a bunch of support, so could the authors please
> kick out a renamed draft and let's see to the next stage? :)
> 
> thanks!
> -chris
> co-chair 1 of 3
> 
> On Wed, Apr 29, 2020 at 9:19 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
>> 
>> Dear co-chairs, WG,
>> 
>> As mentioned yesterday I would like ask the chairs to do a call for adoption on:
>> https://datatracker.ietf.org/doc/draft-sidrops-bruijnzeels-deprecate-rsync/
>> 
>> I am also more than happy to discuss the content, and adapt following discussion, but maybe this is better done if adopted :)
>> 
>> Thanks
>> Tim
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops