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

["Murray S. Kucherawy" <[e-mail]>]

I didn't request them because only WGLC has been done.  SECDIR will be
automatically requested once this enters IETF LC; we can add a TSVDIR
review too.

If the chairs want to request early reviews before we start IETF LC, that's
totally fine with me.

-MSK

On Mon, Apr 11, 2022 at 11:37 AM Stephan Wenger <[e-mail]> wrote:

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