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

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

Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 012D821F8AAC for <mmusic@ietfa.amsl.com>; Fri, 14 Dec 2012 14:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.483
X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kaSaXzBYktDO for <mmusic@ietfa.amsl.com>; Fri, 14 Dec 2012 14:29:36 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 95D3B21F8AA9 for <mmusic@ietf.org>; Fri, 14 Dec 2012 14:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1355524176; x=1356733776; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=p+p7P+hi/F+/qprwj2LLSNDm4m9N3ePsm1eGxls1eSI=; b=mxYeADVUaxH0jVmaobjb9E9WOa1N2upL3xPSpQueOZn9+VvmprkiWyX2 8DI+dXof62miJQBwRi6hZ2IrfktZQ4SZiBqmdykh0UyLBsC+QXIBnXV3y Yg52c4miJyldr7vlrovvNtUb2XRP/a5k4Zlu2ifvzwepOHICkI5mEUZGT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AngIACWny1CrRDoG/2dsb2JhbABFg0i7QhZzgiUIAjA/DQVoPwEEHgWIAg29Co1xgykDiGCFHIgNgRyPLIMU
X-IronPort-AV: E=Sophos;i="4.84,284,1355097600"; d="scan'208";a="63489394"
Received: from mtv-core-1.cisco.com ([]) by mtv-iport-1.cisco.com with ESMTP; 14 Dec 2012 22:29:35 +0000
Received: from DWINGWS01 ([]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBEMTZd2021288; Fri, 14 Dec 2012 22:29:35 GMT
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
X-Mailer: Microsoft Outlook 14.0
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
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 22:29:41 -0000

This is my SDP Directorate review of

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

  * 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