[CCing TCPM for the part that matters to TCPM]
> 4. citing drafts in support of future large SYN options:
> “Is there harm in doing this? E.g., is it bad practice to cite internet
> drafts (non-normatively, of course) in an RFC?”
>
> 4.a. Citing drafts does go against the current BCP, as I
> > On Apr 28, 2016, at 9:26 AM, to...@isi.edu wrote:
> >
> > I guarantee someone will show us a middlebox that NEEDS to modify
> every
> > option we currently have and every option we will ever create.
>
> I'd put it the other way around. The fact that middleware *can* get to
> something lets
> But more to the point, what is your concrete proposal?
1. Get an ExId from IANA. I think filling out
http://www.iana.org/form/protocol-assignment can be done in 5min. This can be
done by anybody interested in experimenting with TCP options, because it is
clear that there is a need to
> More importantly, I don't want to keep re-litigating this point. If you'd
> formed working group consensus around getting an ExID, we would have switched
> to RFC6994. At this point, we're on the home
> stretch for an RFC and have a bunch of deployed code out there, so our
> efforts are
> >> Another approach here would be to make it easy for other RFC authors
> to
> >> leverage tcpcrypt to protect the privacy of there options. For any
> >> options that are tied to data, moving them in-band to special TLV
> >> frames
> >> might make the most sense.
> >
> > Formally, that would
> Another approach here would be to make it easy for other RFC authors to
> leverage tcpcrypt to protect the privacy of there options. For any
> options that are tied to data, moving them in-band to special TLV
> frames
> might make the most sense.
Formally, that would require a proposed
-
From: EXT Mirja Kühlewind [mailto:mirja.kuehlew...@tik.ee.ethz.ch]
Sent: Thursday, April 28, 2016 11:07 AM
To: Scharf, Michael (Nokia - DE); tcpinc
Subject: Re: [tcpinc] Encryption of TCP Options
Hi Michael,
see below.
On 27.04.2016 09:38, Scharf, Michael (Nokia - DE) wrote:
> I th
I think this could be done for non-SYN options that do not modify the semantics
of the key TCP header fields. But there are not to many of those options and
putting them inside TCPINC gets relatively close to developing a new shim layer
transport inside a "TCPINC tunnel".
As far as I
> > An abstract API should never need to get into such a level of detail
> > to require a particular implementation. If you're aiming for something
> > beyond that, IMO the IETF is the wrong place (e.g., a better place
> > would be POSIX).
> To this point, does it make sense to use a common
discuss this formal question.
Michael
-Original Message-
From: Tcpinc [mailto:tcpinc-boun...@ietf.org] On Behalf Of EXT Stephen Farrell
Sent: Tuesday, April 12, 2016 11:55 AM
To: Scharf, Michael (Nokia - DE); David Mazieres expires 2016-07-10 PDT; EXT
Kyle Rose; tcpinc
Subject: Re: [
Inline
-Original Message-
From: EXT David Mazieres [mailto:dm-list-tcpcr...@scs.stanford.edu]
Sent: Monday, April 11, 2016 6:52 PM
To: Scharf, Michael (Nokia - DE); EXT Kyle Rose; tcpinc
Subject: Re: [tcpinc] Confirmation of consensus to adopt API document
"Scharf, Michael (Nokia
11 matches
Mail list logo
