Last Call Review of draft-ietf-avtcore-rtp-evc-05
review-ietf-avtcore-rtp-evc-05-artart-lc-blanchet-2023-09-30-00

I've been assigned as ART reviewer for this draft. I am no expert in RTP
payload, so this review did not verify the validity of the technical solution,
if is sound or not, etc., while I did read it with the most diligence I could.

with the i18n eye, since no user/generic strings seems to be used, don't see
any i18n issues.

Comments (not really substantive to the protocol):
- section 7.3.2.1: "An implementation SHOULD be able to understand all media
type parameters (including all optional media type parameters), even if it
doesn't support the functionality related to the parameter. ". This sentence
seems weird to me. If a new media type parameter is defined and the
implementation is already used in the field, then there is no way that the
implementation will be able to understand that parameter. Maybe I’m not
understanding the context here. - section 9: "the RTP packet is RECOMMENDED but
NOT REQUIRED based on the thoughts". Should this be rephrased using SHOULD and
MUST NOT to use RFC2119 wording? - section 9: "For example, it would be a bad
and insecure implementation practice to forward any JavaScript a decoder
implementation detects to a web browser.". Cannot parse this sentence. Maybe it
is missing a « to » or something. Or it is me. - section 10: Congestion
Control. is after the Security section. Typically, Security is the last section
before IANA. No big issue here. Maybe RTP docs do ordering differently. More an
observation than real issue.

Nits:
- s/MPGEG-2/MPEG-2/ (unless MPGEG is something I don't know)
- section 7.3.2.1, figure 11: the values "O" and "X" are not used in the table.
maybe remove them?

Orthography suggestions (also depends on UK vs US orthographies):
- s/neighbor/neighbour/
- s/signaled/signalled/
- s/signaling/signalling/
- s/behavior/behaviour/