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

[Kyle Rose <[e-mail]>]

On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <[e-mail]>
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