Hi Al,
Thank you for the detailed review! I've written up a PR to address your comments:
More detailed comments inline.
Thanks,
David
On Tue, May 31, 2022 at 3:35 PM Al Morton via Datatracker <noreply@xxxxxxxx> wrote:
I found this paragraph confusing (which doesn't mean it is incorrect, just that
someone with limited background read the section 2 requirements list, all
MUSTs, and then the paragraph below, which seems to have a conflicting MUST
with the SHOULD and MAY that follows). Help readers like me understand the
options you are allowing here:
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.
I see that Christer's GEN_ART review picked-up on this too (I looked after I
was done...).
Let's move this discussion point to the GENART thread to avoid duplication.
The fact that you both found it unclear is additional evidence that this could be
improved, but I'd love a textual suggestion if you have one.
In Section 5, there seems to be a possible operations issue for proxy operators:
Clients MAY optimistically start sending UDP packets in HTTP
Datagrams before receiving the response to its UDP proxying request.
However, implementors should note that such proxied packets may not
be processed by the UDP proxy if it responds to the request with a
failure, or if the proxied packets are received by the UDP proxy
before the request.
This seems like a good place to limit the amount of optimistic traffic, given
that the request is not yet accepted. (also, would the optimistic traffic use
Context ID zero?)
That's good advice, I've added the following to that paragraph:
If a UDP proxy receives such a proxied
packet before it has received the corresponding request, it SHALL either drop
that HTTP Datagram silently or buffer it temporarily (on the order of a round
trip). Additionally, UDP proxies that buffer such packets SHOULD limit the
amount they are willing to buffer to avoid memory exhaustion.
packet before it has received the corresponding request, it SHALL either drop
that HTTP Datagram silently or buffer it temporarily (on the order of a round
trip). Additionally, UDP proxies that buffer such packets SHOULD limit the
amount they are willing to buffer to avoid memory exhaustion.
And yes, proxied UDP uses context ID zero as specified by the paragraph above.
In
6. Performance Considerations
UDP proxies SHOULD strive to avoid increasing burstiness of UDP
traffic: they SHOULD NOT queue packets in order to increase batching.
This requirement is written qualitatively, so users might "know a violation if
they see it", but not hold the proxy system/operator to any specific
performance without providing more details here. Inter-packet delay variation
measurements on proxy ingress and egress would characterize increased
burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased
burstiness will be avoidable, or enforceable.)
I think it makes sense for this requirement on proxies to be a normative SHOULD,
even though it's both qualitative and unenforceable by clients. It fits within the bounds
of what RFC 2119 mandates.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
