RTP Payload Format for Essential Video Coding (EVC)
draft-ietf-avtcore-rtp-evc-07

[Ballot comment]
I'm abstaining on this for now due to the normative reference behind a pay wall (I've emailed requesting the document as well)

My concern here is that a document that normatively references another document behind a paywall may say that the document is available for reviewers - but that doesn't help document consumers that need the same document that is normatively referenced.

While I'm in 2 minds about this, I'm opting not to discuss and choosing to abstain for now.

[Ballot comment]
I'm going to steal John Scudder's "Thanks for this document, which I found to be well-constructed and well-written if one allows for my complete lack of expertise in the subject area." for this ballot. :-)

[Ballot comment]
Thanks for this document, which I found to be well-constructed and well-written if one allows for my complete lack of expertise in the subject area. I have a few comments below that I hope might be helpful.

(Ballot revised to correct a cut and paste error, no substantive changes.)

## COMMENTs

### Section 1.1.4, Type field description appears to be wrong

As best I can tell from my skim of [EVC], the type field, although six bits, can only represent values from 0 to 62, not the more obvious 0 to 63, and uses an oddball encoding, viz

  NalUnitType = nal_unit_type_plus1 − 1

First, I think it's worth explaining in your description of the field that the encodable range is 0 to 62, not the more obvious 0 to 63 one would normally expect from a 6-bit field. I bumped into this as a consequence of being puzzled by paragraph 4 of Section 6, wondering why value 63 was missing.

Second and more important, I think your paragraph has an off-by-one error. You have, "If the value of this field is less than and equal to 23, the NAL unit is a VCL NAL unit." But the field is nal_unit_type_plus1, not NalUnitType. [EVC] says NalUnitType <= 23 is a VCL NAL unit... which means nal_unit_type_plus1 <= 24 is a VCL NAL unit.

Finally, I think it's inaccurate to write "nal_unit_type_plus1. This field specifies the NAL unit type", assuming the field does contain nal_unit_type_plus1 as the name implies. Per [EVC], NalUnitType is a derived quantity, not the raw field value. Anyway, I've probably belabored the point more than is necessary. Suffice it to say, I think you should carefully review this definition and the other parts of the document that reference NAL unit type.

### Section 4.3.3

“If an FU is lost, the receiver SHOULD discard all following fragmentation units in transmission order corresponding to the same fragmented NAL unit unless the decoder in the receiver is known to gracefully handle incomplete NAL units.”

I assume you don't want to get into the weeds of telling implementations how to determine whether an FU was lost, or if it was merely out-of-order, delayed, etc. I wonder if this should be reworded in terms of saying that a fragment shouldn't be presented to the decoder unless all prior fragments have already been presented.

Also, this paragraph appears to conflict with paragraph six of Section 6, which as I read it, tells me that the decoder should only be presented with a complete reassembled NAL unit. The text above seems to say that it's OK to truncate, the only thing not allowed is presenting a NAL with a hole in the middle.

### Section 6

“All normal RTP mechanisms related to buffer management apply. In particular, duplicated or outdated RTP packets (as indicated by the RTP sequence number and the RTP timestamp) are removed. To determine the exact time for decoding, factors such as a possible intentional delay to allow for proper inter-stream synchronization, MUST be factored in.”

Normally I expect that a MUST will be more specifically prescriptive without requiring the implementor to exercise imagination or creativity. The one here seems to be of the form “implementations MUST do the right thing” which seems not that helpful to the implementor. It’s not wrong as far as it goes, but the RFC 2119 keyword seems out of place.

### Section 6, paragraph 5, not-completely-minor nit

I haven't noted most editorial/idiom things I noticed, on the assumption the RFC editor will do a better job with them than I would anyway. But in Section 6 there is "make a difference from”, I assume what you mean here is "distinguish it from". If not, please say more.

### Section 6, paragraph 9, one last not-utterly-trivial nit

“After initial buffering, decoding, and playback are started, and the buffering-while-playing mode is used.”

