RTP Payload Format for Haptics
draft-ietf-avtcore-rtp-haptics-13

draft-ietf-avtcore-rtp-haptics has a set of IESG review comments, which ought to be addressed. For ease of tracking these are listed here, but the complete original set can be found in the data tracker. Please let me know, as responsible AD how you wish to proceed with each of these.

>> 1. IANA

I think the IANA considerations should be moved into the
IANA considerations section.

It is quite unusual to have a IANA considerations section simply pointing to other sections. I am not sure whether it helps IANA. Please move the text from section 6.1 into section 10, and if necessary include a reference to point back to section 6.1. etc.

>> 2. Textual

196   ...  Both
197   quantized and descriptive data can be encoded in a human-readable
198   exchange format based on JSON (.hjif) ...

Just my opinion after squinting at unreadable JSON thousands of times,
but I think the contrast between hjif and hmpg is that hjif is "text-based"
or "text-encoded" rather than being binary encoded.

>> 3. MHIS

This acronym is expanded several times, only one is enough ;-)

>> 4.  Abstract

s/This memo describes/This memo *specifies*/ as this draft is a proposed standard.

>> 5.  Section 1

s/This document describes/This document *specifies*/ as this draft is a proposed standard.

>> 6. Section 3

Please expand `hmpg`

>> 7. In Section 5.1 - Is there a specific value for the "Payload type" field ?

>> 8. Section 5.2 -Please follow the IESG statement, https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, about the "SHOULD”.

Please add a sentence to explain the consequences of NOT following the recommendation.

>> 9. Section 5.3.2

Just curious about the consequence of missing two FUs: one with FUE then one with FUS... i.e., two fragmented units appearing as a single fragmented units.

Should there be text about this specific case ?

>> 10. Section 5.4

This section is about `Transmission` but also contains `If a media receiver receives`; should the section title be modified accordingly ?

>> 11.  Section 6.2

This section as a lot of default value with a `SHOULD`; why not a "MUST" ? What are the consequences of selected another default ? (see above).

>> 12.  Security

Section 9, para 3:  While RFC7201 does give options to an application developer for security mechanisms, it is a bit old at this point.  Most of the options listed have migrated to stronger versions.  For example TLS1.2 (RFC 5246) is on the verge of obsolescence.  BCP 195 (includes RFC 9325 and eventually draft-ietf-uta-require-tls13) provides the most current guidance for using the (D)TLS protocols.  For IPsec, RFC 4301 is an architecture specification, the actual protocols are RFC 4303 and RFC 7296.  I wouldn't recommend putting all of this in the draft. 

I do think that there needs to be a statement that 'appropriate, current, strong security mechanisms' with a disclaimer that RFC 7201 is dated...  The easiest thing to point to is RFC 9325, if you want something specific.  I'm happy to help with the wording.

There were also two comments that you may like to address or comment upon:

>> Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

>> 3GPP Liason

I note from the shepherd's writeup about 3GPP study item being interested in this work and wanted to check if an liaison had been sent to the 3GPP to inform them of this document and asking for their review/inputs, as appropriate.

[Ballot comment]
Hi Hyunsik and Xavier,

Thank you for the discussion and patience with me.

