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

[Tom Herbert <[e-mail]>]

On Wed, Jul 17, 2019 at 9:06 AM C. M. Heard <[e-mail]> wrote:
>
> On Tue, Jul 16, 2019 at 3:15 PM Joe Touch wrote:
> > We CAN easily set a limit IF we went.
> >
> > We don't need to design that into the protocol structure.
> [...]
> > Receivers can do whatever they want to check without us setting
> > protocol limits.
> >
> > A good implementation (of anything) checks resources and limits
> > overuse. Period. We should not need to set limits to make that happen.
> >
> > Besides, such limits *change over time and depend on a particular
> > system's resources* anyway.
> >
> > One size does not fit all for all time.
>
> +1 to all of that.
>
> 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 contaning TLVs.

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 faciliate reuse of the
existing parsing loop.

Tom


Tom

> Mike