Subject: [tcpinc] 1 vs 2

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 4 Nov 2015 00:57:46 +0000

Hi,

first, I apologize if I missed a message and was confused about the process we'd be following to come to a decision. But I was a bit surprised that we now seem to have adopted both individual documents as WG items? I had - probably mistakenly - assumed that we'd take forward only one, and that we were trying to decide which one.

Taking forward both is to me the least preferable option. While I have expressed a strong preference for one candidate, I'd rather grumble for a bit and then help do only the other one than doing both. Doing both is just going to create endless confusion and pain down the road. The technical differences are not large enough IMO to warrant a dual approach (although they are large enough to cause me to have a preference.)

In other words, I'd rather see you flip a coin now.

(I wanted to send this before the meeting later, so we can start the discussion by email now, to conserve microphone time.)

Lars

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 4 Nov 2015 10:19:04 +0900

Hi Lars,

Am 04.11.15 um 09:57 schrieb Eggert, Lars:
> Hi,
>
> first, I apologize if I missed a message and was confused about the
> process we'd be following to come to a decision. But I was a bit
> surprised that we now seem to have adopted both individual documents
> as WG items? I had - probably mistakenly - assumed that we'd take
> forward only one, and that we were trying to decide which one.

Mirja, WG chair, tried to determine after the last IETF meeting in 
Prague if there is rough consensus for one of the drafts which are 
proposing a protocol. There was no rough consensus to select either the 
TLS-based or tcpcrypt as WG item. Actually it looked already at time, 
that both drafts are preferred by the WG to go forward.

>
> Taking forward both is to me the least preferable option. While I
> have expressed a strong preference for one candidate, I'd rather
> grumble for a bit and then help do only the other one than doing
> both. Doing both is just going to create endless confusion and pain
> down the road. The technical differences are not large enough IMO to
> warrant a dual approach (although they are large enough to cause me
> to have a preference.)
>

There seems not to be sufficient consensus to this way either, as this 
was mentioned/discussed in Prague, too.

Not having rough consensus for either protocol proposal, the wish to not 
flip a coin and the appearance that there is some preference to work on 
both lead to the call for consensus to adopt both drafts.

I am personally would also prefer one protocol to work from, but the 
history of the WG lead us to the point where we are now.

Further, I do not like to open up this question again in the WG session, 
as we have had sufficient time in the WG to see which protocol(s) to use 
and the WG has finally made a decision to move forward. At least the WG 
is moving forward.

As said, this is not the best possible outcome in my private opinion, 
but we are not deadlocked in the WG anymore.

   Martin

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 4 Nov 2015 02:12:20 +0000

Hi,

thanks for the history, Martin.

> but we are not deadlocked in the WG anymore.

Well, we also really haven't made progress. If we keep working on two approaches, there is a high likelihood we'll have two RFCs in the end, and I can't see how this would be good.

So maybe after having had a chance to cool off after Prague, couldn't we attempt one more time to see if we can pick one, even if it may involve a coin toss?

Lars

---

From: "Black, David" <[email-masked]>
Date: Wed, 4 Nov 2015 02:14:43 +0000

Lars,

Mirja explained the path forward in this case in the adoption calls for both drafts:

> If we end up adopting more than one approach, I currently see three way to proceed:
> 
> 1) Both approaches (naturally) converge into one approach.
> 
> 2) We work on both approaches to get them into a (similar) state where the wg is
> able to make a decision (and withdraw the other doc).
> 
> 3) We publish both approaches as different 'versions' of tcpinc that can be
> negotiated in the tcp-eno handshake, where at least one of them is mandatory to support/implement.

The choice between 1/2/3 is up to the WG.

Thanks,
--David

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
> Sent: Tuesday, November 03, 2015 8:19 PM
> To: Eggert, Lars; tcpinc
> Subject: Re: [tcpinc] 1 vs 2
> 
> Hi Lars,
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Nov 2015 13:12:58 +0900

> On 4 Nov 2015, at 9:57 AM, Eggert, Lars <[email-masked]> wrote:
> 
> Hi,
>

---

From: David Mazieres <[email-masked]>
Date: Wed, 04 Nov 2015 03:26:01 -0800

> Mirja explained the path forward in this case in the adoption calls

Suppose we go down path 3, namely to publish both approaches as
different versions of tcpinc.  Is it required that both be published
simultaneously?  If we can just publish each RFC when it is ready, then
there might be incentive for people to work on independent
implementations.

Right now, one problem for anyone considering investing time in tcpcrypt
is that even if we get the draft into great shape, get two independent
implementations, etc., we might still end up stuck waiting for
TCP-use-TLS, which might in turn be stuck waiting for TLS 1.3.

So while having two different RFCs does not seem like the end of the
world, forcing them both to proceed in lockstep may greatly delay
deploying anything.  Would it be possible to decouple progress on the
two protocols by working group consensus?

David

---

From: ianG <[email-masked]>
Date: Fri, 6 Nov 2015 02:23:49 +0000

> two protocols by working group consensus?

+1

iang

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 6 Nov 2015 05:02:57 +0000

> two protocols by working group consensus?

I wasn't aware of anything stating (or implying) that the two schemes
had to proceed at the same pace,  so I'd be happy for each to proceed
without any coupling.

DF