[MMUSIC] draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04

"Dan Wing" <dwing@cisco.com> Fri, 14 December 2012 22:29 UTC

From: Dan Wing <dwing@cisco.com>
To: mmusic@ietf.org
Date: Fri, 14 Dec 2012 14:29:35 -0800
Message-ID: <053001cdda4a$7eea6ce0$7cbf46a0$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac3aSCtAs73c0EdzS3SSzI+PgXhD8w==
Content-Language: en-us
Cc: jo@comnet.tkk.fi, draft-ietf-xrblock-rtcp-xr-discard-rle-metrics@tools.ietf.org, varun@comnet.tkk.fi
Subject: [MMUSIC] draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04
Precedence: list

This is my SDP Directorate review of
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04.

Section 6 of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 left me
a bit puzzled.  It was not clear until the very end of that section
that including the defined SDP lines was entirely optional (MAY).
This does not align with RFC3611 (RTCP-XR), which says:
  "If a participant receives an SDP offer and understands the
   "rtcp-xr" attribute but does not wish to implement XR functionality
   offered, its answer SHOULD include an "rtcp-xr" attribute without
   parameters. By doing so, the party declares that, at a minimum, is
   capable of understanding the signaling."

I would like the authors to consider:

  * A shorter SDP section, something like
    http://tools.ietf.org/html/rfc5725#section-4

  * adding an explanation of the benefits (or harm) of including the
    new discard-rle and discard-bytes formats on the a=rtcp-xr line,
    so that implementers can weigh the benefit (or harm) of including
    one or both of those new formats on the a=rtcp-xr line.

  * align the document with RFC3611 (RTCP-XR), especially that the new
    discard-rle and discard-bytes are negotiated in SDP when doing
    Offer/Answer, or describe in the document why RFC3611's
    Offer/Answer model is inappropriate for discard-rle and for
    discard-bytes.

-d

[MMUSIC] draft-ietf-xrblock-rtcp-xr-discard-rle-m… Dan Wing