RTP Payload Format for Versatile Video Coding (VVC)
draft-ietf-avtcore-rtp-vvc-18

[Ballot comment]
Thanks for addressing my comments and resolving the discuss.

for future ref, I am copying here the discuss point that got resolved -

    In section 7.3.2.3, it says sprop-max-don-diff and sprop-depack-buf-bytes parameter should be interpreted differently than usual interpretation of the parameters according to RFC 3264. This is a significant change and kind of easy to miss. This section does not use any normative text to enforce the change either.

[Ballot comment]
My DISCUSSes were addressed in version -17 (see  https://mailarchive.ietf.org/arch/msg/avt/RZr6jWX-S1u6k0efT1Gm-YAbXZw/)

Old DISCUSSes:

Please be aware that this document is far outside my area of expertise,
and my comments might make no sense. Please do not be nervous to tell
me I am wrong - likely I am....

#1

  [VVC] is particularly vulnerable to such
  attacks, as it is extremely simple to generate datagrams containing
  NAL units that affect the decoding process of many future NAL units.
  Therefore, the usage of data origin authentication and data integrity
  protection of at least the RTP packet is RECOMMENDED, for example,
  with SRTP [RFC3711].

If something is "particularly vulnerable", why is its security counter
measures only RECOMMENDED instead of REQUIRED ? Is there a real world
use case where this vulnerable protocol should continue despite the
threat without these counter measures?

#2

Media-Aware Network Element (MANE) are briefly mentioned in the Security
Considerations, but it is unclear to me how a user can opt-in or opt-out
of using these or how it could even evaluate a MANE for trustworthiness.
Does a user even know if there is a MANE ?
And especially combining the two issues, if a MANE can rewrite the SEI,
would it not mean that it could attack a user with malicious data that
appear trusted?

#3

In the IANA Considerations, it points to another section. It is customary
to just make this section stand on its own with clear and explicit instructions
for IANA so they do not need to read or understand large parts of the document.

COMMENTS:

  forbidden_zero_bit.  Required to be zero in VVC.  Note that the
  inclusion of this bit in the NAL unit header was to enable
  transport of VVC video over MPEG-2 transport systems (avoidance of
  start code emulations) [MPEG2S].  In the context of this memo the
  value 1 may be used

So it MUST be zero but MAY be 1? A bit odd for a "forbidden_zero_bit".
Also, what is "this memo"? Does it mean this document or does it mean [MPEG2S] ?
(also, "forbidden zero" kind of reads like "forbidden to be zero" which is
the opposite of what is meant)

PayloadHdr appears without value in Figure 3 and with "(Type=28)" in Figure 4.
Does the first occurance without value also use type=28 ? If so, can this be added? If not, can the non-28 value be added?

What does the ":" character denote in Figure 5 ,6 and 8?

  Fragments of the same NAL unit MUST be sent in consecutive
  order with ascending RTP sequence numbers (with no other RTP packets
  within the same RTP stream being sent between the first and last
  fragment).

Why is this? I would say the RTP seq numbers would allow the target to
order the packets, which it has to do anyway if the network causes re-ordering.
Why then, can the host not do this? Eg if it has two crypto modules to
independently encrypt these packets without needing to sync sending them to
ensure this requirement?

    Security considerations:
    See Section 9 of RFC XXXX.

Does XXXX refer to this document? eg [RFC TBD1]? Or is this a placeholder
for another RFC that was forgotten and needs fixing? I think it is
for this document since it has Security Considerations in Section 9.

In Section 7.3.2 starts with "This section describes the negotiation of
unicast messages" but really also describes using Multicast so it is a
bit contradicting.

  Congestion control for RTP SHALL be used

I always find MUST clearer than SHALL? Might be a non-native english speaker
issue contaminated by Gandalf's speech. The same paragraph uses "MUST monitor"
and not "SHALL monitor", so better at least use either MUST or SHALL for both
of these?

[Ballot comment]
# ART AD Review of draft-ietf-avtcore-rtp-vvc-16

cc @fpalombini

Thank you for the work on this document, and for addressing my previous DISCUSSes.

Thanks for posting the media-types review request https://mailarchive.ietf.org/arch/msg/media-types/iinskT_KIviiCsmnL32ql4PuQfU/ and thanks to Martin Dürst for his review.

Re the IANA registration: in recent years we have preferred to use "IETF" for change controller, to indicate that this comes from a consensus document, as document in https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00. So in this case I would suggest using "IETF ". I am ok with no changes for the other review comments, thanks for the replies.

Francesca

## Comments

### DONL and NALU size in figures 5 and 6

Section 4.3.2:
```
  The first aggregation unit in an AP consists of a conditional 16-bit
  DONL field (in network byte order) followed by a 16-bit unsigned size
  information (in network byte order) that indicates the size of the
```
Which indicates DONL to be a 16-bit field, but in the figure 5 DONL appears to be 24 bits.

```
  An aggregation unit that is not the first aggregation unit in an AP
  will be followed immediately by a 16-bit unsigned size information
  (in network byte order) that indicates the size of the NAL unit in
```

Same for the NALU size: 16 bits in the paragraph above, but 24 bits in figure 6.

EDIT: from the authors - "Aggregation units can start and end at octet boundaries.  We tried to emphasize that by having the first octet in the 32-bit dword belonging to something else.  That’s why there’s the colon between bit 7 and bit 8.  The colon signifies the start and end of the aggregation unit. " I suggest adding a sentence clarifying the above to avoid confusion in the reader.

### Values from \[VVC\] undefined

In section 3.1.1, there are a number of values that are not defined:  GDR_NUT, CRA_NUT, IDR_W_RADL, IDR_N_LP. I understand these come from \[VVC\] and are reported as is, however they make the text harder to parse since to reference to these values is given.

### Wrong reference

Section 4.3:
```
      header.  This payload structure is specified in Section 4.4.1.
```
4.4.1 should be 4.3.1.

### sprop-max-don-diff

sprop-max-don-diff appears first in section 4.3.1 - it would be good to add a reference to 7.2, where its meaning is defined.

### Base 64

In Section 7.2, Base64 is used - please specify if the encoding follows "Base 64 Encoding" (Section 4) or "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5) of RFC 4648. (This can easily be done in one sentence, rather than repeated everytime base64 is mentioned).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
I would like discuss if this specification should be making stronger statement to enforce the reinterpretation the SDP Offer/Answer model for parameters sprop-max-don-diff and sprop-depack-buf-bytes.

In section 7.3.2.3, it says sprop-max-don-diff and sprop-depack-buf-bytes parameter should be interpreted differently than usual interpretation of the parameters according to RFC 3264. This is a significant change and kind of easy to miss. This section does not use any normative text to enforce the change either. 

I am also supporting Francesca's discuss.

[Ballot comment]
Thanks for working on this specification. This is a big task to define payload format for a video codec.

I would note that the VVC specifications are behind paywall and we are heavily depended on the interpretation of the authors of the actual specification here. I hope the specification was somehow made available to the working group to have a look while developing this specification. Having said that I must thank the authors for providing details of the video codec specification that made this review possible.

I have some of observations -

-  Section 4.3.1 : what is the PayloadHdr type for the single NAL unit packet? is this type not needed here?
-  Section 7.3.2 : actually contains both unicast and multicast considerations but in the beginning of the section only mentioned unicast.
-  Section 10 : I think here AVPF (RFC 4584) is the proper profile example than 3551. But that for this section.

[Ballot discuss]
# ART AD Review of draft-ietf-avtcore-rtp-vvc-16

cc @fpalombini

Thank you for the work on this document.

I have two (EDIT: one) DISCUSS points - hopefully easy to resolve - and a few non blocking comments, but answers will be appreciated.

Francesca

## Discuss

### IANA Media type review request missing

As specified by RFC6838, it is strongly encouraged to post the media type registration to the media-types mailing list for review (see https://mailarchive.ietf.org/arch/msg/media-types/3_DukpPWrpkTXO-zynjJlShtC1w/ for an example of a  registration review). Is there any reason this was not done here? If not, please post to the media-types mailing list, and I will remove the discuss with no objections raised in a week or so.

[Ballot comment]
## Comments


### DONL and NALU size in figures 5 and 6

Section 4.3.2:
```
  The first aggregation unit in an AP consists of a conditional 16-bit
  DONL field (in network byte order) followed by a 16-bit unsigned size
  information (in network byte order) that indicates the size of the
```
Which indicates DONL to be a 16-bit field, but in the figure 5 DONL appears to be 24 bits.

```
  An aggregation unit that is not the first aggregation unit in an AP
  will be followed immediately by a 16-bit unsigned size information
  (in network byte order) that indicates the size of the NAL unit in
```

Same for the NALU size: 16 bits in the paragraph above, but 24 bits in figure 6.

EDIT: from the authors - "Aggregation units can start and end at octet boundaries.  We tried to emphasize that by having the first octet in the 32-bit dword belonging to something else.  That’s why there’s the colon between bit 7 and bit 8.  The colon signifies the start and end of the aggregation unit. " I suggest adding a sentence clarifying the above to avoid confusion in the reader.

### Values from \[VVC\] undefined

In section 3.1.1, there are a number of values that are not defined:  GDR_NUT, CRA_NUT, IDR_W_RADL, IDR_N_LP. I understand these come from \[VVC\] and are reported as is, however they make the text harder to parse since to reference to these values is given.

### Wrong reference

Section 4.3:
```
      header.  This payload structure is specified in Section 4.4.1.
```
4.4.1 should be 4.3.1.

### sprop-max-don-diff

sprop-max-don-diff appears first in section 4.3.1 - it would be good to add a reference to 7.2, where its meaning is defined.

### Base 64

In Section 7.2, Base64 is used - please specify if the encoding follows "Base 64 Encoding" (Section 4) or "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5) of RFC 4648. (This can easily be done in one sentence, rather than repeated everytime base64 is mentioned).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
# ART AD Review of draft-ietf-avtcore-rtp-vvc-16

cc @fpalombini

Thank you for the work on this document.

I have two DISCUSS points - hopefully easy to resolve - and a few non blocking comments, but answers will be appreciated.

Francesca

## Discuss

### DONL and NALU size in figures 5 and 6

Section 4.3.2:
```
  The first aggregation unit in an AP consists of a conditional 16-bit
  DONL field (in network byte order) followed by a 16-bit unsigned size
  information (in network byte order) that indicates the size of the
```
Which indicates DONL to be a 16-bit field, but in the figure 5 DONL appears to be 24 bits.

```
  An aggregation unit that is not the first aggregation unit in an AP
  will be followed immediately by a 16-bit unsigned size information
  (in network byte order) that indicates the size of the NAL unit in
```

Same for the NALU size: 16 bits in the paragraph above, but 24 bits in figure 6.

### IANA Media type review request missing

As specified by RFC6838, it is strongly encouraged to post the media type registration to the media-types mailing list for review (see https://mailarchive.ietf.org/arch/msg/media-types/3_DukpPWrpkTXO-zynjJlShtC1w/ for an example of a  registration review). Is there any reason this was not done here? If not, please post to the media-types mailing list, and I will remove the discuss with no objections raised in a week or so.

[Ballot comment]
## Comments

### Values from \[VVC\] undefined

In section 3.1.1, there are a number of values that are not defined:  GDR_NUT, CRA_NUT, IDR_W_RADL, IDR_N_LP. I understand these come from \[VVC\] and are reported as is, however they make the text harder to parse since to reference to these values is given.

### Wrong reference

Section 4.3:
```
      header.  This payload structure is specified in Section 4.4.1.
```
4.4.1 should be 4.3.1.

### sprop-max-don-diff

sprop-max-don-diff appears first in section 4.3.1 - it would be good to add a reference to 7.2, where its meaning is defined.

### Base 64

In Section 7.2, Base64 is used - please specify if the encoding follows "Base 64 Encoding" (Section 4) or "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5) of RFC 4648. (This can easily be done in one sentence, rather than repeated everytime base64 is mentioned).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
Please be aware that this document is far outside my area of expertise,
and my comments might make no sense. Please do not be nervous to tell
me I am wrong - likely I am....

#1

  [VVC] is particularly vulnerable to such
  attacks, as it is extremely simple to generate datagrams containing
  NAL units that affect the decoding process of many future NAL units.
  Therefore, the usage of data origin authentication and data integrity
  protection of at least the RTP packet is RECOMMENDED, for example,
  with SRTP [RFC3711].

If something is "particularly vulnerable", why is its security counter
measures only RECOMMENDED instead of REQUIRED ? Is there a real world
use case where this vulnerable protocol should continue despite the
threat without these counter measures?

#2

Media-Aware Network Element (MANE) are briefly mentioned in the Security
Considerations, but it is unclear to me how a user can opt-in or opt-out
of using these or how it could even evaluate a MANE for trustworthiness.
Does a user even know if there is a MANE ?
And especially combining the two issues, if a MANE can rewrite the SEI,
would it not mean that it could attack a user with malicious data that
appear trusted?

#3

In the IANA Considerations, it points to another section. It is customary
to just make this section stand on its own with clear and explicit instructions
for IANA so they do not need to read or understand large parts of the document.

[Ballot comment]
  forbidden_zero_bit.  Required to be zero in VVC.  Note that the
  inclusion of this bit in the NAL unit header was to enable
  transport of VVC video over MPEG-2 transport systems (avoidance of
  start code emulations) [MPEG2S].  In the context of this memo the
  value 1 may be used

So it MUST be zero but MAY be 1? A bit odd for a "forbidden_zero_bit".
Also, what is "this memo"? Does it mean this document or does it mean [MPEG2S] ?
(also, "forbidden zero" kind of reads like "forbidden to be zero" which is
the opposite of what is meant)

PayloadHdr appears without value in Figure 3 and with "(Type=28)" in Figure 4.
Does the first occurance without value also use type=28 ? If so, can this be added? If not, can the non-28 value be added?

What does the ":" character denote in Figure 5 ,6 and 8?

  Fragments of the same NAL unit MUST be sent in consecutive
  order with ascending RTP sequence numbers (with no other RTP packets
  within the same RTP stream being sent between the first and last
  fragment).

Why is this? I would say the RTP seq numbers would allow the target to
order the packets, which it has to do anyway if the network causes re-ordering.
Why then, can the host not do this? Eg if it has two crypto modules to
independently encrypt these packets without needing to sync sending them to
ensure this requirement?

    Security considerations:
    See Section 9 of RFC XXXX.

Does XXXX refer to this document? eg [RFC TBD1]? Or is this a placeholder
for another RFC that was forgotten and needs fixing? I think it is
for this document since it has Security Considerations in Section 9.

In Section 7.3.2 starts with "This section describes the negotiation of
unicast messages" but really also describes using Multicast so it is a
bit contradicting.

  Congestion control for RTP SHALL be used

I always find MUST clearer than SHALL? Might be a non-native english speaker
issue contaminated by Gandalf's speech. The same paragraph uses "MUST monitor"
and not "SHALL monitor", so better at least use either MUST or SHALL for both
of these?

[Ballot discuss]
Please be aware that this document is far outside my area of expertise,
and my comments might make no sense. Please do not be nervous to tell
me I am wrong - likely I am....

#1

  [VVC] is particularly vulnerable to such
  attacks, as it is extremely simple to generate datagrams containing
  NAL units that affect the decoding process of many future NAL units.
  Therefore, the usage of data origin authentication and data integrity
  protection of at least the RTP packet is RECOMMENDED, for example,
  with SRTP [RFC3711].

If something is "particularly vulnerable", why is its security counter
measures only RECOMMENDED instead of REQUIRED ? Is there a real world
use case where this vulnerable protocol should continue despite the
threat without these counter measures?

#2

Media-Aware Network Element (MANE) are briefly mentioned in the Security
Considerations, but it is unclear to me how a user can optiin or opt-out
of using these or how it could even evaluate a MANE for trustworthiness.
Does a user even know if there is a MANE ?
And especially combining the two issues, if a MANE can rewrite the SEI,
would it not mean that it could attack a user with malicious data that
appear trusted?

#3

In the IANA Considerations, it points to another section. It is customary
to just make this section stand on its own with clear and explicit instructions
for IANA so they do not need to read or understand large parts of the document.

[Ballot discuss]
Please be aware that this document is far outside my area of expertise,
and my comments might make no sense. Please do not be nervous to tell
me I am wrong - likely I am....

#1

  [VVC] is particularly vulnerable to such
  attacks, as it is extremely simple to generate datagrams containing
  NAL units that affect the decoding process of many future NAL units.
  Therefore, the usage of data origin authentication and data integrity
  protection of at least the RTP packet is RECOMMENDED, for example,
  with SRTP [RFC3711].

Is something is "particularly vulnerable", why is its security counter
measures only RECOMMENDED instead of REQUIRED ? Is there a real world
use case where this vulnerable protocol should continue despite the
threat without these counter measures?

#2

Media-Aware Network Element (MANE) are briefly mentioned in the Security
Considerations, but it is unclear to me how a user can optiin or opt-out
of using these or how it could even evaluate a MANE for trustworthiness.
Does a user even know if there is a MANE ?
And especially combining the two issues, if a MANE can rewrite the SEI,
would it not mean that it could attack a user with malicious data that
appear trusted?

#3

In the IANA Considerations, it points to another section. It is customary
to just make this section stand on its own with clear and explicit instructions
for IANA so they do not need to read or understand large parts of the document.

[Ballot discuss]
lease be aware that this document is far outside my area of expertise,
and my comments might make no sense. Please do not be nervous to tell
me I am wrong - likely I am....

#1

  [VVC] is particularly vulnerable to such
  attacks, as it is extremely simple to generate datagrams containing
  NAL units that affect the decoding process of many future NAL units.
  Therefore, the usage of data origin authentication and data integrity
  protection of at least the RTP packet is RECOMMENDED, for example,
  with SRTP [RFC3711].

Is something is "particularly vulnerable", why is its security counter
measures only RECOMMENDED instead of REQUIRED ? Is there a real world
use case where this vulnerable protocol should continue despite the
threat without these counter measures?

#2

Media-Aware Network Element (MANE) are briefly mentioned in the Security
Considerations, but it is unclear to me how a user can optiin or opt-out
of using these or how it could even evaluate a MANE for trustworthiness.
Does a user even know if there is a MANE ?
And especially combining the two issues, if a MANE can rewrite the SEI,
would it not mean that it could attack a user with malicious data that
appear trusted?

#3

In the IANA Considerations, it points to another section. It is customary
to just make this section stand on its own with clear and explicit instructions
for IANA so they do not need to read or understand large parts of the document.

[Ballot comment]
  forbidden_zero_bit.  Required to be zero in VVC.  Note that the
  inclusion of this bit in the NAL unit header was to enable
  transport of VVC video over MPEG-2 transport systems (avoidance of
  start code emulations) [MPEG2S].  In the context of this memo the
  value 1 may be used

So it MUST be zero but MAY be 1? A bit odd for a "forbidden_zero_bit".
Also, what is "this memo"? Does it mean this document or does it mean [MPEG2S] ?

PayloadHdr appears without value in Figure 3 and with "(Type=28)" in Figure 4.
Does the first occurance without value also use type=28 ? If so, can this be added? If not, can the non-28 value be added?

What does the ":" character denote in Figure 5 ,6 and 8?

  Fragments of the same NAL unit MUST be sent in consecutive
  order with ascending RTP sequence numbers (with no other RTP packets
  within the same RTP stream being sent between the first and last
  fragment).

Why is this? I would say the RTP seq numbers would allow the target to
order the packets, which it has to do anyway if the network causes re-ordering.
Why then, can the host not do this? Eg if it has two crypto modules to
indepdently encrypt these packets without needing to sync sending them to
ensure this requirement?

    Security considerations:
    See Section 9 of RFC XXXX.

Does XXXX refer to this document? eg [RFC TBD1]? Or is this a placeholder
for another RFC that was forgotten and needs fixing? I think it is
for this document since it has Security Considerations in Section 9.

In Section 7.3.2 starts with "This section describes the negotiation of
unicast messages" but really also describes using Multicast so it is a
but contradicting.

  Congestion control for RTP SHALL be used

I always find MUST clearer than SHALL? Might be a non-native english speaker
issue contaminated by Gandalf's speech. The same paragraph uses "MUST monitor"
and not "SHALL monitor", so better at least use either MUST or SHALL for both
of these?

[Ballot comment]
** Section 1.1.2.

The decoding capability information includes parameters that stay
  constant for the lifetime of a VVC bitstream, which in IETF terms can
  translate to a session . 

I appreciate the clarity.  Would it be possible reframe this to be explicit on the definition of this “IETF session” for a reader that might not know what that means?

** Section 4.3.1.  What is the Type value in the PayloadHdr of this Single NAL Unit Packet?  Section 4.3.2 which describes APs says its type value is 28.  Section 4.3.3 which describes fragments says its type is 29.  [VCC] is behind a paywall so I am unable to check the Table 5 per the reference in Section 1.1.4.

** Section 4.3.1.  An early reference to sprop-max-don-diff defined later in the document would be very helpful.

** Section 4.3.3.
  FuType: 5 bits

      The field FuType MUST be equal to the field Type of the fragmented
      NAL unit.

What is the reference for the possible values of this field?

** Section 9.  Thank you for discussing the trade-offs with deploying the MANE.  Since E2E security was noted for deployments without the MANE, please also be explicitly on what including the MANE means.

OLD
  To be allowed to perform
  such operations, a MANE is required to be a trusted entity that is
  included in the security context establishment.

NEW
To be allowed to perform such operations, a MANE is required to be a trusted entity that is included in the security context establishment. 
This on-path inclusion of the MANE forgoes end-to-end security guarantees for the end points.

[Ballot comment]
# Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-avtcore-rtp-vvc-16
CC @evyncke

Thank you for the work put into this document.

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

Special thanks to Bernard Aboba for the shepherd's write-up including the WG consensus, but I miss the justification of the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

Even if the content was a little over my head, it is a nice introduction.

### Section 4.3.2
```
  An AP MUST carry at least two aggregation units and can carry as many
  aggregation units as necessary; however, the total amount of data in
  an AP obviously MUST fit into an IP packet, and the size SHOULD be
  chosen so that the resulting IP packet is smaller than the MTU size
  so to avoid IP layer fragmentation.
```

I am afraid that I do not fully understand the "MUST fit" and "size SHOULD be chosen" because having a size smaller than the MTU is the only way to fit in one IP packet. Should the 2nd "SHOULD" be a "MUST" ?

### Section 4.3.3
```
  Fragments of the same NAL unit MUST be sent in consecutive
  order with ascending RTP sequence numbers (with no other RTP packets
  within the same RTP stream being sent between the first and last
  fragment).
```

What is the expected behaviour of the receiver when packets with fragments are received out of orders ? Section 6 does not seem to cover this.

### Section 7.1

`The receiver MUST ignore any parameter unspecified in this memo.` should this doc leave the door open for other docs to update/augment this specification ?


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-avtcore-rtp-vvc-16. If any part of this review is inaccurate, please let us know.

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

In the video Media Types section on the Media Types registry page located at:

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

a new registration will be made as follows:

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

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note: The actions 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 list of actions that will be performed.

For definitions of IANA review states, please see:

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

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

(END IANA COMMENTS)

The following Last Call announcement was sent out (ends 2022-05-19):

From: The IESG
To: IETF-Announce
CC: avt@ietf.org, avtcore-chairs@ietf.org, bernard.aboba@gmail.com, draft-ietf-avtcore-rtp-vvc@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RTP Payload Format for Versatile Video Coding (VVC)) 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 Versatile Video Coding (VVC)'
  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 2022-05-19. 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 video coding
  standard ITU-T Recommendation H.266 and ISO/IEC International
  Standard 23090-3, both also known as Versatile Video Coding (VVC) and
  developed by the Joint Video Experts Team (JVET).  The RTP payload
  format allows for packetization of one or more Network Abstraction
  Layer (NAL) units in each RTP packet payload as well as fragmentation
  of a NAL unit into multiple RTP packets.  The payload format has wide
  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-vvc/


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

  https://datatracker.ietf.org/ipr/4048/
  https://datatracker.ietf.org/ipr/4914/

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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the RTP payload format for ITU-T Recommendation
  H.266, also know as Versatile Video Coding (VVC). 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.

  Similar to earlier hybrid-video-coding-based standards, including
  HEVC, the following basic video coding design is employed by VVC.  A
  prediction signal is first formed by either intra- or motion-
  compensated prediction, and the residual (the difference between the
  original and the prediction) is then coded.  The gains in coding
  efficiency are achieved by redesigning and improving almost all parts
  of the codec over earlier designs.  In addition, VVC includes several
  tools to make the implementation on parallel architectures easier.
  Finally, VVC includes temporal, spatial, and SNR scalability as well
  as multiview coding support.

  VVC inherits the basic systems and transport interfaces designs from
  HEVC and AVC. These include the NAL-unit-based syntax structure, the
  hierarchical syntax and data unit structure, the supplemental
  enhancement information (SEI) message mechanism, and the video
  buffering model based on the hypothetical reference decoder (HRD).
  The scalability features of VVC are conceptually similar to the
  scalable variant of HEVC known as SHVC.

Working Group Summary:

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

  The VVC RTP payload specification has been simplified, compared
  with HEVC. SDP optional parameters have been reduced.
  While HEVC supported SRST, MRST and MRMT transmission
  modes, VVC only supports SRST, which has been the most commonly
  implemented transmission mode for H.264/SVC and HEVC. As a
  result, the VVC RTP payload specification does not require the
  tx-mode parameter.

  The VVC RTP payload specification also has removed discussion of the
  Slice Loss Indication (SLI) and Reference Picture Selection Indication
  (RPSI) Feedback Messages, both of which are rarely implemented with
  modern codecs.

  In addition to these and other simplifications, the WG discussed support
  for the Framemarking RTP header extension and concluded that it need not
  be supported by the VVC RTP payload specification.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are existing implementations of the VVC (H.266) encoder and decoder, including the VVC Test Model. See:
https://jvet.hhi.fraunhofer.de/

There is a prototype implementation of the VVC RTP payload specification covering the mandatory and some optional features of the media plane.
There is no known implementation of the SDP signaling. So far, there have not been any interop events relating to the VVC RTP payload specification.

There have been no MIB Doctor, Yang Doctor, Media Type or other expert reviews.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd is Bernard Aboba. Responsible AD is Murray Kucherawy.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed draft -14.  Previously, I had reviewed draft-10 and provided comments here:
https://mailarchive.ietf.org/arch/msg/avt/CNYVIC_3T9VQxpm6r8dnctvFiaU/

The authors responded to my comments:
https://mailarchive.ietf.org/arch/msg/avt/5U2GmOLMCwR6cYgCaC8O1iQjKbo/

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The specification has not been reviewed by the SDP Directorate.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document does not raise any unique security, AAA, DNS, DHCP, XML or internationalization issues.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The VVC RTP payload specification has made a considerable effort to reduce the number of optional
features, including transmission modes and SDP parameters. This simplification should address some
of the interoperability issues encountered with the HEVC and H.264/SVC RTP payload specifications.

That said, we are still early in the implementation cycle and no interoperability testing has been done.
In the past, organizations such as IMTC developed profiles as well as producing test suites and
organizing interop events.  However, the IMTC (since merged into MEF)
has no current plans to update the HEVC RTP profile for VVC:
https://www.mef.net/wp-content/uploads/2020/09/IMTC1016_22034_1.pdf

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

On March 8, a request for author confirmation was posted to the mailing list: https://mailarchive.ietf.org/arch/msg/avt/s4qv9h6osUBw9GCMux8cSRu1tJM/

A response was received from each of the authors:

Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/z-squBK_9cc1Ebtb5ZUoVANmw6Q/
Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/_LBJVphT1RRtHCR-p3Mvi1Opu8Y/
Yago Sanchez de la Fuente: https://mailarchive.ietf.org/arch/msg/avt/sDovNWZ5CZ-z7mwnv6ygZFJk7x8/
Ye-Kui Wang: https://mailarchive.ietf.org/arch/msg/avt/s6rJHDcLHq9pgyGZGrBFqx6jxvs/
Miska Hannuksela: https://mailarchive.ietf.org/arch/msg/avt/hn0YMTDYVrqmNVjmvs1kBS1XgEY/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Multiple IPR declarations have been filed:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-rtp-vvc

WG discussion on whether to proceed to publication was requested on March 8, 2022:
https://mailarchive.ietf.org/arch/msg/avt/vH-1ZgsF0EMBqIUy64apLQqLl78/

No objections have been sent to the list, nor were any objections raised when
the issue was brought up at the IETF 113 AVTCORE WG meeting.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus behind this document appears solid. A summary of the
second WGLC is here:
https://mailarchive.ietf.org/arch/msg/avt/g5uv_hrfZtPJmJFEWQaHKDwHFqY/

7 responses to the WGLC announcement were received. Of the responses,
6 favored publication "as is" and 1 provided comments. There were no
objections.

*"As is"*
Stephan Wenger:
https://mailarchive.ietf.org/arch/msg/avt/354RgFgb4EWmQFsFNSC41LDls4M/
Sanchez de la Fuente:
https://mailarchive.ietf.org/arch/msg/avt/S8cY3yBtFmbCYc6n8JrfZ_iddxg/
Ye-Kui Wang:
https://mailarchive.ietf.org/arch/msg/avt/9p3ziA8t9d06U7wnCU5qiNd933A/
Shuai Zhao:
https://mailarchive.ietf.org/arch/msg/avt/3nKG5jR_phMtHBECrjHwgf7am5Q/
Miska Hannuksela:
https://mailarchive.ietf.org/arch/msg/avt/3Kb2VCLGUQLwsPeL8pUW2YhWIXg/
Thomas Schierl:
https://mailarchive.ietf.org/arch/msg/avt/XCzdnL3uonjTZMkgWGdlIhAyCyg/

*Comments provided:*
Mach Chen:
https://mailarchive.ietf.org/arch/msg/avt/PWJ2ZsBwolsHxGiWu-wwfIAOX38/
  Response from Stephan:
https://mailarchive.ietf.org/arch/msg/avt/u40nDpFsD7JveHLu-mkW5wi-PH8/
  Response from Mach:
https://mailarchive.ietf.org/arch/msg/avt/3b2FktXkhYzx3Cd1tXKFUh4J_K0/
  Response from Stephan:

The authors addressed the comments in draft -14.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

An ID nits run on -14 discloses 0 errors, 0 flaws and 1 warning:

idnits 2.17.00 (12 Aug 2021)

/tmp/idnits1001/draft-ietf-avtcore-rtp-vvc-14.txt:
/tmp/idnits1001/draft-ietf-avtcore-rtp-vvc-14.txt(3591): Found non-ascii character (Ã) in position 10.


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (25 February 2022) is 19 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '0' on line
    1390
'transmission order), AbsDon[0] is set equal to DON[0]....'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO23090-3'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VSEI'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VVC'


    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).

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

The document contains no MIBs or YANG modules and does not define URI types. It does define a media type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are references to non-IETF documents, such as the VVC specification:
https://www.itu.int/rec/T-REC-H.266

There are no normative references to documents not ready for advancement or in an unclear state.

However, there is one Informative reference that appears improperly formatted, to [CABAC].

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests allocation of a new media type in Section 7.1. AFAICT the request is consistent with the rest of the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are established by the document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG modules.

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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes the RTP payload format for ITU-T Recommendation
  H.266, also know as Versatile Video Coding (VVC). 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.

  Similar to earlier hybrid-video-coding-based standards, including
  HEVC, the following basic video coding design is employed by VVC.  A
  prediction signal is first formed by either intra- or motion-
  compensated prediction, and the residual (the difference between the
  original and the prediction) is then coded.  The gains in coding
  efficiency are achieved by redesigning and improving almost all parts
  of the codec over earlier designs.  In addition, VVC includes several
  tools to make the implementation on parallel architectures easier.
  Finally, VVC includes temporal, spatial, and SNR scalability as well
  as multiview coding support.

  VVC inherits the basic systems and transport interfaces designs from
  HEVC and AVC. These include the NAL-unit-based syntax structure, the
  hierarchical syntax and data unit structure, the supplemental
  enhancement information (SEI) message mechanism, and the video
  buffering model based on the hypothetical reference decoder (HRD).
  The scalability features of VVC are conceptually similar to the
  scalable variant of HEVC known as SHVC.

Working Group Summary:

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

  The VVC RTP payload specification has been simplified, compared
  with HEVC. SDP optional parameters have been reduced.
  While HEVC supported SRST, MRST and MRMT transmission
  modes, VVC only supports SRST, which has been the most commonly
  implemented transmission mode for H.264/SVC and HEVC. As a
  result, the VVC RTP payload specification does not require the
  tx-mode parameter.

  The VVC RTP payload specification also has removed discussion of the
  Slice Loss Indication (SLI) and Reference Picture Selection Indication
  (RPSI) Feedback Messages, both of which are rarely implemented with
  modern codecs.

  In addition to these and other simplifications, the WG discussed support
  for the Framemarking RTP header extension and concluded that it need not
  be supported by the VVC RTP payload specification.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are existing implementations of the VVC (H.266) encoder and decoder, including the VVC Test Model. See:
https://jvet.hhi.fraunhofer.de/

There is a prototype implementation of the VVC RTP payload specification covering the mandatory and some optional features of the media plane.
There is no known implementation of the SDP signaling. So far, there have not been any interop events relating to the VVC RTP payload specification.

There have been no MIB Doctor, Yang Doctor, Media Type or other expert reviews.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd is Bernard Aboba. Responsible AD is Murray Kucherawy.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed draft -14.  Previously, I had reviewed draft-10 and provided comments here:
https://mailarchive.ietf.org/arch/msg/avt/CNYVIC_3T9VQxpm6r8dnctvFiaU/

The authors responded to my comments:
https://mailarchive.ietf.org/arch/msg/avt/5U2GmOLMCwR6cYgCaC8O1iQjKbo/

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The specification has not been reviewed by the SDP Directorate.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document does not raise any unique security, AAA, DNS, DHCP, XML or internationalization issues.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The VVC RTP payload specification has made a considerable effort to reduce the number of optional
features, including transmission modes and SDP parameters. This simplification should address some
of the interoperability issues encountered with the HEVC and H.264/SVC RTP payload specifications.

That said, we are still early in the implementation cycle and no interoperability testing has been done.
In the past, organizations such as IMTC developed profiles as well as producing test suites and
organizing interop events.  However, the IMTC (since merged into MEF)
has no current plans to update the HEVC RTP profile for VVC:
https://www.mef.net/wp-content/uploads/2020/09/IMTC1016_22034_1.pdf

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

On March 8, a request for author confirmation was posted to the mailing list: https://mailarchive.ietf.org/arch/msg/avt/s4qv9h6osUBw9GCMux8cSRu1tJM/

A response was received from each of the authors:

Shuai Zhao: https://mailarchive.ietf.org/arch/msg/avt/z-squBK_9cc1Ebtb5ZUoVANmw6Q/
Stephan Wenger: https://mailarchive.ietf.org/arch/msg/avt/_LBJVphT1RRtHCR-p3Mvi1Opu8Y/
Yago Sanchez de la Fuente: https://mailarchive.ietf.org/arch/msg/avt/sDovNWZ5CZ-z7mwnv6ygZFJk7x8/
Ye-Kui Wang: https://mailarchive.ietf.org/arch/msg/avt/s6rJHDcLHq9pgyGZGrBFqx6jxvs/
Miska Hannuksela: https://mailarchive.ietf.org/arch/msg/avt/hn0YMTDYVrqmNVjmvs1kBS1XgEY/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Multiple IPR declarations have been filed:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-avtcore-rtp-vvc

WG discussion on whether to proceed to publication was requested on March 8, 2022:
https://mailarchive.ietf.org/arch/msg/avt/vH-1ZgsF0EMBqIUy64apLQqLl78/

No objections have been sent to the list, nor were any objections raised when
the issue was brought up at the IETF 113 AVTCORE WG meeting.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus behind this document appears solid. A summary of the
second WGLC is here:
https://mailarchive.ietf.org/arch/msg/avt/g5uv_hrfZtPJmJFEWQaHKDwHFqY/

7 responses to the WGLC announcement were received. Of the responses,
6 favored publication "as is" and 1 provided comments. There were no
objections.

*"As is"*
Stephan Wenger:
https://mailarchive.ietf.org/arch/msg/avt/354RgFgb4EWmQFsFNSC41LDls4M/
Sanchez de la Fuente:
https://mailarchive.ietf.org/arch/msg/avt/S8cY3yBtFmbCYc6n8JrfZ_iddxg/
Ye-Kui Wang:
https://mailarchive.ietf.org/arch/msg/avt/9p3ziA8t9d06U7wnCU5qiNd933A/
Shuai Zhao:
https://mailarchive.ietf.org/arch/msg/avt/3nKG5jR_phMtHBECrjHwgf7am5Q/
Miska Hannuksela:
https://mailarchive.ietf.org/arch/msg/avt/3Kb2VCLGUQLwsPeL8pUW2YhWIXg/
Thomas Schierl:
https://mailarchive.ietf.org/arch/msg/avt/XCzdnL3uonjTZMkgWGdlIhAyCyg/

*Comments provided:*
Mach Chen:
https://mailarchive.ietf.org/arch/msg/avt/PWJ2ZsBwolsHxGiWu-wwfIAOX38/
  Response from Stephan:
https://mailarchive.ietf.org/arch/msg/avt/u40nDpFsD7JveHLu-mkW5wi-PH8/
  Response from Mach:
https://mailarchive.ietf.org/arch/msg/avt/3b2FktXkhYzx3Cd1tXKFUh4J_K0/
  Response from Stephan:

The authors addressed the comments in draft -14.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

An ID nits run on -14 discloses 0 errors, 0 flaws and 1 warning:

idnits 2.17.00 (12 Aug 2021)

/tmp/idnits1001/draft-ietf-avtcore-rtp-vvc-14.txt:
/tmp/idnits1001/draft-ietf-avtcore-rtp-vvc-14.txt(3591): Found non-ascii character (Ã) in position 10.


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (25 February 2022) is 19 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '0' on line
    1390
'transmission order), AbsDon[0] is set equal to DON[0]....'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO23090-3'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VSEI'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'VVC'


    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).

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

The document contains no MIBs or YANG modules and does not define URI types. It does define a media type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There are references to non-IETF documents, such as the VVC specification:
https://www.itu.int/rec/T-REC-H.266

There are no normative references to documents not ready for advancement or in an unclear state.

However, there is one Informative reference that appears improperly formatted, to [CABAC].

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document requests allocation of a new media type in Section 7.1. AFAICT the request is consistent with the rest of the document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries are established by the document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal languages used.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG modules.

A draft Publication. Request is available here:
https://webrtc.internaut.com/vvc/vvc.txt

Next steps:
* Discussion of IPR declarations at IETF 113: https://docs.google.com/presentation/d/14FG3G4v2Ps333QLC4XMeb3ZaNPvtKMsdUir85x2gsGA/edit#slide=id.g11e64f4e2fb_0_0
* SDP Directorate review (request sent to MMUSIC mailing list:  https://mailarchive.ietf.org/arch/msg/mmusic/l255LSB6IxZhfTwkN8urHgfTJs4/)