> AFAICT, the encryption spec is a component of TCP-ENO. This wouldn't be > "overloading", but a sub-field or variant. > > IMO, TCP option kind numbers ought to be assigned only for independently > useful options.
Ok, I stand corrected on that one ... please ignore that comment on 4.2. Thanks, --David > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Wednesday, June 29, 2016 12:54 PM > To: Black, David; Derek Fawcus; [email protected] > Subject: Re: [tcpinc] TCP-ENO: David Black's review > > > > On 6/29/2016 5:45 AM, Black, David wrote: > > Hi Derek, > > > >> > Having encryption params within the scheme being renegotiated seems > likely, but not > >> > changing the scheme, as such I can't see the need to preclude reuse of > >> > the > option > >> > values for per scheme use once the scheme is selected. The actual use I > >> > was > expecting > >> > was that the per scheme renegotiation would/could use those values for > negotiating > >> > new keys, or other per-scheme values. > > Hmm - looks like I may have misread this text last night as releasing the > > option > for arbitrary > > usage. I suppose what is there is ok, but I'd prefer to see another option > > kind > allocated for > > encryption spec usage (if we anticipate that being needed) rather than > overloading the > > TCP-ENO option kind. > > > > Thanks, --David > > AFAICT, the encryption spec is a component of TCP-ENO. This wouldn't be > "overloading", but a sub-field or variant. > > IMO, TCP option kind numbers ought to be assigned only for independently > useful options. > > Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
