Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt

Tom Kristensen <tomkrist@cisco.com> Wed, 17 October 2012 08:44 UTC

Return-Path: <tomkrist@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A9721F87CA for <bfcpbis@ietfa.amsl.com>; Wed, 17 Oct 2012 01:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 HYJZ1ztxENC1 for <bfcpbis@ietfa.amsl.com>; Wed, 17 Oct 2012 01:44:16 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2F21F87B8 for <bfcpbis@ietf.org>; Wed, 17 Oct 2012 01:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4011; q=dns/txt; s=iport; t=1350463455; x=1351673055; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yPhC4+IhEqHZ87b/hoc3lwVTrgpMaNVCmsLEQjFrWYY=; b=dkuJ7guPBXjmSK8CjnU/oyBhEbfq+Uoce9CI73dXmJopUhEQ1TUhEPU4 cbSG1eNurTJN4Kc61lphHfQYuCURDYZK6ybRQl1NJ9I2ovp7CygsXo+Tj Pk7dH86b7BljWcLqk+zOqwtYewxlTUXok4wqKJ57iaYQMkXwuJJVDXDBv Q=;
X-IronPort-AV: E=Sophos;i="4.80,599,1344211200"; d="scan'208";a="8867931"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 17 Oct 2012 08:44:10 +0000
Received: from [10.54.86.36] (dhcp-10-54-86-36.cisco.com [10.54.86.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9H8i9xt024966; Wed, 17 Oct 2012 08:44:09 GMT
Message-ID: <507E6FD9.1080807@cisco.com>
Date: Wed, 17 Oct 2012 10:44:09 +0200
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Jonathan Lennox <jonathan@vidyo.com>
References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <A53159ED-C30B-44C1-8714-41B1317D6BE7@vidyo.com>
In-Reply-To: <A53159ED-C30B-44C1-8714-41B1317D6BE7@vidyo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2012 08:44:17 -0000

I'm not sure we should say much about this in rfc4583bis. This is 
similar to existing "best effort encryption" schemes, where different 
vendors historically have had their own interpretation of a best current 
practice.

Anyway, it is not a big deal adding an informational note, if people 
thinks that's a good idea, explaining that one may very well meet an 
mstrm referring to a still undefined label.

(Do we then reference the IMTC document as an informational reference or 
simply state the fact that this behaviour exists in the wild?!)

-- Tom

On 10/16/2012 12:15 AM, Jonathan Lennox wrote:
> I greatly apologize; I should have sent this earlier.
>
> There are some BFCP usages in the IMTC Role-Based Video Streams work<https://datatracker.ietf.org/liaison/1170/>  which have some unusual features -- in particular, it recommends sending an offer with a BFCP stream referencing an mstrm that does not yet exist.  (The intention is that if the SDP answer indicates that the peer understands both BFCP and the SDP content attribute, a re-INVITE can be sent adding an additional BFCP-controlled video stream with "content:slides".)
>
> This document should probably call out that usage, at least to indicate that it's valid for an mstrm to reference an undefined label.
>
>
> On Oct 15, 2012, at 12:29 PM, Charles Eckel (eckelcu) wrote:
>
>    
>> (As co-chair)
>>
>> For everyone, if there are any outstanding issues of questions you have related to this draft, please share them now.
>> We plan to proceed with the proto writeup soon.
>>
>> Cheers,
>> Charles
>>
>>      
>>> -----Original Message-----
>>> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
>>> Behalf Of Tom Kristensen (tomkrist)
>>> Sent: Friday, October 12, 2012 5:02 AM
>>> To: bfcpbis@ietf.org
>>> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
>>>
>>> On 10/12/2012 01:54 PM, internet-drafts@ietf.org wrote:
>>>        
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>          
>>> directories.
>>>        
>>>>   This draft is a work item of the Binary Floor Control Protocol Bis  Working
>>>>          
>>> Group of the IETF.
>>>        
>>>> 	Title           : Session Description Protocol (SDP) Format for Binary
>>>>          
>>> Floor Control Protocol (BFCP) Streams
>>>        
>>>> 	Author(s)       : Gonzalo Camarillo
>>>>                            Tom Kristensen
>>>> 	Filename        : draft-ietf-bfcpbis-rfc4583bis-03.txt
>>>> 	Pages           : 15
>>>> 	Date            : 2012-10-12
>>>>
>>>> Abstract:
>>>>     This document specifies how to describe Binary Floor Control Protocol
>>>>     (BFCP) streams in Session Description Protocol (SDP) descriptions.
>>>>     User agents using the offer/answer model to establish BFCP streams
>>>>     use this format in their offers and answers.
>>>>
>>>>     This document obsoletes RFC 4583.  Changes from RFC 4583 are
>>>>     summarized in section 12.
>>>>
>>>>          
>>> No comments or input received after WGLC. Anyway, this is a short,
>>> simple draft where the changes follows more or less automatically from
>>> the extensions in rfc4582bis.
>>>
>>> After checking out with the original author of RFC 4583, the ipr
>>> parameter is changed s/pre5378Trust200902/trust200902/.
>>>
>>> Cf.<URL:
>>> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-bfcpbis-
>>> rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4583bis-
>>> 03.txt
>>>        
>>>>          
>>> -- Tom
>>>
>>> _______________________________________________
>>> bfcpbis mailing list
>>> bfcpbis@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>        
>> _______________________________________________
>> bfcpbis mailing list
>> bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>>      
> --
> Jonathan Lennox
> jonathan@vidyo.com
>
>
>