I think this should be, “After initial buffering, decoding and playback are started, and the buffering-while-playing mode is used.” My edit deletes one comma. Sorry for the picky edit, it could make a difference for clarity/ambiguity so I'm calling it out. (When Grammarly saw my edit, it wanted to restore the comma I removed. Grammarly is wrong in this instance.)

## NITS

- It’s regrettable that a lot of abbreviations are used in Section 1, but they’re only defined in Section 3.

- It seems a little odd that only some Section 1.1 subsections are labeled “informative”. Isn’t the entire description here non-normative, since the actual payload spec is [EVC]? (And is "non-normative" what you meant by “informative”?)

- Although the specification appears to be clear and well written from the point of view of consumption by someone who is already an expert in the field (or so I'm guessing!) it's a somewhat dense read for a non-expert. Some of this is unavoidable, but there is also some avoidable density due to the use of abbreviations with no obvious mnemonic. One example is DONL. Another example of a symbol that would've helped my understanding to have glossed much earlier is “sprop”. Eventually, I found Section 7 that enabled me to infer it's short for "stream properties". Too late for me, but maybe not for future readers.

[Ballot comment]
Thanks for this document, which I found to be well-constructed and well-written if one allows for my complete lack of expertise in the subject area. I have a few comments below that I hope might be helpful.

## COMMENTs

### Section 1.1.4, Type field description appears to be wrong

As best I can tell from my skim of [EVC], the type field, although six bits, can only represent values from 0 to 62, not the more obvious 0 to 63, and uses an oddball encoding, viz

  NalUnitType = nal_unit_type_plus1 − 1

First, I think it's worth explaining in your description of the field that the encodable range is 0 to 62, not the more obvious 0 to 63 one would normally expect from a 6-bit field. I bumped into this as a consequence of being puzzled by paragraph 4 of Section 6, wondering why value 63 was missing.

Second and more important, I think your paragraph has an off-by-one error. You have, "If the value of this field is less than and equal to 23, the NAL unit is a VCL NAL unit." But the field is nal_unit_type_plus1, not NalUnitType. [EVC] says NalUnitType <= 23 is a VCL NAL unit... which means nal_unit_type_plus1 <= 24 is a VCL NAL unit.

Finally, I think it's inaccurate to write "nal_unit_type_plus1. This field specifies the NAL unit type", assuming the field does contain nal_unit_type_plus1 as the name implies. Per [EVC], NalUnitType is a derived quantity, not the raw field value. Anyway, I've probably belabored the point more than is necessary. Suffice it to say, I think you should carefully review this definition and the other parts of the document that reference NAL unit type.

### Section 4.3.3

“If an FU is lost, the receiver SHOULD discard all following fragmentation units in transmission order corresponding to the same fragmented NAL unit unless the decoder in the receiver is known to gracefully handle incomplete NAL units.”

I assume you don't want to get into the weeds of telling implementations how to determine whether an FU was lost, or if it was merely out-of-order, delayed, etc. I wonder if this should be reworded in terms of saying that a fragment shouldn't be presented to the decoder unless all prior fragments have already been presented.

Also, this paragraph appears to conflict with paragraph six of Section 6, which as I read it, tells me that the decoder should only be presented with a complete reassembled NAL unit. The text above seems to say that it's OK to truncate, the only thing not allowed is presenting a NAL with a hole in the middle.

### Section 6

“All normal RTP mechanisms related to buffer management apply. In particular, duplicated or outdated RTP packets (as indicated by the RTP sequence number and the RTP timestamp) are removed. To determine the exact time for decoding, factors such as a possible intentional delay to allow for proper inter-stream synchronization, MUST be factored in.”

Normally I expect that a MUST will be more specifically prescriptive without requiring the implementor to exercise imagination or creativity. The one here seems to be of the form “implementations MUST do the right thing” which seems not that helpful to the implementor. It’s not wrong as far as it goes, but the RFC 2119 keyword seems out of place.

### Section 6, paragraph 5, not-completely-minor nit

I haven't noted most editorial/idiom things I noticed, on the assumption the RFC editor will do a better job with them than I would anyway. But in Section 6 there is "make a difference from”, I assume what you mean here is "distinguish it from". If not, please say more.

### Section 6, paragraph 9, one last not-utterly-trivial nit

“After initial buffering, decoding, and playback are started, and the buffering-while-playing mode is used.”

I think this should be, “After initial buffering, decoding and playback are started, and the buffering-while-playing mode is used.” My edit deletes one comma. Sorry for the picky edit, it could make a difference for clarity/ambiguity so I'm calling it out. (When Grammarly saw my edit, it wanted to restore the comma I removed. Grammarly is wrong in this instance.)

## NITS(Quinn Grammarly saw my edit, it wanted to restore, I removed. Grammarly is wrong.)

- It’s regrettable that a lot of abbreviations are used in Section 1, but they’re only defined in Section 3.

- It seems a little odd that only some Section 1.1 subsections are labeled “informative”. Isn’t the entire description here non-normative, since the actual payload spec is [EVC]? (And is "non-normative" what you meant by “informative”?)

- Although the specification appears to be clear and well written from the point of view of consumption by someone who is already an expert in the field (or so I'm guessing!) it's a somewhat dense read for a non-expert. Some of this is unavoidable, but there is also some avoidable density due to the use of abbreviations with no obvious mnemonic. One example is DONL. Another example of a symbol that would've helped my understanding to have glossed much earlier is “sprop”. Eventually, I found Section 7 that enabled me to infer it's short for "stream properties". Too late for me, but maybe not for future readers.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-evc-06

Thank you for the work put into this document. The document is well structured and for many sections easy and clear (noting that I have only skimmed the hard-core codec parts).

I find it strange to have a normative reference behind a paywall, but I appreciate the shepherd's note about its availability to reviewers, big thanks to Stephan

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Bernard Adoba for the shepherd's detailed write-up including the WG consensus, detailed IPR, and a very concise justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

Do not worry :-)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 4.3.1

What is the expected decoder behaviour when DONL is present while it should not?

What is meant by `conditional`? Does it mean 'optional' ?

## Section 4.3.2

Should this be a "MUST" in `he value of Reserve and E Must be equal to 0` ?

What is the expected decoder behaviour when `APs MUST NOT be nested; ` is violated ?

[Ballot comment]

# COMMENTS (non-blocking)

## Section 1

Please expand HEVC and AVC before first use.

## Section 1.1

Is `walled-garden implementations` well-known ? To be honest, this is the first time I see "walled-garden" applied to "implementations".

## Section 1.1.4

Figure 1, any reason why the bit numbers are in a box ? Usually (see figure 2), the bit numbers are 'naked', i.e., without a frame. Same comment for figure 10 later in the text.

Should this I-D also specifies "nuh_reserved_zero_5bits MUST be set to 0" ?

## Section 4.1

As I am not familiar with the RTP packet structure, is it obvious for the implementers how the values of P, X, CC, and CSRC are selected ?

## Section 4.3.1

Please expand/explain `DONL`.

I had no time to request the EVC document to check whether PayloadHdr in EVC cannot be 56/57... I am therefore trusting the authors, WG, and responsible AD on the absence of collision. It may be worth to add a sentence (perhaps in section 4.3) stating that PayloadHdr for NUL will never be equal to 56 or 57.

## Section 4.3.3

The use of DONL is really unclear to me (see above), so how can the presence of DONL be detected in `The DONL field, when present,` ?

As the I-D forbids "atomic" fragment, suggest to use a normative "MUST NOT" in `the Start bit and End bit must not both be set to 1 in the same FU header`.

When can a receiver detect that there is a missing fragment ? If this is on a time-out, then should there be some RECOMMENDED value ?

While I like the idea of processing the first n-1 fragments anyway, why not extending this flexibility to the first n-m fragments (i.e., the last m fragments were lost) ? Of course, the E-bit based system cannot differentiate between n-1 and n-m; then, is it worth mentioning it in the text?

## Section 5

Possibly due to my lack of real-time knowledge, but is there a risk to increase the end-to-end latency is the encoder must wait for several NUL before sending them ?

## Section 13.1

Is SAP still in use ? Anyway, I do not think that RFC 2974 should be normative as it is cited as an example, i.e., it should rather be informative.

# NITS (non-blocking / cosmetic)

## Section 4.3

s/The Three different payload/The *t*hree different payload/ ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

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

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

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

a single new registration is to be made as follows:

Name: evc
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

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

The following Last Call announcement was sent out (ends 2023-11-21):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-evc@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for Essential Video Coding (EVC)) 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 Essential Video Coding (EVC)'
  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 2023-11-21. 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 document describes an RTP payload format for the Essential Video
  Coding (EVC) standard, published as ISO/IEC International Standard
  23094-1.  EVC was developed by the Moving Picture Experts Group
  (MPEG).  The RTP payload format allows for the packetization of one
  or more Network Abstraction Layer (NAL) units in each RTP packet
  payload and the fragmentation of a NAL unit into multiple RTP
  packets.  The payload format has broad applicability in
  videoconferencing, Internet video streaming, and high-bitrate
  entertainment-quality video, among other applications.




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


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

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



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7656: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (Informational - Internet Engineering Task Force (IETF))
    rfc7667: RTP Topologies (Informational - Internet Engineering Task Force (IETF))
    rfc2974: Session Announcement Protocol (Experimental - Internet Engineering Task Force (IETF))

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-avtcore-rtp-evc-05. 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 video namespace in the Media Types registry located at:

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

