Re: [Gen-art] Genart last call review of draft-ietf-quic-http-32

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 02 December 2020 16:00 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7973A1474; Wed, 2 Dec 2020 08:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuTrilTf8Oj8; Wed, 2 Dec 2020 08:00:21 -0800 (PST)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF2B3A157B; Wed, 2 Dec 2020 08:00:16 -0800 (PST)
Received: by mail-ej1-x632.google.com with SMTP id 7so5174025ejm.0; Wed, 02 Dec 2020 08:00:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kC5Mf7hukBibQXczbnCeVFvXr8J1N2TptUr1PM3Obwo=; b=LnF23xhbgzaX0w6DA9VapOa0ML04yQqTbZgsEYuarxQjDZZnX0ZiwOg3jfDfHSaJ1v UH9JCCSVQPXMXUyODtcp/4nBZPBJhJiE4Gzzs6BQQJf1Bh21RAYDIQQnmAW9JuYUVBsN CZZVEQSGod3PmNqPbzzX2UC7ufVzOEt2jEaCl7p0c8FZZGuQlTaLKKD82qfcvZ/TP4g1 t7vAOBFJt1MccS71Py4/IYepCE3GENgd2s9QUxM6dYXTIf0AYIhZ5HG+/JUWxuv8rWFV rHEDV/7h8K0pbRK5Iz//nhAWsW8AOtPYlOgeKpmNgqr56Cl+6NPNlsBhCnfCk9mterv2 aRdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kC5Mf7hukBibQXczbnCeVFvXr8J1N2TptUr1PM3Obwo=; b=quqG7gCrzOcshMAX3IAx7kjcG2JSA26jeeHeqQuI2rU5tEbsHtqB4pSM3XXoXKr/Rg 1DNz1tu6Y1tXKKZAUcz1km1i7214tCSrGb+QQXfLG8b4WS5Um/W9rHMUgtmTKA7AJt6/ QRBucUaX8mQ9gM3PHmeo95cll/wwyVDJgcjP+ZZO5HDnTwUUNO1ehogm1e/QFlCB9R5h zfLJ5IaljDq4s47ZteaVKnKZR00uJ9vz4KMXkK3QalmOJ43U3jxVelkDBO5lRx8mD7Jx rw15bri5FgER/exXXwLOkZHfCQ96ClR7CUo2J7PPFdzAQbp25UgEzFil8gLB5SdPlidG xpdg==
X-Gm-Message-State: AOAM530DD77oLbBe76ISr1TUssrpQW8+e+UIlH4/m3WZJw2ET1RgpRHg GZHc/zzCxX3ZkaATWjiiHhsvAO8gsn/r/gzOnPI=
X-Google-Smtp-Source: ABdhPJw1X+Mpd4QXS5KebWBxCHmEMHD3ZlWyYoyP1GLnHZwkoW1ZAMyocJhoXC8KrvMyR2chWDGK/7dDls4lA8MQ/Ac=
X-Received: by 2002:a17:906:c006:: with SMTP id e6mr427378ejz.374.1606924809630; Wed, 02 Dec 2020 08:00:09 -0800 (PST)
MIME-Version: 1.0
References: <160546479248.16558.8887543649783073280@ietfa.amsl.com> <CALGR9oZ0cUdfk4+DoKa21hZ+KFu6=Zpf-_j-JKBOkHkp9RGw+g@mail.gmail.com>
In-Reply-To: <CALGR9oZ0cUdfk4+DoKa21hZ+KFu6=Zpf-_j-JKBOkHkp9RGw+g@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 2 Dec 2020 15:59:57 +0000
Message-ID: <CALGR9oYNqa3D+R3xXfwEbyhpBkBRFx5s2xBJKwX5tVDXyuGpdw@mail.gmail.com>
To: Theresa Enghardt <ietf@tenghardt.net>
Cc: gen-art@ietf.org, QUIC WG <quic@ietf.org>, last-call@ietf.org, draft-ietf-quic-http.all@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="000000000000757aee05b57d563c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/XqmTUj1rLCAuE_CiUeP-AJPgVYY>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-quic-http-32
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 16:00:26 -0000

Hello

As mentioned previously, review comments raised during the genart http
review were captured as issues on the QUIC WG GitHub repository. These
issues have been assessed by the document editor(s) and shepherd, please
see each individual issue for more-specific discussion. As a summary, the
following resolutions for issues are:

Addressed via Pull Request, changes will appear in the next I-D
=======================================================
https://github.com/quicwg/base-drafts/issues/4352
  - https://github.com/quicwg/base-drafts/pull/4384
https://github.com/quicwg/base-drafts/issues/4351
  - https://github.com/quicwg/base-drafts/pull/4383
https://github.com/quicwg/base-drafts/issues/4353
  - https://github.com/quicwg/base-drafts/pull/4383
https://github.com/quicwg/base-drafts/issues/4354
  - https://github.com/quicwg/base-drafts/pull/4383
https://github.com/quicwg/base-drafts/issues/4355
  - https://github.com/quicwg/base-drafts/pull/4383
https://github.com/quicwg/base-drafts/issues/4356
  - https://github.com/quicwg/base-drafts/pull/4383

