Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard

"Dan Wing" <dwing@cisco.com> Tue, 18 December 2012 17:28 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268621F8633 for <mmusic@ietfa.amsl.com>; Tue, 18 Dec 2012 09:28:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.489
X-Spam-Level:
X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD8-2Rd4hvhg for <mmusic@ietfa.amsl.com>; Tue, 18 Dec 2012 09:28:37 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6AE21F862D for <mmusic@ietf.org>; Tue, 18 Dec 2012 09:28:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2212; q=dns/txt; s=iport; t=1355851717; x=1357061317; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eW7thKebPgd6uRPxmUur0shKozXwh106AQhGFiodqZs=; b=GDqTIgU6cz+SQTh90+lalNZNsJtRnrgXX4TpMyQpOUJQ5Gywo7r31p63 saZmTWAWWhAo2xvSI3Ac2UNqqRGmaH5IgRqV8zLAIQvbl70IVk416YHnv i18ubyT4crvNrJbkERXIKOV+lhbOW39KT6Bno5JMPNXBvAOiF8CxqcQ1a g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuUGAPym0FCrRDoG/2dsb2JhbABFg0i6YRZzgh4BAQEECAIwPwwBAwIJDgMEAQEBJwcZLQkIAgQBEgsFiAKoI5BBjEmEQwOIYYUciA2QSIMU
X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208";a="63778854"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 18 Dec 2012 17:28:34 +0000
Received: from DWINGWS01 ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBIHSYCf022281; Tue, 18 Dec 2012 17:28:34 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Glen Zorn' <gwz@net-zen.net>, 'Jonathan Lennox' <jonathan@vidyo.com>
References: <C3759687E4991243A1A0BD44EAC823034DFB915B07@BE235.mail.lan> <50CFCBF9.3070301@net-zen.net>
In-Reply-To: <50CFCBF9.3070301@net-zen.net>
Date: Tue, 18 Dec 2012 09:28:34 -0800
Message-ID: <0d4c01cddd45$1b443830$51cca890$@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: AQIoYaEQK4bEwygAtyzO2Ml1f9vkzwGOdUiNl11R0vA=
Content-Language: en-us
Cc: draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org, mmusic@ietf.org
Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-xr-discard
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: Tue, 18 Dec 2012 17:28:37 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Glen Zorn
> Sent: Monday, December 17, 2012 5:51 PM
> To: Jonathan Lennox
> Cc: draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org; mmusic@ietf.org;
> gwz@net-zen.net
> Subject: Re: [MMUSIC] SDP Directorate review of draft-ietf-xrblock-rtcp-
> xr-discard
> 
> On 12/17/2012 10:49 PM, Jonathan Lennox wrote:
> 
> > I have been asked to perform  the SDP Directorate review for
>  > draft-ietf-xrblock-rtcp-xr-discard. I reviewed the -10 version of the
> > document.
>  >
>  >
>  >
>  > Syntactically, the SDP usage in this document seems fine. It is a  >
> simple and correct usage of an extension point defined in RFC 3711.
>  >
>  >
>  >
>  > However, the statement in Section 4 that "XR blocks MAY be used  >
> without explicit signaling" is confusing, as it implies that the  >
> entire SDP section is entirely optional. This document should at  >
> least reference Section 5 of RFC 3711, which gives guidance as to  >
> when SDP signaling of the use of XR blocks is recommended.
>  >
> 
> I'm not sure why this is confusing (aside from fact that RFC 3711 is
> itself confusing: it says "although the use of SDP signaling for XR
> blocks may be optional, if used, it MUST be used as defined here". /May/
> be optional?  Optionality seems pretty black and white to me ;-).  That
> said, however, it does seem to be relatively clear that the usage of SDP
> /is/ optional & along with it the section on SDP in this and other
> similar drafts.  What am I missing?

(RFC3611, you both meant to write.  RFC3711 is SRTP, RFC3611 is RTCP-XR).

SDP lines are supposed to be declarative or negotiated.  RTCP-XR seems to
have done neither:  SDP is just there as a check-box.

What is missing is an explanation of when and why would an endpoint would 
include the SDP, and when and why would it omit the SDP.

But, if the endpoints are going to send RTCP-XR whenever it wants,
no matter if the remote end cares to receive RTCP-XR, why do we have
SDP defined at all?  Just send RTCP-XR and let's save SDP implementation
effort and remove the SDP definitions.

-d