Re: Spin bit discussion - where we're at

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

Hi Lars,

Comments inline.

> On 22 Nov 2017, at 12:27, Eggert, Lars <[e-mail]> wrote:
> 
> 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.

(...again, it seems to me that the discussion converged in Singapore, so I'm a little perplexed as to why we're still having this conversation, especially given a explicit statement from the chairs that consensus may necessarily be rougher as we work to meet milestones in a timely manner, but if I'm the only one who believed that we were done, I'm willing to be declared in the rough here.)

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

Indeed, it was specifically designed to be the simplest possible proposal in this space. And if my read of this thread is correct, that the chairs believe there is no consensus to add the spin bit, and that a proposal to add the spin bit will be considered at IETF 101, it'll end up taking basically a year. PR 609 was submitted in Paris, but the discussion about explicit measurability predates it a bit.

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

Ok, this makes sense to me.

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

This net win comes from shifting the effort to the proposers, which still has uncomfortable proof-of-work optics, but I see your point.

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

Everything except point 5 we basically already have in some form or another, and point 5 does not really seem worth spending effort on if the point is to come to a technical decision about this proposal.

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

I think I agree that this is the right aim. But if "affect the cleartext wire format in ways that may affect user privacy" is the criterion, then I would submit that the one thing the DT came to conclusion on is that the spin bit has negligible impact on user privacy, and as such would not be subject thereto. So the criterion is probably something different... let me propose "changes the information content of the wire image".

Thanks, cheers,

Brian