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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 24 October 2012 15:07 UTC

Return-Path: <eckelcu@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 640E821F88A7 for <bfcpbis@ietfa.amsl.com>; Wed, 24 Oct 2012 08:07: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=[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 13ceJP2d66t7 for <bfcpbis@ietfa.amsl.com>; Wed, 24 Oct 2012 08:07:15 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16F21F8881 for <bfcpbis@ietf.org>; Wed, 24 Oct 2012 08:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9005; q=dns/txt; s=iport; t=1351091233; x=1352300833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sXYwytfnGHVQd7MO4jMuLqFO/Wz9RB5y7Mw6Sn6k04g=; b=fDNeygAIwvhfdCScrgk3QIHjgQLJbvy/54VtA1ENA2ktp2nHbdw2pp2D EEywe5nFSkr5tDmhCvR2Wr42rebbIy11dFZUZIl9RgKR3GXPeu5SOLO0m BvVrQ9hfkKn5mmLRoCpR49Wf+lC40pVaPCZNVvVQUPiseTBXGLJRoFG4e 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALMCiFCtJV2a/2dsb2JhbAA+BsFwgQiCHgEBAQQBAQEPASc0CwwEAgEIEQQBAQEKCwkJBycLFAkIAgQBDQUIGodhAQubE6ASi2EmgxeCT2EDlwqNN4Frgm+CGQ
X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="134882088"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2012 15:07:12 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9OF7Ca3010566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 15:07:12 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 10:07:12 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Jonathan Lennox <jonathan@vidyo.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNCAALTCgIACQfqAgAIDEkCAB67PoIAAPMAwgAEnKfA=
Date: Wed, 24 Oct 2012 15:07:11 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C088280EA9E7@xmb-aln-x08.cisco.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> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> <C3759687E4991243A1A0BD44EAC823034DF946C567@BE235.mail.lan>
In-Reply-To: <C3759687E4991243A1A0BD44EAC823034DF946C567@BE235.mail.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.68.16.69]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000
x-tm-as-result: No--64.682400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com)" <Gonzalo.Camarillo@ericsson.com>, "Robert Sparks (rjsparks@nostrum.com)" <rjsparks@nostrum.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, 24 Oct 2012 15:07:17 -0000

Your recollection is correct. Figure 5.2 of the IMTC document contains a call flow illustrating that exact usage; however, I see that figure 5.2 did not survive the MS Word to PDF conversion process and is therefore missing from the version of the document included in the liaison statement.

Cheers,
Charles

> -----Original Message-----
> From: Jonathan Lennox [mailto:jonathan@vidyo.com]
> Sent: Tuesday, October 23, 2012 2:43 PM
> To: Charles Eckel (eckelcu); Tom Kristensen (tomkrist)
> Cc: bfcpbis@ietf.org; Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com);
> Robert Sparks (rjsparks@nostrum.com)
> Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
> 
> Hi Charles,
> 
> I agree that description makes sense.  I thought I had recalled the IMTC
> document recommending that the floorid include a dangling mstrm, rather
> than no mstrm, but now I can't find it.
> 
> Making the text more explicit couldn't hurt, but it's also not particularly
> necessary I think.
> 
> -----Original Message-----
> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> Sent: Tuesday, October 23, 2012 2:17 PM
> To: Tom Kristensen (tomkrist); Jonathan Lennox
> Cc: bfcpbis@ietf.org; Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com);
> Robert Sparks (rjsparks@nostrum.com)
> Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt
> 
> Hi Jonathan,
> 
> I revisited this section of the draft, and on closer inspection, I noticed it
> currently reads as follows:
> 
>    The 'floorid' attribute is used in the SDP media description for BFCP
>    media.  It defines a floor identifier and, possibly, associates it
>    with one or more media streams.
> 
> I interpret this to already account for the possibility of a floorid that is not
> yet associated with an existing media stream. Do you think we need to be
> more explicit? How about we extend the next paragraph as follows:
> 
>    Endpoints that use the offer/answer model to establish BFCP
>    connections MUST support the 'floorid' and the 'label' attributes.  A
>    floor control server acting as an offerer or as an answerer SHOULD
>    include these attributes in its session descriptions.
> 
> Is extended as follows:
> 
>    Endpoints that use the offer/answer model to establish BFCP
>    connections MUST support the 'floorid' and the 'label' attributes.  A
>    floor control server acting as an offerer or as an answerer SHOULD
>    include these attributes in its session descriptions. In some scenarios,
>    a "floorid" may be specified in an initial offer/answer exchange with
>    any associated media streams being identified in subsequent
>    exchanges.
> 
> Cheers,
> Charles
> 
> 
> > -----Original Message-----
> > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
> > Behalf Of Charles Eckel (eckelcu)
> > Sent: Thursday, October 18, 2012 1:33 PM
> > To: Tom Kristensen (tomkrist); Jonathan Lennox
> > Cc: bfcpbis@ietf.org; Gonzalo Camarillo
> > (Gonzalo.Camarillo@ericsson.com); Robert Sparks
> (rjsparks@nostrum.com)
> > Subject: Re: [bfcpbis] I-D Action:
> > draft-ietf-bfcpbis-rfc4583bis-03.txt
> >
> > I see no harm in adding such a note, and it may help. As for
> > referencing the IMTC best practice document, it is available through a
> liaison statement at:
> > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc
> > - the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf
> >
> > However, I expect this IMTC document to be updated and made available
> > externally once the BFCPBIS work completes, so I am not sure
> > referencing it this way is appropriate.
> >
> > Thanks,
> > Charles
> >
> > > -----Original Message-----
> > > From: Tom Kristensen (tomkrist)
> > > Sent: Wednesday, October 17, 2012 1:44 AM
> > > To: Jonathan Lennox
> > > Cc: Charles Eckel (eckelcu); bfcpbis@ietf.org
> > > Subject: Re: [bfcpbis] I-D Action:
> > > draft-ietf-bfcpbis-rfc4583bis-03.txt
> > >
> > > 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/dra
> > > >>> ft-ietf-
> > > bfcpbis-
> > > >>> rfc4583bis-02.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpb
> > > >>> is-
> > > 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
> > > >
> > > >
> > > >
> >
> > _______________________________________________
> > bfcpbis mailing list
> > bfcpbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/bfcpbis