Re: [Masque] Zaheduzzaman Sarker's Discuss on draft-ietf-masque-connect-udp-14: (with DISCUSS and COMMENT)

[David Schinazi <[e-mail]>]

Hi Zahed,

Thank you for your review!

Regarding the DISCUSS point, I totally agree with you, this was an
oversight on my part. I'm fixing it in this PR:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/pull/178
Could you please take a look and let me know if it addresses your DISCUSS
fully?

I'll address the COMMENT portion of your review in a subsequent PR and I'll
reply here when that's ready.

Thanks,
David

On Wed, Jun 15, 2022 at 9:47 AM Zaheduzzaman Sarker via Datatracker <
[e-mail]> wrote:

> 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.
>
>
>
>