a single new registration will be made as follows:

Name: evc
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA understands 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

The following Last Call announcement was sent out (ends 2023-10-04):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-evc@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for Essential Video Coding (EVC)) 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 Essential Video Coding (EVC)'
  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 2023-10-04. 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 document describes an RTP payload format for the Essential Video
  Coding (EVC) standard, published as ISO/IEC International Standard
  23094-1.  EVC was developed by the Moving Picture Experts Group
  (MPEG).  The RTP payload format allows for the packetization of one
  or more Network Abstraction Layer (NAL) units in each RTP packet
  payload and the fragmentation of a NAL unit into multiple RTP
  packets.  The payload format has broad applicability in
  videoconferencing, Internet video streaming, and high-bitrate
  entertainment-quality video, among other applications.




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


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

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



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7656: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources (Informational - Internet Engineering Task Force (IETF))
    rfc7667: RTP Topologies (Informational - Internet Engineering Task Force (IETF))
    rfc2974: Session Announcement Protocol (Experimental - Internet Engineering Task Force (IETF))

Request for Publication
Document: RTP Payload Format for Essential Video Coding (EVC)
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba

# Document Shepherd Write-Up for Group Documents

*This version iq:s 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.

## Technical and Working Group Summary

Technical Summary:

  This document describes the RTP payload format for the Essential
  Video Coding (EVC) standard, published as ISO/IEC 23094-1.
  The RTP payload format, which is applicable to video conferencing,
  video streaming and high-bitrate entertainment-quality video,
  allows for packetization of Network Abstraction Layer (NAL) units
  in an RTP packet payload as well as fragmentation of a NAL
  unit into multiple RTP packets.

  EVC inherits the basic systems and transport interfaces designs from
  VVC, HEVC and AVC. These include the NAL-unit-based syntax structure,
  the hierarchical syntax and data unit structure and the Supplemental
  Enhancement Information (SEI) message mechanism. However, EVC supports
  a subset of VVC feature set.  For example, EVC supports
  temporal but not spatial or quality scalability.

