[TLS] Editorial process

[Eric Rescorla <[e-mail]>]

[Starting a new thread to change topics]

On Tue, Nov 25, 2014 at 2:19 PM, Watson Ladd <[e-mail]> wrote
>
> ... The current proposal has two distinct client auth mechanisms, one in
> the handshake and the other in update.
>
> Making sure the actual proposal is in the draft, and not spread out across
> pull requests would make life a lot easier for analyzing the protocol.
>
A few notes on the process here from my perspective:

The way I think about this is that there is a current proposal which is
what's
in Github and then people (whether me or someone else) suggest changes.
These changes go in Pull Requests so that the WG can see what exactly
is being proposed and then if the WG is happy, those PRs get merged
into the main document. Obviously, no process is perfect, but my experience
and my read of the experience with HTTP is that this is better than the
alternatives, which mostly involve big document revisions and then
comments on the whole document [0].

With regard to the specific question of client auth, the state is as
follows:
The existing document (i.e., the I-D and the version in git master) contains
a single client auth mechanism in the handshake. We have a proposal to
remove that and instead have client auth in an Update [1]. The intention is
that
we would only have one client authentication mechanism.

FWIW, I recognize that there are a lot of PRs outstanding right now and it
can be confusing. I plan on merging a number of them in over the next week
or two.

Best,
-Ekr


[0] Note that it's easy to get git/github to give you the state of the
document
as a whole after a PR is merged.

[1] The PR in question doesn't do that, but that's because I was asked to
do an initial treatment to see if people liked it and s I tried to do the
minimum
to accomplish that.