[AVTCORE] Paul Wouters' No Objection on draft-ietf-avtcore-rtp-vvc-17: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-avtcore-rtp-vvc-17: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

My DISCUSSes were addressed in version -17 (see 
https://mailarchive.ietf.org/arch/msg/avt/RZr6jWX-S1u6k0efT1Gm-YAbXZw/)

Old DISCUSSes:

Please be aware that this document is far outside my area of expertise,
and my comments might make no sense. Please do not be nervous to tell
me I am wrong - likely I am....

#1

   [VVC] is particularly vulnerable to such
   attacks, as it is extremely simple to generate datagrams containing
   NAL units that affect the decoding process of many future NAL units.
   Therefore, the usage of data origin authentication and data integrity
   protection of at least the RTP packet is RECOMMENDED, for example,
   with SRTP [RFC3711].

If something is "particularly vulnerable", why is its security counter
measures only RECOMMENDED instead of REQUIRED ? Is there a real world
use case where this vulnerable protocol should continue despite the
threat without these counter measures?

#2

Media-Aware Network Element (MANE) are briefly mentioned in the Security
Considerations, but it is unclear to me how a user can opt-in or opt-out
of using these or how it could even evaluate a MANE for trustworthiness.
Does a user even know if there is a MANE ?
And especially combining the two issues, if a MANE can rewrite the SEI,
would it not mean that it could attack a user with malicious data that
appear trusted?

#3

In the IANA Considerations, it points to another section. It is customary
to just make this section stand on its own with clear and explicit instructions
for IANA so they do not need to read or understand large parts of the document.

COMMENTS:

   forbidden_zero_bit.  Required to be zero in VVC.  Note that the
   inclusion of this bit in the NAL unit header was to enable
   transport of VVC video over MPEG-2 transport systems (avoidance of
   start code emulations) [MPEG2S].  In the context of this memo the
   value 1 may be used

So it MUST be zero but MAY be 1? A bit odd for a "forbidden_zero_bit".
Also, what is "this memo"? Does it mean this document or does it mean [MPEG2S] ?
(also, "forbidden zero" kind of reads like "forbidden to be zero" which is
the opposite of what is meant)

PayloadHdr appears without value in Figure 3 and with "(Type=28)" in Figure 4.
Does the first occurance without value also use type=28 ? If so, can this be
added? If not, can the non-28 value be added?

What does the ":" character denote in Figure 5 ,6 and 8?

  Fragments of the same NAL unit MUST be sent in consecutive
   order with ascending RTP sequence numbers (with no other RTP packets
   within the same RTP stream being sent between the first and last
   fragment).

Why is this? I would say the RTP seq numbers would allow the target to
order the packets, which it has to do anyway if the network causes re-ordering.
Why then, can the host not do this? Eg if it has two crypto modules to
independently encrypt these packets without needing to sync sending them to
ensure this requirement?

    Security considerations:
    See Section 9 of RFC XXXX.

Does XXXX refer to this document? eg [RFC TBD1]? Or is this a placeholder
for another RFC that was forgotten and needs fixing? I think it is
for this document since it has Security Considerations in Section 9.

In Section 7.3.2 starts with "This section describes the negotiation of
unicast messages" but really also describes using Multicast so it is a
bit contradicting.

   Congestion control for RTP SHALL be used

I always find MUST clearer than SHALL? Might be a non-native english speaker
issue contaminated by Gandalf's speech. The same paragraph uses "MUST monitor"
and not "SHALL monitor", so better at least use either MUST or SHALL for both
of these?