The changes made in -11 vs. -13 [1] adequately address all the DISCUSS/COMMENTs raised in my previous ballot [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-avtcore-rtp-haptics-11&url2=draft-ietf-avtcore-rtp-haptics-13&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/avt/w524h5rU21XUMgJWnRSG7wmqGhA/

[Ballot comment]
Section 9, para 3:  While RFC7201 does give options to an application developer for security mechanisms, it is a bit old at this point.  Most of the options listed have migrated to stronger versions.  For example TLS1.2 (RFC 5246) is on the verge of obsolescence.  BCP 195 (includes RFC 9325 and eventually draft-ietf-uta-require-tls13) provides the most current guidance for using the (D)TLS protocols.  For IPsec, RFC 4301 is an architecture specification, the actual protocols are RFC 4303 and RFC 7296.  I wouldn't recommend putting all of this in the draft. 

I do think that there needs to be a statement that 'appropriate, current, strong security mechanisms' with a disclaimer that RFC 7201 is dated...  The easiest thing to point to is RFC 9325, if you want something specific.  I'm happy to help with the wording.

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-avtcore-rtp-haptics-09
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-haptics-09.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Many thanks to Bron Gondwana for the ARTART review.

## Comments

Thanks for the work on this document.

### IANA Considerations

Like Ketan and Eric, I think the IANA considerations should be moved into the
IANA considerations section.

### Textual

196   ...  Both
197   quantized and descriptive data can be encoded in a human-readable
198   exchange format based on JSON (.hjif) ...

Just my opinion after squinting at unreadable JSON thousands of times,
but I think the contrast between hjif and hmpg is that hjif is "text-based"
or "text-encoded" rather than being binary encoded.

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I have a few comments/suggestions to share.

1) As Eric, I wonder why the IANA actions are outside the IANA Considerations section. Please move (most of the?) contents from section 6.1 into section 10.

2) I note from the shepherd's writeup about 3GPP study item being interested in this work and wanted to check if an liaison had been sent to the 3GPP to inform them of this document and asking for their review/inputs, as appropriate.

[Ballot discuss]
Hi Hyunsik and Xavier,

Thank you for the effort put into this specification.

Thanks to Bo Wu for the OPSDIR review and to the authors for engaging.

Please find below some few points for DISCUSSion:

# Unit Type Extensibility

UT is encoded using three bits and ... all these values are used. This means that there is no available value for a future unit. Are we confident that there won’t be a need for a new unit type in the future?

Also, given the small set of values, is it worth to burn value “0” and not assign a meaning with it or at least tag it as unassigned and available for future assignment.

# Fragmentation unit

## Are there any constraints on the fields of Payload Header that carry fragment units? For example, does the same L value must be used for all fragments?

CURRENT:
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Payload Header | FU Header    |                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              |

## The text reasons about individual bits and not collective set, which leaves some cases unspecified. For example, for deterministic behavior, I suggest to make the text clear that setting simultaneously both FUS/FUE is not allowed and such packets are not valid.

CURRENT:
  FUS (Fragmented Unit Start, 1 bit): this field MUST be set to 1 for
  the first fragment, and 0 for the other fragments.

  FUE (Fragmented Unit End, 1 bit): this field MUST be set to 1 for the
  last fragment, and 0 for the other fragments.

# SDP Offer/Answer

CURRENT:
7.1.  SDP Offer/Answer Considerations

  When using the offer/answer procedure described in [RFC3264] to
  negotiate the use of haptic, the following considerations apply:

RFC3264 should be listed as normative given the normative dependency of this text and behavior right after.

# What is the rationale for the following:

CURRENT:
  Any receiver compliant with [ISO.IEC.23090-31] MUST accept any stream
  with a compatible version, profile and level. 

Unless I’m missing something, blindly accepting streams independent of available resources or local policies seems inadequate here.

[Ballot comment]
# Section 5.1

## contextualized fields

You may consider this change:

OLD:
  The RTP header is defined in [RFC3550] and represented in Figure 2.
  Some of the header field values are interpreted as follows.

NEW:
  The RTP header is defined in [RFC3550] and represented in Figure 2.
  Unless contextualized below, the meaning of the fields depicted in Figure 2 is the same as in Section 5.1 of [RFC3550].

## Use the field name as shown in Figure 2/defined in 3550

OLD:
  TimeStamp (TS): 32 bits.  A timeStamp representing the

NEW:
  Timestamp (TS): 32 bits.  A timestamp representing the

## Consider providing the description following the order of appearance in Figure 2. For example, M should be described first.

## Payload Type

