Re: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

[Stephan Wenger <[e-mail]>]

Hi Murray,
Thanks for the review.  One question to you, and to the chairs, before we start editing: should we wait for sec-dir and transport-dir reviews?  Are there any of those requested?  Should there be?  (For previous video payload formats, sec-dir wanted to weigh in on the security section and transport on the congestion control.)
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/