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

David Schinazi <dschinazi.ietf@gmail.com> Thu, 16 June 2022 18:41 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 2946BC157B4B; Thu, 16 Jun 2022 11:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 nCwFc8aB8bQS; Thu, 16 Jun 2022 11:41:18 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 49398C157B43; Thu, 16 Jun 2022 11:41:18 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id e11so2224088pfj.5; Thu, 16 Jun 2022 11:41:18 -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=Bum8HoGkSscbYazPfcXenHd9Oddk28kEfspI2g/A/zw=; b=CF3RLr9b8WS6FKeriBm67MZdWSI1zWSuc/hAR/4VrRh7ltt5SBweTK/NTDrwKS6KZ4 TdP9f5HCNWjDdlRGE43ymmhl2yy05DSHgH3oAU52nsXpHH65H5srDA8XMdVSYV3r0YPs ePWWhmHFpAqZ+q1+XyRgQxBs2PabXUs5GXvFiR+rEsJChfGH1cV96a2xAIXI/S9vPwIK hWyozSvulrGnYOXJTb8biiOYWvgSDrfcsktDLoGgdz/2kQP9cdG0KBCgw21p1aw53qgR ZFTYDydmvCi4En0CzM183PnyOuSUY8G65nMf4w4WmAIt91LQbZoB09wsA6oHgxMiJmnZ a5+w==
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=Bum8HoGkSscbYazPfcXenHd9Oddk28kEfspI2g/A/zw=; b=GsbPpcNqVCsKTBAmnlhepW8X0UU6ZhVxpd7hawEeOEyLkjIYwVm7sqJD+Wiu+dmn4d 9B2V9iskiaTgy9bXRhyBd8nK9Gdrt7VXuxXQQ2ixfJlg75wDuqhOLPxfrlUyiFe8dVtI uw0rnaNyMX0lZ+iQaY71BxUvY/1p5FafTN7m4in7JqlKcI0pYU8iLNTwXFhmDxTNyMpf cHzMux3nDxM7/zCEypnCE0+SiKrzE++Fn+qjTu6ayK7XfdnNSRpbmWRTP8slPsKh40MO U0sVRF9UDA6qAPVoBPXFvVlNIhfcfHJcvc1Z2155+wPWyOq+0B8hDpl/wqFxynguJ0MI y98g==
X-Gm-Message-State: AJIora8zj3SxCAD2XzRCpOmOeH0/LNLUcBkIVCn7Wj0gYS5hg9Lipjkb GqzpDF4zf+amqJl+/KVbS295kIwHD2c57zkXuPrq9ryt
X-Google-Smtp-Source: AGRyM1s4bnraDERuWMC5XyIcfs+ZqT8QfEsv1gnxQfBEIgW95BH34UJVGRU0CaosKj3wzLz1X82XyNLh9yaafOjXasE=
X-Received: by 2002:a05:6a00:150f:b0:51b:e050:d36e with SMTP id q15-20020a056a00150f00b0051be050d36emr6069707pfu.44.1655404877788; Thu, 16 Jun 2022 11:41:17 -0700 (PDT)
MIME-Version: 1.0
References: <165532474199.60753.8589453083068899777@ietfa.amsl.com> <CAPDSy+4k7B1mQL7cqZh2b2ES2U_CNENhaUkUqFrm77M1DAzUtg@mail.gmail.com> <D2F3DCB9-3598-4025-A7E6-0B952F8844E6@ericsson.com> <CAPDSy+7tb1dUamY+MpQ6GwRRoX=w9FTS7jzExJPJTYYyV0N3fA@mail.gmail.com> <26D5D970-A8B6-4797-8417-6845B125ACCF@ericsson.com>
In-Reply-To: <26D5D970-A8B6-4797-8417-6845B125ACCF@ericsson.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 16 Jun 2022 11:41:06 -0700
Message-ID: <CAPDSy+4LOLHwmBmGXmrRe-VfmeJ8CWNEG-hQs2cj1qvHChhabg@mail.gmail.com>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-masque-h3-datagram@ietf.org" <draft-ietf-masque-h3-datagram@ietf.org>, "masque-chairs@ietf.org" <masque-chairs@ietf.org>, MASQUE <masque@ietf.org>, Christopher Wood <caw@heapingbits.net>
Content-Type: multipart/alternative; boundary="000000000000b33a1f05e194fbe3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/jHl7SEKdnLXqcRBS2W3S0U67Q4o>
Subject: Re: [Masque] Zaheduzzaman Sarker'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: Thu, 16 Jun 2022 18:41:22 -0000

