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

[Joe Touch <[e-mail]>]

Regarding the pad options and option numbers, we have thee choices:

- model TCP codepoints (as we currently do)
- model IPv6 codepoints
- pick our own 

Note that there is no way to do the first two concurrently. 

IMO we should model a transport if we model anything. 

Joe

> On Jul 17, 2019, at 9:36 AM, C. M. Heard <[e-mail]> wrote:
> 
> On Wed, Jul 17, 2019 at 9:21 AM Tom Herbert <[e-mail]> wrote:
> > On Wed, Jul 17, 2019 at 9:06 AM C. M. Heard <[e-mail]> wrote:
> > > It may be reasonable to set some lower bounds on what a conforming
> > > implementation is obliged to accept -- something along the lines of
> > > the requirement in RFC 792 that "[a]ll hosts must be prepared to
> > > accept datagrams of up to 576 octets (whether they arrive whole or
> > > in fragments)." But that does not need to be -- and in general should
> > > not be -- baked into the protocol structure. Capabilities change, and
> > > increased limits can find their way over time into new implementations,
> > > but not if the protocol structure imposes an artificial ceiling.
> > >
> >
> > Mike,
> >
> > See Section 5.3 of RFC8504. This text should be adaptable to any
> > stateless protocol containing TLVs.
> 
> Yes, something along those lies was what I had in mind.
> 
> > Side note: UDP options should define both PAD1 and PADN to be
> > consistent with HBH, Dest, and SR options. Preferably PAD1 would have
> > type 0 and PADN would have type 1 which would facilitate reuse of the
> > existing parsing loop.
> 
> If 8-byte alignment is desired, then PADN saves work. It's not as useful
> if 4-byte alignment is all that's wanted; doubtless that's why it was
> left out of the IPv4 and TCP option design. I would have no problem with
> adopting the more modern IPv6 conventions.
> 
> Mike