+1 Thanks, Kyle! Kind regards Dirk From: Int-area <[email protected]> On Behalf Of Kyle Rose Sent: Mittwoch, 1. Juli 2020 15:57 To: Hannes Tschofenig <[email protected]> Cc: int-area <[email protected]>; [email protected]; IETF SAAG <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
