[payload] Benjamin Kaduk's No Objection on draft-ietf-payload-rtp-vc2hq-06: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-payload-rtp-vc2hq-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-vc2hq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the clear Security Considerations section.
I am a little uncertain about the privacy properties of the padding
data, though, largely due to my uncertainty about the details of how
the padding works.  (This is, perhaps, in a similar vein to Eric's
general concerns on interoperability.)

In particular, Section 4.2 says that the Data Length for a Padding
Data Unit "may have any value" and "indicates the size of the
recommended padding".  There is also an "Optional Payload Data" in
Figure 6, and I failed to find a description of what its contents
are for padding data units.  Section 4.5.1's coverage of the Padding
Data Parse Info Header suggests that the "native VC-2" and RTP
padding elements are essentially distinct, with the RTP one being
essentially a recommendation to add a VC-2 one, but giving no
mandatory guidance on how much padding to apply.  In this scenario I
don't know what the purpose of the "optional payload data" in Figure
6 be, though.  Padding is of course ignored by the actual VC-2
decoder, so the concern would mostly be if the (RTP) bits on the
wire include a side channel or "stegangraphic channel" (not exactly
the normal meaning of that one) where identifying information could
be inserted, unbeknownst to the recipient.  This could come into
play if media encryption is not used, or when a middlebox/mixer is
used, or probably in other scenarios as well.  The specification of
all-zeros padding along with the Padding Data Parse Info Header of
course removes any such channel at that point, but I didn't see
a real confirmation that there was no channel in the RTP bits on the
wire.

Some additional section-by-section comments follow.

Section 4.1

   Timestamp: 32 bits  If the packet contains transform parameters or
         coded slice data for a coded picture then the timestamp
         corresponds to the sampling instant of the coded picture.  A
         90kHz clock SHOULD be used.  A single RTP packet MUST NOT
         contain coded data for more than one coded picture, so there is
         no ambiguity here.

Is this a new requirement or quoting a preexisting one?  If a new
requirement, I suggest replacing "so there is no ambiguity here"
with "in order to eliminate any chance for ambiguity".

Section 4.2

         If the receiver does not receive a transform parameters packet
         for a picture then it MAY assume that the parameters are
         unchanged since the last picture, or MAY discard the picture.

Those seem like two very different options!  How would I choose
between them?


We only get the starting x- and y-coordinates of a slice for the
first slice in a packet; it sounds like the main VC-2 spec specifies
the order in which the following slices are laid out?
(Do we need to say anything about what "x coordinate" and "y
coordinate" mean?  I seem to recall that over history there have
existed pixel identifying schemes that put the origin at both the
top left and bottom left of the display.)

Section 4.5.1

There is some text here and elsewhere that seems to imply reusing a
Parse Info Header for various data received in different RTP
packets, potentially even from different coded pictures.  The Parse
Info Header contains "next" and "prev parse offset"s, though --
when would those offsets need to be updated?

   o  A receiver MAY combine all fragment data units (with parse code
      0xEC) and the same picture number into a single picture data unit
      with parse code 0xE8.  If the stream is required to comply with
      major versions 1 or 2 of the VC-2 Spec then this MUST be done.

The "and" in "and the same picture number" seems to be an editing
error; maybe "with" is better?

   o  Once a data unit has been assembled, whether a Sequence Header,
      Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the
      next parse offset and previous parse offset values in its Parse
      Info Header should be filled with the offset between the start of
      the header and the start of the next or previous.

This text could probably be tightened up with respect to which
next/previous fields are updated when, and what values go in them.
E.g., do we have enough information to fill in the "previous" field
when we start assembling a data unit, and the "next" when we finish
assembling that data unit?

Section 6.1

Perhaps "RFC XXXX" makes more sense as the "published specification"
than ST 2042-1?  That is, this is where the (mandatory) RTP framing
is required, so it may be a better starting point for an
implementor.