+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 <[email protected]> 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, [email protected] wrote: > > +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]> 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 > > > _______________________________________________ > saag mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/saag >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
