[Gen-art] Re: draft-ietf-avtcore-rtp-haptics-09 ietf last call Genart review

[Hyunsik Yang <[e-mail]>]

Hello Christer,

Thanks for reviewing the draft.
Here are our comments — you can see our responses below.
We will submit a new version soon.
Thanks,
Best regards,
----------------------------------------------------------------------------------------------------------------------------------------------
Hello Christer,

Thanks for reviewing the draft.
Here are our comments — you can see our responses below.
We will submit a new version soon.
Thanks,
Best regards,

-----Original Message-----
From: Christer Holmberg via Datatracker <[e-mail]> 
Sent: Friday, November 21, 2025 6:09 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: draft-ietf-avtcore-rtp-haptics-09 ietf last call Genart review

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.

[HY] We added the following sentence in Section 6.2, and added text to SDP parameters with default values, to further clarify a default value should be inferred for those parameters. 
“Among the optional SDP parameters defined in this section, some parameters have a default value which SHOULD be inferred if the parameter is not present, unless an out-of-band agreement indicates a different value, as described in SDP consideration section.”

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.

[HY] We added a couple of sentences explaining the scope of this draft like below. 
Abstract: “It also provides SDP usage information for the haptics media type.”
Intro: “In addition, this document specifies the associated SDP parameters and SDP Offer/Answer considerations for the haptics media type.”

Q_GEN_3:

The draft does not define SDP BUNDLE considerations.

[HY] While haptic streams may in some cases be bundled with audio and video streams, we think that SDP BUNDLE considerations would be out of the scope of this draft.

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.

[HY] We added a sentence explaining the issue you mentioned, as shown below in Section 1. 
“This document does not specify synchronization (lip sync) mechanisms between haptics and audio/video components.”

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).

[HY] In Section 7, we added a sentence explaining the usage of optional parameters, as shown below. Parameter values, including string values, MUST be written without quotation marks ("") in SDP. We also added a sentence “Parameter values which are strings are not case sensitive and SHOULD be written in lowercase”, since we realized that this aspect was not covered previously.


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.

[HY] Thanks for catching this, we wrote _ver_ to appear in italics in HTML, but it appears that RTP payload RFC use a different pattern. So, we revised the text to align to this pattern (parameter: <newline>This parameter ….).

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.

[HY] Agreed, we changed the text to use “may” in lowercase, added “initial version of the MPEG Haptics Coding standard {{ISO.IEC.23090-31}}” in all description of values, and added default inferred values.

Q_6-2_3:

I think it would be useful to reference to specific version numbers, instead of saying "initial releases of the specifications".

[HY] Thanks. We revised the text to indicate the full name ISO/IEC 23090-31:2025 (based on https://www.iso.org/standard/86122.html)

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".

[HY] Thanks, we agree and revised the text to remove “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".

[HY] Thanks. We revised it.