Re: [AVT] Open issue on hdrext draft

David R Oran <oran@cisco.com> Fri, 05 October 2007 23:06 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwFb-0007ax-LL; Fri, 05 Oct 2007 19:06:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdwFY-0007ab-O8 for avt@ietf.org; Fri, 05 Oct 2007 19:06:28 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdwFX-000094-I1 for avt@ietf.org; Fri, 05 Oct 2007 19:06:28 -0400
X-IronPort-AV: E=Sophos;i="4.21,237,1188802800"; d="scan'208";a="231521973"
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 05 Oct 2007 16:06:27 -0700
Received: from [10.32.245.156] ([10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id l95LfHAb022793; Fri, 5 Oct 2007 14:42:20 -0700
In-Reply-To: <470449BC.50603@rogers.com>
References: <p06240851c316f756a59b@[10.0.1.9]> <470449BC.50603@rogers.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <00B93312-D040-4240-8443-A5D40804866A@cisco.com>
Content-Transfer-Encoding: 7bit
From: David R Oran <oran@cisco.com>
Subject: Re: [AVT] Open issue on hdrext draft
Date: Fri, 05 Oct 2007 15:38:27 -0400
To: Tom Taylor <tom.taylor@rogers.com>
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1672; t=1191620541; x=1192484541; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20<oran@cisco.com> |Subject:=20Re=3A=20[AVT]=20Open=20issue=20on=20hdrext=20draft |Sender:=20 |To:=20Tom=20Taylor=20<tom.taylor@rogers.com>; bh=brfWnFheWfn/gcYx7XKhb2ZKHQeQ96qsoXPuulOi1Sg=; b=fD5muS8A5YJ/o2bhxTxLAZH8wtPXSNCTzBcTw6S+rB5Q0Ul6TL5sswGE/TD36rcYTAPocaOm Zmw834CbtgK9/o47tPSWqe1CBCJn+a7+k6+ilK8vXz8L5VehYlcMJXMD;
Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Cullen Jennings <fluffy@cisco.com>, IETF AVT WG <avt@ietf.org>, avt-chairs@tools.ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

On Oct 3, 2007, at 10:02 PM, Tom Taylor wrote:

> Before the header extension draft can be approved we have to settle  
> two or three points that have been raised after the document passed  
> WGLC. One of them is the view of the Working Group regarding  
> registration requirements.
>
> Is it the Working Group's intention that:
>
> (a) any SDO can standardize and register a new RTP header extension  
> without IETF
> review or consent; or
>
> (b) all RTP header extensions require review and agreement by an  
> IETF expert
> before they can be registered; or
>
> (c) all RTP header extensions require IETF consensus before they  
> can be registered.
>
> David Singer had a clear view on this question when he wrote the  
> document in the first place. I should let him speak for himself,  
> but his basic idea was to encourage registration as an alternative  
> to hard-to-get-rid-of experimental identifiers, by making  
> registration a simple process. His preference was thus toward  
> alternative (a).
>
> Last time we didn't ask the question in quite these stark terms,  
> and only Magnus replied. It's hard to read a consensus from that.  
> Would other people care to comment?
>
I would be happy with (a) or (b) with a mild preference for (b)  
because lack of any review often leads to duplication - essentially  
identical extensions with arbitrarily different syntax, and the  
consequent lost opportunities for interoperabiity.

Dave Oran.

> Tom Taylor
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt