Re: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00

[Xavier De Foy <[e-mail]>]

Thank you Stephan,

  It is our understanding that the specs are not entirely finalized yet (since there were last minutes changes accepted in the last meeting, which have consequences for streaming). We contacted our MPEG colleagues and will get back to you ASAP with the details once they update us on the status.

  If you agree, we can let the IETF community know tomorrow during the meeting that the FDIS specs will be made available soon. (And we will send you the FDIS ASAP to make it happen).

  Best Regards,

Xavier & Hyunsik


From: Stephan Wenger <[e-mail]>
Sent: Tuesday, November 7, 2023 8:02 PM
To: Hyunsik Yang <[e-mail]>; Xavier De Foy <[e-mail]>
Cc: IETF AVTCore WG <[e-mail]>; Spencer Dawkins at IETF <[e-mail]>
Subject: Re: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00

As a follow-up regarding the (unavailable 23090-31): please send theFDIS of the version you are citing to me, and I will make it available per the second paragraph of the section “Document access” of this page:https://www.iab.org/wiki/index.php/ISO_liaison_relationship<https://www.iab.org/wiki/index.php/ISO_liaison_relationship> (I mention                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

<https://us.report.cybergraph.mimecast.com/alert-details/?dep=tistzbn4vjRTYkgS1uFIQw%3D%3D7vGBQsQp58Kq2%2BdluJFxBrZnHzxQ3epb3a3N14DwfZqj33GgZyxcpDlXHMxLhm1mu23xl5GLJcaDwxmiRr1ntgwSxiVIJdm2B4e4Pfz6sXoFHg3cF0Gk1ZlZnCd2WHSNtGZsrf%2B8l2tWPni8M8CvZth%2Fj8m5B3wYPOBDdl7NrvVbgJaZt7OkIIPqOqhUXqJd2Ggs6gJlrNQsPUw2V5tCbsbJe7hhmyiehR3Wqnj%2FqHfQcxrVrMLBIbB%2BYzdbUCqPFPKctz6uF7ff%2Fb9QDtxTMAXPfnYegimN5WFVmzQJzp8Wb5mEL8qiQFymsSBwMVkYpOb7hlBjaJHjfaEBldKjRa4MRSdNORA0kZcu2mpzA30dWMQi8ySN5Yq0eRejLQ4h3SX%2FJmIEUI3MI%2BSmFOMau2QZl6gNEG3ch5xUjB0cQna4v6vY8lzYE%2BgwjdPwbu1DjTPicJC9f4WDJ7MiMmf24k2sNImmgoD0hSubthL3Em6whYWvCkjRhFwMNHFCDGY8RflbC93wqbZbFmKUg0obRoRayNoRXzYyFCURFh0YGrrnltoJcQQduye%2FiMbyXeYA3tRDhFovmw%2BfK25%2BLLgelUkywp2haArWO2w4Mnlvhrp%2Brwn4uLFF5Vk7n6PKqmPbS8y5xeL9n7k8FSKd%2FM4KfIkFJC4Mn7xJ2TkYlTf7b4ncw1Y96vYJC3Lr%2BOBbw1U6W%2FMe3VkrI7dkfs2Z9UUO6YuSyczfZSC38m3oWvL9K5Ph8ln9ZXazZXoj3fCq8y29F%2FI59UnWuqLdnKS6KvkzKClnoR3zrNjSaysFe5So4ICBsrlDXrec2gUCvKZ1TL98>
As a follow-up regarding the (unavailable 23090-31): please send the FDIS of the version you are citing to me, and I will make it available per the second paragraph of the section “Document access” of this page: https://www.iab.org/wiki/index.php/ISO_liaison_relationship<https://www.iab.org/wiki/index.php/ISO_liaison_relationship>
(I mentioned that FCD to Spencer, but that was in brain-fog.  It’s the FDIS or FDAM that we need for an approved ISO deliverable.)
Stephan

From: avt <[e-mail]<mailto:[e-mail]>> on behalf of Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 7, 2023 at 09:00
To: Hyunsik Yang <[e-mail]<mailto:[e-mail]>>, Xavier De Foy <[e-mail]<mailto:[e-mail]>>
Cc: IETF AVTCore WG <[e-mail]<mailto:[e-mail]>>
Subject: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00

Hi, Hyunsik and Xavier,


Thank you for submitting this draft to AVTCORE. I do have some suggestions, but overall, I think it's quite good. and very close to being adoption-ready.



Most of my suggestions are opportunities for clarifications.


Please feel free to ask for clarifications, or reply, on the AVTCORE mailing list.



Best,



Spencer


1.     One major point, but fortunately, it's only a process point you're addressing early - this spec uses [ISO.IEC.23090-31], which is not freely downloadable by just anyone. The good news is that Stephan Wegner, the IETF liaison manager for JTC1/SC 29, has experience with obtaining copies of JTC1/SC 29 specifications for reviewers - he told me you should send him the FCD, and he will distribute it to only those IETF people who have need to know.


1.     Nit: please expand acronyms on first use, especially in the Abstract, and especially "MIHS!"


1.     Nit: please update the Conventions section to reflect BCP14, and include RFC2119 and RFC8174 as a Normative References, as


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.


