[Masque] Zaheduzzaman Sarker's No Objection on draft-ietf-masque-connect-udp-14: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-masque-connect-udp-14: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Based on this PR
(https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/pull/178), I
am clearing my discuss but keeping the comments (hopefully the author will
response to the comments as he promised :-)).

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.