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

[Stephan Wenger <[e-mail]>]

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 <[e-mail]> on behalf of "Murray S. Kucherawy" <[e-mail]>
Date: Monday, April 11, 2022 at 10:55
To: IETF AVTCore WG <[e-mail]>
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/