<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.2 (Ruby 2.6.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-he-avtcore-rtcp-green-metadata-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="RTCP Messages for Green Metadata">RTP Control Protocol (RTCP) Messages for Green Metadata</title>

    <author initials="Y." surname="He" fullname="Yong He">
    <organization>Qualcomm</organization>
      <address>
        <postal>
          <street>5775 Morehouse Drive</street>
          <city>San Diego</city>
          <code>92121</code>
          <country>USA</country>
        </postal>
        <email>yonghe@qti.qualcomm.com</email>
      </address>
    </author>
    <author initials="W." surname="Zia" fullname="Waqar Zia">
      <organization>Qualcomm</organization>
      <address>
        <postal>
          <street>Anzinger Str. 13</street>
          <city>Munich</city>
          <code>81671</code>
          <country>Germany</country>
        </postal>
        <email>wzia@qti.qualcomm.com</email>
      </address>
    </author>
    <author initials="C." surname="Herglotz" fullname="Christian Herglotz">
      <organization>FAU</organization>
      <address>
        <postal>
          <street>Schlossplatz 4</street>
          <city>Erlangen</city>
          <code>91054</code>
          <country>Germany</country>
        </postal>
        <email>christian.herglotz@fau.de</email>
      </address>
    </author>
    <author initials="E." surname="Francois" fullname="Edouard Francois">
      <organization>InterDigital</organization>
      <address>
        <postal>
          <street>975 Avenue des Champs Blancs</street>
          <city>Cesson-Sevigne</city>
          <code>35576</code>
          <country>France</country>
        </postal>
        <email>edouard.francois@interdigital.com</email>
      </address>
    </author>


    <date year="2022" month="July" day="29"/>

    <area>ART</area>
    <workgroup>AVTCORE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
<abstract>
<t>This memo describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this document enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services.</t>
</abstract>
  </front>
  <middle>
<section anchor="introduction"><name>Introduction</name>
<t>ISO/IEC 23001-11 specification, Energy Efficient Media Consumption (Green metadata) <xref target="GreenMetadata"/>, 
specifies metadata that facilitates reduction of energy usage during media consumption. Two main types of metadata are 
defined in the specification. The first type consists of metadata generated by a video encoder which provides information 
about the decoding complexity of the delivered bitstream and about the quality of the decoded content. This first type of 
metadata is conveyed via the supplemental enhancement information (SEI) message mechanism specified in the video coding 
standard ITU-T Recommendation H.264 and ISO/IEC 14496-10 <xref target="AVC"/>, H.265 and ISO/IEC 23008-5 <xref target="HEVC"/>, 
H.266 and ISO/IEC 23090-3 <xref target="VVC"/>.</t>
<t>The second type consists of metadata generated by a decoder as feedback conveyed to the encoder to adapt the decoder 
energy consumption. This document focuses on this second type of metadata which is conveyed as extension of RTCP feedback 
messages <xref target="RFC4585"/>. The feedback in the second type of metadata specified in ISO/IEC 23001-11 <xref target="GreenMetadata"/> 
includes decoder operations reduction request, coding tools configuration request and spatial and temporal scaling request. 
This document defines new RTCP payload format for the spatial and temporal resolution request and notification feedback message.</t>
</section>
<section anchor="conventions"><name>Conventions</name>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

</section>
<section anchor="definitionsandabbr"><name>Abbreviations</name>
<t>AVPF: The extended RTP profile for RTCP-based feedback</t>
<t>FCI:  Feedback Control Information <xref target="RFC4585"/></t>
<t>FMT:  Feedback Message Type <xref target="RFC4585"/></t>
<t>PSFB: Payload-specific FB message <xref target="RFC4585"/></t>
<t>TSRR: Temporal-Spatial Resolution Request</t>
<t>TSRN: Temporal-Spatial Resolution Notification</t>
</section>
<section anchor="format-of-rtcp-feedback-messages"><name>Format of RTCP Feedback Messages</name>
<t>This document extends the RTCP feedback messages defined in the RTP/AVPF <xref target="RFC4585"/> and <xref target="RFC5104"/> 
by defining a Green Metadata feedback message. The message can be used by the receiver to inform the sender of the desirable coding 
spatial resolution and temporal resolution (frame rate) of the bitstream delivered, and by the sender to indicate the coding spatial 
and temporal resolution it will use henceforth.</t>
<t>RTCP Green Metadata feedback message follows a similar message format as RTCP Temporal-Spatial Trade-off Request and 
Notification <xref target="RFC5104"/>. The message may be sent in a regular full compound RTCP packet or in an early RTCP packet, 
as per the RTP/AVPF rules. </t>
<t>This document specifies two additional payload-specific feedback messages: Temporal-Spatial Resolution 
Request (TSRR) and Temporal-Spatial Resolution Notification (TSRN)</t>

<section anchor="temporalspatial-resolution-request"><name>Temporal-Spatial Resolution Request</name>
<t>The TSRR feedback message is identified by RTCP packet type value PT=PSFB and FMT=11.</t>
<t>The FCI field MUST contain one or more TSRR FCI entries.</t>
<section anchor="message-format"><name>Message format</name>
<t>The content of the FCI entry for the Temporal-Spatial Resolution Request is depicted in <xref target="tsrr"/>. </t>
<figure anchor="tsrr"><artwork><![CDATA[
 
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Seq nr.     |         Reserved          |   Frame Rate      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Picture Width         |    Picture Height           |0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Syntax of an FCI Entry in the TSRR Message
]]></artwork></figure>

<t>SSRC (32 bits): The Synchronization Source (SSRC) of the media sender that is requested to apply the frame rate and picture resolution.</t>
<t>Seq nr. (8 bits): Request sequence number. The sequence number space is unique for pairing of the SSRC of request source and 
the SSRC of the request target. The sequence number SHALL be increased by 1 modulo 256 for each new command. A repetition SHALL 
NOT increase the sequence number. The initial value is arbitrary.</t>
<t>Reserved (14 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.</t>
<t>Frame Rate (10 bits): frames_per_second. This field specifies the frame rate as defined in clause 5.3 of <xref target="GreenMetadata"/>. 
An integer value between 1 and 1023 that indicates the coding frame rate that is requested.  The value of Frame Rate equal to 0 is illegal.</t>
<t>Picture Width (14 bits): pic_width_in_luma_samples. This field specifies the picture width as defined in clause 5.3 of 
<xref target="GreenMetadata"/>. An integer value between 1 and 16383 that indicates the coding picture width in the units of 
luma samples that is requested. The value of Picture Width equal to 0 is illegal.</t>
<t>Picture Height (14 bits): pic_height_in_luma_samples. This specifies the picture height as defined in clause 5.3 of 
<xref target="GreenMetadata"/>. An integer value between 1 and 16383 that indicates the coding picture height in the units of 
luma samples that is requested. The value of Picture Height equal to 0 is illegal.</t>
</section>
<section anchor="semantics"><name>Semantics</name>
<t>A decoder can suggest a temporal-spatial resolution by sending a TSRR message to an encoder. If the encoder is capable of 
adjusting its temporal-spatial resolution, it SHOULD take into account the received TSRR message for future coding of pictures. 
</t>
<t>The reaction to the reception of more than one TSRR message by a media sender from different media receivers is left open 
to the implementation. The selected Frame Rate, Picture Width and Picture Height SHALL be communicated to the media receivers 
by means of the TSRN message (see section  <xref target="n-temporalspatial-resolution-notification-tsrn"/>).</t>
<t>Within the common packet header for feedback messages (as defined in section 6.1 of <xref target="RFC4585"/>), 
the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL 
be set to 0. The SSRCs of the media senders to which the TSRR applies are in the corresponding FCI entries. </t>
<t>A TSRR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.</t>
</section>
<section anchor="timing-rules"><name>Timing Rules</name>
<t>The timing follows the rules outlined in section 3 of <xref target="RFC4585"/>. This request message is not time critical 
and SHOULD be sent using regular RTCP timing. Only if it is known that the user interface requires quick feedback, the message 
MAY be sent with early or immediate feedback timing.</t>
</section>
<section anchor="handling-of-message-in-mixers-and-translators"><name>Handling of Message in Mixers and Translators</name>
<t>A mixer or media translator that encodes content sent to the session participant issuing the TSRR SHALL consider the request 
to determine if it can fulfill it by changing its own encoding parameters. A media translator unable to fulfill the request MAY 
forward the request unaltered towards the media sender. A mixer encoding for multiple session participants will need to consider 
the joint needs of these participants before generating a TSRR on its own behalf towards the media sender.</t>
</section>
</section>
<section anchor="n-temporalspatial-resolution-notification-tsrn"><name>Temporal-Spatial Resolution Notification (TSRN)</name>
<t>The TSRN message is identified by RTCP packet type value PT=PSFB and FMT=12.</t>
<t>The FCI field SHALL contain one or more TSRN FCI entries.</t>
<section anchor="n-message-format-0"><name>Message format</name>
<t>The content of the FCI entry for the Temporal-Spatial Resolution Notification is depicted in   <xref target="tsrn"/>. </t>
<figure anchor="tsrn"><artwork><![CDATA[
 
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Seq nr.     |         Reserved          |   Frame Rate      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Picture Width         |    Picture Height           |0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Syntax of an FCI Entry in the TSRN Message
]]></artwork></figure>

<t>SSRC (32 bits): The Synchronization Source (SSRC) of the source of the TSRR that resulted in this notification.</t>
<t>Seq nr. (8 bits): The sequence number value from the TSRR that is being acknowledged.</t>
<t>Reserved (14 bits): All bits SHALL be set to 0 by the sender and SHALL be ignored on reception.</t>
<t>Frame Rate (10 bits): The frame rate the media sender is using henceforth.</t>
<t>Picture Width (14 bits): The coding picture width the media sender is using henceforth.</t>
<t>Picture Height (14 bits): The coding picture height the media sender is using henceforth.</t>
<t>It is to note that the returned value (Frame Rate, Picture Width, Picture Height) may differ from the requested one, 
for example, in cases where a media encoder cannot change its frame rate or picture resolution, or when pre-recorded content is used.</t>
</section>
<section anchor="semantics-0"><name>Semantics</name>
<t>This feedback message is used to acknowledge the reception of a TSRR. For each TSRR received targeted at the session participant, 
a TSRN FCI entry SHALL be sent in a TSRN feedback message. A single TSRN message MAY acknowledge multiple requests using multiple 
FCI entries. The Frame Rate, Picture Width and Picture Height value included SHALL be the same in all FCI entries of the TSRN message. 
Including an FCI for each requestor allows each requesting entity to determine that the media sender received the request. 
The notification SHALL also be sent in response to TSRR repetitions received. If the request receiver has received TSRR with 
several different sequence numbers from a single requestor, it SHALL only respond to the request with the highest (modulo 256) 
sequence number. Note that the highest sequence number may be a smaller integer value due to the wrapping of the field. Appendix A.1 
of <xref target="RFC3550"/> has an algorithm for keeping track of the highest received sequence number for RTP packets; it could be 
adapted for this usage. </t>
<t>The TSRN SHALL include the Temporal-Spatial Resolution Frame Rate, Picture Width and Picture Height that will be used as a result 
of the request. This is not necessarily the same Frame Rate, Picture Width and Picture Height as requested, as the media sender may 
need to aggregate requests from several requesting session participants. It may also have some other policies or rules that limit 
the selection.</t>
<t>Within the common packet header for feedback messages (as defined in section 6.1 of <xref target="RFC4585"/>), the "SSRC of packet 
sender" field indicates the source of the Notification, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of 
the requesting entities to which the Notification applies are in the corresponding FCI entries.</t>
</section>
<section anchor="timing-rules-0"><name>Timing Rules</name>
<t>The timing follows the rules outlined in section 3 of <xref target="RFC4585"/>. This acknowledgement message is not extremely time 
critical and SHOULD be sent using regular RTCP timing.</t>
</section>
<section anchor="handling-of-tsrn-in-mixers-and-translators"><name>Handling of TSRN in Mixers and Translators</name>
<t>A mixer or translator that acts upon a TSRR SHALL also send the corresponding TSRN. In cases where it needs to forward a TSRR itself, 
the notification message MAY need to be delayed until the TSRR has been responded to.</t>
</section>
</section>
</section>
<section anchor="Security"><name>Security Considerations</name>

<t>The defined messages have certain properties that have security
implications. These must be addressed and taken into account by
users of this protocol.</t>

<t>Spoofed or maliciously created feedback messages of the type defined in this specification can have the following implications:</t>

<t><list style="symbols">
  <t>severely reduced picture resolution due to false TSRR messages that sets the picture width and height to a very low value;</t>
  <t>severely reduced frame rate due to false TSRR messages that sets the frame rate to a very low value.</t>
</list></t>
<t>To prevent these attacks, there is a need to apply authentication and integrity protection of the feedback messages. This can be
accomplished against threats external to the current RTP session using the RTP profile that combines Secure RTP <xref target="SRTP"/> and 
AVPF into SAVPF <xref target="SAVPF"/>. In the mixer cases, separate security contexts and filtering can be applied between the mixer and the participants, 
thus protecting other users on the mixer from a misbehaving participant.</t>

</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>Placeholder</t>

</section>

  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC3550' target='https://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></author>
<author fullname='R. Frederick' initials='R.' surname='Frederick'><organization/></author>
<author fullname='V. Jacobson' initials='V.' surname='Jacobson'><organization/></author>
<date month='July' year='2003'/>
<abstract><t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions 
suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network 
services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data 
transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast 
networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the 
underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in 
this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes 
to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm 
for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join 
a session simultaneously.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>

<reference anchor='RFC4585' target='https://www.rfc-editor.org/info/rfc4585'>
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title>
<author fullname='J. Ott' initials='J.' surname='Ott'><organization/></author>
<author fullname='S. Wenger' initials='S.' surname='Wenger'><organization/></author>
<author fullname='N. Sato' initials='N.' surname='Sato'><organization/></author>
<author fullname='C. Burmeister' initials='C.' surname='Burmeister'><organization/></author>
<author fullname='J. Rey' initials='J.' surname='Rey'><organization/></author>
<date month='July' year='2006'/>
<abstract><t>Real-time media streams that use RTP are, to some degree, resilient against packet losses.  
Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception 
statistics and thus allow a sender to adapt its transmission behavior in the mid-term.  This is the sole means for 
feedback and feedback-based error repair (besides a few codec-specific mechanisms).  This document defines an extension 
to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders 
and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented.  
This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.  
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4585'/>
<seriesInfo name='DOI' value='10.17487/RFC4585'/>
</reference>

<reference anchor='RFC5104' target='https://www.rfc-editor.org/info/rfc5104'>
<front>
<title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</title>
<author fullname='S. Wenger' initials='S.' surname='Wenger'><organization/></author>
<author fullname='U. Chandra' initials='U.' surname='Chandra'><organization/></author>
<author fullname='M. Westerlund' initials='M.' surname='Westerlund'><organization/></author>
<author fullname='B. Burman' initials='B.' surname='Burman'><organization/></author>
<date month='February' year='2008'/>
<abstract><t>This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). 
They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use.  
However, some are also usable in smaller multicast environments and point-to-point calls.</t><t>The extensions discussed are 
messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and 
Temporal-Spatial Trade-off.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5104'/>
<seriesInfo name='DOI' value='10.17487/RFC5104'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor="GreenMetadata" target='https://www.iso.org/standard/83674.html'>
  <front>
    <title>ISO/IEC DIS 23001-11, Information technology - MPEG Systems Technologies - Part 11: Energy-Efficient Media Consumption (Green Metadata)</title>
    <author >
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>

    </references>

    <references title='Informative References'>
    
<reference anchor="VVC" target="http://www.itu.int/rec/T-REC-H.266">
  <front>
    <title>Versatile Video Coding, ITU-T Recommendation H.266</title>
    <author >
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>


<reference anchor="HEVC" target="https://www.itu.int/rec/T-REC-H.265">
  <front>
    <title>High efficiency video coding, ITU-T Recommendation H.265</title>
    <author >
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>


<reference anchor="AVC" target="https://www.itu.int/rec/T-REC-H.264">
  <front>
    <title>Advanced video coding, ITU-T Recommendation H.264</title>
    <author >
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>

<reference anchor="SRTP" target="https://datatracker.ietf.org/doc/pdf/rfc3711">
  <front>
    <title>The Secure Real-time Transport Protocol(SRTP)</title>
    <author fullname='M. Baugher' ><organization/></author>
    <author fullname='D. McGrew' ><organization/></author>
    <author fullname='M. Naslund' ><organization/></author>
    <author fullname='E. Carrara' ><organization/></author>
    <author fullname='K. Norrman' ><organization/></author>
    <date year="2004"/>
  </front>
</reference>

<reference anchor="SAVPF" target="https://datatracker.ietf.org/doc/pdf/rfc5124">
  <front>
    <title>"Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)" </title>
    <author fullname='J. Ott' ><organization/></author>
    <author fullname='E. Carrara' ><organization/></author>
    <date year="2008"/>
  </front>
</reference>

    </references>
    
<section anchor="changehistory"><name>Change History</name>
<t>To RFC Editor: PLEASE REMOVE ThIS SECTION BEFORE PUBLICATION</t>

<t>draft-he-avtcore-rtcp-green-metadata-00 ........ initial version</t>    
<t>draft-he-avtcore-rtcp-green-metadata-01 ........ editorial corrections</t>    
</section>

  </back>
</rfc>
