Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02

Tom Jones <> Fri, 11 May 2018 10:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D88EE12D947 for <>; Fri, 11 May 2018 03:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M_i4kLUqMFOh for <>; Fri, 11 May 2018 03:07:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 653F0127078 for <>; Fri, 11 May 2018 03:07:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 666511B00243; Fri, 11 May 2018 11:07:26 +0100 (BST)
Received: from compute7.internal (compute7.nyi.internal []) by mailauth.nyi.internal (Postfix) with ESMTP id 0827C232F4; Fri, 11 May 2018 06:07:25 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute7.internal (MEProxy); Fri, 11 May 2018 06:07:25 -0400
X-ME-Sender: <xms:XWv1WvEUzTiFw8UzJBHA0dYgYbmt4pxYmjbUFqFhMItHmb1MxBqjtg>
Received: from ( []) by (Postfix) with ESMTPA id 68AED102C7; Fri, 11 May 2018 06:07:24 -0400 (EDT)
Date: Fri, 11 May 2018 11:07:32 +0100
From: Tom Jones <>
To: "C. M. Heard" <>
Cc: Joe Touch <>, tsvwg <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 May 2018 10:07:47 -0000

Hi Mike,


On Sun, May 06, 2018 at 10:23:54AM -0700, C. M. Heard wrote:
> Greetings,
> Some issues came to my attention during a recent off-list discussion with
> someone from the DNS community.
> Section 5.4, Alternate Checksum (ACS): since the option area is not
> included in the ACS, the following text seems out of place:
>    When ACS is computed, its checksum (CRC) area is zeroed. No other
>    options are zeroed before computing ACS.

I need some clarification on this too.

> All that is needed is to stuff the remainder of the standard polynomial
> long division in the ACS checksum area.
> There are also some issues that need to nailed down for clarity. the usual
> way that the specified polynomial is used is to invert the first 16 bits of
> data and transmit the complement of the resulting polynomial division. If
> that is not done here, it would probably be good to say so. Also, it is
> necessary to specify whether the data polynomial is constructed as if the
> bytes are transmitted most significant bit first or least significant bit
> first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be
> 0x11021, but that fact is not needed, and I recommend omitting it).

The currect text on the OCS says the checksum is not inverted, this
should be added here as well.

> Section 5.5, LITE option: the following instruction
>    3. Swap all four bytes of the LITE option with the first 4 bytes of
>       the LITE data area (Figure 11).
> works only if the LITE data area is at least four bytes long. However, the
> option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one
> simply moves the option to the start of the LITE data area and moves the
> displaced LITE bytes just past the end of the relocated LITE option. This
> operation is then reversed on the receive side. In effect, one is swapping
> the locations of the LITE option and the initial segment of the LITE data
> area of length min(4, LITE offset).

A UDP Lite region greater than 0 must be a minimum of 8 octets. 

	A Checksum Coverage of zero indicates that the entire UDP-Lite
	packet is covered by the checksum.  This means that the value of
	the Checksum Coverage field MUST be either 0 or at least 8.

So only the 0 coverage case must be considered by this document.

> Note that being able to use the LITE option with a length of zero is
> important for option negotiation.

- [tj]