Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22

[Erik Auerswald <[e-mail]>]

Hi Mike,

On Thu, Jun 29, 2023 at 02:44:24PM -0700, C. M. Heard wrote:
> On Thu, Jun 29, 2023 at 9:28 AM Erik Auerswald wrote:
> >
> > > * Section 9.4: Agreed text for the (simplest) way to handle options
> > > in fragments of a datagram.
> >
> > I have to admit that I am utterly confused by section 9.4.
> > […]
> > Then "Frag. Start" seems to only be defined for the non-terminal FRAG
> > option format, but it is also part of the terminal FRAG option format.
> 
> That is not true. "Frag. Start" and "Frag. Offset" are defined in both
> terminal and non-terminal fragments (look carefully at Figure 10 and
> Figure 11).

I was not clear enough in what I was trying to say:

  * Both figure 10 and figure 11 show a "Frag. Start" field.

  * The text only defines the use for the non-terminal FRAG option format.
    The text beneath figure 10 explicitly says "In the non-terminal FRAG
    option format, Frag. Start[…]".  There is no similar text beneath
    figure 11.  There is no text with "In the terminal FRAG option format,
    Frag. Start[…]".

Perhaps the solution is to remove "In the non-terminal FRAG option format, "
from the definition.  But then I do not understand section 9.4 at all.
(I understand the idea of fragmentation and how to implement it, but I do
not understand how the description in section 9.4 can be a specification
for fragmentation.)

> […]
> Comparing RDOS with Frag. Start is just plain nonsense.
> […]
> > I would like to suggest considering a complete rewrite of the FRAG
> > description.
> 
> I don't think that is necessary. I think if the following text is
> removed from Section 9.4, the rest of the section will make sense.
> […]

I do not feel able to evaluate this.  I have to defer to reading the
next iteration of the section 9.4 (FRAG) contents.

Regards,
Erik