Re: [AVTCORE] Comments on draft-he-avtcore-rtcp-green-metadata

[Yong He <[e-mail]>]

Hi Stephan, Jonathan, all,

Thank Stephan for clarifying ISO/IEC standard sharing policy. I just sent a separate email to Stephan with the 23001-11 DIS link.

Please see my response to Jonathan’s comments inline below.

Thanks,
Yong

From: avt <[e-mail]> On Behalf Of Stephan Wenger
Sent: Thursday, July 21, 2022 11:19 PM
To: Jonathan Lennox <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [AVTCORE] Comments on draft-he-avtcore-rtcp-green-metadata


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

In an attempt to nip the discussion about public availability of ISO/IEC standards in the butt:

  1.  ISO/IEC standards are behind paywalls and the forces that be in ISO will generally not allow sharing an ISOIEC standard without payment.  There are exception mechanisms, but they are increasingly difficult to use.  Personally, I do not consider the Green Metadata work to likely become subject of such an ISO exception and, AFAIK, SC29 has not specifically asked for this standard to become free.
  2.  The IETF has no requirement that normative references must be available for free.
  3.  The IETF has an existing Cat A liaison relationship with ISO/IEC/SC29 and its WGs.  Through this relationship, WG documents, including for example technically identical pre-ballot versions of an ISO standard can be shared with the IETF.
  4.  Perhaps in order to prevent widespread circumvention of the paid business model for ISO standards, ISO staff has previously expressed a preference to use the mechanism under point 3 above only with regards to those IETFers who specifically request access to an ISO document, for example for the purpose of review IETF documents that normatively reference the ISO standard.
  5.  Above has worked for a number of ISO standards and IETF RFCs, most recently for the JPEG-XS work.  I suggest we use it here as well.

To simplify things, and speaking as the IETF’s liaison manager towards SC29 and MPEG, I can offer my service as a clearing house:

Authors of draft-he-avtcore-rtcp-green-metadata: please point me to the MPEG input document that is closest to the ISO/IEC DIS 23001-11.  I will download that document using my MPEG credentials.
IETFers interested in reviewing draft-he-avtcore-rtcp-green-metadata: please let me know if you want a copy of the document.  I will send it to you by private email.

Good?

Thanks,
Stephan


From: avt <[e-mail]<mailto:[e-mail]>> on behalf of Jonathan Lennox <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 21, 2022 at 23:39
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [AVTCORE] Comments on draft-he-avtcore-rtcp-green-metadata

Hi - I read over draft-he-avtcore-rtcp-green-metadata in advance of the IETF meeting.

Some comments as an individual:

My first question is whether there is a freely-available (non-paywalled) version of the [GreenMetadata] spec?

In the absence of this, it is somewhat difficult to completely understand the semantics of the TSRR message as this document is currently written, so it might be useful to specify the semantics in full in this document, and cite [GreenMetadata] only informatively.

That said, I infer that the message's intended semantic is “this is the maximum resolution/frame rate I am interested in displaying at this time”.  Is this correct?  If so this seems like a useful semantic, and I can see how it could be used to save both energy and other resources.

A few more minor comments as an individual:

The FMT values you chose for your message are already assigned - please see https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-9 for the list of the currently-assigned values.  The next two free values are 11 and 12.  (There’s no need to repeat the assignments from RFC 4585 or 5104 in your document.)
[Yong]  Thanks for the reference, I’ll update the FMT values and remove the assignments in next version

The ability to specify a resolution or frame rate of 0, meaning “no video bitstream is requested”, seems to overlap in semantics with the PAUSE/RESUME semantics defined in RFC 7728, and also with various higher-level ways of turning video on and off; rather than have to specify how these mechanisms interact, it might be better for this specification to forbid values of 0.
[Yong] good point, I’ll update the draft to forbid values of 0 in next version

Finally, the URL in the reference for [GreenMetadata] points to the ISO standard "ISO 5834-1:2019: Implants for surgery — Ultra-high-molecular-weight polyethylene — Part 1: Powder form”, which I suppose is indicative of the broad range of topics that ISO standardizes.  I suspect you instead meant to point at https://www.iso.org/standard/83674.html.
[Yong] You are right, the URL is wrong, will correct it in next version as well.

As a chair, my question is the usual one: if we standardized this, is there a community that would be interested in implementing and using it?
[Yong] During the development of green metadata standard in MPEG we have seen major chip company’s (including Qualcomm, Samsung and others) interest in this for real-time communication