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

[David Schinazi <[e-mail]>]

Thanks for the quick response Zahed.
I'll follow-up on the remaining comments on the separate email thread that
was created when you changed your ballot position.
David

On Thu, Jun 16, 2022 at 2:29 AM Zaheduzzaman Sarker <
[e-mail]> wrote:

>
>
> On 15 Jun 2022, at 19:30, David Schinazi <[e-mail]> wrote:
>
> 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
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-d0a88faca26025ce&q=1&e=85e9d057-dd5b-40f7-b156-3baab9c7ffa8&u=https%3A%2F%2Fgithub.com%2Fietf-wg-masque%2Fdraft-ietf-masque-connect-udp%2Fpull%2F178>
> Could you please take a look and let me know if it addresses your DISCUSS
> fully?
>
>
> This looks good enough to me. Based on this I will change my discuss
> ballot to no objection and will keep the comments so that we can follow up
> on those.
>
> Thanks.
>
> //Zahed
>
>
> 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.
>>
>>
>>
>>
>