[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119<https://www.rfc-editor.org/rfc/rfc2119>>.


[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174<https://www.rfc-editor.org/rfc/rfc8174>>.


1.     In Section 3, terminology, this might be clearer:


This document uses the definitions of the MPEG Haptics Coding standard [ISO.IEC.23090-31]. Some terms from that document are provided here for convenience.


1.     For Section 4.1, please add "hmpg" to the Definitions section, with its expansion


1.     For Section 4.2, please add "independent", "sync", "dependent", "non-sync", "time-independent", and "time-dependent" to the Definitions section


1.      For Section 4.3, I'm puzzled by the use of SHOULD, for a new specification that hasn't been deployed. Upon reflection, I don't think the considerations in this section need to be normative at all. Here's my suggestion:


The following considerations apply for the streaming of MIHS over RTP:


If a media sender sets durations with the same value for all non-zero duration MIHS units between initialization MIHS units, this will make the decoder more robust to RTP packet loss.


If a media sender sends one, or a few, MIHS silent units at the beginning of a haptic silence, and does not send subsequent consecutive silent units, this will allow the sender and receiver to save network resources.


If a media receiver receives a MIHS silent unit, the receiver can assume that silence is intended until the reception of a non-silent MIHS unit. This will make the decoder more robust to RTP packet loss.


EDITOR'S NOTE: these considerations may need to be re-evaluated depending on the finalization of the haptics coding specifications in MPEG.


1.     For Section 5.2, each of the field descriptions includes both the description of the field, and language about the way different values are processed by the receiver. I suggest moving the language about processing to section 5.3. So, for example,


D (Dependency, 1 bit): this field is used to indicate whether the MIHS unit included in the RTP payload is, when its value is one, dependent (i.e., "non-sync") or, when its value is zero, independent (i.e., "sync"). In case of congestion, a receiver or intermediate node MAY prioritize independent packets over dependent ones, since the non reception of an independent MIHS unit can prevent the decoding of multiple subsequent dependent MIHS units.


would be split into


D (Dependency, 1 bit): this field is used to indicate whether the MIHS unit included in the RTP payload is, when its value is one, dependent (i.e., "non-sync") or, when its value is zero, independent (i.e., "sync").


in Section 5.2, and


In case of congestion, a receiver or intermediate node MAY prioritize independent packets over dependent ones, since the non reception of an independent MIHS unit can prevent the decoding of multiple subsequent dependent MIHS units.


1.     In Section 5.3, there's a mention of "aggregation". This would be clearer if the text said


Editor's Note: consider if it would be useful to add the ability to aggregate multiple MIHS units in a single RTP payload - for instance, to aggregate multiple MIHS units with different layer values into a single RTP payload.


1.     In Section 5.3, there's a figure that contains the payload structure type values. It would be good to also provide a figure that contains the MIHS Layer values, with a pointer from the description in Section 5.2.


1.     In Section 5.3.2, it would be good to point out that the use of MIHS Unit Fragmentation in RTP means that a media receiver can receive some fragments, but not other fragments, and the missing fragments would not be retransmitted by RTP. If there is any danger of an actuator behaving oddly because it interpreted a partial MIHS Unit Fragment, you might want to mention that, as guidance to implementers.


1.     In Section 6, is it correct to say


"This section specifies the optional parameters.described in [ISO.IEC.23090-31]"?


1.     In Section 6.1, I suggest moving this text to the end of Section 6:


The receiver MUST ignore any parameter unspecified in this memo.


1.     In Section 6.1, this looks a lot like an IANA Considerations section, but the information here is much abbreviated, compared to https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-haptics-05#name-subtype-registrations. Since Section 10, IANA Considerations, just says "see Section 6", I'd suggest adding all of the attributes used in those registrations, especially since https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-haptics-05#name-subtype-registrations says those registrations are also provided as examples. Alternatively, you could move the rest of Section 6 (including 6.1 and 6.2) into the IANA Considerations section, where IANA would be looking for what you want them to know, anyway.


1.     In Section 6.2 - I know this is going to be complicated, but I'll do my best. 🙃


My understanding - please correct me - is that most or all of these optional parameters are described in [ISO.IEC.23090-31], including values, and all that we're doing here is naming the parameters in a way that SDP would understand. So I THINK all that's required in this document, is to say (for example)


Corresponding parameter in [ISO.IEC.23090-31]

SDP Parameter Name

…

…

avatar type

hmpg-avtypes

…

…


If the IETF will not define new SDP parameters without a change to [ISO.IEC.23090-31], that should be about right. The other option would be to include values for each SDP parameter name from [ISO.IEC.23090-31], for the convenience of the reader.


If the IETF wants to use existing parameters that are already defined in [ISO.IEC.23090-31], we can update this RFC, or we could create an IANA registry for these parameters, with


Change controller: ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Haptic Coding)


HOWEVER, if the IETF wants to use NEW parameters that are defined in revisions to [ISO.IEC.23090-31], using an IANA registry for these parameters becomes much more appealing.


If the IETF ever decides to define new parameters that aren't already in a JTC1/SC 29/WG 7 specification, using an IANA registry is almost certainly the Right Thing To Do.


I note that our AD, Murray Kucherawy, is a backup Designated Expert for https://www.iana.org/assignments/media-types/media-types.xhtml<https://www.iana.org/assignments/media-types/media-types.xhtml>, and you're already talking to Stephan Wegner, the IETF liaison manager for JTC1/SC 29 about availability of [ISO.IEC.23090-31] for reviewers, I'm sure AVTCORE has the wisdom I lack, to work through all the details here!