Subject: [tcpinc] Meta-comment on the adoption calls

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Oct 2015 16:52:44 -0700

I have just commented in each of the two drafts calls for adoption, noting
that I support adopting each of them.  I did that in part because I agree
with Mirja's note that forcing the wg to make a decision has not worked
previously and in part because I see evidence of collaboration between the
teams and approaches  (the format changes in tcpcrypt are one example and
the reviews of tcp-tls another).

I understand Steven's concerns about working to create two long term
solutions, but I believe that much of the issue so far has been because
there has been a fundamental assumption that they are competitors.  I
believe that Mirja's note casts them as collaborators, and I believe that
moving forward on that basis is a better bet than having one "win" now.  We
don't need to decide on the final output of that collaboration right now,
but I think we do need to move to that basis as soon as possible.

Just my opinion, of course,

Ted

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 21 Oct 2015 01:33:51 +0100

> Just my opinion, of course,

And a reasonable one with which I just happen to disagree. It
seems to me that the longer this goes on the less likely it is
that one proposal will be dropped. My prediction is that if
both are developed further, they'll end up functionally the
same, with the only differentiator of note being a lack of
interop, and that that'd be a situation that'd persist for
years to come. Or worse, if tcpinc is even moderately successful,
for decades to come.

For me, the canonical example of that kind of outcome was CMC
vs. CMP which is almost 20 years ago, and as a result of which
we almost have a full zoo of mostly but not quite unused PKI
management protocols, even today. (CMP vs CMC was not the only
reason why we've seen issues in PKI management, but it is still
a painful and very long term lesson.)

That's independent of whether the proponents help one another
or are sworn enemies.

S.

> 
> Ted
> 
> 
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Oct 2015 07:45:32 -0700

On Tue, Oct 20, 2015 at 5:33 PM, Stephen Farrell <[email-masked]>
wrote:

> that one proposal will be dropped.
>

​And the longer we stay in "competitive mode", I think the more likely it
will be both will be dropped, at least for mass deployment.  I think having
two is a better problem than having none.  (I don't dispute that it may
eventually be a problem, but it's more of a *crise de succès*).

On this point, in other words, we may simply disagree on likely outcome.

regards,

Ted

---

From: ianG <[email-masked]>
Date: Thu, 22 Oct 2015 11:36:33 +0100

On 21/10/2015 00:52 am, Ted Hardie wrote:
> I have just commented in each of the two drafts calls for adoption,
> noting that I support adopting each of them.  I did that in part because
> I agree with Mirja's note that forcing the wg to make a decision has not
> worked previously and in part because I see evidence of collaboration
> between the teams and approaches  (the format changes in tcpcrypt are
> one example and the reviews of tcp-tls another).

Collaboration can be useful, but the question is whether it improves 
anything?  Not really, marginally, but it's not worth the cost.  Both 
protocols can be made to work.

> believe that Mirja's note casts them as collaborators, and I believe
> that moving forward on that basis is a better bet than having one "win"
> now.  We don't need to decide on the final output of that collaboration
> right now, but I think we do need to move to that basis as soon as possible.
>

To me it comes down to simple game theory.

1.  would we get a better result by having two competing or even 
cooperative proposals?

No.  Both proposals have the technical chops to do a reasonable job. 
Both can be made to work.

2.  Would we get a slower result by having two proposals?

Yes.  There is no doubt at all that we will expend energy and 
potentially enter into deadly embrace if we have two proposals.  We've 
already lost a year.

Even if the two proposals enter a convergence path, it will still be 
lost time, probably another year, more likely 2-3.  We also have a 
serious risk of entering deadly embrace.

Draw it out as a 2 x 2 matrix.  In which square do you want to be?

iang

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 22 Oct 2015 14:37:56 +0200

Hi Iang, hi all,

just as a side comment on this bit:

> serious risk of entering deadly embrace.

The reason why I'm not forcing a decision right now is because I don't want 
to loose any further time. I personally agree that basically both proposals 
are find and, both proposals could fulfill our charter, so my mail goal here 
as a chair is to publish a solution as soon as possible; also because if we 
wait to long, tcpinc might not be useful anymore.

This is also reflected by the milestones we finally set up:

Aug 2016 	Submit extended API to IESG as Informational
Jul 2016 	Submit unauthenticated key exchange mechanism and extensions to 
current TCP to IESG for publication as Experimental
Mar 2016 	Adpot first WG document on extended API
Nov 2015 	Adopt first WG document on unauthenticated key exchange mechanism 
and extensions to current TCP

I will try very hard to stick to this time schedule; that's also why we have 
adoption calls right now. And in case we end up adopting both proposals and 
one of the author teams does not make the given time-line, that might simply 
be the decision for the other proposal.

Mirja