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

[Hyunsik Yang <[e-mail]>]

Hello Bron,

Thank you for reviewing the document.
Based on your comments, we reviewed and revised the document for the use of requirement-level terminology.
The modifications will appear in the -11 draft revision.

Please let us know if you recommend any additional changes.

Thank you.
Best regards,

-----Original Message-----
From: Bron Gondwana via Datatracker <[e-mail]> 
Sent: Wednesday, November 26, 2025 12:43 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: draft-ietf-avtcore-rtp-haptics-09 ietf last call Artart review

Document: draft-ietf-avtcore-rtp-haptics
Title: RTP Payload Format for Haptics
Reviewer: Bron Gondwana
Review result: Ready with Nits

I am the ARTART reviewer for draft-ietf-avtcore-rtp-haptics.

Thanks to the authors for this document. I found it quite clear and easy to follow.

I suspect I was chosen for this particular documents because I've managed to become some kind of defacto date-time field reviewer!

Timestamps:

So I looked at that first.  There are 10 mentions of "timestamp" in the document, some of which are a 16 bit "timestamp offset".

There is this definition is this in section 5.1:

   TimeStamp (TS): 32 bits.  A timeStamp representing the sampling time
   of the first sample of the MIHS unit in the RTP payload.  The clock
   frequency MUST be set to the sample rate of the encoded haptic data
   and is conveyed out-of-band (e.g., as an SDP parameter).

I did some searching in RFC3550 and found:

5.1 RTP Fixed Header Fields

   timestamp: 32 bits
      The timestamp reflects the sampling instant of the first octet in
      the RTP data packet.  The sampling instant MUST be derived from a
      clock that increments monotonically and linearly in time to allow
      synchronization and jitter calculations

So this "timestamp" is actually just an internal clock for the stream and has no fixed relationship to a date-time.  This looks like it's using RFC3550 as designed and has no date-time considerations.

I did do some other review as well:

Section 6.1 says: 

"The receiver MUST ignore any parameter unspecified in this memo."

I have seen similar documents say "MUST ignore any parameter it does not understand" or similar, something which anticipates that it will likely be extended in future.

I guess it doesn't matter because the future spec will "updates" this one, but that language seemed unnecessarily prescriptive to me.  The intent of "ignore the fields not defined the in specs that you implement" is important and good.

Section 7 says:

"The clock rate in the "a=rtpmap" line MAY be any sampling rate, typically 8000."

I don't believe that should be a capital MAY - the definition of MAY in RFC2119 is:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

This does not appear to be one of those.

In fact, it's worth reviewing this whole document for excessive use of capitalised RFC2119 words, e.g. in section 9, we see:

                                                        "Additionally,
   misusing the functionalities of actuators (such as force, position,
   temperature, vibration, electro-tactile, etc.)  MAY pose a risk of
   harm to the user,

I suspect the authors aren't intentionally suggesting that vendors can optionally include "risk of harm to the user" functionality.