To be addressed by a Pull Request
=================================
https://github.com/quicwg/base-drafts/issues/4357
https://github.com/quicwg/base-drafts/issues/4358


Kinds regards
Lars and Lucas
QUIC WG Co-chairs

On Sun, Nov 15, 2020 at 7:02 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hi Theresa,
>
> Thanks for the review! Since the QUIC WG uses a Github Workflow I've
> created a separate issue for each of the items in your review and tagged
> you in it, see in-line responses for the precise issue link. All issues are
> track in the milestone https://github.com/quicwg/base-drafts/milestone/9
>
> We'd appreciate it if you could coordinate with the HTTP document editor
> via GitHub, on the issue itself and/or any Pull Request that might be
> raised to address your comments.
>
>
>
> On Sun, Nov 15, 2020 at 6:26 PM Theresa Enghardt via Datatracker <
> noreply@ietf.org> wrote:
>
>> <snip>
>>
>> Minor issues:
>>
>> The document defines "stream" as a QUIC stream, but then also uses the
>> term
>> "HTTP/3 stream". Perhaps it's worth defining "HTTP/3 stream" explicitly,
>> in
>> analogy to "HTTP/3 connection". Perhaps it's worth defining "message", too
>> (this is only an HTTP concept, correct?).
>>
>> The document should make sure it clearly distinguishes terms and concept
>> of
>> QUIC vs. of HTTP/3 in all cases. In particular, what is the relationship
>> between HTTP/3 frames and QUIC frames? It's important to make their
>> difference
>> and relationship explicit, as the document uses several other terms
>> interchangeably between HTTP/3 and QUIC, like "connection" and perhaps
>> "stream".
>>
>
> https://github.com/quicwg/base-drafts/issues/4351
>
>
>>
>> The concepts around error codes is not entirely clear to me, e.g.,
>> H3_REQUEST_INCOMPLETE or H3_NO_ERROR - Are these a separate concept from
>> HTTP
>> response status codes such as "200 OK" and "404 Not Found", etc.? Are
>> these
>> error codes related to QUIC errors? Is the "application error code"
>> mentioned
>> in Section 5.3 the same concept or is it a different concept? Is the
>> "application error code" an HTTP/3 concept of a QUIC concept? Is
>> "connection
>> error" used in Section 7 the same concept or is it a difference concept?
>> Does a
>> "connection error" as used in Section 7 always mean that the entire
>> connection
>> fails, as opposed to a single stream? Section 8 aims to explain some of
>> these
>> concepts, and I think the document should reference to this section for
>> more
>> information when it starts mentioning all these different error types.
>> (Or, if
>> they are all the same, perhaps the terminology should be unified.)
>>
>
> https://github.com/quicwg/base-drafts/issues/4352
>
>
>>
>> Section 4.1.1.
>>
>> "HTTP messages carry metadata as a series of key-value pairs, called HTTP
>> fields." Are these the same as HTTP headers and trailers? Or are HTTP
>> fields a
>> more general concept? Are they also allowed in bodies?
>>
>
> https://github.com/quicwg/base-drafts/issues/4353
>
>
>> Section 4.1.1.3
>>
>> "because this limit is applied at each hop," ...
>> What is a hop in the context of HTTP? I think it's worth at least briefly
>> introducing this concept to make things clearer, as the document includes
>> many
>> different concepts from different layers.
>>
>
> https://github.com/quicwg/base-drafts/issues/4354
>
>
>> Section 4.1.2
>>
>> "Automatically retrying such requests is
>>    not possible, unless this is otherwise permitted (e.g., idempotent
>>    actions like GET, PUT, or DELETE)."
>> Retrying is "not possible" means it's prohibited? Is there a reference to
>> the
>> exceptions to that rule, e.g., a list of actions that are considered
>> idempotent? If so, please provide a reference.
>>
>
> https://github.com/quicwg/base-drafts/issues/4355
>
>
>> Section 4.2
>>
>> "A proxy that supports CONNECT establishes a TCP connection […]"
>> Is this necessarily always TCP, not QUIC? Can this change in the future?
>>
>
> <http://goog_722064023>
> https://github.com/quicwg/base-drafts/issues/4356
>
>
>> Section 5.1
>>
>> "HTTP/3 implementations will need to open a new HTTP/3
>>    connection for new requests if the existing connection has been idle
>>    for longer than the server's advertised idle timeout"
>> Only the server's timeout? Does "implementations" here mean only clients?
>>
>
> https://github.com/quicwg/base-drafts/issues/4357
>
>
>>
> Section 6.2
>>
>> "However, stream types that could modify the state or
>>    semantics of existing protocol components, including QPACK or other
>>    extensions, MUST NOT be sent until the peer is known to support them."
>> Is there a defined list of stream types that are not allowed to be used?
>> If so,
>> please provide a reference.
>>
>> Is section 6 missing the request stream? It has subsections for Control
>> Streams
>> and Push Streams, but then Section 7 says that Request Stream is also a
>> stream
>> type.
>>
>
> <http://goog_722064019>
> https://github.com/quicwg/base-drafts/issues/4358
>
> Kind regards,
> Lucas
> QUIC WG Co-chair
>