Working Group Summary:

  The EVC payload specification closely resembles the RTP payload
  specification for VVC (RFC 9328), so discussion in the WG focused
  on the differences between the EVC and VVC codecs and the impact
  on the RTP payload format.

## 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?

WG consensus behind this document appears solid. A summary of the WGLC was
posted to the AVTCORE mailing list on May 2, 2023:
https://mailarchive.ietf.org/arch/msg/avt/9KnvogwIX6Wi77VtYNmV3Sjfhik/

5 responses were received to the WGLC announcement, all supporting publication.
There were no objections.

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

The EVC RTP payload format is derived from RFC 9328, the VVC RTP payload format.
Since the WG previously came to consensus on RFC 9328, the development of the
EVC payload format went smoothly.

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 appeal threats or extreme discontent expressed.

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

Tencent has developed a prototype of the EVC RTP payload format, which is
almost identical to the media plane of RFC 9328.
See: https://mailarchive.ietf.org/arch/msg/avt/2ihJhUi4OKaj80RrUAeW_6lt5LI/

There are no known implementation of the SDP signaling. So far, there have not
been any interop events relating to the EVC RTP payload specification.

## 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 EVC RTP payload format document is based on the EVC specification developed in ISO.
The authors of the EVC payload format include the IETF liaison to SC29 (Stephan Wenger)
as well as individuals involved in the development of the ISO EVC specification,
so there has been close coordination.

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 URIs. It does include a
Media Type Registration in Section 7.1. This is based on the Media Type
Registration in RFC 9328:
https://iana.org/assignments/media-types/video/H266

