From nobody Thu Jun 16 05:41:09 2022 Return-Path: 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 7F0F9C14CF00; Thu, 16 Jun 2022 05:41:06 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 Axm3aJ86POt4; Thu, 16 Jun 2022 05:41:02 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 1612EC14F6E7; Thu, 16 Jun 2022 05:41:02 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:1c88:e8ae:82ba:5180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id D93ED1F09C0; Thu, 16 Jun 2022 15:40:44 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1655383244; bh=g/BkK8udyuuhDcxhJrIx1liwtF+V2yGWrkaODrYimgo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=zGJOGyAwrZdCUUHZS2EgXkBatG0YnXiIdJtMJ6X2tD4eKdx+VrwtB3PfTzrItGLIE Md/cYPWPXgoHAOpaGXYDNBtDeCh2HJn/fWFG82TKjHLIkbQuRYTHZkwvFuPZZybW32 OCmqASxckoEawA70ab/toHjvHYgBwnQKvBYCmtAw= Content-Type: multipart/signed; boundary="Apple-Mail=_C36C2E2C-C565-4353-8A53-F78E37E1F5F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) From: Lars Eggert In-Reply-To: <165376042188.7925.12885270916317718696@ietfa.amsl.com> Date: Thu, 16 Jun 2022 15:40:43 +0300 Cc: General Area Review Team , draft-ietf-masque-connect-udp.all@ietf.org, last-call@ietf.org, masque@ietf.org Message-Id: <0AEE111A-99EB-48AF-AF58-B92A21C6C5A8@eggert.org> References: <165376042188.7925.12885270916317718696@ietfa.amsl.com> To: Christer Holmberg X-MailScanner-ID: D93ED1F09C0.A55F4 X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Gen-art] Genart last call review of draft-ietf-masque-connect-udp-12 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2022 12:41:06 -0000 --Apple-Mail=_C36C2E2C-C565-4353-8A53-F78E37E1F5F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Christer, thank you for your review. I have entered a No Objection = ballot for this document. Lars > On 2022-5-28, at 20:53, Christer Holmberg via Datatracker = wrote: >=20 > Reviewer: Christer Holmberg > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-masque-connect-udp-12 > Reviewer: Christer Holmberg > Review Date: 2022-05-28 > IETF LC End Date: 2022-06-08 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: The document is well written, and easy to read. However, I do = have > some comments (mainly editorial) that I would like the authors to = address. >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: >=20 > GENERAL: > -------- >=20 > QG_1: >=20 > The document contains a mix of "SHALL", "MUST", "SHALL NOT" and "MUST = NOT", but > I can't see any specifc pattern based on whether "SHALL (NOT)" or = "MUST (NOT)" > is used. >=20 > ABSTRACT: > --------- >=20 > QA_1: >=20 > The text says: >=20 > "This document describes how to proxy UDP in HTTP," >=20 > To me "proxy UDP in HTTP" sounds a little weird. Isn't "tunneling UDP = over > HTTP" more appropriate? That terminology is also used later in the = document. >=20 > (The same comment applies to "proxy TCP in HTTP") >=20 > Section 1: > ---------- >=20 > Q1_1: >=20 > The text says: >=20 > "While HTTP provides the CONNECT method (see Section 9.3.6 of = [HTTP]) > for creating a TCP [TCP] tunnel to a proxy, it lacks a method for > doing so for UDP [UDP] traffic." >=20 > I suggest to remove the "it lacks..." part, because the following = paragraph > says that the document defines such method. >=20 > Q1_2: >=20 > The text says: >=20 > "This protocol supports all versions of HTTP" >=20 > I think the text should say which is the latest supported, as there is = no > guarantee future versions of HTTP will be supported. >=20 > Section 1.1: > ------------ >=20 > Q1_1_1: >=20 > The txt says: >=20 > "Note that, when the HTTP version in use does not support = multiplexing > streams (such as HTTP/1.1), any reference to "stream" in this > document represents the entire connection." >=20 > I suggest to replace "Note that," with e.g., "In this document,", as = in the > paragraph above. >=20 > Section 2: > ---------- >=20 > Q2_1: >=20 > I suggest placing the example URIs after the requirements and = procedures for > creating the URL. >=20 > Q2_2: >=20 > The text says: >=20 > "If the client detects that any of the requirements above are not = met > by a URI Template, the client MUST reject its configuration and fail > the request without sending it to the UDP proxy. While clients > SHOULD validate the requirements above, some clients MAY use a > general-purpose URI Template implementation that lacks this specific > validation." >=20 > It sounds strange to say "MUST reject" while saying "SHOULD validate = but MAY > use a general-purpose URI Template implementation". >=20 > I suggest to say "SHOULD validate the URI Template and reject it if it = does not > fulfil the requirements above". >=20 > Section 3: > ---------- >=20 > Q3_1: >=20 > (This comment might apply to other parts of the document too) >=20 > The text says: >=20 > "To initiate a UDP tunnel associated with a single HTTP stream, > clients issue a request containing the "connect-udp" upgrade token." >=20 > I suggest to refer to a single entity for the procedure, i.e., = "client" instead > of "clients". >=20 > Section 3.1: > ------------ >=20 > Q3_1_1: >=20 > The text says: >=20 > "Upon receiving a UDP proxying request: >=20 > * if the recipient is configured to use another HTTP proxy, it will > act as an intermediary: it forwards the request to another HTTP > server. Note that such intermediaries may need to reencode the > request if they forward it using a version of HTTP that is > different from the one used to receive it, as the request = encoding > differs by version (see below). >=20 > * otherwise, the recipient will act as a UDP proxy: it extracts the > "target_host" and "target_port" variables from the URI it has > reconstructed from the request headers, and establishes a tunnel > by directly opening a UDP socket to the requested target." >=20 > It is unclear whether the rest of the Section text applies to both of = these > bullets, or only one of them. >=20 > Also, the "(see below)" part in the first bullet refers to the = following > Sections, but it is unclear. If refering to another section, I suggest = using > explicit Section references instead of "below". >=20 > Sections 3.2, 3.3, 3.4 and 3.5: > ------------------------------- >=20 > I suggest to use sub-sections, with e.g., the following structure: >=20 > 3.2. HTTP/1.1 Usage > 3.2.1. Request > 3.2.2. Response > 3.3. HTTP/2 and HTTP/3 Usage > 3.3.1. Request > 3.3.2. Response >=20 > Section 4: > ---------- >=20 > The text says: >=20 > "This protocol..." >=20 > What protocol? :) As this is the first sentence of the Section, please = be > specific. >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_C36C2E2C-C565-4353-8A53-F78E37E1F5F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmKrJMsACgkQVLXDCb9w wVfjExAAlaY+rWajjZD7djI3rMR+a0y+toZ5S6Xbi4VtQL7CuqMny5MqW1GyEvi8 ixCWnFjRO9PuRSls1QqO0roP/pWagwEWwfDmPNh8g1BGGPb2lKfmolr+Q/3z6lsZ ozsEdqwXWmzo+MtPeCsnkSDJpC47Lptz4bVuUMFpBw9xi/6JSFBWYLK+lBAwd1TW 5pK+xEOInVO6Ch+Sa2m7NsyTmkdkWm7yELbjkZrOCg2OR/pX6G7u4mfrm8WzfZem 6i01gOzQ6L2EaJr7uWW/7cO0SLGW1U56Fi2Abwjy6iqGTK19PrkOdies7GaR7on0 iW9LeC/PCixiwRMQ8ClFb39ei0abN+grcMJbsfu2W47PDZekjlKWvnuLMLaJmKKI ekpENAezxdSZYPLn/ittnDkyTOfj3ljfb4LoT4InZJ75QLjEgcsbto5AOZ0zjVXn Ktikfvmu+YQ2shJD4RRkPg5zzNuJCYe9HyGxsBpwtxicCpcSKsPEKxA5HL08BIXA UiJ0j5Ex8mQ2sb1TDEn+sS7ehTVpqg2KPuVdQTgcZFCtup6FcuECEXNQenuHph3b E5K2ZnghFAXeTXnAEIX0WF69I7zJ3LIycFJ6Nz7qHH1comOpoGMT7qnhqmvIdZwl twyfJvuFOBoC3wXgv+XqFLA/QzpVkDpPcUmYF8qYZNUqeZFh41Q= =f5yM -----END PGP SIGNATURE----- --Apple-Mail=_C36C2E2C-C565-4353-8A53-F78E37E1F5F7--