One document matched: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3550 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3611 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc4585 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc4566 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc6390 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6390.xml">
<!ENTITY rfc6776 PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6776.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-discard PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-discard.xml">
<!ENTITY I-D.ietf-xrblock-rtcp-xr-burst-gap-discard PUBLIC "" 
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-xrblock-rtcp-xr-burst-gap-discard.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<rfc ipr="trust200902"
     docName="draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05.txt" category="std">
<!-- What is the category field value-->
<front>
    <title abbrev="RTCP XR Discard RLE">
         RTP Control Protocol (RTCP) Extended Reports (XR) for  Run Length
         Encoding (RLE) of Discarded Packets
    </title>

    <author initials="J." surname="Ott" fullname="Joerg Ott">
      <organization>Aalto University</organization>
      <address>
        <postal>
          <street>School of Electrical Engineering</street>
          <street>Otakaari 5 A</street>
          <city>Espoo</city> 
          <region>FIN</region><code>02150</code>
          <country>Finland</country>
        </postal>
        <email>jo@comnet.tkk.fi</email>
      </address>
    </author>
    
    <author fullname="Varun Singh" initials="V" surname="Singh">
      <organization>Aalto University</organization>
      <address>
        <postal>
          <street>School of Electrical Engineering</street>
          <street>Otakaari 5 A</street>
          <city>Espoo</city>
          <region>FIN</region>
          <code>02150</code>
          <country>Finland</country>
        </postal>
        <email>varun@comnet.tkk.fi</email>
        <uri>http://www.netlab.tkk.fi/~varun/</uri>
      </address>
    </author>
    
    <author initials="I." surname="Curcio" fullname="Igor D.D. Curcio">
      <organization>Nokia Research Center</organization>
      <address>
        <postal>
          <street>P.O. Box 1000 (Visiokatu 3)</street>
          <city>Tampere</city> <region>FIN</region><code>33721</code>
          <country>Finland</country>
        </postal>
        <email>igor.curcio@nokia.com</email>
      </address>
    </author>

    <date year="2012" />
    <area>RAI</area>
    <workgroup>XR Block Working Group</workgroup>
    <keyword>RTP</keyword>
    <keyword>RTCP</keyword>
    <keyword>discard metrics</keyword>
    <abstract>
      <t>
      The RTP Control Protocol (RTCP) is used in conjunction with the Real-
      time Transport Protocol (RTP) in to provide a variety of short-term and
      long-term reception statistics. The available reporting may include
      aggregate information across longer periods of time as well as
      individual packet reporting. This document specifies a per-packet report
      metric capturing individual packets discarded from the jitter buffer
      after successful reception.
      </t>
    </abstract>