CURRENT:
  Payload type (PT): 7 bits.  The assignment of a payload type MUST be
  performed either through the profile used or in a dynamic way.

How is that different from the 3550 definition?

      This field identifies the format of the RTP payload and determines
      its interpretation by the application.  A profile MAY specify a
      default static mapping of payload type codes to payload formats.
      Additional payload type codes MAY be defined dynamically through
      non-RTP means (see Section 3).  A set of default mappings for
      audio and video is specified in the companion RFC 3551 [1].  An
      RTP source MAY change the payload type during a session, but this
      field SHOULD NOT be used for multiplexing separate media streams
      (see Section 5.2).

# Sections 5.3.*: Padding

The figures show padding but that is not described in the narrative text. Please consider clarifying the use of padding in all relevant sections.

# Section 5.4: Acceptable behavior

CURRENT:
  decoder more robust to RTP packet loss.  If a sender sends MIHS units
  with high duration variations, the receiver MAY need to wait for a
  long period of time (e.g., the upper bound of the duration
  variation), to determine if a MIHS unit was lost in transmission.
  Whether this behavior is acceptable or not is application dependent.

Can this behavior be controlled by the application for the sake of better experience?

# Inappropriate use of normative language

There are several occurrences where I think the use of normative language is not justified. For example;

Section 5.4:
  Since, from a receiver standpoint, a missed MIHS unit MAY
  originate from a not-sent silent unit, or a lost packet,

Section 7:
  The OPTIONAL parameters (defined in Section 6.2), when present,…

Section 7.1:
  This parameter indicates
  whether silence suppression SHOULD be used, as described in
  Section 5.4. 

These should be updated to

Section 5.4:
  Since, from a receiver standpoint, a missed MIHS unit may
  originate from a not-sent silent unit, or a lost packet,

Section 7:
  The optional parameters (defined in Section 6.2), when present,…

Section 7.1:
  This parameter indicates
  whether silence suppression should be used, as described in
  Section 5.4. 

Cheers,
Med

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-avtcore-rtp-haptics-11
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### MHIS

This acronym is expanded several times, only one is enough ;-)

### Abstract

s/This memo describes/This memo *specifies*/ as this draft is a proposed standard.

### Section 1

s/This document describes/This document *specifies*/ as this draft is a proposed standard.

### Section 3

Should `hmpg` be expanded ?

### Section 5.1

Is there a specific value for the "Payload type" field ?

### Section 5.2

Please follow the IESG statement, https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, about the "SHOULD".

### Section 5.3.2

Just curious about the consequence of missing two FUs: one with FUE then one with FUS... i.e., two fragmented units appearing as a single fragmented units.

Should there be text about this specific case ?

### Section 5.4

This section is about `Transmission` but also contains `If a media receiver receives`; should the section title be modified accordingly ?

### Section 6.2

This section as a lot of default value with a `SHOULD`; why not a "MUST" ? What are the consequences of selected another default ?

### Section 10

It is quite unusual to have a IANA considerations section simply pointing to other sections. I am not sure whether it helps IANA.

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-avtcore-rtp-haptics-09. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the haptics namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

the existing registration for the 'hmpg' haptic subtype will have its template modified using the contents of Section 6.1 of the current document and have [ RFC-to-be ] added to the reference for the registration.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by OPSDIR Completed: Has Issues. Reviewer: Bo Wu. Sent review to list. Submission of review completed at an earlier date.

Request for IETF Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2025-12-01):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, draft-ietf-avtcore-rtp-haptics@ietf.org, gorry@erg.abdn.ac.uk, ietf@mariuskleidl.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for Haptics) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document: - 'RTP Payload
Format for Haptics'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-12-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This memo describes an RTP payload format for the MPEG-I haptic data.
  A haptic media stream is composed of MIHS units including a MIHS
  (MPEG-I Haptic Stream) unit header and zero or more MIHS packets.
  The RTP Payload header format allows for packetization of a MIHS unit
  in an RTP packet payload as well as fragmentation of a MIHS unit into
  multiple RTP packets.  The original subtype registration for haptics/
  hmpg, registered with IANA in RFC9695, did not include any required
  or optional parameters.  This memo updates RFC9695 and the haptics/
  hmpg registration to add optional parameters.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-haptics/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6232/

