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

Tom Jones <tom@erg.abdn.ac.uk> Fri, 11 May 2018 10:07 UTC

Return-Path: <tom@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 D88EE12D947 for <tsvwg@ietfa.amsl.com>; Fri, 11 May 2018 03:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_i4kLUqMFOh for <tsvwg@ietfa.amsl.com>; Fri, 11 May 2018 03:07:28 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 653F0127078 for <tsvwg@ietf.org>; Fri, 11 May 2018 03:07:28 -0700 (PDT)
Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 666511B00243; Fri, 11 May 2018 11:07:26 +0100 (BST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 0827C232F4; Fri, 11 May 2018 06:07:25 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 11 May 2018 06:07:25 -0400
X-ME-Sender: <xms:XWv1WvEUzTiFw8UzJBHA0dYgYbmt4pxYmjbUFqFhMItHmb1MxBqjtg>
Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (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 <tom@erg.abdn.ac.uk>
To: "C. M. Heard" <heard@pobox.com>
Cc: Joe Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Message-ID: <20180511100731.GA886@tom-desk.erg.abdn.ac.uk>
References: <CACL_3VHckarqxHkcqY_-+ehRU588gfB_2FoDDYL_buv9EjpTAw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACL_3VHckarqxHkcqY_-+ehRU588gfB_2FoDDYL_buv9EjpTAw@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/mtxPnaNrS8m1zsIDMQ5vcldUBq4>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 11 May 2018 10:07:47 -0000

Hi Mike,

inline

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]