IETF Logo Mail Archive

Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

"C. M. Heard" <heard@pobox.com> Sun, 21 April 2024 20:15 UTC

Return-Path: <heard@pobox.com>
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 2723AC14F5EC; Sun, 21 Apr 2024 13:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
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 8oYqw4OkvnWN; Sun, 21 Apr 2024 13:15:32 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DBCC14F5EF; Sun, 21 Apr 2024 13:15:31 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3AAAD1E2267; Sun, 21 Apr 2024 16:15:30 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=K48srYmzkcpdQ5h9eE3oIM9nauxTrMKs 4E+I6ZHzEVU=; b=JyPgb74qBbuR6e2zx/b1Crxj2HF8leW938H/BCAozFjWpcXM i4tLizRGBy9OJ7du1t/0PX3T2vGdIJi0/ELRrW+mQYbhqsx07Ug1cJWyvI+H/GdK xZY5at8JCPMwVOUwkMotTRdCDn9/0tlvdW7+9arKA2XmnUqJSnQaSOLsgVU=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 32CAF1E2265; Sun, 21 Apr 2024 16:15:30 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-ej1-f48.google.com (unknown [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 8EF8B1E2263; Sun, 21 Apr 2024 16:15:29 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a51a80b190bso234420866b.3; Sun, 21 Apr 2024 13:15:29 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUYQcIqTaeoKx4/2HYz9Wz4UjQRBmjHPHpa5MIFWIqGrLKCH7+qbhnZLfIqn6ALM2tHGQt8scaHP6Gfsi1zzA4Qt/uS/r61A7wIJnFfllCanlOVP9dx77po43JG3eIOPNBPzfUXH8tCc2E=
X-Gm-Message-State: AOJu0YybGxuYqcT+87bT9iu0a+OjHH966/mn38ygBdAGjgACwY7LrV34 223BMVeoRjL6PuzFm1PnvoRGGzKqY/yQS2FJfpAPpw4+EmtzY1fLuS6uBL3wrI87t+ljzkhvZ7P 34B9b5hNNQ7gdZxa3WzLNpa5qVvw=
X-Google-Smtp-Source: AGHT+IH2S5n5pVYAeQlzCymZjkTajkAzcKCXWLkLG4nqtNYwoJXvap0++DcncVLELhv7jAW9u5BIrdCyI5Z0+eUrn4s=
X-Received: by 2002:a50:8707:0:b0:56c:1735:57a2 with SMTP id i7-20020a508707000000b0056c173557a2mr6807058edb.31.1713730528591; Sun, 21 Apr 2024 13:15:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com> <2BEB5CC3-BB54-4119-A20F-8497ED4B5AE2@erg.abdn.ac.uk> <CAEh=tccKg7YHYkwKZ978uaXmTkBu3zyA+WBAW=eBMKAh2PSVDw@mail.gmail.com> <CACL_3VG6k9Rg4316dZUd5ksQ2pLZHxzDc2dZqVD0Z9yPQBo3Yw@mail.gmail.com> <CAEh=tcc7xvi5rNtYXChr84_zp3Sq8bJE4684V4qhL580RZeE9Q@mail.gmail.com>
In-Reply-To: <CAEh=tcc7xvi5rNtYXChr84_zp3Sq8bJE4684V4qhL580RZeE9Q@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Sun, 21 Apr 2024 13:15:18 -0700
X-Gmail-Original-Message-ID: <CACL_3VFqeFgehYbt1e5hfAF7NZwDLhA31AkR3Ju21o0iAoHHbQ@mail.gmail.com>
Message-ID: <CACL_3VFqeFgehYbt1e5hfAF7NZwDLhA31AkR3Ju21o0iAoHHbQ@mail.gmail.com>
To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, "Gorry (erg)" <gorry@erg.abdn.ac.uk>, Martin Duke <martin.h.duke@gmail.com>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-udp-options.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000065d1fa0616a0fb53"
X-Pobox-Relay-ID: E6154DFA-001B-11EF-9CB4-25B3960A682E-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BM7w7mTduw82p__PzK2ht5fnfT4>
Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32
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: Sun, 21 Apr 2024 20:15:36 -0000

On Thu, Apr 11, 2024 at 4:20 AM Zaheduzzaman Sarker <
zahed.sarker.ietf@gmail.com> wrote:

> On Tue, Apr 9, 2024 at 8:26 PM C. M. Heard <heard@pobox.com> wrote:
>
>> On Tue, Apr 9, 2024 at 6:09 AM Zaheduzzaman Sarker <
>> zahed.sarker.ietf@gmail.com> wrote:
>>
>>> On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <gorry@erg.abdn.ac.uk>
>>> wrote:
>>>
>> The backwards compatibility with UDP was considered important in the
>>>> development of this Spec.
>>>>
>>>
>>> This point is absent, AFAIK in Section 16 of the draft now.
>>>
>>
>>
>> Adding such a discussion is a reasonable request; IMO the best place
>> would be Section 6 (Design Principles).
>>
>
> Please add it.
>

After further review, it seems to me that the following text now in Section
6 adequately addresses this issue:

   6. The UDP option mechanism and UDP options themselves should
      default to the same behavior experienced by a legacy receiver.

      By default, even when option checksums (OCS, APC),
      authentication, or encryption fail, every received packet is
      passed (possibly with an empty data payload) to the user
      application. Options that do not modify user data should (by
      default) result in the user data also being passed, even if,
      e.g., option checksums or authentication fails. It is always the
      user's obligation to override this default behavior explicitly.

   These principles are intended to enable the design and use of UDP
   options with minimal impact to legacy UDP endpoints, preferably
   none. UDP is - and remains - a minimal transport protocol.
   Additional capability is explicitly activated by user applications
   or libraries acting on their behalf.


See also the response to Issue #43
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/43>.

Mike Heard

>

v2.23.0 | Report a Bug | By Email