A review request sent to the media-types mailing list by Stephan Wenger on
March 29, 2023:
https://mailarchive.ietf.org/arch/msg/media-types/5cThdv2nppJbe7nc6vxG0SLOQnk/

A review by Roni Even was posted on April 03, 2023:
https://mailarchive.ietf.org/arch/msg/media-types/AOesp9XTwX29lVgahETowZOMS1w/

Other than recommending that IETF AVTCORE WG be listed as the change controller,
no other issues were found.

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.

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.

No formal languages are used in this specification.

## 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?

I believe that the document is clearly written, complete and correctly designed.

Whether it will ultimately be widely deployed will be determined largely by
factors outside the control of the IETF, such as the performance of EVC in
comparison to other codecs which have either been specified or are under
development (e.g. AV1 and AV2).

The document is motivated by the desire to offer a royalty-free codec utilizing
a subset of the tools in VVC. This goal, if achieved, would assist in the
deployment of EVC (see note relating to IPR declarations below).

The approach to RTP packetization utilized by EVC has been previously applied in
the VVC, HEVC and AVC RTP payload specifications, so that the design is well
understood.  As the design has evolved from the AVC specification to HEVC
and VVC, the approach has been simplified with infrequently used options being
eliminated, reducing implementation complexity and improving interoperability.
This trend continues with EVC, which offers a limited feature set compared
with VVC (e.g. support for temporal scalability, but not spatial or quality).

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 registration, which has been reviewed.

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 as a Proposed Standard is requested. This is reflected in Datatracker.
RFC 9328, which is closely related to this document, was also published as a
Proposed Standard.

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.

On June 16, 2023 a request for author confirmation was posted to the AVTCORE WG mailing list:
https://mailarchive.ietf.org/arch/msg/avt/-lVJ9hRTn0Y7iz369pW88N6jy-4/

A response was received from each of the authors:

Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/Eqb8TWcVzaOaBTmr9-op65UQXFY/
Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/oZceElHTOKvifqThAl5gCczHQlY/
Youngkwon Lim: https://mailarchive.ietf.org/arch/msg/avt/fH6_1ES0kl3u8QAqksOpiGzS9Ms/

An IPR declaration has been filed:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-rtp-evc

As noted in draft-ietf-avtcore-rtp-evc Section 1:

"The Essential Video Coding [EVC] standard, which is formally designated as ISO/IEC International Standard 23094-1
[ISO23094-1] has been published in 2020. One goal of MPEG is to keep [EVC]'s Baseline profile essentially
royalty-free by using technologies published more than 20 years ago or otherwise known to be available for use
without a requirement for paying royalties, whereas more advanced profiles follow a reasonable and
non-discriminatory licensing terms policy."