Hi Zahed,

Thanks for confirming. Since we already reference RFC 9114, I don't think
the additional reference would add much clarity, and it would make the text
less readable. So I'd prefer to leave it as-is.

David

On Thu, Jun 16, 2022 at 11:26 AM Zaheduzzaman Sarker <
zaheduzzaman.sarker@ericsson.com> wrote:

> Hi David,
>
> You are not missing something. But think I am missing a pointer to H3
> "connection error” - that is a reference to section 8 of RFC 9114. I am
> thinking if someone reads the spec who is not seasoned in QUIC and H3
> definitions, then it will help to hit the reference and get the proper
> interpretation of “treat as an HTTP/3 connection error of type
> H3_DATAGRAM_ERROR (0x33)”.
>
> But this is just an editorial suggestion.
>
> //Zahed
>
> On 16 Jun 2022, at 18:35, David Schinazi <dschinazi.ietf@gmail.com> wrote:
>
> Hi Zahed,
>
> I'm confused. “treat as an HTTP/3 connection error of type
> H3_DATAGRAM_ERROR (0x33)” is very clearly defined in QUIC and HTTP/3 - it's
> a connection error, not a stream error. Additionally, there is no stream
> involved at the stage of the processing path that leads to this error, so
> it is not possible for an implementer to do it wrong. Am I missing
> something?
>
> David
>
> On Thu, Jun 16, 2022 at 2:27 AM Zaheduzzaman Sarker <
> zaheduzzaman.sarker@ericsson.com> wrote:
>
>> Thanks for addressing my comments.
>>
>> One reflection inline.
>>
>> //Zahed
>>
>> On 16 Jun 2022, at 02:02, David Schinazi <dschinazi.ietf@gmail.com>
>> wrote:
>>
>> Thanks for your comments, Zahed!
>> Responses inline.
>> David
>>
>> On Wed, Jun 15, 2022 at 1:25 PM Zaheduzzaman Sarker via Datatracker <
>> noreply@ietf.org> wrote:
>>
>>> - Section 2 : should it be HTTP/1.x instead of HTTP/1 :-)?
>>>
>>
>> Agreed, fixed in this commit:
>>
>> https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/commit/e9922855baf774abed3612dc26bcb22145e1ad9f
>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1a8332a43397eb6d&q=1&e=6c7a336f-be95-4a3e-bfb3-ab5aae69ee31&u=https%3A%2F%2Fgithub.com%2Fietf-wg-masque%2Fdraft-ietf-masque-h3-datagram%2Fcommit%2Fe9922855baf774abed3612dc26bcb22145e1ad9f>
>>
>>
>>> - Section 2 : it says
>>>
>>>            "value MUST be treated as an HTTP/3 connection error of type
>>>            H3_DATAGRAM_ERROR (0x33)"
>>>
>>>      does this mean request stream MUST be aborted as it was also
>>> written in
>>>      the section?
>>>
>>
>> The text you're referring to discusses what to do when Quarter Stream ID
>> >= 2^60.
>> When that happens, multiplying the Quarter Stream ID by four would result
>> in an
>> invalid stream ID, so it is impossible to abort that stream. That's why
>> we close the
>> entire connection.
>>
>> Right, that is the behaviour we want. However, it is not obvious if we
>> just state “ treat as an HTTP/3 connection error of type H3_DATAGRAM_ERROR
>> (0x33)” as it seems H3_DATAGRAM_ERROR can result in both stream termination
>> and connection termination. I think we should be explicit about terminating
>> the connection or refer to section 8 of RFC9114 for definition of
>> "connection error".
>>
>>
>> - Section 3 in general : I think we can be specific that "intermediaries"
>>> are
>>> HTTP intermediaries as defined in HTTP semantic , as it is done in the
>>> draft-masque-connect-udp?
>>>
>>
>> Agreed, fixed in this commit:
>>
>> https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/commit/7328c4fdc84aedd6a69ebfd0fe2df711cad571e7
>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4c3b00f8a1770c3f&q=1&e=6c7a336f-be95-4a3e-bfb3-ab5aae69ee31&u=https%3A%2F%2Fgithub.com%2Fietf-wg-masque%2Fdraft-ietf-masque-h3-datagram%2Fcommit%2F7328c4fdc84aedd6a69ebfd0fe2df711cad571e7>
>>
>>
>>
>>
>