While reviewing the document I had two comments:

* The introduction seems to assume definitions that were in the abstract, specifically “MIHS” :
I suggest it might make reading easier to insert this sentence (taken form the abstract), or similar into the start of the introduction.
“ A haptic media stream is composed of MIHS units including a MIHS(MPEG-I Haptic Stream) unit header and zero or more MIHS packets.”

* To help a reader, maybe it is worth the introduction defining the common term: NAL unit.

I found one sentence hard to parse:

* In section 9, I read “This responsibility lays on anyone using RTP in an application. ”, which I think I agree with, but didn’t read correctly for me as English, is it possible to rephrase this sentence?

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The community showed interested in this document during the call for adoption, WG meetings and its last call.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No points were particularly controversial.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Citing from https://mailarchive.ietf.org/arch/msg/avt/D19cLYPBg0h-FCw_lQJGt1pYAoM/:

Currently we are aware of one implementation of the contents of the document, which is an internal implementation by InterDigital. We expect additional implementations to be developed in the future:

  *  One potential implementation could be an RTP extension to the 5G-MAG V3C Immersive Platform, which supports MPEG Haptics, and indicated a possibility to have an RTP plugin [1].
  *  Another driver for future implementations is the 3GPP support for haptics, with work started in a Release 19 study [2], which is expected to continue in future releases.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document defines an RTP payload format for MPEG-I haptic data, which is defined by the technical committee ISO/IEC JTC 1/SC 29. They expressed their support for this document in https://mailarchive.ietf.org/arch/msg/avt/Wh64L7O0XgII2ZtIATM3x7xvaaY/.

Besides this, there is no close interaction with another IETF working group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not define any MIBs, YANG modules or URI types.