Given the EVC development goals, the filing of an IPR declaration was brought to the attention
of the WG on the mailing list as well as at IETF 117.

On June 16, 2023 the AVTCORE WG was asked whether, in view of the IPR declaration,
it wished to continue to proceed to publication:
https://mailarchive.ietf.org/arch/msg/avt/JUDZDgW31xjHMO-kMb6NSr-Buj0/

Responses on the mailing list indicated a willingness to proceed:
Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/f5H_Sqz3bSzMGFWccNosnrmnYGk/
Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/IVFbH1nb6aPjmByc-hX7VEwemhA/
Youngkwon Ling: https://mailarchive.ietf.org/arch/msg/avt/CQLmSbVscmFBNtEeLs94qNph9FQ/
Roman Chernyak: https://mailarchive.ietf.org/arch/msg/avt/Tp81f2zPTyj8ikOC3SMcPUWc9H0/

No objections to publication were expressed on the AVTCORE WG mailing list.

At IETF 117, the issue was brought up at the AVTCORE WG meeting.  No objections were
voiced. 

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.

On June 26, 2023 I posted a message to the AVTCORE WG mailing list, requesting the
agreement of authors, editors and contributor to be listed as such:
https://mailarchive.ietf.org/arch/msg/avt/GpbLyMJVRu0cf44MGbp9DZbEm84/

The authors and acknowledged contributors have affirmed their willingness to be listed:

Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/AGKjtH5idZThJ6HPvK3teig7gJw/
Youngkwon Lim: https://mailarchive.ietf.org/arch/msg/avt/zPbyT2GXAGgtWPsZ0maVM5hZ1Gc/
Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/9opVmOWsRFlCknrp6fw9l789_Jk/
Roman Chernyak: https://mailarchive.ietf.org/arch/msg/avt/CPGFxFs5aS8z93DQY2LDqQzSiSM/

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

An ID nits check run on -04 discloses 0 errors, 0 flaws and 1 warning.

Section 12 has two spelling errors:

  Large parts of this specification share text with the RTP payload
  format for VVC [RFC9328].  Roman Chernyak is thanksed for his
                                               
s/thansked/thanked/

  valueable review comments.  We thank the authors of that
s/valueable/valuable/

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

The normative and informative references appear to be appropriate.

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 EVC RTP Payload format has a normative reference to the EVC specification,
"ISO/IEC 23094-1 Essential Video Coding", 2020,

This specification is behind a paywall.  However, to assist reviewers interested in the
specification, Stephan Wenger (IETF liaison to SC29) has worked with ISO/IEC to make the
specification free of charge to reviewers requesting it:
https://mailarchive.ietf.org/arch/msg/avt/HmTrkqKQFr406LLjAYFfZ0MODvI/

To test the process, I sent email to Stephan Wenger ,
requesting access to the EVC specification, and it was provided to me.

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?

There are no normative references to documents in an unclear state.

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 document does not change the status of any existing RFC.

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 IANA considerations section, which includes the Media Registration,
is based on RFC 9325, albeit with a smaller range of options and parameters.

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.

