On 2/8/15 5:30 PM, Ted Lemon wrote:
> On Feb 8, 2015, at 6:21 PM, C. M. Heard wrote:
>> Would your objections be addressed if Section 3 of the draft were
>> replaced by something along the lines of the following?
>
> No. This is not a draft about filtering extension headers. It is a draft
>
On Feb 10, 2015, at 1:38 PM, Fernando Gont wrote:
> Not sure what the "(as opposed to an extension header)" means. Could you
> elaborate/clarify a bit?
What I'm proposing is that unknown codes can be assumed to be extension
headers. Any known code may be either an extension header or a protoco
On Tue, 10 Feb 2015, Fernando Gont wrote:
> On 02/10/2015 02:48 PM, Ted Lemon wrote:
> > Ideally, such devices should be configurable with a list of protocol
> > header identifiers so that if new transport protocols are
> > standardized after the device is released, they can be added to the
> > lis
Hi, Ted,
On 02/10/2015 02:48 PM, Ted Lemon wrote:
> On Feb 9, 2015, at 11:56 PM, joel jaeggli wrote:
>> We do ourselves and the community a disservice when we fail to
>> include discussion of operational divergence from expected
>> behavior. if whe can find a position that falls short of advocac
On Feb 9, 2015, at 11:56 PM, joel jaeggli wrote:
> We do ourselves and the community a disservice when we fail to include
> discussion of operational divergence from expected behavior. if whe can
> find a position that falls short of advocacy where does that leave us?
I would suggest a note in t
On Mon, 9 Feb 2015, joel jaeggli wrote:
> On 2/9/15 7:09 PM, Ted Lemon wrote:
> > I think what will happen in practice is that there will be some
> > fast-path logic that looks at the first 256 bytes of the packet at
> > most, and probably discards it if it can't be made sense of by the
> > end of
On 2/9/15 1:57 PM, Fernando Gont wrote:
> On 02/08/2015 04:24 PM, Ted Lemon wrote:
>> On Feb 8, 2015, at 1:47 PM, C. M. Heard wrote:
>>> It is not necessarily true that an unknown upper layer protocol
>>> header will look like a malformed extension header to a device that
>>> assumes it is an