[tsvwg] Comments on draft-ietf-tsvwg-udp-options-20

[Gorry Fairhurst <[e-mail]>]

I have just read version 20, and I have some questions as a working 
group member. I hope this helps,

Gorry

P.S. I plan to also re-read and send comments specifically on the 
security mechanisms in a week or so.

----

1. The text in Figure 1, uses "ToS", this ought to be updated in line 
with the terminology in RFC2474, and refer to this as the DS field.

2. In Figure 4 legend:
"here using one zero for alignment"
I think it would be clear to say this is a byte, rather than just the value:
"here using one zero byte for alignment"

3. "UNSAFE options are used only in with",
- I think this should be more like:
"UNSAFE options are used only with"

3. "ignored but passing the UDP payload to the user when not supported"
- Would it be easier for reading, if there was a comma before the "but'?

4. "Except for NOP, EXP, and UEXP, each option SHOULD NOT occur more
    than once in a single UDP datagram."
- what happens if, in the future, other options or replacements are 
actually defined? It seems hard to know whether there will ever be an 
updates.
Could this instead be written as more like:
"Extensions SHOULD NOT occur more than once in a single UDP datagram,
the only specified extensions are NOP, EXP, and UEXP."

5. "Impossible lengths
    should indicate a malformed surplus area and all options silently
    discarded."
- Why ought this not be "SHOULD", and can we also modify the word order?
Could this be written as:
"An impossible length SHOULD be treated as an indication of a malformed 
surplus area and all options ought to be silently discarded.

6. " >> When the UDP options do not consume the entire surplus area, the
    last non-NOP option MUST be EOL."
- What is the required receiver behaviour when this is observed?

7. ">> NOPs SHOULD NOT be used as padding before the EOL option. As a
    one byte option, it need not be otherwise aligned."
- Does this really matter for interoperation at the receiver?
- I can see the argument that NOPs ought not to be used, but does this 
really need a keyword for receiver interoperability, or is this just 
good advice?

8. "on receipt but MUST be"
- Please add a comma before "but".

9. " >> UDP packets SHOULD NOT use more than seven consecutive NOPs,
    i.e., to support alignment up to 8-byte boundaries. UDP packets
    SHOULD NOT use NOPs at the end of the options area as a substitute
    for EOL followed by zero-fill. "
- What is the required receiver behaviour if consecutive NOPs are observed?

10. " MUST be receive the"
- Please omit "be".

11. "Start pointer can indicate the start of the
       original surplus area anywhere in the reassembled data."
- Insert "The" ?

12. "Values should "increase" (allowing for rollover) according to a
       typical 'tick' time"
- explain rollover in terms of the modulo the field size?

13. " or intend optionally for
    modification of any UDP options, including their new areas, in
    transit."
- I was unaware of what was intended here, perhaps this could be clearer?

14. " UDP options are transport options. Generally, transport headers,
    options, and data re not intended"
- Please add "a" to make this "are not intended.."

15. "Although option nicknames are not used in-band, new UNSAFE safe
    option values SHOULD commence with the letter "U" and avoid that
    letter as commencing safe options."
- Query: Please clarify: Is this intended as a capital "U", a small "u", 
or both cases?

16. " Future options MUST NOT be defined as having a value
    dependent on the contents of the surplus area."
- This troubles me, because it seeks to limit evolution in the future,
albeit for good reason. I'm not saying we should expect this type of 
change, but then I don't
also know that somebody might propose something that is useful in future.
- I wondered if it is wiser to say that we don't expect options
to define this, and any case that does, then has to explain how it will
co-exist with existing deployments, etc.

17. "reassembly of that UDP packet must be abandoned
    and all the fragments that have been received for that UDP packet
    must be discarded, and no ICMP error messages should be sent."
I this doesn't explain why this is required or recommended for the 
receiver,
what happens when the assembly doesn't complete and the data is truncated.
- why not require this with MUST?
- I also don't yet see why this ought not to be "ICMP error messages 
SHOULD NOT be sent", since I think that can have implications on 
end-to-end operation.

18. ">> UDP options that rely on soft-state exchange MUST allow for
    message reordering and loss."
- This is a normative requirement currently, but I do not understand why 
this is a requirement, it is surely a reality that designs need to 
accommodate. For instance, RFC 8085 said "Therefore,
    UDP-based applications need to be robust to reordering and delay."