Subject: Re: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14--looking for help on the media type registration stuff

From: Stephan Wenger <[email-masked]>
Date: Wed, 13 Apr 2022 16:43:56 +0000

Hi Murray and all,

I went through Murray’s comments in a bit more detail.  Most of them are easily addressable and make sense to me.

The one I find personally unpalatable is the need to rework the media type registration.  In my experience, real-world systems using any of the advanced features of the newer ITU video codecs use means not based on SDP for capability exchange.  Webrtc is nowadays mostly VP9 based, and I have not heard of an HEVC/RFC7798 based webrtc system using more than the barebones of the RFC7798 media type.  No one seems to use SIP anymore, and certainly(?) not in conjunction with modern codecs.  Frankly, I at least consider most of this section boilerplate, except for that it gives implementation advise for those who use jingle or whatnot.  For that, we don’t need template compliance.  Addressing boilerplate for boilerplate’s sake is annoying.

What we did when drafting this section was to start with RFC7798’s media type registration, and adjusted from there.  It looks like RFC7798 may well have the same problems as this draft.  No one has ever complained about it.

I wonder whether there’s anyone here on this list with a) an interest in VVC’s media type registration, and b) at least basic knowledge of the requirements of RFC6838?  If that person would step forward and help us with that section, I would very much appreciate it.

Failing that, we will try to populate the template based on the current text and our (likely incomplete) understanding of the details of RFC6838.  Which will probably lead to us getting things wrong, and in more review cycles.

So, in short: HELP, PLEASE.

Thanks,
Stephan

From: avt <[email-masked]> on behalf of "Murray S. Kucherawy" <[email-masked]>
Date: Monday, April 11, 2022 at 10:55
To: IETF AVTCore WG <[email-masked]>
Subject: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

Hi all,

Comments on this draft before we move it forward.  I bounced around the document as I went through this, checking references and whatnot, so this is not in any particular order.

Generally, this seems to be in good shape.  Structurally, the major thing that needs attention is the IANA stuff.  A pet peeve of mine in documents these days is abuse of SHOULD, but this seems to have used it properly for the most part (I raised a couple of them below) so kudos there.

This is an area of ART in which I'm not particularly strong, so it's possible there are technical issues I've missed.  I'm trusting that the WG and other reviewers are comfortable with how solid this is in that regard.

As a reminder, I will be around for the rest of this week and then on vacation from IETF work until May.

-MSK

INTERESTING STUFF
SECTION 1

The first sentence of the first paragraph appears to be incomplete.

SECTION 7.1

This media type registration form is not complete.  Several sections are missing.  Please use the template found in Section 5.6 of RFC 6838.  Also, "Required Parameters" should be "N/A", not "None".

I suggest you include the completed template in Section 11.  It can refer to Section 7.1 for all the details about the optional parameters, etc.

The general format of this section is also confusing.  For instance, it gradually goes through all of the optional parameters, but then just after "interop-constraints", which is an optional parameter, it gets into "sprop-sublayer-id" which is not in the list at the top of the template.  I can't tell if there should be a section break here, or if the list of optional parameters is incomplete, or something else.

SECTION 3.2

This section lists "RPS" as an acronym used in this document, but it isn't.

SECTION 4.3.2

When would an implementation legitimately not do what the SHOULD says here?

SECTION 7.2.2.3
I don't understand the SHOULD here.  Can this work if an implementation doesn't understand all of the media type parameters?  When might one legitimately continue without that being the case?

APPENDIX A

Please add a note to the RFC Editor to delete this section prior to publication (which I assume is the intent).

NITS
SECTION 1.1.1

"... the maximum size of coding tree unit ..." -- missing "a" or "the"?

s/signalling/signaling/

SECTION 1.1.2

s/labelled/labeled/

s/labelling/labeling/ (2x)

s/signalling/signaling/ (2x)

s/MPGEG/MPEG/

SECTION 1.1.3

s/signalling/signaling/ (3x)

SECTION 5

"... aggregation packet together one or more NAL units ..." -- missing a "with"?

SECTION 6

"... RTP sequences number ..." -- s/sequences/sequence/

SECTION 7.1

s/signalling/signaling/

s/signalled/signaled/ (3x)

SECTION 10

s/achieving/achieved/

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Apr 2022 10:13:19 -0700

Stephan --