The document does intend to update the haptics/hmpg media type registration. The corresponding change controller is ISO/IEC JTC1/SC 29/WG 7, who voiced their support for the document (see question 5). In addition, a request to review the media type update has been sent to the media-types mailing list (https://mailarchive.ietf.org/arch/msg/media-types/ZekX1o2-UH-PW7lW5E6tz9o0kfs/), but no concerns were voiced.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module is defined.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not contain formal code.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document defines a useful RTP payload format, is well written and ready to be handed to the AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None of the issues detailed in [6] apply to this document, other than the media type changes. See question 5 and 6 for details on the change controller's support and the correspondence with the mediaman WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Publication is requested as a Proposed Standard, as is typical for new RTP payloads for established media formats.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, as confirmed in https://mailarchive.ietf.org/arch/msg/avt/D19cLYPBg0h-FCw_lQJGt1pYAoM/.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits have been identified.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The ISO/IEC documents for the MPEG Haptics Coding standard are not freely available. Stephan Wenger can provide said documents for reviews if needed, as confirmed in https://mailarchive.ietf.org/arch/msg/avt/J-Jh8Njr5EQ9N5HqPAag154cJnc/.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The draft intends to update RFC 9695, as is listed on the title page and mentioned in the abstract. I don't think this is reflected in the metadata on Datatracker yet.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The update to the haptics/hmpg media type and the registration of the SDP haptics parameter look good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The community showed interested in this document during the call for adoption, WG meetings and its last call.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No points were particularly controversial.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Citing from https://mailarchive.ietf.org/arch/msg/avt/D19cLYPBg0h-FCw_lQJGt1pYAoM/:

Currently we are aware of one implementation of the contents of the document, which is an internal implementation by InterDigital. We expect additional implementations to be developed in the future:

  *  One potential implementation could be an RTP extension to the 5G-MAG V3C Immersive Platform, which supports MPEG Haptics, and indicated a possibility to have an RTP plugin [1].
  *  Another driver for future implementations is the 3GPP support for haptics, with work started in a Release 19 study [2], which is expected to continue in future releases.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document defines an RTP payload format for MPEG-I haptic data, which is defined by the technical committee ISO/IEC JTC 1/SC 29. They expressed their support for this document in https://mailarchive.ietf.org/arch/msg/avt/Wh64L7O0XgII2ZtIATM3x7xvaaY/.

Besides this, there is no close interaction with another IETF working group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not define any MIBs, YANG modules or URI types.

The document does intend to update the haptics/hmpg media type registration. The corresponding change controller is ISO/IEC JTC1/SC 29/WG 7, who voiced their support for the document (see question 5). In addition, a request to review the media type update has been sent to the media-types mailing list (https://mailarchive.ietf.org/arch/msg/media-types/ZekX1o2-UH-PW7lW5E6tz9o0kfs/), but no concerns were voiced.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module is defined.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not contain formal code.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document defines a useful RTP payload format, is well written and ready to be handed to the AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None of the issues detailed in [6] apply to this document, other than the media type changes. See question 5 and 6 for details on the change controller's support and the correspondence with the mediaman WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Publication is requested as a Proposed Standard, as is typical for new RTP payloads for established media formats.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, as confirmed in https://mailarchive.ietf.org/arch/msg/avt/D19cLYPBg0h-FCw_lQJGt1pYAoM/.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits have been identified.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The ISO/IEC documents for the MPEG Haptics Coding standard are not freely available. Stephan Wenger can provide said documents for reviews if needed, as confirmed in https://mailarchive.ietf.org/arch/msg/avt/J-Jh8Njr5EQ9N5HqPAag154cJnc/.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The draft intends to update RFC 9695, as is listed on the title page and mentioned in the abstract. I don't think this is reflected in the metadata on Datatracker yet.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The update to the haptics/hmpg media type and the registration of the SDP haptics parameter look good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The community showed interested in this document during the call for adoption, WG meetings and its last call.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No points were particularly controversial.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

TBD

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document defines an RTP payload format for MPEG-I haptic data, which is defined by the technical committee ISO/IEC JTC 1/SC 29. They expressed their support for this document in https://mailarchive.ietf.org/arch/msg/avt/Wh64L7O0XgII2ZtIATM3x7xvaaY/.

Besides this, there is no close interaction with another IETF working group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document does not define any MIBs, YANG modules or URI types.

The document does intend to update the haptics/hmpg media type registration. The corresponding change controller is ISO/IEC JTC1/SC 29/WG 7, who voiced their support for the document (see question 5). In addition, a request to review the media type update has been sent to the media-types mailing list (https://mailarchive.ietf.org/arch/msg/media-types/ZekX1o2-UH-PW7lW5E6tz9o0kfs/), but no concerns were voiced.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module is defined.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The document does not contain formal code.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, the document defines a useful RTP payload format, is well written and ready to be handed to the AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None of the issues detailed in [6] apply to this document, other than the media type changes. See question 5 and 6 for details on the change controller's support and the correspondence with the mediaman WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Publication is requested as a Proposed Standard, as is typical for new RTP payloads for established media formats.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

TBD

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits have been identified.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

RFC2119, RFC8174 RFC3550, RFC9695, and RFC8866 should be normative references.

TODO: Remove if fixed.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The ISO/IEC documents for the MPEG Haptics Coding standard are not freely available. The authors can provide said documents for reviews if needed.

TODO: Check confirmation

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The draft intends to update RFC 9695, as is listed on the title page and mentioned in the abstract. I don't think this is reflected in the metadata on Datatracker yet.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The update to the haptics/hmpg media type and the registration of the SDP haptics parameter look good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registries are requested.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/