Re: [Masque] Erik Kline's Yes on draft-ietf-masque-h3-datagram-10: (with COMMENT)

David Schinazi <dschinazi.ietf@gmail.com> Wed, 15 June 2022 20:58 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EB6C159481; Wed, 15 Jun 2022 13:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pVGWcKTNbsIA; Wed, 15 Jun 2022 13:58:38 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F40C157B5E; Wed, 15 Jun 2022 13:58:38 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id q12-20020a17090a304c00b001e2d4fb0eb4so3283644pjl.4; Wed, 15 Jun 2022 13:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+pzts0FyYUpniivFZgGcNT9kbCzdQ1wAnKqcEZg4x5o=; b=kcLY4QWERBOB41VrkSd6+k6Nfg68IKEgM+rUBykaIjnSq9ojMWtoavJrS/Sh2Zn9PT 7jh3vdDcoo6SBFc5CssOUW8XV8JCRRlJMylo2Y9yrx4i5lfUWCvsK4tb8lWUj0pzjyUa aAdFkdUfrPmROLNxsYo0cXKAZQ14YrJc9z3p86S4VvKgJme2fNG1DR7hsMmaFJ/XrEaL +vGyBy/TtoPQeXCwI6OGX7U32rTi0e2oZUMBwJKkcmeI9pJlkeriEJbVW1OquF7RBO1V SLdLefN/1BoLz8MmkfITOuBbzz+sIvQEM26qwQOKZdI0nS+OD+idOYFvYquX77Z+L5M1 2jCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+pzts0FyYUpniivFZgGcNT9kbCzdQ1wAnKqcEZg4x5o=; b=0JO0rlRfIaHmEYuoyJsIZvtl1WVIVGXZu5D65Mx2Y9MpaUC6KAQgCMEgaH7ak1Rvlo kqdPTMrC7Ks6RQL6b6PVvmGoAIWV0kL6yHtN/1q1/jwquEaMe/rpAnb9WEx/Og5JvQXk fWAGjXrP9q2LRxxEPDLSH7UNioI8xJn/YDnXnrc9aeyTn9/H662f5oTq4ltmWL+bHlPE LwjHs+wwB/CIsDGP1GYhoIuCqfSu7srmIG3cIn62k3K1CU3CWk4M3As4UbNiXh7NAN0F Qilni6SHu7lY43WoZh1Q4ZkGRoiA7TvClwn8pg1MGdjTT6nsm0GwlG3wcNU8XVEoNco2 Y02Q==
X-Gm-Message-State: AJIora/2BprayMaOgaLH5w+WBEMVLXCp/R9Ey3fRQjKa7O50SaPOOfTY RKbfc+kY1GnOCHhtM08yQ6uGkoo5vHyh+phH0Vo=
X-Google-Smtp-Source: AGRyM1sC4LOi/633WnTb4rNt/Jaij3XmF2Y+DrO8g1cBnSoaj3Z74Ulo3SuVRUsOdkDaJXeYrE/n7RgcB+5EiPBY2Z0=
X-Received: by 2002:a17:902:a58b:b0:168:b680:c769 with SMTP id az11-20020a170902a58b00b00168b680c769mr1578879plb.32.1655326717925; Wed, 15 Jun 2022 13:58:37 -0700 (PDT)
MIME-Version: 1.0
References: <165507272176.13413.7473506800933970739@ietfa.amsl.com>
In-Reply-To: <165507272176.13413.7473506800933970739@ietfa.amsl.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 15 Jun 2022 13:58:26 -0700
Message-ID: <CAPDSy+4fcBSVR0m4SwGfoWvaBAD7ZuwTpSqEZ1-i=CXh=hmzXQ@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-masque-h3-datagram@ietf.org, masque-chairs@ietf.org, MASQUE <masque@ietf.org>, Christopher Wood <caw@heapingbits.net>
Content-Type: multipart/alternative; boundary="000000000000025e0f05e182c9fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/8ucnEp8AlU-Qn7utz2CfIpLtx34>
Subject: Re: [Masque] Erik Kline's Yes on draft-ietf-masque-h3-datagram-10: (with COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 20:58:39 -0000

Thanks for your review, Eric!
Responses inline.
David

On Sun, Jun 12, 2022 at 3:25 PM Erik Kline via Datatracker <noreply@ietf.org>
wrote:

>
> * Possibly the definition of Capsule Type should mention the IANA registry
>   via a short reference ("; see Section 5.4").
>

Agreed, added via this commit:
https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/commit/cd550aee6dd871d7396ee97b7a3e42642ee5535c

* If new 2xx codes are defined in the future, are they required to state
>   what their suitability is in scenarios upgrading to Capsule Protocol use?
>
>   If so, is there any additional guidance beyond what one could divine
>   from a reading of the 2nd to last paragraph?
>
>   (New 2xx codes seem extremely unlikely, but is such a thing completely
>    impossible?)
>

New 2xx codes have specific semantics that are well-defined in Section 15
of RFC 9110: clients MUST treat any unknown 2xx error code as 200. Any
new 2xx code that is defined after this specification is published will
therefore
know that existing implementations will by default treat them as 200. If
they
want different treatment, they'll have to specify it. Since this is
guaranteed
by the semantics of HTTP status codes, I don't think there's anything to
add to this document.