You raise a good question about the usefulness of defining SDP parameters
which are unlikely to be implemented.  The RTP payload specification for
VVC has done a good job of dropping features (e.g. MRST) which were rarely
implemented, or caused interop issues. Is this another opportunity to apply
the "less is more" principle?

There is a WebRTC implementation of HEVC in Safari behind a flag, and it
seems quite possible that there will be a WebRTC implementation of VVC as
well.  RFC 7742 Section 6.2 defines the WebRTC SDP parameters for H.264,
and my understanding is that H.265/H.266 implementations are likely to take
a similar approach.  For example, RFC 7742 specifies that sprop-parameters
are always sent in-band, not signaled in SDP.

In terms of how to proceed with registering a modern codec, it does seem
that the bar has been raised.   The AV1 registration had some of the same
challenges (and frustrations):
https://www.iana.org/assignments/media-types/video/AV1

BTW, in looking through the IANA registration pages, one weird thing I
found is that a number of recent payload formats have not made their way
into the IANA registry:
Real-Time Transport Protocol (RTP) Parameters (iana.org)
<https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-2>

On Wed, Apr 13, 2022 at 9:44 AM Stephan Wenger <[email-masked]> wrote:

> The one I find personally unpalatable is the need to rework the media type
> registration.  In my experience, real-world systems using any of the
> advanced features of the newer ITU video codecs use means not based on SDP
> for capability exchange.  Webrtc is nowadays mostly VP9 based, and I have
> not heard of an HEVC/RFC7798 based webrtc system using more than the
> barebones of the RFC7798 media type.  No one seems to use SIP anymore, and
> certainly(?) not in conjunction with modern codecs.  Frankly, I at least
> consider most of this section boilerplate, except for that it gives
> implementation advise for those who use jingle or whatnot.  For that, we
> don’t need template compliance.  Addressing boilerplate for boilerplate’s
> sake is annoying.
>
>
>
> What we did when drafting this section was to start with RFC7798’s media
> type registration, and adjusted from there.  It looks like RFC7798 may well
> have the same problems as this draft.  No one has ever complained about it.
>
>
>
> I wonder whether there’s anyone here on this list with a) an interest in
> VVC’s media type registration, and b) at least basic knowledge of the
> requirements of RFC6838?  If that person would step forward and help us
> with that section, I would very much appreciate it.
>
>
>
> Failing that, we will try to populate the template based on the current
> text and our (likely incomplete) understanding of the details of RFC6838.
> Which will probably lead to us getting things wrong, and in more review
> cycles.
>
>
>
> *From: *avt <[email-masked]> on behalf of "Murray S. Kucherawy" <
> [email-masked]>
> *Date: *Monday, April 11, 2022 at 10:55
> *To: *IETF AVTCore WG <[email-masked]>
> *Subject: *[AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14
>
>
>
> Hi all,
>
>
>
> Comments on this draft before we move it forward.  I bounced around the
> document as I went through this, checking references and whatnot, so this
> is not in any particular order.
>
>
>
> Generally, this seems to be in good shape.  Structurally, the major thing
> that needs attention is the IANA stuff.  A pet peeve of mine in documents
> these days is abuse of SHOULD, but this seems to have used it properly for
> the most part (I raised a couple of them below) so kudos there.
>
>
>
> This is an area of ART in which I'm not particularly strong, so it's
> possible there are technical issues I've missed.  I'm trusting that the WG
> and other reviewers are comfortable with how solid this is in that regard.
>
>
>
> This media type registration form is not complete.  Several sections are
> missing.  Please use the template found in Section 5.6 of RFC 6838.  Also,
> "Required Parameters" should be "N/A", not "None".
>
>
>
> I suggest you include the completed template in Section 11.  It can refer
> to Section 7.1 for all the details about the optional parameters, etc.
>
>
>
> The general format of this section is also confusing.  For instance, it
> gradually goes through all of the optional parameters, but then just after
> "interop-constraints", which is an optional parameter, it gets into
> "sprop-sublayer-id" which is not in the list at the top of the template.  I
> can't tell if there should be a section break here, or if the list of
> optional parameters is incomplete, or something else.
>
>
>
> SECTION 3.2
>
>
>
> I don't understand the SHOULD here.  Can this work if an implementation
> doesn't understand all of the media type parameters?  When might one
> legitimately continue without that being the case?
>
>
>
> APPENDIX A
>
>
>
> Please add a note to the RFC Editor to delete this section prior to
> publication (which I assume is the intent).
>
>
>
> NITS
>
> SECTION 1.1.1
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>