</front>
<middle>

  <section title="Introduction">
    <t>
      <xref target="RFC3550">RTP</xref> provides a transport for real-time
      media flows such as audio and video together with the RTP control
      protocol (RTCP) which provides periodic feedback about the media streams
      received in a specific duration. In addition, RTCP can be used for
      timely feedback about individual events to report (e.g., packet loss)
      <xref target="RFC4585"/>. Both long-term and short-term feedback enable
      a sender to adapt its media transmission and/or encoding dynamically to
      the observed path characteristics.
    </t>

    <t>
      <xref target="RFC3611">RFC3611</xref> defines RTCP Extended Reports as a
      detailed reporting framework to provide more than just the coarse RR
      statistics.  The detailed reporting may enable a sender to react more
      appropriately to the observed networking conditions as these can be
      characterized better, although at the expense of extra overhead.
    </t>
    <t>
      Among many other report blocks, RFC3611 specifies the Loss RLE block
      which reports runs of packets received and lost with the granularity of
      individual packets. This can help both error recovery and path loss
      characterization. In addition to lost packets, RFC3611 defines the
      notion of "discarded" packets: packets that were received but dropped
      from the jitter buffer because they were either too early (for
      buffering) or too late (for playout). The "discard rate" metric is part
      of the VoIP metrics report block even though it is not just applicable
      to audio: it is specified as the fraction of discarded packets since the
      beginning of the session. See section 4.7.1 of <xref
      target="RFC3611">RFC3611</xref>.
    </t>
    <t>
      Recently proposed extensions to the XR reporting suggest enhancing this
      discard metric:
      <list style="symbols">
    <t>
      Reporting the number of discarded packets in a measurement interval,
      i.e., during either the last reporting interval or since the beginning
      of the session, as indicated by a flag in the suggested XR report <xref
      target="I-D.ietf-xrblock-rtcp-xr-discard"/>. If an endpoint needs to
      report packet discard due to other reasons than early- and late-arrival
      (for example, discard due to duplication, redundancy, etc.) then it
      should consider using the Discarded Packets Report Block <xref
      target="I-D.ietf-xrblock-rtcp-xr-discard"/>.
    </t>
    <t>
      Reporting gaps and bursts of discarded packets during a measurement
      interval, i.e., the last reporting interval or the duration of the
      session <xref target="I-D.ietf-xrblock-rtcp-xr-burst-gap-discard"/>.
    </t>
      </list>
    </t>
    <t>
      However, none of these metrics allow a receiver to report precisely
      which packets were discarded. While this information could in theory be
      derived from high-frequency reporting on the number of discarded packets
      <xref target="I-D.ietf-xrblock-rtcp-xr-discard"/> or from the gap/burst
      report <xref target="I-D.ietf-xrblock-rtcp-xr-burst-gap-discard"/>,
      these two mechanisms do not appear feasible: The former would require an
      unduly high amount of reporting which still might not be sufficient due
      to the non-deterministic scheduling of RTCP packets. The latter incur
      significant complexity and reporting overhead and might still not
      deliver the desired accuracy.
    </t>
    <t>
      This document defines a discard report block following the idea of the
      run-length encoding applied for lost and received packets in 
      <xref target="RFC3611" />.
    </t>
    <t>
      Complementary to or instead of the indication which packets were
      discarded, an XR block is defined to indicate the number of bytes
      discarded, per interval or for the duration of the session, similar to
      other XR report blocks.
     </t>
<!--    <t>
      Alternatively, if the sender keeps a history of the size of the packets reported 
      in the measurement interval then the sender can calculate the number of 
      bytes discarded from the information in the discard RLE block. 
    </t> -->
</section>

<section title="Terminology" anchor="sec-terminology">
  <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    in this document are to be interpreted as described in BCP 14,
    <xref target="RFC2119">RFC 2119</xref> and indicate requirement
    levels for compliant implementations.
  </t>
  <t>
    The terminology defined in <xref target="RFC3550">RTP</xref> and
    in the extensions for XR reporting <xref target="RFC3611"/> applies.
  </t>
</section>

<section title="XR Discard RLE Report Block" anchor="spec">
  <t>
    The XR Discard RLE report block uses the same format as specified for the
    loss and duplicate report blocks in <xref target="RFC3611" />. <xref
    target="packet-format-rle"/> recaps the packet format. The fields "BT",
    "T", "block length", "SSRC of source", "begin_seq", and "end_seq" SHALL
    have the same semantics and representation as defined in <xref
    target="RFC3611" />. The "chunks" encoding the run length SHALL have the
    same representation as in RFC3611, but encode discarded packets.
  </t>
  <t>
    <figure anchor="packet-format-rle" title="XR Discard Report Block">
      <artwork><![CDATA[
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=DRLE   |rsvd |E|   T   |         block length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk 1              |             chunk 2           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          chunk n-1            |             chunk n           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ]]></artwork>
    </figure>
  </t>
  <t>
    Block Type (BT, 8 bits): A Run-length encoded Discarded Packets Report
    Block is identified by the constant DRLE.
  </t>
  <t>
    [Note to RFC Editor: please replace DRLE with the IANA provided RTCP XR
    block type for this block. Please remove this note prior to publication as
    an RFC.]
  </t>
  <t>
    rsvd (3 bits): These reserved bits SHOULD be set to zero by receivers and
    MUST be ignored by senders.
  </t>
  <t>
    The 'E' bit is introduced to distinguish between packets discarded due
    to early arrival and those discarded due to late arrival.  The 'E' bit
    MUST be set to '1' if the chunks represent packets discarded due to
    too early arrival and MUST be set to '0' otherwise.
  </t>
  <t>
    In case both early and late discarded packets shall be reported, two
    Discard RLE report blocks MUST be included; their sequence number range
    MAY overlap, but individual packets MUST only be reported as either early
    or late and not appear marked in both. Packets reported in neither are
    considered to be properly received and not discarded.
  </t>
  <t>
    Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP RR
    as a compound RTCP packet.
  </t>
