Subject: [Gen-art] draft-ietf-avtcore-rtp-haptics-09 ietf last call Genart review
From: Christer Holmberg via Datatracker <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 21 Nov 2025 03:09:12 -0800
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>

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