Re: [tsvwg] [saag] [Int-area] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

+1

I think it is a good draft, out of very hard work, a lot of sweat.

Behcet

On Wed, Jul 1, 2020 at 10:10 AM Joseph Touch <touch@strayalpha.com> wrote:

> -1
>
> Although it’s understandable to describe “what operators do”, the IETF
> isn’t a news service. We typically summarize these behaviors to take a
> position on them.
>
> The draft provides a good description of the tradeoff between the privacy
> rights of endpoints and the rights of operators and the impact of both on
> protocol design on that tradeoff.
>
> What I seem to be seeing is increasing “rough consensus” that the summary
> position should be closer to endpoint privacy than in the current form.
>
> Although I don’t feel strongly that the text absolutely needs revision in
> that direction, I would oppose changes to relax or shift in the other
> direct.
>
> Joe
>
> On Jul 1, 2020, at 7:11 AM, Dirk.von-Hugo@telekom.de wrote:
>
> +1
> Thanks, Kyle!
> Kind regards
> Dirk
>
> *From:* Int-area <int-area-bounces@ietf.org> *On Behalf Of *Kyle Rose
> *Sent:* Mittwoch, 1. Juli 2020 15:57
> *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> *Cc:* int-area <int-area@ietf.org>; tsvwg@ietf.org; IETF SAAG <
> saag@ietf.org>
> *Subject:* Re: [Int-area] [saag] 3rd WGLC (limited-scope):
> draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
>
> On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
>
> I noticed this in various IETF discussions and so I will describe it in
> the abstract.
>
> A group of people propose an idea. Those who do not like the idea are then
> asked to convince the original contributors that their idea is not sound or
> contribute text so make it look nicer.
> Not only is this requiring me to spend my time on something I don’t agree
> with but it turns out that no discussions will change the mind of the
> original contributors. They just strongly believe in their ideas. They will
> keep proposing the same idea over and over again (for years) till it gets
> published as an RFC..
>
>
> I don't understand why so many are opposed to publishing a document that
> merely describes how operators manage protocols in the absence of header
> encryption, and how header encryption interferes with those practices. That
> is, at least, in its original form, before this WG decided it needed to
> incorporate pro-encryption advocacy, greatly complicating the document and
> the resulting analysis.
>
> For the OG version, I ask myself the following questions:
>
> Does the document describe reality? Yes: it tells us what practices
> operators employ today.
> Is the document useful? Yes: see above, plus it makes clear that there
> will be an impact to operators and/or protocol users from this evolution.
> Does the document establish an IETF position on encryption? No. There are
> plenty of other published RFCs that embody the spirit "encrypt all the
> things". This document does not change that.
> Does the document make normative statements about future protocol
> development? No.
>
> On what basis would I therefore oppose publication?
>
> I may or may not have opinions about prioritization of user privacy over
> manageability, the tussle between manageability and deployability, and what
> alternatives are available to operators for managing protocols with
> encrypted headers. I would be happy to help express those in a follow-on
> document. But this document describing where those conflicts lie is a
> *prerequisite* to developing those alternatives. And frankly those opinions
> are irrelevant to the intended content of *this* document.
>
> Kyle
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>