[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/

Request for Publication
Document: RTP Payload Format for Essential Video Coding (EVC)
Link: https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc
Intended Status: Proposed Standard
Document Shepard: Bernard Aboba

# Document Shepherd Write-Up for Group Documents

*This version iq:s 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.

## Technical and Working Group Summary

Technical Summary:

  This document describes the RTP payload format for the Essential
  Video Coding (EVC) standard, published as ISO/IEC 23094-1.
  The RTP payload format, which is applicable to video conferencing,
  video streaming and high-bitrate entertainment-quality video,
  allows for packetization of Network Abstraction Layer (NAL) units
  in an RTP packet payload as well as fragmentation of a NAL
  unit into multiple RTP packets.

  EVC inherits the basic systems and transport interfaces designs from
  VVC, HEVC and AVC. These include the NAL-unit-based syntax structure,
  the hierarchical syntax and data unit structure and the Supplemental
  Enhancement Information (SEI) message mechanism. However, EVC supports
  a subset of VVC feature set.  For example, EVC supports
  temporal but not spatial or quality scalability.

Working Group Summary:

  The EVC payload specification closely resembles the RTP payload
  specification for VVC (RFC 9328), so discussion in the WG focused
  on the differences between the EVC and VVC codecs and the impact
  on the RTP payload format.

## 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?

WG consensus behind this document appears solid. A summary of the WGLC was
posted to the AVTCORE mailing list on May 2, 2023:
https://mailarchive.ietf.org/arch/msg/avt/9KnvogwIX6Wi77VtYNmV3Sjfhik/

5 responses were received to the WGLC announcement, all supporting publication.
There were no objections.

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

The EVC RTP payload format is derived from RFC 9328, the VVC RTP payload format.
Since the WG previously came to consensus on RFC 9328, the development of the
EVC payload format went smoothly.

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 appeal threats or extreme discontent expressed.

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

Tencent has developed a prototype of the EVC RTP payload format, which is
almost identical to the media plane of RFC 9328.
See: https://mailarchive.ietf.org/arch/msg/avt/2ihJhUi4OKaj80RrUAeW_6lt5LI/

There are no known implementation of the SDP signaling. So far, there have not
been any interop events relating to the EVC RTP payload specification.

## 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 EVC RTP payload format document is based on the EVC specification developed in ISO.
The authors of the EVC payload format include the IETF liaison to SC29 (Stephan Wenger)
as well as individuals involved in the development of the ISO EVC specification,
so there has been close coordination.

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 URIs. It does include a
Media Type Registration in Section 7.1. This is based on the Media Type
Registration in RFC 9328:
https://iana.org/assignments/media-types/video/H266

A review request sent to the media-types mailing list by Stephan Wenger on
March 29, 2023:
https://mailarchive.ietf.org/arch/msg/media-types/5cThdv2nppJbe7nc6vxG0SLOQnk/

A review by Roni Even was posted on April 03, 2023:
https://mailarchive.ietf.org/arch/msg/media-types/AOesp9XTwX29lVgahETowZOMS1w/

Other than recommending that IETF AVTCORE WG be listed as the change controller,
no other issues were found.

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.

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.

No formal languages are used in this specification.

## 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?

I believe that the document is clearly written, complete and correctly designed.

Whether it will ultimately be widely deployed will be determined largely by
factors outside the control of the IETF, such as the performance of EVC in
comparison to other codecs which have either been specified or are under
development (e.g. AV1 and AV2).

The document is motivated by the desire to offer a royalty-free codec utilizing
a subset of the tools in VVC. This goal, if achieved, would assist in the
deployment of EVC (see note relating to IPR declarations below).

The approach to RTP packetization utilized by EVC has been previously applied in
the VVC, HEVC and AVC RTP payload specifications, so that the design is well
understood.  As the design has evolved from the AVC specification to HEVC
and VVC, the approach has been simplified with infrequently used options being
eliminated, reducing implementation complexity and improving interoperability.
This trend continues with EVC, which offers a limited feature set compared
with VVC (e.g. support for temporal scalability, but not spatial or quality).

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 registration, which has been reviewed.

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 as a Proposed Standard is requested. This is reflected in Datatracker.
RFC 9328, which is closely related to this document, was also published as a
Proposed Standard.

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.

On June 16, 2023 a request for author confirmation was posted to the AVTCORE WG mailing list:
https://mailarchive.ietf.org/arch/msg/avt/-lVJ9hRTn0Y7iz369pW88N6jy-4/

A response was received from each of the authors:

Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/Eqb8TWcVzaOaBTmr9-op65UQXFY/
Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/oZceElHTOKvifqThAl5gCczHQlY/
Youngkwon Lim: https://mailarchive.ietf.org/arch/msg/avt/fH6_1ES0kl3u8QAqksOpiGzS9Ms/

An IPR declaration has been filed:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-rtp-evc

As noted in draft-ietf-avtcore-rtp-evc Section 1:

"The Essential Video Coding [EVC] standard, which is formally designated as ISO/IEC International Standard 23094-1
[ISO23094-1] has been published in 2020. One goal of MPEG is to keep [EVC]'s Baseline profile essentially
royalty-free by using technologies published more than 20 years ago or otherwise known to be available for use
without a requirement for paying royalties, whereas more advanced profiles follow a reasonable and
non-discriminatory licensing terms policy."

Given the EVC development goals, the filing of an IPR declaration was brought to the attention
of the WG on the mailing list as well as at IETF 117.

On June 16, 2023 the AVTCORE WG was asked whether, in view of the IPR declaration,
it wished to continue to proceed to publication:
https://mailarchive.ietf.org/arch/msg/avt/JUDZDgW31xjHMO-kMb6NSr-Buj0/

Responses on the mailing list indicated a willingness to proceed:
Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/f5H_Sqz3bSzMGFWccNosnrmnYGk/
Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/IVFbH1nb6aPjmByc-hX7VEwemhA/
Youngkwon Ling: https://mailarchive.ietf.org/arch/msg/avt/CQLmSbVscmFBNtEeLs94qNph9FQ/
Roman Chernyak: https://mailarchive.ietf.org/arch/msg/avt/Tp81f2zPTyj8ikOC3SMcPUWc9H0/

No objections to publication were expressed on the AVTCORE WG mailing list.

At IETF 117, the issue was brought up at the AVTCORE WG meeting.  No objections were
voiced. 

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.

On June 26, 2023 I posted a message to the AVTCORE WG mailing list, requesting the
agreement of authors, editors and contributor to be listed as such:
https://mailarchive.ietf.org/arch/msg/avt/GpbLyMJVRu0cf44MGbp9DZbEm84/

The authors and acknowledged contributors have affirmed their willingness to be listed:

Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/AGKjtH5idZThJ6HPvK3teig7gJw/
Youngkwon Lim: https://mailarchive.ietf.org/arch/msg/avt/zPbyT2GXAGgtWPsZ0maVM5hZ1Gc/
Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/9opVmOWsRFlCknrp6fw9l789_Jk/
Roman Chernyak: https://mailarchive.ietf.org/arch/msg/avt/CPGFxFs5aS8z93DQY2LDqQzSiSM/

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

An ID nits check run on -04 discloses 0 errors, 0 flaws and 1 warning.

Section 12 has two spelling errors:

  Large parts of this specification share text with the RTP payload
  format for VVC [RFC9328].  Roman Chernyak is thanksed for his
                                               
s/thansked/thanked/

  valueable review comments.  We thank the authors of that
s/valueable/valuable/

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

The normative and informative references appear to be appropriate.

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 EVC RTP Payload format has a normative reference to the EVC specification,
"ISO/IEC 23094-1 Essential Video Coding", 2020,

This specification is behind a paywall.  However, to assist reviewers interested in the
specification, Stephan Wenger (IETF liaison to SC29) has worked with ISO/IEC to make the
specification free of charge to reviewers requesting it:
https://mailarchive.ietf.org/arch/msg/avt/HmTrkqKQFr406LLjAYFfZ0MODvI/

To test the process, I sent email to Stephan Wenger ,
requesting access to the EVC specification, and it was provided to me.

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?

There are no normative references to documents in an unclear state.

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 document does not change the status of any existing RFC.

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 IANA considerations section, which includes the Media Registration,
is based on RFC 9325, albeit with a smaller range of options and parameters.

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.

[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/

Write-Up awaiting response to mailing list queries:

1. Author confirmation of BCP 78/79 compliance: https://mailarchive.ietf.org/arch/msg/avt/-lVJ9hRTn0Y7iz369pW88N6jy-4/
2. IPR declaration(s) and willingness to proceed: https://mailarchive.ietf.org/arch/msg/avt/JUDZDgW31xjHMO-kMb6NSr-Buj0/
3. Implementation experience: https://mailarchive.ietf.org/arch/msg/avt/LoPV8RjMlvDcGyEIze3e_biheGY/