Hi all, and just to make this very clear again (I thought I was saying this very clearly in the meeting already):
We will not hold one of the docs up to wait for the other! Mirja > Am 05.11.2015 um 10:23 schrieb Black, David <david.bl...@emc.com>: > >> 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? > > I think that's possible. This will likely come down to the form of the > references from the TCP-ENO draft to each of the protocol drafts - a > normative reference results in the TCP-ENO draft not being published as > an RFC until any normatively referenced protocol draft is also published > as an RFC (I have a draft that's been at the RFC editor for many months > now due to this sort of reference wait). > > Of course, this begs the "mandatory to implement" (MTI) topic that we > discussed yesterday, as the reference from TCP-ENO to the/a MTI protocol > has to be normative, and the chairs would like to defer that discussion > for the time being. > > Thanks, > --David & Mirja > >> -----Original Message----- >> From: Tcpinc [mailto:tcpinc-boun...@ietf.org] On Behalf Of David Mazieres >> Sent: Wednesday, November 04, 2015 6:26 AM >> To: tcpinc >> Subject: Re: [tcpinc] 1 vs 2 >> >> "Black, David" <david.bl...@emc.com> writes: >> >>> Lars, >>> >>> Mirja explained the path forward in this case in the adoption calls >>> for both drafts: >> >> 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 >> >> _______________________________________________ >> Tcpinc mailing list >> Tcpinc@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpinc > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
