I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call.
While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here.
And I found a couple of nits to be resolved together with any LC comments:
Sec 3.2 - Please update the citation to point to draft-ietf-mmusic-ice-dualstack-fairness-02.
Sec 3.4 -
"Third, using TCP only between the endpoint and its relay may result
in less issues with TCP in regards to real-time constraints, e.g. due
to head of line blocking."
This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP."
And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.
I have reviewed this document in preparation for IETF last call. It is in good shape and I have requested the last call.
While the last call is ongoing, I would like to double-check that this document (particularly Section 4) raises no new security considerations that should be documented in Section 6. I'm wondering if there are scenarios where a malicious application could try to game the priority scheme to some ill effect? draft-ietf-tsvwg-rtcweb-qos talks a bit about this, so I'm wondering if anything needs to be said here.
And I found a couple of nits to be resolved together with any LC comments:
"Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking."
This is awkwardly phrased. I would suggest something like "Third, using TCP between the client's TURN server and its peer may result in more performance problems (due to head-of-line blocking) than using UDP."
And one bit I left out — if text is to be added to reference draft-ietf-rtcweb-return, that should be done together with addressing nits and LC comments.