[Masque] Zaheduzzaman Sarker's Discuss on draft-ietf-masque-connect-udp-14: (with DISCUSS and COMMENT)
Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> Wed, 15 June 2022 16:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: masque@ietf.org
Delivered-To: masque@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E6EC1594A8; Wed, 15 Jun 2022 09:47:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-masque-connect-udp@ietf.org, masque-chairs@ietf.org, masque@ietf.org, ekinnear@apple.com, ekinnear@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
Message-ID: <165531164435.17461.6838948810178516092@ietfa.amsl.com>
Date: Wed, 15 Jun 2022 09:47:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/jwDJ2-_e4EzHI_MIVHzKs3kVRNQ>
Subject: [Masque] Zaheduzzaman Sarker's Discuss on draft-ietf-masque-connect-udp-14: (with DISCUSS and COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
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 16:47:24 -0000
Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-masque-connect-udp-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is I think simply a oversight but I am putting a discuss so that this certainly gets addressed before the document proceeds to the next stage. Section 3.2 does not say what happens when the requirements are not met. There must be guidance on what to do in that case like there are in section 3.3, 3.4 an 3.5. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks a lot for working on this specification. I think this specification will be very useful. I don't have other major issues other than mentioned in the discuss points. Below are some comments which I believe will improve the document if addressed. - Section 3: s/pct-encoding/percent-encoding and would be good to add a reference to pct-encoding (https://datatracker.ietf.org/doc/html/rfc3986) - Section 3.1: it took a bit of time for me to understand if we are redefining the "intermediaries" here again. We have already described what is an intermediary in the context of this document. Hence, I would suggest that we just write - if the recipient is an intermediary, it forwards .... - Section 3.1: what exactly "fail the request" means? is it only a notification to some waiting processes/methods or sending the error message or both? can we be more specific here? - Section 5 : reference to the QUIC DATAGRAM frame would be nicer. - Section 5 : it says - "Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527 using Context ID zero. An endpoint that receives a DATAGRAM capsule using Context ID zero whose Payload field is longer than 65527 MUST abort the stream. " I assume the HTTP Datagram and a DATAGRAM capsule is referring to the same thing, but this is confusing. Can use HTTP DATAGRAM in the second sentence as well? The DATAGRAM capsule kind of appeared in this section all on a sudden. In this section to me it seems HTTP DATAGRAM and DATAGRAM capsule is interchangeably used, if I am correct then I think it is worth mentioning this for the sake of better understanding. - Section 5 : it says "If a UDP proxy knows it can only send out UDP packets of a certain length due to its underlying link MTU, it SHOULD discard incoming DATAGRAM capsules using Context ID zero whose Payload field is longer than that limit without buffering the capsule contents." It is not clear why "SHOULD" is used here? what are the other option the UDP proxy has in this case? - Section 3.6: if this section should be removed then [STRUCT-FIELD] must not be in the normative section, actually should be removed from the references. Either at this stage of this document we can remove this section or we can add a note to remove normative reference when this section is removed.
- [Masque] Zaheduzzaman Sarker's Discuss on draft-i… Zaheduzzaman Sarker via Datatracker
- Re: [Masque] Zaheduzzaman Sarker's Discuss on dra… David Schinazi
- Re: [Masque] Zaheduzzaman Sarker's Discuss on dra… Zaheduzzaman Sarker
- Re: [Masque] Zaheduzzaman Sarker's Discuss on dra… David Schinazi