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