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

From: Nathalie Trenaman <[email-masked]>
Date: Mon, 4 May 2020 10:21:26 +0200

I support this.

Thanks,
Nathalie 

> Op 29 apr. 2020, om 15:18 heeft Tim Bruijnzeels <[email-masked]> het volgende geschreven:
> 
> 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

---

From: Oleg Muravskiy <[email-masked]>
Date: Mon, 4 May 2020 17:36:53 +0200

> I am also more than happy to discuss the content, and adapt following discussion, but maybe this is better done if adopted :)

Support

Oleg

---

From: Amreesh Phokeer <[email-masked]>
Date: Mon, 4 May 2020 21:12:36 +0400

I would like to see this adopted.

Thanks,
Amreesh

On Wed, Apr 29, 2020 at 5:19 PM Tim Bruijnzeels <[email-masked]> wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

-- 
Amreesh Phokeer

---

From: Melchior Aelmans <[email-masked]>
Date: Mon, 4 May 2020 22:37:31 +0200

I support adoption.

Cheers,
Melchior

On Mon, May 4, 2020 at 5:37 PM Oleg Muravskiy <[email-masked]> wrote:

> > I am also more than happy to discuss the content, and adapt following
> discussion, but maybe this is better done if adopted :)
>
> Support
>
>
> Oleg

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 5 May 2020 23:56:30 +0300

I support adoption while its naming may lead to confusion.
As discussed during the interim, the draft does not suggest depreciation of
rsync.

-- 
Best regards,
Alexander Azimov

---

From: Chriztoffer Hansen <[email-masked]>
Date: Wed, 6 May 2020 14:16:09 +0200

On Wed, 29 Apr 2020 at 15:18, Tim Bruijnzeels <[email-masked]> wrote:
> As mentioned yesterday I would like to ask the chairs to do a call for adoption on:

In favour :+1:

-- 
Chriztoffer

---

From: George Michaelson <[email-masked]>
Date: Thu, 7 May 2020 08:25:32 +1000

co-author, also +1 to adoption.

This work is necessary now, to define the process to move off rsync.
We only have a higher hill to climb, if we delay on this and let the
RP population grow.

This complements proposed work in RP timing, and it provides for a
secure channel to fetch repository contents which mitigates some of
the MITM risks inherent in rsync which is incapable of being secured.

-G

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 May 2020 18:13:30 -0700

i am sufficiently old school that i do not speak for adoption or wglc of
a draft on which i am co-author.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 May 2020 10:31:45 +0200

Hi,

> On 5 May 2020, at 22:56, Alexander Azimov <[email-masked]> wrote:
> 
> 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