[tsvwg] Comments on draft-ietf-tsvwg-udp-options-20
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 22 May 2023 13:21 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2149C14CE5D for <tsvwg@ietfa.amsl.com>; Mon, 22 May 2023 06:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDWs6YlByfnG for <tsvwg@ietfa.amsl.com>; Mon, 22 May 2023 06:21:39 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id D801FC151072 for <tsvwg@ietf.org>; Mon, 22 May 2023 06:21:38 -0700 (PDT)
Received: from [192.0.0.2] (nat64-30-177.mtg.ripe.net [193.0.30.177]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0C0111B001B7; Mon, 22 May 2023 14:21:35 +0100 (BST)
Message-ID: <3e867434-5fb2-cf67-6226-fdfb0d736439@erg.abdn.ac.uk>
Date: Mon, 22 May 2023 15:21:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: UNIVERSITY OF ABERDEEN
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/QP5Nv_1DJjJMqrtEvRKHxMciaeg>
Subject: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-20
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2023 13:21:40 -0000
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."
- [tsvwg] Comments on draft-ietf-tsvwg-udp-options-… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com