Document: draft-ietf-avtcore-rtp-haptics Title: RTP Payload Format for Haptics Reviewer: Christer Holmberg Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-avtcore-rtp-haptics-09 Reviewer: Christer Holmberg Review Date: 2025-11-21 IETF LC End Date: 2025-12-01 IESG Telechat date: Not scheduled for a telechat Summary: The draft is well written, and in general easy to read. However, I do have a number of questions and issues, mostly related to SDP, that I would like the authors to address. Major issues: GENERAL: -------- Q_GEN_1: The draft says that the new parameters are OPTIONAL, but if a parameter is not present Section 7.1 defines which default value SHOULD be used. So, while it may be optional to explicitly include the parameters in SDP, my understanding is that it is still mandatory to support them, and assume the default value if they are not present in SDP. Or? I think it would be useful to clarify that. Q_GEN_2: I think the Abstract and/or Introduction should also mention that the draft defines the SDP and SDP O/A considerations for the haptics media type. Q_GEN_3: The draft does not define SDP BUNDLE considerations. Q_GEN_4: here is nothing regarding "lipsync" between haptics and audio/video. If that is outside the scope, perhaps it would be useful to indicate that. SECTION 6.2: ------------ Q_6-2_4: While it can be seen in the SDP examples, I think it would be useful to explicitly state that the parameter values (including string values) are used without quotation marks in SDP. There are examples from the past where different vendors have had different interpretations regarding that, which has caused interoperability problems. (Perhaps this belong to Section 7). Minor issues: SECTION 6.2: ------------ Q_6-2_1: In the text, optional parameter names are used with underscores (e.g., "_ver_"), but they are not used in the SDP. Is this some new way in IETF to define parameters? If not, I suggest to remove them. Q_6-2_2: For many of the parameters, there is text saying "is a string which MAY in the initial release of the specifications hold values among". Since this draft does not define those values, I don't think the use of capital letter MAY is correct. I suggest something like: "The initial release of the specifications define the following values for the parameter: X, Y, Z". Or something like that... In addition, it would be good to indicate whether or not there is a default value if the parameter is not present. Q_6-2_3: I think it would be useful to reference to specific version numbers, instead of saying "initial releases of the specifications". SECTION 7.1: ------------ Q_7-1_1: The text says: "The receiver properties expressed using the SDP parameters 'ver','profile' and 'lvl' have a mandatory character, since they represent implementation capabilities." It is unclear to me what is meant by "mandatory character". Nits/editorial comments: SECTION 7: ---------- Q_7_2: The text says: "The clock rate in the "a=rtpmap" line MAY be any sampling rate, typically 8000." The capital letter MAY is strange. I think you should use "can" or "may". _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
