- This decision was made specifically to avoid arguments about the merits of documents that the WG wasn't interested in.
The point I was trying to make was that there is an opportunity to change a decision on
“is the working group interested in X”
To
“is it necessary to work on X to insure independent, interoperable implementations”
As “interest” is somewhat personal and difficult to judge “rough consensus” because everyone in the working group doesn’t have to be interested for the work to proceed.
Some would assert that it’s bad to define extensibility mechanisms that limit their availability
https://tools.ietf.org/html/draft-nottingham-thanks-larry-00
From: Eric Rescorla <ekr@xxxxxxxx>
Sent: Wednesday, March 11, 2020 3:52 PM
To: Larry Masinter <LMM@xxxxxxx>
Cc: Nico Williams <nico@xxxxxxxxxxxxxxxx>; Paul Wouters <paul@xxxxxxxxx>; IETF <ietf@xxxxxxxx>; Pete Resnick <resnick@xxxxxxxxxxxx>
Subject: Re: Dispute process (Was: Resignation request)
On Wed, Mar 11, 2020 at 3:50 PM Larry Masinter <LMM@xxxxxxx> wrote:
Nico wrote
Then take this to the limit. Suppose we did some number TLS extensions
this way, with several overlapping somewhat, but in ways the authors did
not care to unify. What would happen?
-Ekr wrote:
> Well, we're running this experiment now, and have been ever since late 2018, so I guess we'll find out. So far it does not seem to have been an issue.
The “running code” part of “ rough consensus” seems useful in resolving disputes about a working group dropping or disagreeing to some work.
Perhaps.
However, what we found is that we were spending quite a bit of time evaluating documents when what the authors really wanted was a code point. This change has reduced the need for that.
-Ekr
