Re: Spin bit discussion - where we're at

[Mark Nottingham <[e-mail]>]

> On 22 Nov 2017, at 10:27 pm, Eggert, Lars <[e-mail]> wrote:
> 
> Hi,
> 
> Mark is asleep (I hope), so below is my personal view.

Not asleep, but close. Personal views likewise.


> 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.

+1. Brian, I would remind you that the DT did *not* gain consensus on doing the spin bit. This is (still) a contentious issue.


> 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).

Exactly. Brian, please don't view this as a series of hoops to jump through; we are trying to find you (and other proponents) a path that is productive.

Since you asked earlier: I see item 5 as an extension of item 3. Since the spin bit is disconnected from the application payload, it might be used -- both by endpoints and networks -- for other purposes, thereby creating incentives that reduce its value and/or have unfortunate side effects. If this happens, it might not remain fit for purpose (and I've heard a few people expressing concern about this). An exploration of this area -- by whoever chooses to do so -- would help address those concerns. Not "required", just something we think would be helpful to have.


> 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.)

Agreed. If data is being added to the cleartext, we'll likely need to examine it in a similar way.

OK, *now* I'm going to sleep.


--
Mark Nottingham   https://www.mnot.net/