Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

["Black, David" <[e-mail]>]

Still as an individual ...

> What I was actually advocating was that in the presence of any option marked
> "drop if unknown" there MUST NOT be any legacy data, i.e, such options
> could not appear in the trailer format. All payload would have to be in the
> surplus area (which requires the header format). In that case, "drop the
> packet" and "drop the surplus" would amount to the same thing.

That would "freeze" LITE - if we ever found anything problematic with LITE and wanted to replace it with LITE2, that replacement would be prohibited by such a requirement.

NB: *replace* is crucial in this context - this is not about trying to use both LITE and LITE2 in the same packet.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of C. M. Heard
> Sent: Saturday, July 20, 2019 8:51 PM
> To: Derek Fawcus
> Cc: tsvwg
> Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
> 
> 
> [EXTERNAL EMAIL]
> 
> On Sat, Jul 20, 2019 at 2:56 PM Derek Fawcus wrote:
> > I suspect we should interpret "drop the packet" here for options marked
> > as "drop if not known" to actually mean "discard the surplus".
> >
> > i.e. if a non-legacy receiver in processing the surplus finds such an
> > option, it then switches to operating in legacy mode for that packet.
> 
> I do not agree.
> 
> > Which means that like the legacy receiver, it will either see a zero length
> > UDP packet (if UDP payload length was zero) or see whatever legacy UDP data
> > was passed in the non-surplus area.
> 
> What I was actually advocating was that in the presence of any option marked
> "drop if unknown" there MUST NOT be any legacy data, i.e, such options
> could not appear in the trailer format. All payload would have to be in the
> surplus area (which requires the header format). In that case, "drop the
> packet" and "drop the surplus" would amount to the same thing.
> 
> Mike