Re: [tcpinc] AD review of tcp-eno

[Kyle Rose <[e-mail]>]

On Fri, Jul 28, 2017 at 2:17 PM, David Mazieres expires 2017-10-26 PDT <
[e-mail]>
wrote:

> Kyle Rose <[e-mail]> writes:
>
> > Does it make sense to allocate a few TEP IDs (e.g., 0x7c-0x7f) as
> explicit
> > "for testing purposes: not for production use" IDs that implementors can
> > use in testing? Another alternative is an explicit ExID-like mechanism,
> but
> > that seems far too heavy-weight for something like ENO. A range like this
> > would at least offer implementors a no-effort way to do their own
> > development and testing without poisoning other TEP IDs.
>
> The document already reserves 0x20 for experimental use.


Evidently, I must have glossed over that entry in table 2 a half-dozen
times over the past two years. Heh. I think we're good on that point.


>   I'm a little
> hesitant to go allocating the top end of the space, because in the
> unlikely event that ENO is so successful we project running out of code
> points, we might want to use the low two bits of 0x7c-0x7f or 0x78-0x7f
> as the first three bits of a 10- or 11-bit extended TEP Id.


Hopefully that's a lot of crypto evolution away. Certainly, if we make the
standard "RFC", then many documents would likely have to be published
before we were in danger of exhausting this space.


> Is one
> experimental TEP ID not enough?
>

I was thinking of implementors developing multiple TEPs simultaneously,
like you did with both of the NIST curves. Is this realistic? I don't know.
Will it be confusing to have two separate experimental ID spaces? Possibly.
Can implementors just encode their algorithm choices as suboption data?
Yes. So it's probably not a big deal.


> The intention with 0x20 is eventually to specify an ExID-like mechanism,
> but I think maybe we felt it was premature to do so in this document.
> We could also add vaguer language about how users of 0x20 should start
> options with two or more identifier bytes to leave open the possibility
> of interoperating with other experiments.
>

Without a registry of TEP ExIDs, conflicts between experimental TEPs are
likely to happen if this mechanism takes off and those experiments are
deployed on the public internet. Does it matter if it's just an experiment?
Possibly, if the TEP designer decides they need test results at scale
before even approaching the IETF. Maybe the guidance in this doc should be
for the first two bytes of the 0x20 suboption data to be 00 00, which
leaves us room in the future to create a TEP ExID standard with the hope
that the other 65535 values are unused.

Kyle