Reviewer: Olivier Bonaventure Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. I received this document from the viewpoint of the transport and have identified several parts that are unclear in the document. In section 4, you note " The SCIP payload size will vary considerably, especially during SCIP secure session establishment." Vary "considerably" is a vague statement. Given problems with PathMTU, it could be useful to discuss how MTU issues should be handled by SCIP implementations and whether you rely on fragmentation. You define an audio payload format and a video payload format. When the two formats are used together, are there RTP synchronization issues as described in section 3.3.4 or RFC8088 that need to be taken into account ? You only mention that clock rates of 8000Hz and 90000Hz SHALL be used for voice and video. The most important point is that the document should describe how applications will react in case of congestion. If there is a persistent congestion, does the application reduces its transmission rate or not ? Please refer to the following section of RFC8088 7.3. Congestion Control RTP and its profiles do discuss congestion control. There is ongoing work in the IETF with both a basic circuit-breaker mechanism [RFC8083] using basic RTCP messages intended to prevent persistent congestion and also work on more capable congestion avoidance / bitrate adaptation mechanism in the RMCAT WG. Congestion control is an important issue in any usage in networks that are not dedicated. For that reason, it is recommended that all RTP payload format documents discuss the possibilities that exist to regulate the bitrate of the transmissions using the described RTP payload format. Some formats may have limited or step-wise regulation of bitrate. Such limiting factors should be discussed. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
