Martin Thomson <[email protected]> writes: > On 14 August 2015 at 11:05, David Mazieres > <[email protected]> wrote: >> If we don't specify requirements for the session ID, then applications >> will have to be knowledgeable about what encryption spec they are using. >> That means if we get large SYN options down the line and massively >> optimize TCPINC, applications won't be able to take advantage of it >> automatically. > > > Sorry, I missed an important word. I have *no* problem with > specifying requirements; I just have a problem with specifying > mechanism with a requirement for that mechanism.
So what is your proposal? Do you think TCP-ENO should specify the mechanism or the requirement? Right now, I think the draft is written in an attempt to specify the requirements and leave the mechanism as open-ended as possible. I haven't seen any ideas on how to make it more mechanism-agnostic. Does this mean you'd favor dispensing with the requirements and just specifying a mechanism? > If you look at this in the abstract, how the session ID is acquired > and defined can (and should) be opaque to an application using this. > At some level, the requirement you want is an API one: the application > MUST be able to acquire an identifier that is unique for the session. Exactly. > Also, given the other discussion, perhaps the model in RFC 5705 is the > right one to use: don't expose a unique id, but provide an application > the ability to extract a value, with the limitation that it be > specific to that application. Well, I'd say RFC 5705 tends towards the mechanism end of the spectrum, since it tells you exactly what to feed into your PRF. I don't know if we want to make such assumptions about TCP-ENO specs. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
