[AVTCORE] Re: Éric Vyncke's Discuss on draft-ietf-avtcore-rtcp-green-metadata-16: (with DISCUSS)

[Yong He <[e-mail]>]

Dear Éric and IESG,

A new revision (-d17) has been uploaded to address the open DISCUSS on the expected receiver's behaviors when receiving invalid requests.

The additional text is added to section 4.2.2 as follows,
"If the request receiver has received TSRR with Frame Rate, Picture Width or Picture Height value of 0, it MUST ignore the TSRR message. If the request receiver has received TSRR with the Frame Rate, Picture Width or Picture Height greater than the frame Rate, picture width or picture height negotiated via SDP, it MUST ignore the TSRR message."

Any further feedback on the -d17 revision would be greatly appreciated.

Best regards,
Yong
________________________________
From: Eric Vyncke (evyncke) <[e-mail]>
Sent: Wednesday, September 9, 2026 3:07 AM
To: Yong He <[e-mail]>; The IESG <[e-mail]>; Stephan Wenger <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-avtcore-rtcp-green-metadata-16: (with DISCUSS)


CAUTION: This email originated from a known Qualcomm vendor. Please exercise caution with any unexpected requests, links, or attachments.

Hello Yong

I am sorry but this is an IETF document, so, in my view, it should follow the IETF ways of writing specifications, including the expected receiver behaviour when receiving badly formatted frames.

Regards

-éric

From: Yong He <[e-mail]>
Date: Thursday, 27 August 2026 at 17:39
To: The IESG <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>; Stephan Wenger <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-avtcore-rtcp-green-metadata-16: (with DISCUSS)

Hi Eric,

Regarding the concern, "What should the decoder/receiver do when `The value of Frame Rate equal to 0 MUST NOT be sent` is violated ?", I share Stephan's view on this matter, if my understanding is correctly. It is preferable not to specify any normative behavior for handling non-compliant requests and instead leave the response to the decoder/receiver implementation. Implementers should have the flexibility to decide how best to handle such invalid requests.

I removed the original text that requires the decoder/receiver to ignore the invalid requests as I consider this the simplest approach and believe it aligns with Stephen's recommendation.

BR, Yong


________________________________
From: Éric Vyncke via Datatracker <[e-mail]>
Sent: Thursday, August 27, 2026 1:58 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Éric Vyncke's Discuss on draft-ietf-avtcore-rtcp-green-metadata-16: (with DISCUSS)

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Éric Vyncke has entered the following ballot position for
draft-ietf-avtcore-rtcp-green-metadata-16: 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-rtcp-green-metadata/



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

Thanks for the -16 revision of this document as it addresses most of my
blocking and COMMENT issues (see
https://mailarchive.ietf.org/arch/msg/avt/Jl37msuWJmxEQC9VvGzOoCwekPc/)

There is still a remaining blocking issue that was not addressed (or did I miss
it ?), Stephan Wenger offered several solutions (see
https://mailarchive.ietf.org/arch/msg/avt/5TIhVvfSxd12DxPhgdQVaS5ZD2M/)

### Sections 4.1.1 & 4.2.1 (and possibly others)

What should the decoder/receiver do when `The value of Frame Rate equal to 0
MUST NOT be sent` is violated ?