[AVTCORE] Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-evc-06: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-avtcore-rtp-evc-06: Discuss

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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-evc-06

Thank you for the work put into this document. The document is well structured
and for many sections easy and clear (noting that I have only skimmed the
hard-core codec parts).

I find it strange to have a normative reference behind a paywall, but I
appreciate the shepherd's note about its availability to reviewers, big thanks
to Stephan

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and one nit.

Special thanks to Bernard Adoba for the shepherd's detailed write-up including
the WG consensus, detailed IPR, and a very concise justification of the
intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

Do not worry :-)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Section 4.3.1

What is the expected decoder behaviour when DONL is present while it should not?

What is meant by `conditional`? Does it mean 'optional' ?

## Section 4.3.2

Should this be a "MUST" in `he value of Reserve and E Must be equal to 0` ?

What is the expected decoder behaviour when `APs MUST NOT be nested; ` is
violated ?


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


# COMMENTS (non-blocking)

## Section 1

Please expand HEVC and AVC before first use.

## Section 1.1

Is `walled-garden implementations` well-known ? To be honest, this is the first
time I see "walled-garden" applied to "implementations".

## Section 1.1.4

Figure 1, any reason why the bit numbers are in a box ? Usually (see figure 2),
the bit numbers are 'naked', i.e., without a frame. Same comment for figure 10
later in the text.

Should this I-D also specifies "nuh_reserved_zero_5bits MUST be set to 0" ?

## Section 4.1

As I am not familiar with the RTP packet structure, is it obvious for the
implementers how the values of P, X, CC, and CSRC are selected ?

## Section 4.3.1

Please expand/explain `DONL`.

I had no time to request the EVC document to check whether PayloadHdr in EVC
cannot be 56/57... I am therefore trusting the authors, WG, and responsible AD
on the absence of collision. It may be worth to add a sentence (perhaps in
section 4.3) stating that PayloadHdr for NUL will never be equal to 56 or 57.

## Section 4.3.3

The use of DONL is really unclear to me (see above), so how can the presence of
DONL be detected in `The DONL field, when present,` ?

As the I-D forbids "atomic" fragment, suggest to use a normative "MUST NOT" in
`the Start bit and End bit must not both be set to 1 in the same FU header`.

When can a receiver detect that there is a missing fragment ? If this is on a
time-out, then should there be some RECOMMENDED value ?

While I like the idea of processing the first n-1 fragments anyway, why not
extending this flexibility to the first n-m fragments (i.e., the last m
fragments were lost) ? Of course, the E-bit based system cannot differentiate
between n-1 and n-m; then, is it worth mentioning it in the text?

## Section 5

Possibly due to my lack of real-time knowledge, but is there a risk to increase
the end-to-end latency is the encoder must wait for several NUL before sending
them ?

## Section 13.1

Is SAP still in use ? Anyway, I do not think that RFC 2974 should be normative
as it is cited as an example, i.e., it should rather be informative.

# NITS (non-blocking / cosmetic)

## Section 4.3

s/The Three different payload/The *t*hree different payload/ ?