<!--  <t>
    Editor's node: is it acceptable to use one of the 'reserved' bits for this
    purpose or should two block types be used?
  </t> -->
</section>
<section title="XR Bytes Discarded Report Block" anchor="spec-2">
  <t>
    The XR Bytes Discarded report block uses the following format which
    follows the model of the framework for performance metric development
    <xref target="RFC6390" />.
  </t>
  <t>
    <!-- Todo: change I to 2-bits -->
    <figure anchor="packet-format-bytes" title="XR Bytes Discarded Report Block">
      <artwork><![CDATA[
    0               1               2               3
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=BDR    | I |E|reserved |       block length=2          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  number of bytes discarded                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
    </figure>
  </t>
  <t>
    Block Type (BT, 8 bits): A Bytes Discarded Packets Report Block is
    identified by the constant BDR.
  </t>
  <t>
    [Note to RFC Editor: please replace BDR with the IANA provided RTCP XR
    block type for this block. Please remove this note prior to publication as
    an RFC.]
  </t>
  <t>
    The Interval Metric flag (I) (2 bits) is used to indicate whether the
    discard metric is Interval, or a Cumulative metric, that is, whether the
    reported value applies to the most recent measurement interval duration
    between successive reports (I=10, the Interval Duration) or to the
    accumulation period characteristic of cumulative measurements (I=11, the
    Cumulative Duration). Since the bytes discarded are not measured at a
    particular time instance but over one or several reporting intervals, the
    metric MUST NOT be reported as a Sampled Metric (I=01).
  </t>
<!--[Changed because I bit in MONARCH is 2 bits ]
Numerical values for sampled duration are provided in the
Measurement Identifier block referenced by the tag field below.

      The Interval Metric flag (I) (1 bit) is used to indicate whether the
      Post-Repair Loss metric is an Interval or a Cumulative metric, that is, 
      whether the reported value applies to the most recent measurement interval
      duration between successive metrics reports (I=1) (the Interval
      Duration) or to the accumulation period characteristic of
      cumulative measurements (I=0) (the Cumulative Duration).
      Numerical values for both these intervals are provided in the
      Measurement Identifier block referenced by the tag field below.
      
      
<t>
    Measurement Identifier association (Tag) 3 bits:

    This field is used to identify the Measurement Identifier block
    which describes the sampled measurement. The tag in the corresponding 
    Measurement Identifier block has the same tag value. Note that there 
    may be more than one Measurement Identifier block per RTCP packet.
    The tag MUST be set to 0 when using cumulative or interval durations.
</t>

      
      -->
  <t>
    The 'E' bit is introduced to distinguish between packets discarded due to
    early arrival and those discarded due to late arrival. The 'E' bit MUST be
    set to '1' if it reports bytes discarded due to early arrival and MUST be
    set to '0' if it reports bytes discarded due to late arrival. In case both
    early and late discarded packets shall be reported, two Bytes Discarded
    report blocks MUST be included.
  </t>
  <t>
    These reserved bits (5 bits) SHOULD be set to zero by receivers and MUST
    be ignored by senders.
  </t>
  <t>
    block length (16 bits) MUST be set to 2, in accordance with the definition
    of this field in <xref target="RFC3611" />. The block MUST be discarded if
    the block length is set to a different value.
  </t>
  <t>
    The 'number of bytes discarded' is a 32-bit unsigned integer value
    indicating the total number of bytes discarded. 
  </t>
  <t>
    If Interval Metric flag (I=11) is set, the value in the field indicates
    the number of bytes discarded from the start of the session, if Interval
    Metric flag (I=01) is set, it indicates the number of bytes discarded
    since the last RTCP XR Byte Discarded Block was received.
  </t>
  <t>
    If the XR block follows a measurement identity block <xref
    target="RFC6776"/> in the same RTCP
    compound packet then the cumulative (I=11) or the interval (I=10) for this
    report block corresponds to the values of the "measurement duration" in
    the measurement information block.
  </t>
  <t>
    <!--
    Bytes Discarded Report Blocks SHOULD be sent in conjunction with an RTCP RR
    as a compound RTCP packet.
    -->
    If the receiver sends the Bytes Discarded Report Block without the
    measurement identity block then the discard block MUST be sent in
    conjunction with an RTCP RR as a compound RTCP packet.
  </t>
<!--  <t>
    Editor's note: is it acceptable to use one of the 'reserved' bits for this
    purpose or should two block types be used?
  </t> -->
</section>

<section title="Protocol Operation" anchor="protocol">
  <t>
    This section describes the behavior of the reporting (= receiver) node and
    the media sender.
  </t>
  <section title="Reporting Node (Receiver)">
    <t>
      Transmission of RTCP XR Discard RLE Reports is up to the discretion
      of the receiver, as is the reporting granularity.  However, it is
      RECOMMENDED that the receiver signals all discarded packets using
      the method defined in this document.  If all packets over a reporting
      period were lost, the receiver MAY use the Discard Report Block
      <xref target="I-D.ietf-xrblock-rtcp-xr-discard"/> instead.  In case
      of limited available reporting bandwidth, it is up to the receiver
      whether or not to include RTCP XR Discard RLE reports.
    </t>
    <t>
      The receiver MAY send the Discard RLE Reports as part of the
      regularly scheduled RTCP packets as per RFC3550.  It MAY also
      include Discard RLE Reports in immediate or early feedback
      packets as per RFC4585.
    </t>
  </section>
  <section title="Media Sender">
    <t>
      The media sender MUST be prepared to operate without receiving any
      Discard RLE reports.  If Discard RLE reports are generated by the
      receiver, the sender cannot rely on all these reports being received,
      nor can the sender rely on a regular generation pattern from the 
      receiver side.
    </t>
    <t>
      However, if the sender receives any RTCP reports but no Discard RLE
      report blocks and is aware that the receiver supports Discard RLE
      report blocks, it MAY assume that no packets were discarded at the
      receiver.
    </t>
    <t>
     The sender SHOULD accept the Bytes Discarded Report Block only if it is
     received in a compound RTCP receiver report or if it is preceded by a
     measurement identity block <xref target="RFC6776"/>.
     Under all other circumstances it MUST ignore the block.
    </t>
  </section>
</section>

<section title="SDP signaling" anchor="sdp">
<!--  <t>
    The report blocks specified in this document define extensions to RTCP XR
    reporting. Whether or not this specific extended report is sent is left to
    the discretion of the receiver. Its presence may enable better operation
    of the sender since more detailed information is available. Not providing
    this information will make the sender rely on other RTCP reports.
  </t> -->
  <t>
    A participant of a media session MAY use SDP to signal its support for the
    two report blocks specified in this document or use them without any
    prior signaling (see section 5 of <xref target="RFC3611" />).
  </t>
  <t>
    For signaling in SDP, the RTCP XR attribute as defined in <xref
    target="RFC3611" /> MUST be used. The SDP <xref target="RFC4566" />
    attribute 'xr-format' defined in RFC3611 is augmented as described in the
    following to indicate the RLE discard metric and bytes discarded metric.
  </t>
  <t>
    <figure>
    <artwork><![CDATA[
   rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 
                    CRLF   ; defined in [RFC3611]
   
   xr-format       =/ xr-discard-rle
                    / xr-discard-bytes
   
   xr-discard-rle   = "discard-rle"
   xr-discard-bytes = "discard-bytes"
   ]]></artwork>
    </figure>
  </t>
  <t>
    The parameter 'discard-rle' MUST be used to indicate support for the
    Discard RLE Report Block defined in <xref target="spec"/>, the parameter
    'discard-bytes' to indicate support for the Bytes Discarded Report Block
    defined in <xref target="spec-2"/>
  </t>
<!--  <t>
    For signaling support of the RLE discard metric and bytes discarded
    metric, the rules defined in RFC3611 apply. Generally, senders and
    receivers SHOULD indicate this capability if they support these metrics
    and would like to use it in the specific media session being signaled. The
    receiver MAY decide not to send discard information unless it knows about
    the sender's support to save on RTCP reporting bandwidth.
  </t> -->
  <t>
    When SDP is used in Offer/Answer context, the mechanism defined in <xref
    target="RFC3611" /> for unilateral "rtcp-xr" attribute parameters applies
    (see section 5.2 of <xref target="RFC3611" />).
  </t>
</section>

<section title="Security Considerations" anchor="security">
  <t>
    The security considerations of <xref target="RFC3550" />, <xref
    target="RFC3611" />, and <xref target="RFC4585" /> apply. Since this
    document offers only a more precise reporting for an already existing
    metric, no further security implications are foreseen.
  </t>
</section>


<section title="IANA Considerations" anchor="iana">
  <t>
    New block types for RTCP XR are subject to IANA registration.  For
    general guidelines on IANA considerations for RTCP XR, refer to
    <xref target="RFC3611" />.
  </t>
  <section title="XR Report Block Registration">
    <t>
      This document extends the IANA "RTP Control Protocol Extended Reports
      (RTCP XR) Block Type Registry" by two new values: DRLE and BDR.
    </t>
    <t>
      [Note to RFC Editor: please replace DRLE and BDR with the IANA provided
      RTCP XR block type for this block here and in the diagrams above. Please
      remove this note prior to publication as an RFC.]
    </t>
  </section>
  <section title="SDP Parameter Registration">
    <t>
      This document registers two new parameters for the Session Description
      Protocol (SDP), "discard-rle" and "discard-bytes", in the "RTP Control
      Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP)
      Parameters Registry".
    </t>
  </section>
  <section title="Contact information for IANA registrations">
    <t>
      Joerg Ott (jo@comnet.tkk.fi)
    </t>
    <t>
      Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland.
    </t>
  </section>  
</section>
<section title="Acknowledgements">
  <t>
    Thanks to Qin Wu, Colin Perkins, Dan Romascanu, Roni Even and Dan Wing for
    providing valuable feedback on earlier versions of this draft
  </t>
</section>

</middle>
<back>

    <references title="Normative References"> 
        &rfc2119;
        &rfc3550;
        &rfc3611;
        &rfc4585;
        &rfc4566;
        &rfc6390;
        &rfc6776;
    </references>
    
    <references title="Informative References"> 
        &I-D.ietf-xrblock-rtcp-xr-discard;
        &I-D.ietf-xrblock-rtcp-xr-burst-gap-discard;
    </references>
    
    <section anchor="App-a" title="Change Log"> 
        <t>Note to the RFC-Editor: please remove this section prior to
           publication as an RFC.</t> 
        <section title="changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00"> 
            <t><list style="symbols">
                <t>Changed the interval flag from 1 to 2 bits in the discarded 
                    bytes report. Also added the measurement identification 
                    tag to the block.</t>
                <t>Added this section.</t>
            </list></t>
        </section>
        <section title="changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01"> 
            <t><list style="symbols">
                <t>Removed the measurement identification tag in the bytes
                discarded block.</t>
            </list></t>
        </section>
        <section title="changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02"> 
            <t><list style="symbols">
                <t>Removed the extra Tag bits from the Discarded bytes XR block.</t>
                <t>Clarified use of measurement identity block in Section
                     4 and 5.2</t>
            </list></t>
        </section>
        <section title="changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03"> 
            <t><list style="symbols">
                <t>Added explanation for block length in bytes discarded block.</t>
                <t>Added an acknowledgement section.</t>
            </list></t>
        </section>
        <section title="changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04"> 
            <t><list style="symbols">
                <t>Added Block Type definition to each XRBlock.</t>
                <t>Made changes requested in WGLC.</t>
            </list></t>
        </section>
        <section title="changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05"> 
            <t><list style="symbols">
                <t>Made changes requested by SDP directorate.</t>
            </list></t>
        </section>
    </section>
  </back>

</rfc>

<!-- LocalWords: xref CDATA  -->