Re: Spin bit discussion - where we're at

["Eggert, Lars" <[e-mail]>]

Hi,

Mark is asleep (I hope), so below is my personal view.

On 2017-11-22, at 11:58, Brian Trammell (IETF) <[e-mail]> wrote:
>> On 22 Nov 2017, at 11:35, Eggert, Lars <[e-mail]> wrote:
> 
>> For proposals other than the Spin Bit (I think I have seen individual contributors at least mention "loss" and "congestion" bits, but without much detail), we wanted to clarify that we'd like to see an analysis and discussion of their privacy aspects to roughly the same degree as the DT has performed for the Spin Bit proposal.
> 
> Ok. A couple of process questions remain open here, then:
> 
> (1) can the chairs articulate why, before the finalization of v1, they are proposing to go to a method of working that is somewhat more heavyweight than the issues-and-PRs-plus-ML that enhancements or change requests to the protocol to date have required?

The discussion leading up to and around the Spin Bit has demonstrated that proposals that affect the cleartext part of the wire image are incredibly controversial, and take the WG a lot of time to chew through. The Spin Bit alone took six months and a DT, and it's arguably amongst the most simple proposals one could make in this space.

We're trying to find a way to have future discussions on such proposals in an efficient manner, in a way that minimizes further delays to our main deliverables (the base drafts).

Part of this is that such proposals should be contributed to the WG in a way that lets other contributors understand the rational, design, and implications of the proposal, i.e., a somewhat longer and more structured format than we'd usually see for GitHub issues and PRs.

So yes, we're asking the proponents of new schemes that affect the wire image to do a bit more work and produce a more comprehensive proposal, compared to what we get in GitHub. But the hope is that this will reduce the effort the WG needs to spend overall on understanding and discussing such proposals, i.e., we hope for a net win.

For the Spin Bit specifically, most of the things that Mark listed exist in one way or another, it'll be mostly a short exercise in assembling that material?

> (2) to what proposals, specifically, does this heavyweight process apply? the spin bit and measurement proposals articulated to date? proposals impacting the measurability of the protocol? proposals impacting specific unencrypted bits in headers? all proposals impacting the wire image of the protocol?

My personal view is that I'd like to see this for proposals that affect the cleartext wire format in ways that may affect user privacy. For example, renumbering the packet types is probably not a change we need to be overly concerned with. (I realize this is not a clear-cut definition.)

Lars