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

Christopher Morrow <christopher.morrow@gmail.com> Tue, 21 July 2020 21:50 UTC

Return-Path: <christopher.morrow@gmail.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 C789D3A0AC6; Tue, 21 Jul 2020 14:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 syhfHz0Sru6H; Tue, 21 Jul 2020 14:50:09 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2A03A0ACD; Tue, 21 Jul 2020 14:50:09 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id d27so351623qtg.4; Tue, 21 Jul 2020 14:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=z8z5Nn2TXELSm5yz3iqtan68HP+aGxF+3Iczn39nmgc=; b=nYFLW3lfBXd/FB9Lksd38HqmRedp72pe110d+uI5cposM7i9Q7K/uU4gGQBlq7EXPo 82NcL7YosqwfZhStK3rbNkmW7/Q6Yo6SPCyLGF4bB9Ew2JtT3NxwOPvFaPU6HMuGz8E9 q+t/dSbxmODlWFLUy6HoLm9B7iMbPYRa3BYOHVA8+2hiH6yiuGlKgOCl8wcdLnFK34Ye cpR6+EBkrupAiH9MXcTl2qedfodmdNRih3qoLq3xDeeRsR9c4xlpy3O9zBOr99drGaJg mhsyylRqVTovY1wpe5v/ehDaVn7Bku5QYJgXRv9nRWyCIByUVHeBtzJOO2Hyz9y8ZyPN Z+dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=z8z5Nn2TXELSm5yz3iqtan68HP+aGxF+3Iczn39nmgc=; b=gLMEITuJQUaAMhCSQAG41Gmkh6yJZf74BnufT1yA8vJxYtVVa/SUvdECi7TlCWx/t7 m8E/7IYQLK7CY39nFLTcTw7ExVhhOBfFOL1WnC4UZXB1tioO5OrX1mOTzc/Va4cRaL2T 63wZE2nSHUhyRhg0ONuzoqDru/3gLVemA90ND1rCPMPzJCprHa8MdpViWPJ9bHiPYhiX cQveiHR7Btlu00ohIBn9qmLZRy3TTEqqVlOTc086oL3iPcF0KSoFEatb+N9IKhkxnN/E BvTKAmp4ojlymrn/Kb5X4hU39QfkUS521IwFzsKVHeZ+AEg/r7df4ZqYTNiwzQ+HXbWY Wb8A==
X-Gm-Message-State: AOAM533vgnyGdW7ghWyWL6v2WjbrQaJgNXHh5BTRy5k2iEb9I+VwIgl9 kYJnKxJEgAMjN35XoIqwrW0suPr5nrtBhxr/B6ScDV4l
X-Google-Smtp-Source: ABdhPJzRqTiS60kaMeYnDy7G4c8f5FK3cGTV4cW/1hbnr3ULQpVO2jtHKsFbJqy+3RWEclaMk3r5tW7YW8vgbgPZnSU=
X-Received: by 2002:aed:2e07:: with SMTP id j7mr32135372qtd.338.1595368208035; Tue, 21 Jul 2020 14:50:08 -0700 (PDT)
MIME-Version: 1.0
References: <29748EA5-6016-4E6D-9261-A069F7431390@nlnetlabs.nl> <CAL9jLaZOzGFTMMkFOz5-7vi0oQuFPZjmsXRF_7j1hG4pbuL34g@mail.gmail.com> <1F13C3C6-5D00-4DBD-BD6B-D4690B6F2B33@nlnetlabs.nl>
In-Reply-To: <1F13C3C6-5D00-4DBD-BD6B-D4690B6F2B33@nlnetlabs.nl>
From: Christopher Morrow <christopher.morrow@gmail.com>
Date: Tue, 21 Jul 2020 21:49:57 +0000
Message-ID: <CAL9jLabYpSHttDe0_jgWnmQNNQe-SSK1Gs6PSvu8KLB=snaUgA@mail.gmail.com>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDROps Chairs <sidrops-chairs@ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1lLBUD_hJI9RK_CwU7q5tAuUYHw>
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 21:50:11 -0000

On Tue, Jul 21, 2020 at 10:51 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
>
> 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.

hopefully you had a good weekend! :)

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

I don't THINK so? :) but we can mention it in the chair slides section
and say: "If there's more than a quick question we can just re-read
the renamed draft and interim in ~3 more weeks" ?

> 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!
>

I think just a quick note and then interim if we need more deep discussion.
I'd like the main focus to be agreeing on the -bis text... then we can
stack the next set of contentious discussions :)

>
> 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
>