Re: Spin bit discussion - where we're at

["Brian Trammell (IETF)" <[e-mail]>]

hi Mark,

> On 22 Nov 2017, at 12:44, Mark Nottingham <[e-mail]> wrote:
> 
>> 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.

The DT did not, but the WG discussed it after the DT report. I'll take your statement here as an indication that the rough consensus I thought I saw for the spin bit as harmless and useful in Singapore and on the list afterward is not an impression shared by the chairs and the rest of the WG.

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

Okay. I'm trying not to, but it seems to me to be difficult to avoid the perception of a series of hoops to jump through when an enumeration of work items is laid out under the signature of a WG chair speaking as such, especially when much of the information is available, albeit in a less organized form.

(in re productive: at this point I've spent my time budget on this for the day on this thread, which is basically my fault, but I think I have a much clearer picture of the state of things, so thank you for that.)

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

Okay. I'm not saying it wouldn't be interesting, I'm saying it won't be a useful input to the WG's decision. I won't spend any time on it, except what naturally comes out of point 3, and I'll hope that's enough for the WG to decide.

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

s/data/information content/ but yeah, the boundary here is looking pretty clear, and quite useful to ensure this process is not applied in an arbitrary way.

'Night. I'm off to enjoy the last nice day in Zürich.

Thanks, cheers,

Brian