From eckelcu@cisco.com Mon Oct 8 11:09:26 2012 Return-Path: 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 0257921F87C5 for ; Mon, 8 Oct 2012 11:09:26 -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 bYeoQNcE4urn for ; Mon, 8 Oct 2012 11:09:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89221F87C3 for ; Mon, 8 Oct 2012 11:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3129; q=dns/txt; s=iport; t=1349719765; x=1350929365; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iuLyb8hgRJzTP5bBIfkHXLCLweCL8mt9hgGjUhPPmu0=; b=XgG85ny7MCBfhkq6hgPsoNFHJys/j6k/XWJUvij3ILzAQkB2FhbW7QsM umpo7l6U/22+g/QUM/UqyiVmEBE/PAb+Jre8o3UGOivGARWgebLC6k25j VILm74sbeYEk7GpNFU8bRf8VJLcyWnEgDuzLT4pEmtKK91w8bh1a3TvBL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ8Wc1CtJV2b/2dsb2JhbABFvy+BCIIgAQEBBAEBAQ8BCh00FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIGodiAQuaJp9qi0+FMGADlwCNMIFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,555,1344211200"; d="scan'208";a="129231793" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 08 Oct 2012 18:09:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q98I9DKd018223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 18:09:13 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 13:09:13 -0500 From: "Charles Eckel (eckelcu)" To: "Horvath, Ernst" , "bfcpbis@ietf.org" Thread-Topic: WGLC for draft-ietf-bfcpbis-rfc4582bis Thread-Index: Ac2NAeUBlWZWMlJIRpyXKbtffhLaTQLV4YwwAKtpOOACngDJ0A== Date: Mon, 8 Oct 2012 18:09:12 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280DE72A@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.23] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--47.238300-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 Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:09:26 -0000 (as an individual) Hi Horvath, Sorry for the delay in responding. I agree that NAT traversal should not be= a subsection of Large message considerations; however, I think it would be= better to relocate it to section 6.2.3 as a part of Section 6.2 "Unreliabl= e Transport". 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . .=20 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . .=20 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . .=20 6.2.3. NAT Traversal . . . . . . . . . . . . . . . . . . . .=20 6.3. Large Message Considerations . . . . . . . . . . . . . . .=20 6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . .=20 Cheers, Charles > -----Original Message----- > From: Horvath, Ernst [mailto:ernst.horvath@siemens-enterprise.com] > Sent: Tuesday, September 25, 2012 3:29 AM > To: Charles Eckel (eckelcu); bfcpbis@ietf.org > Subject: RE: WGLC for draft-ietf-bfcpbis-rfc4582bis >=20 >=20 > Currently 6.3.2 "NAT Traversal" is a subsection of 6.3 "Large Message > Considerations". Is this really the intention, or should NAT Traversal be= tter > be renumbered as section 6.4? >=20 > Regards, > Ernst >=20 > > -----Original Message----- > > From: bfcpbis-bounces@ietf.org > > [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) > > Sent: Samstag, 22. September 2012 02:36 > > To: bfcpbis@ietf.org > > Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis > > > > Just a gentle reminder that we are into the last week for > > comments. Please review the draft and submit your comments by > > the Sept 28th, 2012 deadline (not 2011 as erroneously typed > > previously) > > > > Thanks, > > Charles (as co-chair) > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Friday, September 07, 2012 7:06 AM > > > To: bfcpbis@ietf.org > > > Subject: WGLC for draft-ietf-bfcpbis-rfc4582bis > > > > > > (As WG co-chair) > > > > > > This is to announce a working group last call for > > draft-ietf-bfcpbis- > > > rfc4582bis, "The Binary Floor Control Protocol (BFCP)". > > > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ > > > > > > This is intended as a Standards Track RFC, obsoleting RFC 4582. > > > Please respond to the list by September 28th 2011 (i.e. 3 > > weeks) with any > > > comments. > > > > > > It is helpful to attempt to categorize your comment (e.g. > > technical issue vs. > > > editorial), and also to provide any replacement text you > > feel is necessary. > > > If you review the document and have no comments, please > > tell the chairs > > > that you have reviewed it. This is always useful > > information in assessing the > > > degree of WG review and consensus behind the document. > > > Note, another WGLC for draft-ietf-bfcpbis-rfc4583bis will > > be run in parallel. > > > > > > Cheers, > > > Charles > > _______________________________________________ > > bfcpbis mailing list > > bfcpbis@ietf.org > > https://www.ietf.org/mailman/listinfo/bfcpbis > > From tomkrist@cisco.com Wed Oct 10 01:52:36 2012 Return-Path: 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 424D221F86F5 for ; Wed, 10 Oct 2012 01:52:36 -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 r9I2prD5JWyM for ; Wed, 10 Oct 2012 01:52:35 -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 27C8721F8585 for ; Wed, 10 Oct 2012 01:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3997; q=dns/txt; s=iport; t=1349859155; x=1351068755; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rQwQ9sD/+eWC7p1adpUbynMDp+VXXlDuBqQvuNjJe4w=; b=UcJatkPGuqe24dBLDXIhSs8FALD5fSfMUvNl6xWozhcCokPKxUeiLuez 2AGQIYJE7aDP2wAJJhupazWymuALPDa1cQPk4ElkhkgTbvee6JamdMH65 DnckfmGSkNSvE61k9pk14cQpWA0FNRiYh9GoTudgTvuXD5A3ATctMHweq k=; X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="8675481" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2012 08:52:34 +0000 Received: from [10.61.99.201] (dhcp-10-61-99-201.cisco.com [10.61.99.201]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9A8qXTe000746; Wed, 10 Oct 2012 08:52:33 GMT Message-ID: <50753751.1080305@cisco.com> Date: Wed, 10 Oct 2012 10:52:33 +0200 From: Tom Kristensen 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: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280DE72A@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280DE72A@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Horvath, Ernst" , "bfcpbis@ietf.org" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:52:36 -0000 Actually, my proposal would be to move both the subsections under 6.2 "Unreliable Transport", since the "NAT Traversal" and "Large Message..."/"Fragmentation Handling" is written in the UDP/BFCP context. I also propose to collapse the section "Large Message..." and its subsection "Fragmentation Handling" into one, since the main thing here is to describe the fragmentation handling solution. OK? -- Tom On 10/08/2012 08:09 PM, Charles Eckel (eckelcu) wrote: > (as an individual) > > Hi Horvath, > > Sorry for the delay in responding. I agree that NAT traversal should not be a subsection of Large message considerations; however, I think it would be better to relocate it to section 6.2.3 as a part of Section 6.2 "Unreliable Transport". > > 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . > 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . > 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . > 6.2.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . > 6.3. Large Message Considerations . . . . . . . . . . . . . . . > 6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . . > > Cheers, > Charles > > >> -----Original Message----- >> From: Horvath, Ernst [mailto:ernst.horvath@siemens-enterprise.com] >> Sent: Tuesday, September 25, 2012 3:29 AM >> To: Charles Eckel (eckelcu); bfcpbis@ietf.org >> Subject: RE: WGLC for draft-ietf-bfcpbis-rfc4582bis >> >> >> Currently 6.3.2 "NAT Traversal" is a subsection of 6.3 "Large Message >> Considerations". Is this really the intention, or should NAT Traversal better >> be renumbered as section 6.4? >> >> Regards, >> Ernst >> >> >>> -----Original Message----- >>> From: bfcpbis-bounces@ietf.org >>> [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu) >>> Sent: Samstag, 22. September 2012 02:36 >>> To: bfcpbis@ietf.org >>> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis >>> >>> Just a gentle reminder that we are into the last week for >>> comments. Please review the draft and submit your comments by >>> the Sept 28th, 2012 deadline (not 2011 as erroneously typed >>> previously) >>> >>> Thanks, >>> Charles (as co-chair) >>> >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) >>>> Sent: Friday, September 07, 2012 7:06 AM >>>> To: bfcpbis@ietf.org >>>> Subject: WGLC for draft-ietf-bfcpbis-rfc4582bis >>>> >>>> (As WG co-chair) >>>> >>>> This is to announce a working group last call for >>>> >>> draft-ietf-bfcpbis- >>> >>>> rfc4582bis, "The Binary Floor Control Protocol (BFCP)". >>>> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ >>>> >>>> This is intended as a Standards Track RFC, obsoleting RFC 4582. >>>> Please respond to the list by September 28th 2011 (i.e. 3 >>>> >>> weeks) with any >>> >>>> comments. >>>> >>>> It is helpful to attempt to categorize your comment (e.g. >>>> >>> technical issue vs. >>> >>>> editorial), and also to provide any replacement text you >>>> >>> feel is necessary. >>> >>>> If you review the document and have no comments, please >>>> >>> tell the chairs >>> >>>> that you have reviewed it. This is always useful >>>> >>> information in assessing the >>> >>>> degree of WG review and consensus behind the document. >>>> Note, another WGLC for draft-ietf-bfcpbis-rfc4583bis will >>>> >>> be run in parallel. >>> >>>> Cheers, >>>> Charles >>>> >>> _______________________________________________ >>> 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 > From tomkrist@cisco.com Wed Oct 10 02:04:00 2012 Return-Path: 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 56CC621F86E4 for ; Wed, 10 Oct 2012 02:04:00 -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 aoHPK92Ke8J7 for ; Wed, 10 Oct 2012 02:03:59 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4601221F8574 for ; Wed, 10 Oct 2012 02:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4138; q=dns/txt; s=iport; t=1349859839; x=1351069439; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=m3A+IRNvteIf+nKF0KJZTQKU5rZNFLVUS0w86ATlxsY=; b=geV2DgOT50ynUpvH+N5VpBHWU4Xi3WHlLMUzUrZIS3BWcw0rlUXIgWim W7Xn7gyQ2Nlx+LY/Ndal2x4vp9f/FRIJeItY2qS9NTmC3y/CwLxq/MXc7 GRVJq2jlkYzwXAwGz2Vbins+j5hHSrKz4bpPIU7upMGlcGi53lTvVd4J6 M=; X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="8685907" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2012 09:03:55 +0000 Received: from [10.61.99.201] (dhcp-10-61-99-201.cisco.com [10.61.99.201]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9A93sZh002602; Wed, 10 Oct 2012 09:03:55 GMT Message-ID: <507539FA.6080406@cisco.com> Date: Wed, 10 Oct 2012 11:03:54 +0200 From: Tom Kristensen 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: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280A8B97@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280A8B97@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 09:04:00 -0000 On 09/25/2012 12:18 AM, Charles Eckel (eckelcu) wrote: Reply comments inline. > (as an individual) > > I have reviewed the draft and I think that overall it is in very good shape. The only comment I would consider major is one dealing with section 4's description of server-initiated transactions: > > Section 4 reads as follows: > > There are two types of transaction in BFCP: client-initiated > transactions and server-initiated transactions. Client-initiated > transactions consist of a message from a client to the floor control > server and a response from the floor control server to the client. > Correspondingly, server-initiated transactions consist of a message > from the floor control server to a client and the associated > acknowledgement message from the client to the floor control server. > Both messages can be related because they carry the same Transaction > ID value in their common headers. > > This is accurate when using UDP as the transport, but does not account for the case of using TCP as the transport. A more detailed and accurate description is provided in Section 8, which reads as follows: > > In BFCP, there are two types of transactions: client-initiated > transactions and server-initiated transactions (notifications). > Client-initiated transactions consist of a request from a client to a > floor control server and a response from the floor control server to > the client. The request carries a Transaction ID in its common > header, which the floor control server copies into the response. > Clients use Transaction ID values to match responses with previously > issued requests. > > Server-initiated transactions consist of a single message from a > floor control server to a client. Since they do not trigger any > response, their Transaction ID is set to 0 when used over reliable > transports, but must be non-zero and unique in the context of > outstanding transactions over unreliable transports. > > I suggest replacing the section 4 text with the following introductory level text, that currently exists in section 8 . > > In BFCP, there are two types of transactions: client-initiated > transactions and server-initiated transactions (notifications). > > The rest of the details currently in section 4 can replaced with a reference to section 8. > I agree. Good catch as well, since the section 4 text is unchanged from RFC 4582 - and amusingly enough fits with the semantics of UDP/BFCP! > I also have the following minor comments. > > 1) Section 5.2.6, note after table 5 > r/is intended being used/is intended to be used > OK. > 2) Section 5.3.14 current reads as follows: > > Floor participants and chairs acknowledge the receipt of a subsequent > FloorRequestStatus message from the floor control server when > communicating over unreliable transport. > > I suggest the following rewording: > > When communicating over unreliable transport, floor participants and chairs > acknowledge the receipt of a subsequent FloorRequestStatus message from > the floor control server by sending an FloorRequestStatusAck. > > 3) Similar change for section 5.3.15. > OK for 2) and 3). Easier to read and understand. > 4) Section 6.2, currently contains the following fragment: > > Only allowing exactly one BFCP message or message segment per UDP > datagram. > > This is covered previously in the paragraph, so this fragment can be removed. > Fine, but I'll add "... or message segment" to the previous sentence, so that it reads: "Each BFCP UDP datagram MUST contain exactly one BFCP message or message segment" > 5) Section 6.2, > r/Entities MUST only have at most one/Entities MUST have at most one > Agree, better language! > 6) Section 6.2.1 > r/attempt, this is identical/attempt. This is identical OK. I'll change the upcoming rfc4582bis version accordingly if no objections or further comments on these issues are received. -- Tom From tomkrist@cisco.com Wed Oct 10 02:16:35 2012 Return-Path: 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 21D7321F861B for ; Wed, 10 Oct 2012 02:16:35 -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, HTML_MESSAGE=0.001, 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 vJggHAJSL3Qn for ; Wed, 10 Oct 2012 02:16:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A43CF21F861A for ; Wed, 10 Oct 2012 02:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7189; q=dns/txt; s=iport; t=1349860593; x=1351070193; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=i4ko+TbrcQFUoqp7FUdjyMWT2vydm+zr7DI2UozSDeo=; b=iy3FimFjFwntlkOG/SZ/2OCMauQEbOBTdb9tea3tTAN8eYWAIPodpLeF vIIjZ8fZbax5r55cmaqitaXij2k+NEE7Sz9QOs4B4ttf9xf50pLsNbRtm uZM5Sc4ZRTKWIQf1CsmKQ4ZpQ2IdRsJrEKrVUiXmVKNUBOMqRqm83QoSr E=; X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208,217";a="77339557" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 10 Oct 2012 09:16:30 +0000 Received: from [10.61.99.201] (dhcp-10-61-99-201.cisco.com [10.61.99.201]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9A9GUXl007427; Wed, 10 Oct 2012 09:16:30 GMT Message-ID: <50753CEE.2080907@cisco.com> Date: Wed, 10 Oct 2012 11:16:30 +0200 From: Tom Kristensen 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: Mary Barnes References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010009080905010706050703" Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 09:16:35 -0000 This is a multi-part message in MIME format. --------------010009080905010706050703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/24/2012 11:13 PM, Mary Barnes wrote: > I have reviewed the document and it looks pretty much ready. > > I do have a couple of questions for clarification: > - Section 5.1 - Payload Length: states that "receiving server MAY send > an Error message" > but I would think that the client should know about the error. Is > there a specific reason this is a MAY versus a SHOULD or even a MUST? > Why would the error message matter if it's not required? I don't remember why MAY was chosen here, but after having a look at this again I see that SHOULD is used for sending an Error message twice in the original RFC 4582. So, we should (!) change to SHOULD. OK? > - Section 5.2 - "M" after Table 2 - I have a similar question about > the 'M' bit. RFC 4582 states that message is rejected if there is an > unrecognized M bit, whereas this document states that an error message > MAY be sent. Certainly, 4582 lacked appropriate normative language, > but if the error message is just a MAY, then why bother? Yeah, why bother ;-) We'll change to SHOULD. However, it wouldn't harm using MUST for sending these error messages - apart from that SHOULD is used in RFC 4582 and that is my main reason for suggesting using SHOULD here. > There are also a few nits that should be fixed/clarified before > progressing. > > Section 5.2.6 - Note under table 5: "intended being used" -> > "intended to be used" OK > Section 6.1.: "e.g.," was changed to "e.g.". The former is correct. OK > Section 9.1: You lost some indented paragraphs in this section - i.e., > they got shifted to align with the other paragraphs in that section. > I'm not sure if that was intentional. What do you mean? Same white space indentation as in RFC 4582, isn't it? > Section 16: > - New Primitives. The text says five were added, but only 4 are > listed and that's all that's all that's defined per Figure 1. > - New error codes. The text says that 3 are aded, but it looks > there's really 5 that have been added. > - Typo. Referring to section 12.4.2 states that the change was from > SUPPORTED-PRIMITIVES to SUPPORTED-PRIMITVIES but the latter is really > the typo. Fine, good catches - will change. I'll change accordingly ASAP in the new version if no objections are provided! -- Tom --------------010009080905010706050703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/24/2012 11:13 PM, Mary Barnes wrote:
I have reviewed the document and it looks pretty much ready.  

I do have a couple of questions for clarification:
- Section 5.1 - Payload Length: states that "receiving server MAY send an Error message"
but I would think that the client should know about the error. Is there a specific reason this is a MAY versus a SHOULD or even a MUST? Why would the error message matter if it's not required? 

I don't remember why MAY was chosen here, but after having a look at this again I see that SHOULD is used for sending an Error message twice in the original RFC 4582. So, we should (!) change to SHOULD.  OK?

- Section 5.2 - "M" after Table 2 - I have a similar question about the 'M' bit. RFC 4582 states that message is rejected if there is an unrecognized M bit, whereas this document states that an error message MAY be sent. Certainly, 4582 lacked appropriate normative language, but if the error message is just a MAY, then why bother?

Yeah, why bother ;-) 
We'll change to SHOULD. However, it wouldn't harm using MUST for sending these error messages - apart from that SHOULD is used in RFC 4582 and that is my main reason for suggesting using SHOULD here.

There are also a few nits that should be fixed/clarified before progressing.

Section 5.2.6 - Note under table 5:    "intended being used" -> "intended to be used"

OK

Section 6.1.: "e.g.,"  was changed to "e.g.".   The former is correct.

OK

Section 9.1: You lost some indented paragraphs in this section - i.e., they got shifted to align with the other paragraphs in that section.  I'm not sure if that was intentional.

What do you mean? Same white space indentation as in RFC 4582, isn't it?

Section 16:
- New Primitives.  The text says five were added, but only 4 are listed and that's all that's all that's defined per Figure 1. 
- New error codes.  The text says that 3 are aded, but it looks there's really 5 that have been added. 
- Typo.  Referring to section 12.4.2 states that the change was from SUPPORTED-PRIMITIVES to SUPPORTED-PRIMITVIES but the latter is really the typo.

Fine, good catches - will change.



I'll change accordingly ASAP in the new version if no objections are provided!

-- Tom
--------------010009080905010706050703-- From eckelcu@cisco.com Wed Oct 10 08:22:25 2012 Return-Path: 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 518D721F87D3 for ; Wed, 10 Oct 2012 08:22:24 -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 mgaHRL1Mv61n for ; Wed, 10 Oct 2012 08:22:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6074421F87D2 for ; Wed, 10 Oct 2012 08:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5500; q=dns/txt; s=iport; t=1349882543; x=1351092143; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gr+soB1hXVIpquFf551F0Nbr+9UTE6yn6pKO6bWJbEo=; b=hB21ybM0ct8P1+8ozmabTERf69izNeBaPBlg1iV84TMDg7DeyB7rI8rl WDDQ6v97pjccGaLaWeoTyHxwq/1gtByhPvS2TAYMw0gwN4UMoR0fxcdfg J0F9rBsVJOJ0SK+DF1txa9jWGP3M7qUyhP1Jl0WacHWcqvN0gr3VpjArS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANiRdVCtJV2d/2dsb2JhbABEvy6BCIIgAQEBBAEBAQ8BCh00CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQOBQgTB4dhAQuXZKAni0cLCYUsYAOXAY0wgWuCbYFaATw X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="127190064" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 10 Oct 2012 15:22:22 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9AFMMii019994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Oct 2012 15:22:22 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 10:22:21 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" Thread-Topic: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis Thread-Index: Ac2NAeUBlWZWMlJIRpyXKbtffhLaTQLV4YwwAKtpOOACngDJ0ABb2v+AAAKFa1A= Date: Wed, 10 Oct 2012 15:22:21 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280E2A12@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280DE72A@xmb-aln-x08.cisco.com> <50753751.1080305@cisco.com> In-Reply-To: <50753751.1080305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.23] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--62.049400-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: "Horvath, Ernst" , "bfcpbis@ietf.org" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:22:25 -0000 Works for me. I originally thought we might also address BFCP messages that= exceeded the 16 bit payload length field, and I structured the section ac= cordingly. We decided to not tackle that, but the section structure remaine= d anyway. I like your proposal. As part of the reorganization, it may be worthwhile to change the text for = what is currently section 6.3 from: Large messages become a concern when using BFCP if the overall size of a single BFCP message exceeds that representable within the 16-bit Payload Length field of the COMMON-HEADER. When using UDP, there is the added concern that a single BFCP message can be fragmented at the IP layer if its overall size exceeds the MTU threshold of the network. To=20 The size of a BFCP message is limited by the 16-bit Payload Length field= of the=20 COMMON-HEADER. When using UDP, a single BFCP message may be fragmented= =20 at the IP layer if its overall size exceeds the MTU threshold of the net= work. After this, the information in what is currently section 6.3.1 can clearly = be targeted at UDP only. Cheers, Charles > -----Original Message----- > From: Tom Kristensen (tomkrist) > Sent: Wednesday, October 10, 2012 1:53 AM > To: Charles Eckel (eckelcu) > Cc: Horvath, Ernst; bfcpbis@ietf.org > Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis >=20 > Actually, my proposal would be to move both the subsections under 6.2 > "Unreliable Transport", since the "NAT Traversal" and "Large > Message..."/"Fragmentation Handling" is written in the UDP/BFCP context. >=20 > I also propose to collapse the section "Large Message..." and its > subsection "Fragmentation Handling" into one, since the main thing here > is to describe the fragmentation handling solution. >=20 > OK? >=20 > -- Tom >=20 > On 10/08/2012 08:09 PM, Charles Eckel (eckelcu) wrote: > > (as an individual) > > > > Hi Horvath, > > > > Sorry for the delay in responding. I agree that NAT traversal should no= t be > a subsection of Large message considerations; however, I think it would b= e > better to relocate it to section 6.2.3 as a part of Section 6.2 "Unreliab= le > Transport". > > > > 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . > > 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . > > 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . > > 6.2.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . > > 6.3. Large Message Considerations . . . . . . . . . . . . . . . > > 6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . . > > > > Cheers, > > Charles > > > > > >> -----Original Message----- > >> From: Horvath, Ernst [mailto:ernst.horvath@siemens-enterprise.com] > >> Sent: Tuesday, September 25, 2012 3:29 AM > >> To: Charles Eckel (eckelcu); bfcpbis@ietf.org > >> Subject: RE: WGLC for draft-ietf-bfcpbis-rfc4582bis > >> > >> > >> Currently 6.3.2 "NAT Traversal" is a subsection of 6.3 "Large Message > >> Considerations". Is this really the intention, or should NAT Traversal > better > >> be renumbered as section 6.4? > >> > >> Regards, > >> Ernst > >> > >> > >>> -----Original Message----- > >>> From: bfcpbis-bounces@ietf.org > >>> [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu= ) > >>> Sent: Samstag, 22. September 2012 02:36 > >>> To: bfcpbis@ietf.org > >>> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis > >>> > >>> Just a gentle reminder that we are into the last week for > >>> comments. Please review the draft and submit your comments by > >>> the Sept 28th, 2012 deadline (not 2011 as erroneously typed > >>> previously) > >>> > >>> Thanks, > >>> Charles (as co-chair) > >>> > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) > >>>> Sent: Friday, September 07, 2012 7:06 AM > >>>> To: bfcpbis@ietf.org > >>>> Subject: WGLC for draft-ietf-bfcpbis-rfc4582bis > >>>> > >>>> (As WG co-chair) > >>>> > >>>> This is to announce a working group last call for > >>>> > >>> draft-ietf-bfcpbis- > >>> > >>>> rfc4582bis, "The Binary Floor Control Protocol (BFCP)". > >>>> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ > >>>> > >>>> This is intended as a Standards Track RFC, obsoleting RFC 4582. > >>>> Please respond to the list by September 28th 2011 (i.e. 3 > >>>> > >>> weeks) with any > >>> > >>>> comments. > >>>> > >>>> It is helpful to attempt to categorize your comment (e.g. > >>>> > >>> technical issue vs. > >>> > >>>> editorial), and also to provide any replacement text you > >>>> > >>> feel is necessary. > >>> > >>>> If you review the document and have no comments, please > >>>> > >>> tell the chairs > >>> > >>>> that you have reviewed it. This is always useful > >>>> > >>> information in assessing the > >>> > >>>> degree of WG review and consensus behind the document. > >>>> Note, another WGLC for draft-ietf-bfcpbis-rfc4583bis will > >>>> > >>> be run in parallel. > >>> > >>>> Cheers, > >>>> Charles > >>>> > >>> _______________________________________________ > >>> 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 > > From eckelcu@cisco.com Wed Oct 10 10:13:47 2012 Return-Path: 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 3201A21F86B1 for ; Wed, 10 Oct 2012 10:13:47 -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 ho0v8bqKzlw0 for ; Wed, 10 Oct 2012 10:13:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2410821F84FD for ; Wed, 10 Oct 2012 10:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4652; q=dns/txt; s=iport; t=1349889226; x=1351098826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OT+zBxLglrsyxatnKOYEv+3SOh9h04jSQn0PGQCzYrA=; b=lW3zWg4yk8rk/6dlA5EgiVbR7ilxWiA2xODoJrTxPTqReHWIl6ISDFQS VcFzcJZM9Y+hKU6G3vRQnxFb3D91iO1eLDh5JR/kWkXeMUdA4aQBP75Tv T2cGpKjBMRNoIn7vtTkU0fFqG93UB85h5zvcEEGMknCPI45/HTz4A6lTP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHurdVCtJV2Z/2dsb2JhbABEvzGBCIIgAQEBBBIBJy0SDAQCAQgRBAEBAQoLCRAyHQgBAQQOBQgah2EBl1agH4tHgnOCTWADpDGBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,565,1344211200"; d="scan'208";a="130251103" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 10 Oct 2012 17:13:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9AHDjWb006244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Oct 2012 17:13:45 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 12:13:45 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" Thread-Topic: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis Thread-Index: Ac2NAeUBlWZWMlJIRpyXKbtffhLaTQLV4YwwAJIvu8ADE3q/AAAGnV1Q Date: Wed, 10 Oct 2012 17:13:44 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280E2B96@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280A8B97@xmb-aln-x08.cisco.com> <507539FA.6080406@cisco.com> In-Reply-To: <507539FA.6080406@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.23] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--56.387300-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" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 17:13:47 -0000 That all works for me. Thanks, Charles > -----Original Message----- > From: Tom Kristensen (tomkrist) > Sent: Wednesday, October 10, 2012 2:04 AM > To: Charles Eckel (eckelcu) > Cc: bfcpbis@ietf.org > Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis >=20 > On 09/25/2012 12:18 AM, Charles Eckel (eckelcu) wrote: >=20 > Reply comments inline. >=20 > > (as an individual) > > > > I have reviewed the draft and I think that overall it is in very good s= hape. > The only comment I would consider major is one dealing with section 4's > description of server-initiated transactions: > > > > Section 4 reads as follows: > > > > There are two types of transaction in BFCP: client-initiated > > transactions and server-initiated transactions. Client-initiated > > transactions consist of a message from a client to the floor contro= l > > server and a response from the floor control server to the client. > > Correspondingly, server-initiated transactions consist of a message > > from the floor control server to a client and the associated > > acknowledgement message from the client to the floor control server= . > > Both messages can be related because they carry the same Transactio= n > > ID value in their common headers. > > > > This is accurate when using UDP as the transport, but does not account = for > the case of using TCP as the transport. A more detailed and accurate > description is provided in Section 8, which reads as follows: > > > > In BFCP, there are two types of transactions: client-initiated > > transactions and server-initiated transactions (notifications). > > Client-initiated transactions consist of a request from a client to= a > > floor control server and a response from the floor control server t= o > > the client. The request carries a Transaction ID in its common > > header, which the floor control server copies into the response. > > Clients use Transaction ID values to match responses with previousl= y > > issued requests. > > > > Server-initiated transactions consist of a single message from a > > floor control server to a client. Since they do not trigger any > > response, their Transaction ID is set to 0 when used over reliable > > transports, but must be non-zero and unique in the context of > > outstanding transactions over unreliable transports. > > > > I suggest replacing the section 4 text with the following introductory = level > text, that currently exists in section 8 . > > > > In BFCP, there are two types of transactions: client-initiated > > transactions and server-initiated transactions (notifications). > > > > The rest of the details currently in section 4 can replaced with a ref= erence > to section 8. > > > I agree. Good catch as well, since the section 4 text is unchanged from > RFC 4582 - and amusingly enough fits with the semantics of UDP/BFCP! > > I also have the following minor comments. > > > > 1) Section 5.2.6, note after table 5 > > r/is intended being used/is intended to be used > > > OK. > > 2) Section 5.3.14 current reads as follows: > > > > Floor participants and chairs acknowledge the receipt of a subseque= nt > > FloorRequestStatus message from the floor control server when > > communicating over unreliable transport. > > > > I suggest the following rewording: > > > > When communicating over unreliable transport, floor participants an= d > chairs > > acknowledge the receipt of a subsequent FloorRequestStatus message > from > > the floor control server by sending an FloorRequestStatusAck. > > > > 3) Similar change for section 5.3.15. > > > OK for 2) and 3). Easier to read and understand. > > 4) Section 6.2, currently contains the following fragment: > > > > Only allowing exactly one BFCP message or message segment per UDP > > datagram. > > > > This is covered previously in the paragraph, so this fragment can be > removed. > > > Fine, but I'll add "... or message segment" to the previous sentence, so > that it reads: > "Each BFCP UDP datagram MUST contain exactly > one BFCP message or message segment" > > 5) Section 6.2, > > r/Entities MUST only have at most one/Entities MUST have at most one > > > Agree, better language! > > 6) Section 6.2.1 > > r/attempt, this is identical/attempt. This is identical > OK. >=20 >=20 > I'll change the upcoming rfc4582bis version accordingly if no objections > or further comments on these issues are received. >=20 > -- Tom From internet-drafts@ietf.org Fri Oct 12 04:54:22 2012 Return-Path: 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 7201C21F84DC; Fri, 12 Oct 2012 04:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 oYVNMCL+x5yK; Fri, 12 Oct 2012 04:54:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F419A21F84FA; Fri, 12 Oct 2012 04:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 04:54:21 -0700 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:54:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Workin= g Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Author(s) : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-06.txt Pages : 87 Date : 2012-10-12 Abstract: Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in section 16. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4582bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Oct 12 04:54:32 2012 Return-Path: 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 BFDAA21F85A2; Fri, 12 Oct 2012 04:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 aMBq2i7rkYk6; Fri, 12 Oct 2012 04:54:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5587221F8582; Fri, 12 Oct 2012 04:54:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012115432.971.75272.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 04:54:32 -0700 Cc: bfcpbis@ietf.org Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 11:54:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Workin= g Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Flo= or 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4583bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomkrist@cisco.com Fri Oct 12 05:00:09 2012 Return-Path: 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 AF82921F857D for ; Fri, 12 Oct 2012 05:00:09 -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 63hS4VwjfdSq for ; Fri, 12 Oct 2012 05:00:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC56521F8503 for ; Fri, 12 Oct 2012 05:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1155; q=dns/txt; s=iport; t=1350043208; x=1351252808; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Wx9aU7hNBLh8gk+KPsmUWoiGktciK+TG3tHv1GrNpcI=; b=O0Z96nKfFrWcFfcv+qGuBY4KAIqFtfeyuyxq3UHrENB7MQsjJJ4/YW5w W0RDco+QleTvyS9d3QYGvDnjdoALjmqHBkuE14HU1Jtvq14chkMQwTYP4 7bLzqnovKqLx771zXo0xCPowMJ2CaHowS79vdLgpOpCsweLjtXz4ntyPU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD4FeFCQ/khL/2dsb2JhbABEv1yBCIIgAQEBBBIBJTYKEQsYCRYPCQMCAQIBRRMGAgEBHodiC5l/oA+LUIMcgyEDlW2BFYRNiGOBa4Jv X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="77421358" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Oct 2012 12:00:07 +0000 Received: from [10.55.82.36] (dhcp-10-55-82-36.cisco.com [10.55.82.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9CC07oW023052 for ; Fri, 12 Oct 2012 12:00:07 GMT Message-ID: <50780647.6070003@cisco.com> Date: Fri, 12 Oct 2012 14:00:07 +0200 From: Tom Kristensen 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: bfcpbis@ietf.org References: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> In-Reply-To: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 12:00:09 -0000 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 : The Binary Floor Control Protocol (BFCP) > Author(s) : Gonzalo Camarillo > Keith Drage > Tom Kristensen > Joerg Ott > Charles Eckel > Filename : draft-ietf-bfcpbis-rfc4582bis-06.txt > Pages : 87 > Date : 2012-10-12 > Updated after receiving WGLC review comments from Mary Barnes, Charles Eckel and Ernst Horvath, according to discussion and description on the BFCPbis WG mailing list. In addition, and after checking out with the original authors of RFC 4582, the ipr parameter is changed s/pre5378Trust200902/trust200902/. Cf. -- Tom From tomkrist@cisco.com Fri Oct 12 05:02:29 2012 Return-Path: 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 9252F21F8582 for ; Fri, 12 Oct 2012 05:02:29 -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 JLpzzZ1Ou8Ew for ; Fri, 12 Oct 2012 05:02:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D91AA21F856D for ; Fri, 12 Oct 2012 05:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1458; q=dns/txt; s=iport; t=1350043349; x=1351252949; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0pBZbzTmKcHGUs3XCECFurVFU0CZ2pDQ/tb4KHNUdUQ=; b=LWzyj6PlSSlJBld953osnsf7votg+vU9d162EkjYQw2O9tVGVgMJMl/5 5alZyYvKKXu4Hc8sOp6RTGqRPt1G8CDRA6cN1BNG8lu7mMhLsni7peIPm webaRDPERmhkfLbKp/DUyJcuGzmz3PDhYnlHEYjWirssEhlvL95nfEKxu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGEGeFCQ/khR/2dsb2JhbABEv1yBCIIgAQEBBBIBJUARCxgJFg8JAwIBAgFFEwYCAQEeh2ILmXugD4tQgxyDIQOVbYEVhE2IY4Frgm8 X-IronPort-AV: E=Sophos;i="4.80,576,1344211200"; d="scan'208";a="77421399" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 Oct 2012 12:02:27 +0000 Received: from [10.55.82.36] (dhcp-10-55-82-36.cisco.com [10.55.82.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9CC2RcI012611 for ; Fri, 12 Oct 2012 12:02:27 GMT Message-ID: <507806D3.8090508@cisco.com> Date: Fri, 12 Oct 2012 14:02:27 +0200 From: Tom Kristensen 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: bfcpbis@ietf.org References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> In-Reply-To: <20121012115432.971.75272.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 12:02:29 -0000 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. -- Tom From eckelcu@cisco.com Fri Oct 12 15:54:54 2012 Return-Path: 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 5DBF121F84D8 for ; Fri, 12 Oct 2012 15:54:54 -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 FQdown2ar4iY for ; Fri, 12 Oct 2012 15:54:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BE49C21F8491 for ; Fri, 12 Oct 2012 15:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2098; q=dns/txt; s=iport; t=1350082493; x=1351292093; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RJsR1C9p5bEy5I0A7WP/dS29EMKROftUGlug0ndZHCo=; b=Eg1nbELDlsNROquLfHdR23sVo8M2C7EX90/xpmG+bAwCIjis2IR2nDL6 +fqpKUwKf499Xwn5X+QydDH5h2Ra0QzMrxm2FHR7xJUMrsycI4qWvhh3k s9jFNnUGDLEa8XxS4/BcpOfWH6NNfPjOBEvdnbZyPiXokLXb8b1RZ7DjU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANOeeFCtJXG9/2dsb2JhbABFv22BCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQEBChQJBycLFAkIAgQBEggah2EBC5szn3qLUoVdYAOXAo0wgWuCbYFcIxg X-IronPort-AV: E=Sophos;i="4.80,578,1344211200"; d="scan'208";a="131136004" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 12 Oct 2012 22:54:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9CMsrX8032221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 12 Oct 2012 22:54:53 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 17:54:53 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt Thread-Index: AQHNqHBT/Moj/2Z7+E+25CL3XKCrZ5e15S+AgABiH4A= Date: Fri, 12 Oct 2012 22:54:52 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280E3FA1@xmb-aln-x08.cisco.com> References: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> <50780647.6070003@cisco.com> In-Reply-To: <50780647.6070003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--48.716800-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 Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 22:54:54 -0000 Hi Tom, Thanks for the quick turnaround on this. I have reviewed the updated draft = and validated that all of my comments were addressed, except for this very = minor nit: 5) Section 6.2, r/Entities MUST only have at most one/Entities MUST have at most one I am okay not addressing this; however, if you need to make changes for any= other reason, it would be good to address this one as well. 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:00 AM > To: bfcpbis@ietf.org > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt >=20 > 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 W= orking > Group of the IETF. > > > > Title : The Binary Floor Control Protocol (BFCP) > > Author(s) : Gonzalo Camarillo > > Keith Drage > > Tom Kristensen > > Joerg Ott > > Charles Eckel > > Filename : draft-ietf-bfcpbis-rfc4582bis-06.txt > > Pages : 87 > > Date : 2012-10-12 > > >=20 > Updated after receiving WGLC review comments from Mary Barnes, Charles > Eckel and Ernst Horvath, according to discussion and description on the > BFCPbis WG mailing list. >=20 > In addition, and after checking out with the original authors of RFC > 4582, the ipr parameter is changed s/pre5378Trust200902/trust200902/. >=20 > Cf. http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf= -bfcpbis- > rfc4582bis-05.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4= 582bis- > 06.txt > > >=20 > -- Tom > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From 2mkristensen@gmail.com Mon Oct 15 01:32:05 2012 Return-Path: <2mkristensen@gmail.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 167FE21F8622 for ; Mon, 15 Oct 2012 01:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 IeGsS4mJWXcP for ; Mon, 15 Oct 2012 01:32:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19E8F21F8621 for ; Mon, 15 Oct 2012 01:32:03 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5651867obq.31 for ; Mon, 15 Oct 2012 01:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+mdVsJzAcZnVLtkd2RKAhR1fJ1C7T1+cXiaOXV68GhM=; b=fIrXkkMNLWYOKYnwkn7LZXiiApxv004/I+gp1PXZ7RjDIZzh8o8Up8TKFdHAWPhqii LnFIM2BsUsKflt8ZeQw2nZRZWUQCHo4i/8D+ekl76qYiIodxKSw43bmi2AQjeWZjpWIZ Q6+QKaIfr+U1oErcskdOsst8WeN2ZQv2OJSOu6XGBSTtaCLf7E8ujld26VrX9SxR+c+D 6xzW57T7l1E8Nhg/JtGXYQtEGw3f2Vs0LX9XLYKjdsOsiRQRCsYHK9cDauNKis4lGF5h RxTthyxDHW4XmfzXiRi/uS0StI9pYgRjHbD2vMR6YGyQ6g/AaXt7aMNymuRGxu31M/ia O+Yg== MIME-Version: 1.0 Received: by 10.182.18.165 with SMTP id x5mr9088287obd.73.1350289923293; Mon, 15 Oct 2012 01:32:03 -0700 (PDT) Received: by 10.182.232.67 with HTTP; Mon, 15 Oct 2012 01:32:03 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280E3FA1@xmb-aln-x08.cisco.com> References: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> <50780647.6070003@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E3FA1@xmb-aln-x08.cisco.com> Date: Mon, 15 Oct 2012 10:32:03 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 08:32:05 -0000 Thanks. I'll change it in my local diff, and I'm pretty sure something will need a change as the draft proceeds the higher layers of IETF process! -- Tom On 13/10/2012, Charles Eckel (eckelcu) wrote: > Hi Tom, > > Thanks for the quick turnaround on this. I have reviewed the updated draft > and validated that all of my comments were addressed, except for this very > minor nit: > > 5) Section 6.2, > r/Entities MUST only have at most one/Entities MUST have at most one > > I am okay not addressing this; however, if you need to make changes for any > other reason, it would be good to address this one as well. > > 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:00 AM >> To: bfcpbis@ietf.org >> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.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 : The Binary Floor Control Protocol (BFCP) >> > Author(s) : Gonzalo Camarillo >> > Keith Drage >> > Tom Kristensen >> > Joerg Ott >> > Charles Eckel >> > Filename : draft-ietf-bfcpbis-rfc4582bis-06.txt >> > Pages : 87 >> > Date : 2012-10-12 >> > >> >> Updated after receiving WGLC review comments from Mary Barnes, Charles >> Eckel and Ernst Horvath, according to discussion and description on the >> BFCPbis WG mailing list. >> >> In addition, and after checking out with the original authors of RFC >> 4582, the ipr parameter is changed s/pre5378Trust200902/trust200902/. >> >> Cf. > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-bfcpbis- >> rfc4582bis-05.txt&url2=http://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4582bis- >> 06.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 > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ From eckelcu@cisco.com Mon Oct 15 09:28:26 2012 Return-Path: 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 B85D921F86C7 for ; Mon, 15 Oct 2012 09:28:26 -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 Ae8TKJwoDSHR for ; Mon, 15 Oct 2012 09:28:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9521F86D1 for ; Mon, 15 Oct 2012 09:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1983; q=dns/txt; s=iport; t=1350318506; x=1351528106; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lLgD3BPzCSRgjg/lF2vb1XMtDZuC6R/k6pvEQ3SBjbs=; b=isaVAVlY1BLi1JloHRjJI9gBAq9jLYxwhDqOHrePnreq655NzT8Z7Hzp 0E644r9BpUSgvgfAtsoAU5V6eCVvgoknyDaJDGih+WlKQxwqzaE3WRibC NyvJwnKAcosvaVgYuUJXzTIIAjX87QRsVPNbFHsBtGYaM5sXuAcn3DHdG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIg4fFCtJXG9/2dsb2JhbABFv3eBCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoPAgMJBycLFAkIAgQBDQUIGodhAQueAZ95i1mDJgeCMGADlwGNMIFrgm2BPR87 X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="131774888" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 15 Oct 2012 16:28:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9FGSPPI026180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 16:28:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 11:28:25 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt Thread-Index: AQHNqHBT/Moj/2Z7+E+25CL3XKCrZ5e15S+AgAStAjA= Date: Mon, 15 Oct 2012 16:28:24 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280E4E04@xmb-aln-x08.cisco.com> References: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> <50780647.6070003@cisco.com> In-Reply-To: <50780647.6070003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--45.553600-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: "Horvath, Ernst \(ernst.horvath@siemens-enterprise.com\)" , "Mary Barnes \(mary.ietf.barnes@gmail.com\)" Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:28:26 -0000 (As co-chair) For those who provided comments during WGLC, please verify that this draft = addresses your comments. For everyone, if there are any outstanding issues of questions you have rel= ated to this draft, please share them now. We plan to proceed with the proto writeup soon.=20 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:00 AM > To: bfcpbis@ietf.org > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt >=20 > 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 W= orking > Group of the IETF. > > > > Title : The Binary Floor Control Protocol (BFCP) > > Author(s) : Gonzalo Camarillo > > Keith Drage > > Tom Kristensen > > Joerg Ott > > Charles Eckel > > Filename : draft-ietf-bfcpbis-rfc4582bis-06.txt > > Pages : 87 > > Date : 2012-10-12 > > >=20 > Updated after receiving WGLC review comments from Mary Barnes, Charles > Eckel and Ernst Horvath, according to discussion and description on the > BFCPbis WG mailing list. >=20 > In addition, and after checking out with the original authors of RFC > 4582, the ipr parameter is changed s/pre5378Trust200902/trust200902/. >=20 > Cf. http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf= -bfcpbis- > rfc4582bis-05.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4= 582bis- > 06.txt > > >=20 > -- Tom > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Mon Oct 15 09:29:10 2012 Return-Path: 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 39FA921F8701 for ; Mon, 15 Oct 2012 09:29:10 -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 IRB6murfV7GV for ; Mon, 15 Oct 2012 09:29:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 57B8A21F86FF for ; Mon, 15 Oct 2012 09:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2206; q=dns/txt; s=iport; t=1350318549; x=1351528149; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1UTj+eEiI9yhHgTObgfSarQV+9/2ryX8lGlUOb+qPQk=; b=TZPFx9/Tcaqazoxg3QIurbSwf7AcHd0hZrUqIgVRTu6wS+eWD2mv3v4y NloEbWp2FCt8WTV+XlE/AiA4NhrAFafy6hUJKf0lViTtOhuMTTvU6Rqdn Yq9OI+jGUpV/P9WXmeFu/BeucJnWp7tIzx4QJU9Fq5akn2cU8pSVJIk4l s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALU4fFCtJV2d/2dsb2JhbABFv3eBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQEBChQJBycLFAkIAgQBEggah2EBC54Bn3mLWYVdYAOXAY0wgWuCbYIX X-IronPort-AV: E=Sophos;i="4.80,588,1344211200"; d="scan'208";a="131521377" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 16:29:09 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9FGT8Il011294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Oct 2012 16:29:08 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 11:29:08 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNA= Date: Mon, 15 Oct 2012 16:29:08 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> In-Reply-To: <507806D3.8090508@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.26] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004 x-tm-as-result: No--47.715900-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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 16:29:10 -0000 (As co-chair) For everyone, if there are any outstanding issues of questions you have rel= ated to this draft, please share them now. We plan to proceed with the proto writeup soon.=20 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 >=20 > 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 W= orking > 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 Protoc= ol > > (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. > > >=20 > 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. >=20 > After checking out with the original author of RFC 4583, the ipr > parameter is changed s/pre5378Trust200902/trust200902/. >=20 > Cf. http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf= -bfcpbis- > rfc4583bis-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4= 583bis- > 03.txt > > >=20 > -- Tom >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From jonathan@vidyo.com Mon Oct 15 15:15:34 2012 Return-Path: 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 193EB21F8A35 for ; Mon, 15 Oct 2012 15:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 aIdnkl5J2m1n for ; Mon, 15 Oct 2012 15:15:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4518221F8A33 for ; Mon, 15 Oct 2012 15:15:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9096A4169AD; Mon, 15 Oct 2012 17:49:54 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BCEC64169D5; Mon, 15 Oct 2012 17:49:53 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 15 Oct 2012 18:15:30 -0400 From: Jonathan Lennox To: "Charles Eckel (eckelcu)" Date: Mon, 15 Oct 2012 18:15:29 -0400 Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: Ac2rIpW3FHUaPJSWTcmveMqCV6kPgw== Message-ID: References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 22:15:34 -0000 I greatly apologize; I should have sent this earlier. There are some BFCP usages in the IMTC Role-Based Video Streams work which have some unusual features -- = in particular, it recommends sending an offer with a BFCP stream referencin= g an mstrm that does not yet exist. (The intention is that if the SDP answ= er indicates that the peer understands both BFCP and the SDP content attrib= ute, a re-INVITE can be sent adding an additional BFCP-controlled video str= eam with "content:slides".) This document should probably call out that usage, at least to indicate tha= t 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) >=20 > For everyone, if there are any outstanding issues of questions you have r= elated to this draft, please share them now. > We plan to proceed with the proto writeup soon.=20 >=20 > Cheers, > Charles >=20 >> -----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 >>=20 >> 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 Wo= rking >> Group of the IETF. >>>=20 >>> 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 >>>=20 >>> Abstract: >>> This document specifies how to describe Binary Floor Control Protoco= l >>> (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. >>>=20 >>> This document obsoletes RFC 4583. Changes from RFC 4583 are >>> summarized in section 12. >>>=20 >>=20 >> 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. >>=20 >> After checking out with the original author of RFC 4583, the ipr >> parameter is changed s/pre5378Trust200902/trust200902/. >>=20 >> Cf. > http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-iet= f-bfcpbis- >> rfc4583bis-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfcpbis-rfc= 4583bis- >> 03.txt >>>=20 >>=20 >> -- Tom >>=20 >> _______________________________________________ >> 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 >=20 -- Jonathan Lennox jonathan@vidyo.com From mary.ietf.barnes@gmail.com Tue Oct 16 14:03:27 2012 Return-Path: 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 CF8D211E80F3 for ; Tue, 16 Oct 2012 14:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 cTAdEuFfrLRg for ; Tue, 16 Oct 2012 14:03:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1811E80D5 for ; Tue, 16 Oct 2012 14:03:26 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5174796lbo.31 for ; Tue, 16 Oct 2012 14:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pOnydD4I7LKlIEBImHk67xWF7eQa5ndDPmHprkgSAdM=; b=lyYEmnx87Ie0MnByGtrClU7lJ3f6jO44Z8wx02+XshHrkK9oMNLU4SvjyuNedPopkA Gc8y2WQwZyfO8S5az7n79TIhbh4f7LrPU5PKj6Gmwh7dxeCsH1xHrm09IflxtfZPnGtk yBEkHU3wrKLqhPQUqutLAldkDtuRRL0QzWnWRJXdxwlehhinWGJCEsdXbSOGIyUy5wYR 5leKzJ87RbDtBjigjfloVtPNqOsTlJ4SKqjKjn7erVuFN7KoEomFCfctHrW/p8HOWbNV xgudUMNJoeO2fyYhybfkmBtcHXrAwK7hNqprBcmDJKSrajx2N2wGuTNsDwrY3BpxdGfO 15fg== MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr13722421lab.48.1350421405666; Tue, 16 Oct 2012 14:03:25 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 16 Oct 2012 14:03:25 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280E4E04@xmb-aln-x08.cisco.com> References: <20121012115421.26326.75189.idtracker@ietfa.amsl.com> <50780647.6070003@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E04@xmb-aln-x08.cisco.com> Date: Tue, 16 Oct 2012 16:03:25 -0500 Message-ID: From: Mary Barnes To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=f46d040714af2e8f0004cc337ccc Cc: "Horvath, Ernst \(ernst.horvath@siemens-enterprise.com\)" , "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 21:03:27 -0000 --f46d040714af2e8f0004cc337ccc Content-Type: text/plain; charset=ISO-8859-1 I reviewed the updated version and my previous review comments have been addressed. Mary. On Mon, Oct 15, 2012 at 11:28 AM, Charles Eckel (eckelcu) wrote: > (As co-chair) > > For those who provided comments during WGLC, please verify that this draft > addresses your comments. > 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:00 AM > > To: bfcpbis@ietf.org > > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.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 : The Binary Floor Control Protocol (BFCP) > > > Author(s) : Gonzalo Camarillo > > > Keith Drage > > > Tom Kristensen > > > Joerg Ott > > > Charles Eckel > > > Filename : draft-ietf-bfcpbis-rfc4582bis-06.txt > > > Pages : 87 > > > Date : 2012-10-12 > > > > > > > Updated after receiving WGLC review comments from Mary Barnes, Charles > > Eckel and Ernst Horvath, according to discussion and description on the > > BFCPbis WG mailing list. > > > > In addition, and after checking out with the original authors of RFC > > 4582, the ipr parameter is changed s/pre5378Trust200902/trust200902/. > > > > Cf. > > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-bfcpbis- > > rfc4582bis-05.txt&url2= > http://tools.ietf.org/id/draft-ietf-bfcpbis-rfc4582bis- > > 06.txt > > > > > > > -- Tom > > _______________________________________________ > > bfcpbis mailing list > > bfcpbis@ietf.org > > https://www.ietf.org/mailman/listinfo/bfcpbis > --f46d040714af2e8f0004cc337ccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I reviewed the updated version and my previous review comments have been ad= dressed.

Mary.

On Mon,= Oct 15, 2012 at 11:28 AM, Charles Eckel (eckelcu) <eckelcu@cisco.com&= gt; wrote:
(As co-chair)

For those who provided comments during WGLC, please verify that this draft = addresses your comments.
For everyone, if there are any outstanding issues of questions you have rel= ated 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-bounce= s@ietf.org] On
> Behalf Of Tom Kristensen (tomkrist)
> Sent: Friday, October 12, 2012 5:00 AM
> To: bfcpbis@ietf.org
> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-06.tx= t
>
> On 10/12/2012 01:54 PM, = internet-drafts@ietf.org wr= ote:
> > A New Internet-Draft is available from the on-line Internet-Draft= s
> directories.
> > =A0 This draft is a work item of the Binary Floor Control Protoco= l Bis =A0Working
> Group of the IETF.
> >
> > =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Binary Floor Control Prot= ocol (BFCP)
> > =A0 =A0 Author(s) =A0 =A0 =A0 : Gonzalo Camarillo
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Keith Drag= e
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tom Kriste= nsen
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Joerg Ott<= br> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Charles Ec= kel
> > =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-bfcpbis-rfc4582bis-0= 6.txt
> > =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 87
> > =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-12
> >
>
> Updated after receiving WGLC review comments from Mary Barnes, Charles=
> Eckel and Ernst Horvath, according to discussion and description on th= e
> BFCPbis WG mailing list.
>
> In addition, and after checking out with the original authors of RFC > 4582, the ipr parameter is changed s/pre5378Trust200902/trust200902/.<= br> >
> Cf. <URL:
> http://tools.ietf.org//rfcdiff?u= rl1=3Dhttp://tools.ietf.org/id/draft-ietf-bfcpbis-
> rfc4582bis-05.txt&url2=3Dhttp://tools.ietf.org/id/draft= -ietf-bfcpbis-rfc4582bis-
> 06.txt
> =A0>
>
> -- Tom
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis

--f46d040714af2e8f0004cc337ccc-- From tomkrist@cisco.com Wed Oct 17 01:44:17 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.>> 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 > > > From eckelcu@cisco.com Thu Oct 18 13:33:27 2012 Return-Path: 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 24C1021F84F2 for ; Thu, 18 Oct 2012 13:33:27 -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 D2ia-NIcaTMC for ; Thu, 18 Oct 2012 13:33:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 119E021F84F9 for ; Thu, 18 Oct 2012 13:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4942; q=dns/txt; s=iport; t=1350592406; x=1351802006; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1+jdbYcAkrm3YfAJ61UnYl0YkRC1BDWbJvYGYTONlxo=; b=TPwFeHKGhnqLkiW6sanY6Pw5fQMEAzl1HGV33z20v3tFDc2sd6LLO7DE IVvIC/NLLb1y7ykXqDZQNqgt2bA5JpWftgGClhOUCW0xjvuPNZxJIA1Ff DKsnnklrG5+tktJcG9Xcq5zeIuC42u5dtpU5CqD6QWh0VwKa/oPwSAX3a o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGVmgFCtJXHB/2dsb2JhbAA/BsBTgQiCIAEBAQIBAQEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBqHXAUBC50WoDiLWCaFPGADlwCNNIFrgm+CFw X-IronPort-AV: E=Sophos;i="4.80,609,1344211200"; d="scan'208";a="133180008" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 18 Oct 2012 20:33:25 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9IKXPOC006153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 20:33:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 15:33:25 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Jonathan Lennox Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNCAALTCgIACQfqAgAIDEkA= Date: Thu, 18 Oct 2012 20:33:25 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <507E6FD9.1080807@cisco.com> In-Reply-To: <507E6FD9.1080807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.120] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--57.009000-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" , "Gonzalo Camarillo \(Gonzalo.Camarillo@ericsson.com\)" , "Robert Sparks \(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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 20:33:27 -0000 I see no harm in adding such a note, and it may help. As for referencing th= e 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 exter= nally 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 >=20 > 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. >=20 > 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. >=20 > (Do we then reference the IMTC document as an informational reference or > simply state the fact that this behaviour exists in the wild?!) >=20 > -- Tom >=20 > 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 which have some unusual > features -- in particular, it recommends sending an offer with a BFCP str= eam > 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 hav= e > 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.t= xt > >>> > >>> 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 Bin= ary > >>>> > >>> 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) description= s. > >>>> User agents using the offer/answer model to establish BFCP strea= ms > >>>> 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 fro= m > >>> the extensions in rfc4582bis. > >>> > >>> After checking out with the original author of RFC 4583, the ipr > >>> parameter is changed s/pre5378Trust200902/trust200902/. > >>> > >>> Cf. >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-= ietf- > bfcpbis- > >>> rfc4583bis-02.txt&url2=3Dhttp://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 > > > > > > From eckelcu@cisco.com Tue Oct 23 11:17:07 2012 Return-Path: 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 B505721F86C1 for ; Tue, 23 Oct 2012 11:17:07 -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 1xMoF1+KIoM6 for ; Tue, 23 Oct 2012 11:17:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B024721F86B1 for ; Tue, 23 Oct 2012 11:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7106; q=dns/txt; s=iport; t=1351016226; x=1352225826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CJfELyaf2k0NPq1B2Vg8njByvgAi1HOuvCyh9a6bCj4=; b=epNxTM0+0OMDEWGl/dKgeySBw01SwgY3+SYA1iDmnAl+aXDsDg4jptxy oNKolwBWmru7pVS2Em2W9o6SrXWfpRRQdZqw1HHn4xIPhirZlqsQm3UyN 9jBcekzMI9xnEbekJqBJXGFeRn2yhvCBrlkigrkKQIJkCJKFPk2g1IcpV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAArehlCtJV2c/2dsb2JhbAA+BsFwgQiCHgEBAQMBAQEBDwEnNAsFBwQCAQgRBAEBAQoLCQkHJwsUCQgCBAENBQgah1wFAQucBo9ckC6LXyaDCYJPYAOXCI03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134571356" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2012 18:17:06 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9NIH6r1021203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 18:17:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 13:17:05 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Jonathan Lennox Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNCAALTCgIACQfqAgAIDEkCAB67PoA== Date: Tue, 23 Oct 2012 18:17:05 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> 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-19298.000 x-tm-as-result: No--63.434700-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" , "Gonzalo Camarillo \(Gonzalo.Camarillo@ericsson.com\)" , "Robert Sparks \(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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:17:07 -0000 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.=20 I interpret this to already account for the possibility of a floorid that i= s 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=20 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 >=20 > 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 >=20 > 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. >=20 > Thanks, > Charles >=20 > > -----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 curren= t > > 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 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 i= f 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 indica= te > 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 h= ave > > 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 B= is > > Working > > >>>> > > >>> Group of the IETF. > > >>> > > >>>> Title : Session Description Protocol (SDP) Format for B= inary > > >>>> > > >>> 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) descripti= ons. > > >>>> 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. > >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draf= t-ietf- > > bfcpbis- > > >>> rfc4583bis-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfcpbi= s- > > 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 > > > > > > > > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From jonathan@vidyo.com Tue Oct 23 14:43:18 2012 Return-Path: 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 523641F0C92 for ; Tue, 23 Oct 2012 14:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 KhbiHnyXOZBh for ; Tue, 23 Oct 2012 14:43:17 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 116221F0C42 for ; Tue, 23 Oct 2012 14:43:17 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CE6F6416A04; Tue, 23 Oct 2012 17:43:17 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5F21B41689D; Tue, 23 Oct 2012 17:43:16 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 23 Oct 2012 17:43:05 -0400 From: Jonathan Lennox To: "Charles Eckel (eckelcu)" , "Tom Kristensen (tomkrist)" Date: Tue, 23 Oct 2012 17:43:11 -0400 Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNCAALTCgIACQfqAgAIDEkCAB67PoIAAPMAw Message-ID: References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:43:18 -0000 Hi Charles, I agree that description makes sense. I thought I had recalled the IMTC do= cument 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]=20 Sent: Tuesday, October 23, 2012 2:17 PM To: Tom Kristensen (tomkrist); Jonathan Lennox Cc: bfcpbis@ietf.org; Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com); R= obert 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.=20 I interpret this to already account for the possibility of a floorid that i= s 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=20 any associated media streams being identified in subsequent exchanges. Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On=20 > 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=20 > (Gonzalo.Camarillo@ericsson.com); Robert Sparks (rjsparks@nostrum.com) > Subject: Re: [bfcpbis] I-D Action:=20 > draft-ietf-bfcpbis-rfc4583bis-03.txt >=20 > I see no harm in adding such a note, and it may help. As for=20 > referencing the IMTC best practice document, it is available through a li= aison 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 >=20 > However, I expect this IMTC document to be updated and made available=20 > externally once the BFCPBIS work completes, so I am not sure=20 > referencing it this way is appropriate. >=20 > Thanks, > Charles >=20 > > -----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:=20 > > draft-ietf-bfcpbis-rfc4583bis-03.txt > > > > I'm not sure we should say much about this in rfc4583bis. This is=20 > > similar to existing "best effort encryption" schemes, where=20 > > different vendors historically have had their own interpretation of=20 > > a best current practice. > > > > Anyway, it is not a big deal adding an informational note, if people=20 > > thinks that's a good idea, explaining that one may very well meet an=20 > > mstrm referring to a still undefined label. > > > > (Do we then reference the IMTC document as an informational=20 > > 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 which have some > unusual > > features -- in particular, it recommends sending an offer with a=20 > > BFCP > stream > > referencing an mstrm that does not yet exist. (The intention is=20 > > that if the SDP answer indicates that the peer understands both BFCP=20 > > and the SDP content attribute, a re-INVITE can be sent adding an=20 > > additional BFCP- controlled video stream with "content:slides".) > > > > > > This document should probably call out that usage, at least to=20 > > > 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=20 > > >> 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:=20 > > >>> 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=20 > > >>>> Internet-Drafts > > >>>> > > >>> directories. > > >>> > > >>>> This draft is a work item of the Binary Floor Control=20 > > >>>> Protocol Bis > > Working > > >>>> > > >>> Group of the IETF. > > >>> > > >>>> Title : Session Description Protocol (SDP) Format for B= inary > > >>>> > > >>> 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=20 > > >>>> Control > > Protocol > > >>>> (BFCP) streams in Session Description Protocol (SDP) descripti= ons. > > >>>> 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=20 > > >>> short, simple draft where the changes follows more or less=20 > > >>> automatically > from > > >>> the extensions in rfc4582bis. > > >>> > > >>> After checking out with the original author of RFC 4583, the ipr=20 > > >>> parameter is changed s/pre5378Trust200902/trust200902/. > > >>> > > >>> Cf. > >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/dra > > >>> ft-ietf- > > bfcpbis- > > >>> rfc4583bis-02.txt&url2=3Dhttp://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 > > > > > > > > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From tomkrist@cisco.com Tue Oct 23 22:47:40 2012 Return-Path: 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 D0A9021F8CEB for ; Tue, 23 Oct 2012 22:47:40 -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 YEQz1pBYR4Ac for ; Tue, 23 Oct 2012 22:47:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id F256B21F8CBC for ; Tue, 23 Oct 2012 22:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8730; q=dns/txt; s=iport; t=1351057659; x=1352267259; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HEBIRyhap4Iq38tRe5h93bpVOMwgCIqzp0XzTpeFeTo=; b=nKezTn22tRUZ+Iu888E+4BZsejCcb5qM5vL742OYf4pDkMuMQ2q4XtQW J/MSc4XrjL+Nyg8HUnau7e2rL9yFEhzd+ZuqodB9N6yrs4Qz5EhtY7qR7 /Uk1GTnRvSxKrBkzYAqUOaZVy4Pak97NhTdavFd2rZ51B8qS69pulRr3P E=; X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208";a="77704442" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 24 Oct 2012 05:47:37 +0000 Received: from [10.55.81.19] (dhcp-10-55-81-19.cisco.com [10.55.81.19]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9O5larg017684; Wed, 24 Oct 2012 05:47:36 GMT Message-ID: <508780F8.7080309@cisco.com> Date: Wed, 24 Oct 2012 07:47:36 +0200 From: Tom Kristensen 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 References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" , "Robert Sparks \(rjsparks@nostrum.com\)" , "Charles Eckel \(eckelcu\)" , "Gonzalo Camarillo \(Gonzalo.Camarillo@ericsson.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 05:47:40 -0000 Charles, The additional text is good. However, I don't think it's necessary to include. -- Tom On 10/23/2012 11:43 PM, Jonathan Lennox wrote: > 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 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.>>>>> 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 >> From gonzalo.camarillo@ericsson.com Wed Oct 24 03:21:30 2012 Return-Path: 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 2DC5821F8BAF for ; Wed, 24 Oct 2012 03:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ZHYm4vxxYGWu for ; Wed, 24 Oct 2012 03:21:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74021F8BB0 for ; Wed, 24 Oct 2012 03:21:27 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-d0-5087c126a672 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.7A.04547.621C7805; Wed, 24 Oct 2012 12:21:26 +0200 (CEST) Received: from [131.160.36.90] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 12:21:25 +0200 Message-ID: <5087C125.2050109@ericsson.com> Date: Wed, 24 Oct 2012 13:21:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: BFCPBIS WG X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+Jvra7awfYAg6v/xCz+rTvK5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFMdDWwFdxMrHr/8wNTAuMmvi5GTQ0LAROJ153IWCFtM4sK9 9WxdjFwcQgKnGCXuT29jhnBWM0o0ffvCBlLFK6AtsXPFb7AOFgFVic83e1lBbDYBC4ktt+6D xUUFgiXObdwGVS8ocXLmE7C4iICixMlXE5lBbGEBU4mnF44yQ2yWlHgz+SZYDbOAnsSUqy2M ELa8xPa3c8BqhID2Ln/WwjKBkX8WkrGzkLTMQtKygJF5FaNwbmJmTnq5kV5qUWZycXF+nl5x 6iZGYKAd3PJbdQfjnXMihxilOViUxHmtt+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBY MaeDRUbAvPR9qnZXjz+f+tkZeRL+X/1k+QW+HnvmP+X0uyW8RgXLWTLcruQ8qN+jJqH02PLk +6uXNsnNDQwW/HFUrWRPT5FvRfXdw5z7rOZ/WLDzs9C0/+ZWjTWGm19c6484FJstlrUrp/Cm 5vKTf3049cxncrWY5Zt1yLneO1YeoHpkv70SS3FGoqEWc1FxIgBUPRqzAgIAAA== Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-06 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:21:30 -0000 Folks, here you have some comments on the following draft: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06 Cheers, Gonzalo Comments on draft-ietf-bfcpbis-rfc4582bis-06 In the whole document: when referring to a reliable or to an unreliable transport, the indefinite article (i.e., "a" or "an") needs to be used. For example: OLD: When communicating over unreliable transport... NEW: When communicating over an unreliable transport... Abstract: OLD: Changes from RFC 4582 are summarized in section 16. NEW: Changes from RFC 4582 are summarized in Section 16. Sections 3.1 and 3.3 The document needs to reference the XCON documents (which were published after RFC 4582) that deal with floor creation, termination, and floor-resource association (e.g., RFC 6503). Roberta wrote the following text. You can use it as a base, edit it as you wish, and add a paragraph to each of the sections (3.1 and 3.3). "As to the XCON framework, floor settings such as floor identifiers, associated resources, moderator identifier, etc., are held in the section of conference objects. Conference control clients using CCMP (RFC 6505) can specify such floor-related settings by editing the floor-information section of the to-be created conference object provided in the body of a CCMP confRequest/create message issued to the conference control server. According to the conferencing system policies, conference control clients can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the section of the target conference object. More information about CCMP and BFCP interaction can be found in RFC6504." Section 3.2: Add a reference to RFC 5018. Section 4: OLD: There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions (notifications), further details in Section 8. NEW: There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions (notifications). Section 8 describes both types of transactions in detail. Section 4.1: OLD: Figures 2 and 3 below show call flows for two sample BFCP interactions when used over reliable transport. Appendix A shows the same sample interactions but over an unreliable transport. NEW: Figures 2 and 3 below show examples of call flows where BFCP is used over a reliable transport. Appendix A shows the same call flow examples using an unreliable transport instead. Sections 5.3.14 and 5.3.15 talk about acknowledging a "subsequent" message. Why is it a subsequent message? Maybe we can delete that word. Section 5.3.14. OLD: FloorRequestStatus message from the floor control server by sending an FloorRequestStatusAck. NEW: FloorRequestStatus message from the floor control server by sending a FloorRequestStatusAck message. Do a similar fix to the above across the document so that it is consistent. For example, the same issue appears in Sections 5.3.15 and 5.3.16. Section 6 says: "(e.g., using an SDP offer/answer exchange [7])" We should also add a reference to RFC 5018. Additionally, the document could discuss at some point what happens when the mechanism in RFC 5018 is used. Section 6: OLD: TCP, appropriate where entities can be sure that their connectivity is not impeded by NAT devices, media relays or firewalls; NEW: TCP, appropriate where connectivity is not impeded by network elements such as NAT devices or media relays; Section 6.1 OLD: Consequently, message framing is implemented in the application layer. NEW: Consequently, message framing needs to be implemented in the application layer. Section 6.2 OLD: To avoid BFCP messages being fragmented at the IP layer, in the event the size of a BFCP message exceeds the MTU size, the fragmentation will be handled by the BFCP protocol. NEW: To keep large BFCP messages from being fragmented at the IP layer, the fragmentation of BFCP messages that exceeding the MTU size is performed at the BFCP level. OLD: The message format for exchange of BFCP in UDP datagrams is the same as for a TCP stream above. NEW: The message format for BFCP messages is the same regardless of whether the messages are sent in UDP datagrams or over a TCP stream. In the following paragraph, I have removed the MUST because the floor control server could respond with, for example, an error message instead. OLD: Clients MUST announce their presence to the floor control server by transmission of a Hello message. This Hello message MUST be responded to with a HelloAck message and only upon receipt of HelloAck can the client consider the floor control service as present and available. NEW: Clients MUST announce their presence to the floor control server by sending a Hello message. The floor control server responds to the Hello message with a HelloAck message. The client considers the floor control service as present and available only upon receiving the HelloAck message. The following paragraph (the second sentence in particular) needs to be clarified. The paragraph starts talking about a floor control server receiving a message and then talks about a client discarding the message. Also, why would an entity discard a message only to receive a retransmission of the *same* message later? It is not clear what the paragraph means. "If a Floor Control Server receives data that cannot be parsed, the receiving server SHOULD send an Error message with parameter value 10 (Unable to parse message) indicating receipt of a malformed message. If the message can be parsed to the extent that it is able to discern that it was a response to an outstanding request transaction, the client MAY discard the message as the client will retransmit the message when the retransmit timer T1 specified in Section 8.3.1 fires." The document says: " Transaction ID values are non-sequential and entities are at liberty to select values at random." The document needs to make it clear what is the requirement and the level of randomness required. For example, what happens if the same transaction ID is reused and a retransmission of the message that first used that transaction ID arrives? What is a "delinquent" response? Section 6.2.2 deals with ICMP errors for UDP. We should also specify how to handle ICMP errors for TCP, for consistency. Also in Section 6.2.2, the following sentences talk about a "conversation" and a "connection" in the context of UDP. What do those terms mean? "The entity MAY attempt to re-establish the conversation afresh. The new connection will appear as a wholly new floor participant, chair or floor control server with all state previously held about that participant lost." Section 6.2.2 also says: "Note: This is because the peer entities cannot rely on IP and port tuple to uniquely identify the participant, nor would extending Hello to include an attribute that advertised what the entity previously was assigned as a User ID be acceptable due to session hijacking." This paragraph in unclear as well... it needs to be clarified together with the previous one so that both are easier to understand. Also in Section 6.2.2, per one of my comments above, remove the reference to firewalls. In general, remove references to firewalls across the document (e.g., they also appear in Appendix A). Section 6.2.3 says: "The size of a BFCP message is limited by the 16-bit Payload Length field of the COMMON-HEADER." This is applicable to BFCP messages in general whether they are sent over TCP or UDP. However, Section 6.2.3 is under Section 6.2, which deals with unreliable transports. The document needs to make it clear that this is also applicable to TCP. Also, what is the implication of that limit? What happens if a message would need to be larger than that? What does the floor control server do in that case? Also in Section 6.2.3: "When using UDP, a single BFCP message may be fragmented at the IP layer if its overall size exceeds the MTU threshold of the network." Use "path MTU" instead of "MTU threshold". Also, the sentence should be clear that we are simply talking hypothetically, since BFCP entities will not send such large messages; they will fragment them instead following the steps that are described right after that sentence. Across the document, always use "path MTU". Not "MTU" on any other term. Also in Section 6.2.3: "When transmitting a BFCP message with size greater than the MTU, the sender should fragment the message into a series of N contiguous data ranges." We need to add a normative word. A MUST probably. Where does the document talk about path MTU discovery? How do BFCP entities discover what is the path MTU? Also in Section 6.2.3: "When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until it has received the entire BFCP message." When dealing with fragmentation and especially with the buffering of unauthenticated fragments one always thinks about DoS attacks. Could a client perform a resource attack on a server by using this fragmentation mechanism? We should probably discuss this somewhere in the document, explaining that the time this state is kept is limited by a timer and what role DTLS plays into this. Also in Section 6.2.3: "The receiver MUST then retransmit the ACK. The receiver can discard an incomplete buffer utilizing the Response Retransmission Timer, starting the timer after the receipt of the first fragment." The first sentence should not contain a normative statement, since sending an ACK on receiving a message is specified somewhere else. Also, the term "ACK" has not been defined in the document. It should if we want to use it in this section. The second sentence should have a normative statement. Section 6.2.3 needs to briefly discuss (at the beginning of the section) that BFCP acknowledges the reception of whole messages, not of fragments. That is why the loss of a fragment implies the retransmission of the whole message. The document can talk about how inefficient that is and why we have decided to do it anyway (e.g., for simplicity reasons). Section 6.2.3 needs to talk about the interactions of using DTLS and fragmentation. Section 6.2.4 talks (in a couple of places) about BFCP over UDP entities. However, the rest of the document talks about entities using unreliable transports. The terminology needs to be consistent. Section 8: "Server-initiated transactions consist of a single message from a floor control server to a client. Since they do not trigger any response, their Transaction ID is set to 0 when used over reliable transports, but must be non-zero and unique in the context of outstanding transactions over unreliable transports." This paragraph needs to be rephrased so that it is clear how this works for TCP and for UDP. For example, with UDP the transaction will not be a single message. Also in Section 8: "When using BFCP over unreliable transports, all requests will use retransmit timer T1 (see Section 8.3) until the transaction is completed." Use "retransmission timer" instead. Section 8.1 "The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction." See my comment above about reusing transaction ID values and the risk of receiving retransmissions of the original message. Section 8.3.1 We probably want to remove the following statement: "Alternatively, they MAY continue without BFCP and therefore not be participant in any floor control actions." Section 8.3.2 "T2 shall be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities." This sentence probably belongs to Section 8.3.3, together with a discussion on the default value that has been chosen for T2. Note that whole Section 8.3.3 contains such a discussion for T1, it does not contain one for T2. From gonzalo.camarillo@ericsson.com Wed Oct 24 03:32:36 2012 Return-Path: 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 25A9821F8BAF for ; Wed, 24 Oct 2012 03:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 COOH8gTEVDLC for ; Wed, 24 Oct 2012 03:32:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B563B21F8B76 for ; Wed, 24 Oct 2012 03:32:32 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-e6-5087c3bf4118 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 72.5C.04547.FB3C7805; Wed, 24 Oct 2012 12:32:31 +0200 (CEST) Received: from [131.160.36.90] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 12:32:30 +0200 Message-ID: <5087C3BE.1080301@ericsson.com> Date: Wed, 24 Oct 2012 13:32:30 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tom Kristensen References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> <50753CEE.2080907@cisco.com> In-Reply-To: <50753CEE.2080907@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvre7+w+0BBl/uCVr8W3eUyWLTrC9s Fp/372e2uHLkF5sDi8eU3xtZPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujI9L+tkKjjFV zG9oYG1g/MHYxcjJISFgIrFx5hsWCFtM4sK99WxdjFwcQgKnGCVOflzHDOGsZpS4t2gdUAcH B6+AtsT+m9YgDSwCqhJfdi4CG8QmYCGx5dZ9sEGiAsES5zZuYwOxeQUEJU7OfAIWFxFQl+jb +50dZCazQDujxLmeu6wgCWEBW4n/m/axQCxbwygxYcYRsASngKbEvsOP2SHOk5R4M/km2CRm AT2JKVdbGCFseYntb+cwg9hCQMctf9bCMoFRaBaS5bOQtMxC0rKAkXkVo3BuYmZOermRXmpR ZnJxcX6eXnHqJkZgkB/c8lt1B+OdcyKHGKU5WJTEea237vEXEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwFjtaLXqnrbbw4/Mgcca3rh+Z1ppvySB5dOthGkbfe1Orfh6hzNjw13NyU8Ng5o2 T28+t+uoosLnZNPvNtbZCfMcNeKe3GeO008W+Pco4tmFyi629+syNtm+qr57UTfKJ/cH4/6L R/cUPP2R+D9vMtutAxnC209OyuzSYpAJdPcVTJNRuFkcXKzEUpyRaKjFXFScCAC9UCMEQAIA AA== Cc: "bfcpbis@ietf.org" , Mary Barnes , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:32:36 -0000 Hi Tom, > I don't remember why MAY was chosen here, but after having a look at > this again I see that SHOULD is used for sending an Error message twice > in the original RFC 4582. So, we should (!) change to SHOULD. OK? yes, the sending of error responses should appear at the SHOULD level. Thanks, Gonzalo From tomkrist@cisco.com Wed Oct 24 04:30:06 2012 Return-Path: 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 90C1121F8B7C for ; Wed, 24 Oct 2012 04:30:06 -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 TWtlooVYiuTm for ; Wed, 24 Oct 2012 04:30:06 -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 B7AC821F8B76 for ; Wed, 24 Oct 2012 04:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=435; q=dns/txt; s=iport; t=1351078205; x=1352287805; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=83rponLwQdhHTYtDpJHI4Zio0Vu9eBWOXmVLUgZVNP4=; b=N2vu84X/9dJNsbWzt/zzCyJT5FXN/blRut7Ve1DNs6QeXMqHKlk6EBdd GcOHLR0VORlmz7cxVppBniSIxmEajHDJlQHZHAxhtXnQ/1Q6xg8QD1IUD FgIZ6AkCVS8g3PaxZ8+NObOrbxWBv0Gyx3JO5Z98vEZeUQvrV1b0CCH9F M=; X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="9050555" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 24 Oct 2012 11:30:04 +0000 Received: from [10.55.81.19] (dhcp-10-55-81-19.cisco.com [10.55.81.19]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9OBU4i3021337; Wed, 24 Oct 2012 11:30:04 GMT Message-ID: <5087D13C.70302@cisco.com> Date: Wed, 24 Oct 2012 13:30:04 +0200 From: Tom Kristensen 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: Gonzalo Camarillo References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com> <50753CEE.2080907@cisco.com> <5087C3BE.1080301@ericsson.com> In-Reply-To: <5087C3BE.1080301@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" , Mary Barnes , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:30:06 -0000 On 10/24/2012 12:32 PM, Gonzalo Camarillo wrote: > Hi Tom, > > >> I don't remember why MAY was chosen here, but after having a look at >> this again I see that SHOULD is used for sending an Error message twice >> in the original RFC 4582. So, we should (!) change to SHOULD. OK? >> > yes, the sending of error responses should appear at the SHOULD level. > Good, this is fixed in the -06 version. -- Tom From tomkrist@cisco.com Wed Oct 24 04:38:55 2012 Return-Path: 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 A8F3821F8B89 for ; Wed, 24 Oct 2012 04:38:54 -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 RG8jMp1UrhDb for ; Wed, 24 Oct 2012 04:38:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A821B21F8829 for ; Wed, 24 Oct 2012 04:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=512; q=dns/txt; s=iport; t=1351078734; x=1352288334; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lfCioCVSJVog+kr005rCdLmvSQ1mDLZcvj8b/Z1iEF0=; b=g6hbB7SPHbTPbBBVZ0uFaS6Q1LWuEMHO8aYfmLs5NSJEqm5cd3OOm037 ydh7WBFgeURnywcjgJb1NOaGlPn/lMWfuOF2plk98ZdZ0yc9ZHIfMykmG 3WmWBIOyW8rZ/VPaK8bGly8jLSp/xyiRja1UCkup7/wpStI8IwXmkhnBk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8JAIrRh1CQ/khL/2dsb2JhbABEhU27IAQEgQeBCIIeAQEBBBIBJUABEAsYCRYPCQMCAQIBRQYNAQcBAR6HYgubF6AHi2CGawOVc4EXhE2IaoFrgnE X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="145736500" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2012 11:38:53 +0000 Received: from [10.55.81.19] (dhcp-10-55-81-19.cisco.com [10.55.81.19]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9OBcq9L022953; Wed, 24 Oct 2012 11:38:52 GMT Message-ID: <5087D34C.4080708@cisco.com> Date: Wed, 24 Oct 2012 13:38:52 +0200 From: Tom Kristensen 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: Gonzalo Camarillo References: <5087C125.2050109@ericsson.com> In-Reply-To: <5087C125.2050109@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BFCPBIS WG Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-06 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:38:55 -0000 On 10/24/2012 12:21 PM, Gonzalo Camarillo wrote: > Folks, > > here you have some comments on the following draft: > > http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06 > > Cheers, > > Gonzalo > > > Comments on draft-ietf-bfcpbis-rfc4582bis-06 > Thanks, Good and important feedback on various issues. I'll ASAP go through the text and fix accordingly, and provide answers and comments to this thread where things need more discussion and input from the WG. -- Tom From gonzalo.camarillo@ericsson.com Wed Oct 24 07:27:51 2012 Return-Path: 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 BBE7F21F8A8C for ; Wed, 24 Oct 2012 07:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 DN53RUR2BtKR for ; Wed, 24 Oct 2012 07:27:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7C21F8A89 for ; Wed, 24 Oct 2012 07:27:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-fb-5087fae4c21a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FB.91.04547.4EAF7805; Wed, 24 Oct 2012 16:27:49 +0200 (CEST) Received: from [131.160.126.188] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 16:27:48 +0200 Message-ID: <5087FAE4.5010900@ericsson.com> Date: Wed, 24 Oct 2012 17:27:48 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: bfcpbis@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvre7TX+0BBvsOMlr8W3eUyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGSuOahW846o48/UOcwPjS44uRk4OCQETiY/rPrBB2GISF+6t B7K5OIQETjFKbJjwjAXCWcsocerwPSaQKl4BbYkrr76xgNgsAqoSuy7sBYuzCVhIbLl1Hywu KhAscW7jNjaIekGJkzOfgMVFBEQkdsy6yApiCwuYSny7fIMFYrOkxJvJN8FsZgE9iSlXWxgh bHmJ7W/nMIPYQkB7lz9rYZnAyD8LydhZSFpmIWlZwMi8ilE4NzEzJ73cSC+1KDO5uDg/T684 dRMjMMwObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDc M61Mc/dH1r8+ihqzfebczy+vTdeab7DJZ+mEox+/tYl7tu6LkOHLv+Jn/C8gVmg5z1TXL50L txuwvVv56/3cLRKLl7x+6rySITqHNbG6o1Pmky+raPOehw+js125zDTmRc45+/Hg3T9i7Dfm rev/tiwh//sssfM54mvWOXBdWjmxzrS5atljJZbijERDLeai4kQA/ZhPpgECAAA= Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:27:51 -0000 Folks, here you have some comments on the following draft: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-03 Cheers, Gonzalo Comments on draft-ietf-bfcpbis-rfc4583bis-03 Section 3 includes a discussion about how to set the port field. That discussion is only relevant to TCP. The new draft needs to explain that and add a discussion about port handling in UDP. Also, the document needs to discuss what is the equivalent of establishing a TCP connection (i.e., it allows endpoints to start exchanging BFCP messages) in UDP. Section 6 contains the following new paragraph: " Note: In [15] 'm-stream' was erroneously used in Section 9. Although the example was non-normative, it is implemented by some vendors. Therefore, it is RECOMMENDED to support parsing and interpreting 'm-stream' the same way as 'mstrm' when receiving." The text should clarify (or be more explicit about) whether existing implementations are floor control server implementations or client implementations. The idea is that new implementers know clearly what exactly they need to support in order to be backwards compatible with those legacy implementations (whose implementers did not read RFCs but only the examples :-) ). The last paragraph of Section 8 discusses which entity behaves as the TLS server. Do we need a similar discussion for DTLS? From eckelcu@cisco.com Wed Oct 24 08:07:17 2012 Return-Path: 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 ; 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 ; 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 ; 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)" To: Jonathan Lennox , "Tom Kristensen (tomkrist)" 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> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> In-Reply-To: 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" , "Gonzalo Camarillo \(Gonzalo.Camarillo@ericsson.com\)" , "Robert Sparks \(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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ca= ll flow illustrating that exact usage; however, I see that figure 5.2 did n= ot survive the MS Word to PDF conversion process and is therefore missing f= rom 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 >=20 > Hi Charles, >=20 > 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. >=20 > Making the text more explicit couldn't hurt, but it's also not particular= ly > necessary I think. >=20 > -----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 >=20 > Hi Jonathan, >=20 > I revisited this section of the draft, and on closer inspection, I notice= d it > currently reads as follows: >=20 > 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. >=20 > 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: >=20 > 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. >=20 > Is extended as follows: >=20 > 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 scenario= s, > a "floorid" may be specified in an initial offer/answer exchange with > any associated media streams being identified in subsequent > exchanges. >=20 > Cheers, > Charles >=20 >=20 > > -----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 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) descrip= tions. > > > >>>> 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. > > >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/dr= a > > > >>> ft-ietf- > > > bfcpbis- > > > >>> rfc4583bis-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfcp= b > > > >>> 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 From jonathan@vidyo.com Thu Oct 25 08:43:57 2012 Return-Path: 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 AFB0721F888D for ; Thu, 25 Oct 2012 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 NemNJNCiWJ+f for ; Thu, 25 Oct 2012 08:43:56 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0921F88BD for ; Thu, 25 Oct 2012 08:43:56 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6CEBB7DD489; Thu, 25 Oct 2012 11:18:39 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8FCC57DD414; Thu, 25 Oct 2012 11:18:38 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Thu, 25 Oct 2012 11:43:50 -0400 From: Jonathan Lennox To: "Charles Eckel (eckelcu)" , "Tom Kristensen (tomkrist)" Date: Thu, 25 Oct 2012 11:43:54 -0400 Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNCAALTCgIACQfqAgAIDEkCAB67PoIAAPMAwgAEnKfCAAZ24IA== Message-ID: References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA9E7@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280EA9E7@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:43:57 -0000 Ah, that makes sense -- I noticed that figure was blank. Presumably IMTC is going to update their documents once BFCPbis is done? H= opefully they could update their recommendation to suggest an omitted mstrm= rather than a dangling one. -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 Sent: Wednesday, October 24, 2012 11:07 AM To: Jonathan Lennox; Tom Kristensen (tomkrist) Cc: bfcpbis@ietf.org; Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com); R= obert Sparks (rjsparks@nostrum.com) Subject: RE: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Your recollection is correct. Figure 5.2 of the IMTC document contains a ca= ll flow illustrating that exact usage; however, I see that figure 5.2 did n= ot survive the MS Word to PDF conversion process and is therefore missing f= rom 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=20 > (Gonzalo.Camarillo@ericsson.com); Robert Sparks (rjsparks@nostrum.com) > Subject: RE: [bfcpbis] I-D Action:=20 > draft-ietf-bfcpbis-rfc4583bis-03.txt >=20 > Hi Charles, >=20 > I agree that description makes sense. I thought I had recalled the=20 > IMTC document recommending that the floorid include a dangling mstrm,=20 > rather than no mstrm, but now I can't find it. >=20 > Making the text more explicit couldn't hurt, but it's also not=20 > particularly necessary I think. >=20 > -----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=20 > (Gonzalo.Camarillo@ericsson.com); Robert Sparks (rjsparks@nostrum.com) > Subject: RE: [bfcpbis] I-D Action:=20 > draft-ietf-bfcpbis-rfc4583bis-03.txt >=20 > Hi Jonathan, >=20 > I revisited this section of the draft, and on closer inspection, I=20 > noticed it currently reads as follows: >=20 > 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. >=20 > I interpret this to already account for the possibility of a floorid=20 > that is not yet associated with an existing media stream. Do you think=20 > we need to be more explicit? How about we extend the next paragraph as fo= llows: >=20 > 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. >=20 > Is extended as follows: >=20 > 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 scenario= s, > a "floorid" may be specified in an initial offer/answer exchange with > any associated media streams being identified in subsequent > exchanges. >=20 > Cheers, > Charles >=20 >=20 > > -----Original Message----- > > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On=20 > > 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=20 > > (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=20 > > referencing the IMTC best practice document, it is available through=20 > > a > liaison statement at: > > https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-im > > tc > > -=20 > > the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf > > > > However, I expect this IMTC document to be updated and made=20 > > available externally once the BFCPBIS work completes, so I am not=20 > > 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=20 > > > similar to existing "best effort encryption" schemes, where=20 > > > different vendors historically have had their own interpretation=20 > > > of a best current practice. > > > > > > Anyway, it is not a big deal adding an informational note, if=20 > > > people thinks that's a good idea, explaining that one may very=20 > > > well meet an mstrm referring to a still undefined label. > > > > > > (Do we then reference the IMTC document as an informational=20 > > > 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 which have some > > unusual > > > features -- in particular, it recommends sending an offer with a=20 > > > BFCP > > stream > > > referencing an mstrm that does not yet exist. (The intention is=20 > > > that if the SDP answer indicates that the peer understands both=20 > > > BFCP and the SDP content attribute, a re-INVITE can be sent adding=20 > > > an additional BFCP- controlled video stream with=20 > > > "content:slides".) > > > > > > > > This document should probably call out that usage, at least to=20 > > > > 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=20 > > > >> 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=20 > > > >>> [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=20 > > > >>>> Internet-Drafts > > > >>>> > > > >>> directories. > > > >>> > > > >>>> This draft is a work item of the Binary Floor Control=20 > > > >>>> 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=20 > > > >>>> Control > > > Protocol > > > >>>> (BFCP) streams in Session Description Protocol (SDP) descrip= tions. > > > >>>> User agents using the offer/answer model to establish=20 > > > >>>> 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=20 > > > >>> short, simple draft where the changes follows more or less=20 > > > >>> automatically > > from > > > >>> the extensions in rfc4582bis. > > > >>> > > > >>> After checking out with the original author of RFC 4583, the=20 > > > >>> ipr parameter is changed s/pre5378Trust200902/trust200902/. > > > >>> > > > >>> Cf. > > >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/d > > > >>> ra > > > >>> ft-ietf- > > > bfcpbis- > > > >>> rfc4583bis-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bfc > > > >>> pb > > > >>> 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 From eckelcu@cisco.com Thu Oct 25 09:50:09 2012 Return-Path: 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 7F6AC21F8695 for ; Thu, 25 Oct 2012 09:50:09 -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 PyTAeVHsiU1r for ; Thu, 25 Oct 2012 09:50:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 45CA421F867E for ; Thu, 25 Oct 2012 09:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10858; q=dns/txt; s=iport; t=1351183808; x=1352393408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EswogLrFb6MqRXZ1ebYjBC5QW4WWxmf3gmICYSd5i2k=; b=ACJVurt8sf9iqxcmBi5ig5oYIP2KskgbWnhT7Z/4D776WLJ/HgJnGmLo tlB1zw++6sQZqxHAVzgt6uLDIkRHrfqgyalyoB33qunyg/qK9a5QAxmj+ y4GL++Ci+Me6ManlC3e4sqiDsh9qLdfgaEOkIW2imxkIRLQ93DdFMQIGA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKJsiVCtJXG8/2dsb2JhbAA+BsIkgQiCHgEBAQQBAQEPASc0CwwEAgEIEQQBAQEKCwkJBycLFAkIAgQBDQUIGodhAQueQKAgi2EmgxeCT2EDlwuNO4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,648,1344211200"; d="scan'208";a="135350629" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 25 Oct 2012 16:50:07 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9PGo7DG028157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Oct 2012 16:50:07 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 11:50:06 -0500 From: "Charles Eckel (eckelcu)" To: Jonathan Lennox , "Tom Kristensen (tomkrist)" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-03.txt Thread-Index: AQHNqHBd/v/ZJA5VKU6Gd9pb0Gn1K5e15daAgASthNCAALTCgIACQfqAgAIDEkCAB67PoIAAPMAwgAEnKfCAAZ24IIAAEaLg Date: Thu, 25 Oct 2012 16:50:06 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280EC647@xmb-aln-x08.cisco.com> References: <20121012115432.971.75272.idtracker@ietfa.amsl.com> <507806D3.8090508@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E4E14@xmb-aln-x08.cisco.com> <507E6FD9.1080807@cisco.com> <92B7E61ADAC1BB4F941F943788C088280E718B@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA37F@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C088280EA9E7@xmb-aln-x08.cisco.com> In-Reply-To: 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-19306.000 x-tm-as-result: No--65.799200-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" , "Gonzalo Camarillo \(Gonzalo.Camarillo@ericsson.com\)" , "Robert Sparks \(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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:50:09 -0000 Yes, the plan is to update the document and make it publicly available foll= owing IETF standardization of the updated BFCP RFCs.=20 As for removing the dangling mstrm, I will add it to the list of potential = changes to incorporate into the update. Cheers, Charles =20 > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Thursday, October 25, 2012 8:44 AM > 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 >=20 > Ah, that makes sense -- I noticed that figure was blank. >=20 > Presumably IMTC is going to update their documents once BFCPbis is done? > Hopefully they could update their recommendation to suggest an omitted > mstrm rather than a dangling one. >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: Wednesday, October 24, 2012 11:07 AM > To: Jonathan Lennox; 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 >=20 > 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 no= t > survive the MS Word to PDF conversion process and is therefore missing > from the version of the document included in the liaison statement. >=20 > Cheers, > Charles >=20 > > -----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 BFC= P > > 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 scenar= ios, > > a "floorid" may be specified in an initial offer/answer exchange wit= h > > 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-im > > > tc > > > - > > > 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 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 f= or > > 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 a= re > > > > >>>> 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. > > > >>> http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/= d > > > > >>> ra > > > > >>> ft-ietf- > > > > bfcpbis- > > > > >>> rfc4583bis-02.txt&url2=3Dhttp://tools.ietf.org/id/draft-ietf-bf= c > > > > >>> pb > > > > >>> 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 From tomkrist@cisco.com Tue Oct 30 02:43:28 2012 Return-Path: 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 152E021F84B6 for ; Tue, 30 Oct 2012 02:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 Ipk-JwF4klbY for ; Tue, 30 Oct 2012 02:43:27 -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 EAE0421F84B9 for ; Tue, 30 Oct 2012 02:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3413; q=dns/txt; s=iport; t=1351590207; x=1352799807; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IjnfYvQymaZxnE4eg0QsTfjZTjTwXkn2X7LNN68zf7E=; b=k64mJxEnfEXL4hLdH4G+H/6C4xUz63sKUWyhCoKelwPgg0Ba5o0whV9N 72mFOhJ7NGVPiglfF8BrbwVyYKJ1biBjTuy5BZrYL9Ypt/1aIZTV58UJF JqScQ27hmt7koYYzD73WH5lGMFGyDnFMDP48KFREvWwl2mvdBKhsRyo2M 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAPmgj1CQ/khR/2dsb2JhbABEv22DSIEIgh4BAQEDARIBJUABBQsLGAkWDwkDAgECAUUGDQEHAQEeh14GnEGPZ5Aoi3WGXQOSQoMyhWmIboFrgnA X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="9197870" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 30 Oct 2012 09:43:06 +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 q9U9h6ca031445; Tue, 30 Oct 2012 09:43:06 GMT Message-ID: <508FA129.1090802@cisco.com> Date: Tue, 30 Oct 2012 10:43:05 +0100 From: Tom Kristensen 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: Gonzalo Camarillo References: <5087FAE4.5010900@ericsson.com> In-Reply-To: <5087FAE4.5010900@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 09:43:28 -0000 On 10/24/2012 04:27 PM, Gonzalo Camarillo wrote: > Folks, > [...] > Comments on draft-ietf-bfcpbis-rfc4583bis-03 > > Section 3 includes a discussion about how to set the port field. That > discussion is only relevant to TCP. The new draft needs to explain that > and add a discussion about port handling in UDP. > Good catch. Reorganizing the text and adding this for UDP: "When UDP is used as transport, the port field contains the port to which the remote endpoint will direct BFCP messages regardless of the value of the 'setup' attribute." > Also, the document needs to discuss what is the equivalent of > establishing a TCP connection (i.e., it allows endpoints to start > exchanging BFCP messages) in UDP. > The term "BFCP connection" is used in rfc4582bis/rfc4583bis independent of underlying transport. (For rfc4582bis: I propose we keep this common term regardless of underlying transport and change the three occurrences of "BFCP association" in Section 6.2 and 8.31 to "BFCP connection" as well.) However, we do indeed need to specify the counterpart of Section 7 "TCP Connection Management" for UDP as transport. Will add a sentence or two, since using UDP as transport is quite straight forward. Will also need to add a UDP description to Section 8, i.e. mandate using the 'setup' attribute when DTLS is used. Added to start of Section 7, now renamed to "BFCP Connection Management": "BFCP connections may use TCP or UDP as underlying transport. BFCP entities exchanging BFCP messages over UDP will direct the BFCP messages to the peer side connection address and port provided in the SDP 'm' line. TCP connection management is more complicated and is described below." And the subsection named "TCP Connection Management" follows. Added this sentence at the end of Section 8: "Endpoints that use the offer/answer model to establish a DTLS association MUST support the 'setup' attribute, as defined in RFC 4145. When DTLS is used with UDP, the 'setup' attribute indicates which of the endpoints (client or floor control server) initiates the DTLS association setup." > Section 6 contains the following new paragraph: > > " Note: In [15] 'm-stream' was erroneously used in Section 9. Although > the example was non-normative, it is implemented by some vendors. > Therefore, it is RECOMMENDED to support parsing and interpreting > 'm-stream' the same way as 'mstrm' when receiving." > > The text should clarify (or be more explicit about) whether existing > implementations are floor control server implementations or client > implementations. The idea is that new implementers know clearly what > exactly they need to support in order to be backwards compatible with > those legacy implementations (whose implementers did not read RFCs but > only the examples :-) ). > Yeah, what kind of developers do this kind of things? :-P Usage of a=floorid (and mstrm/m-stream) applies to endpoints willing to act as server, will add this to the second sentence in the note: "[...] some vendors and occurs in cases where the endpoint is willing to act as an server." > The last paragraph of Section 8 discusses which entity behaves as the > TLS server. Do we need a similar discussion for DTLS? > Indeed. Handled above. -- Tom From gonzalo.camarillo@ericsson.com Tue Oct 30 04:51:15 2012 Return-Path: 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 E512F21F8564 for ; Tue, 30 Oct 2012 04:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, 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 F14J3-yZjR-G for ; Tue, 30 Oct 2012 04:51:15 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AF5FA21F855E for ; Tue, 30 Oct 2012 04:51:14 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-03-508fbf31792e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D3.21.26143.13FBF805; Tue, 30 Oct 2012 12:51:13 +0100 (CET) Received: from [131.160.36.177] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 30 Oct 2012 12:51:13 +0100 Message-ID: <508FBF31.8000906@ericsson.com> Date: Tue, 30 Oct 2012 13:51:13 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tom Kristensen References: <5087FAE4.5010900@ericsson.com> <508FA129.1090802@cisco.com> In-Reply-To: <508FA129.1090802@cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra7h/v4Ag9+f1Sz+rTvKZHHlyC82 ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStj4t15jAXNihXfp21gbGBsk+pi5OSQEDCR +PvxEzOELSZx4d56ti5GLg4hgZOMEosX/maGcNYwSqz58pkJpIpXQFtibctNsA4WAVWJ/W+f sYHYbAIWEltu3WcBsUUFgiXObdzGBlEvKHFy5hOwuIiAukTf3u/sIDazgIjEgue/geIcHMIC zhI79yeBhIUEPCS+XX3GCmJzCmhKLF6yAeo4SYk3k2+yQLTqSUy52sIIYctLbH87hxmiV1ti +bMWlgmMQrOQbJ6FpGUWkpYFjMyrGNlzEzNz0suNNjECQ/Xglt+qOxjvnBM5xCjNwaIkzmu9 dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBka7bBY7l9tuxRZX3ee0bfjn8Ps/k5LysUPr tm9Rvh/dbim65HGs3Zcl61LyvyTsMBRZfjPH78+EnVl+WSWtsxiPJZzVeT29pTHhuEEz0/a/ Lbo8d/LnT7rSefkJl91J9jeq9+J38K6zzNBbv/TB2oOFf35zx3/Yd2pybf68LcbCQcHigecm VxQpsRRnJBpqMRcVJwIAJpQw9CMCAAA= Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:51:16 -0000 Hi Tom, thanks for your answers. With respect to the term BFCP connection, in addition to making a consistent use of it across both documents, make sure it is defined somewhere so that implementers are clear on what it means. Regarding UDP, we cannot really use the setup attribute for that. That attribute is defined for connection oriented protocols. Additionally, we need to be consistent regarding DTLS and TLS server determination. Section 8 explains how to determine the endpoint acting as the TLS server (i.e., the answerer). We cannot determine which endpoint acts as the DTLS server in a different way. Cheers, Gonzalo On 30/10/2012 11:43 AM, Tom Kristensen wrote: > On 10/24/2012 04:27 PM, Gonzalo Camarillo wrote: >> Folks, >> > [...] >> Comments on draft-ietf-bfcpbis-rfc4583bis-03 >> >> Section 3 includes a discussion about how to set the port field. That >> discussion is only relevant to TCP. The new draft needs to explain that >> and add a discussion about port handling in UDP. >> > > Good catch. Reorganizing the text and adding this for UDP: > > "When UDP is used as transport, the port field contains the > port to which the remote endpoint will direct BFCP messages > regardless of the value of the 'setup' attribute." > >> Also, the document needs to discuss what is the equivalent of >> establishing a TCP connection (i.e., it allows endpoints to start >> exchanging BFCP messages) in UDP. >> > > The term "BFCP connection" is used in rfc4582bis/rfc4583bis independent > of underlying transport. > > (For rfc4582bis: I propose we keep this common term regardless of > underlying transport and change the three occurrences of "BFCP > association" in Section 6.2 and 8.31 to "BFCP connection" as well.) > > However, we do indeed need to specify the counterpart of Section 7 "TCP > Connection Management" for UDP as transport. Will add a sentence or two, > since using UDP as transport is quite straight forward. Will also need > to add a UDP description to Section 8, i.e. mandate using the 'setup' > attribute when DTLS is used. > > Added to start of Section 7, now renamed to "BFCP Connection Management": > "BFCP connections may use TCP or UDP as underlying transport. BFCP > entities exchanging BFCP messages over UDP will direct the BFCP > messages to the peer side connection address and port provided in > the SDP 'm' line. TCP connection management is more complicated > and is described below." > And the subsection named "TCP Connection Management" follows. > > Added this sentence at the end of Section 8: > "Endpoints that use the offer/answer model to establish a DTLS > association MUST > support the 'setup' attribute, as defined in RFC 4145. When > DTLS is used with UDP, the 'setup' attribute indicates which of the > endpoints > (client or floor control server) initiates the DTLS association setup." > >> Section 6 contains the following new paragraph: >> >> " Note: In [15] 'm-stream' was erroneously used in Section 9. Although >> the example was non-normative, it is implemented by some vendors. >> Therefore, it is RECOMMENDED to support parsing and interpreting >> 'm-stream' the same way as 'mstrm' when receiving." >> >> The text should clarify (or be more explicit about) whether existing >> implementations are floor control server implementations or client >> implementations. The idea is that new implementers know clearly what >> exactly they need to support in order to be backwards compatible with >> those legacy implementations (whose implementers did not read RFCs but >> only the examples :-) ). >> > > Yeah, what kind of developers do this kind of things? :-P > > Usage of a=floorid (and mstrm/m-stream) applies to endpoints willing to > act as server, will add this to the second sentence in the note: > "[...] some vendors and occurs in cases where the endpoint is willing > to act as an server." > >> The last paragraph of Section 8 discusses which entity behaves as the >> TLS server. Do we need a similar discussion for DTLS? >> > > Indeed. Handled above. > > -- Tom > From tomkrist@cisco.com Tue Oct 30 05:19:26 2012 Return-Path: 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 235B521F8578 for ; Tue, 30 Oct 2012 05:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 ZH3eDjPxPpfW for ; Tue, 30 Oct 2012 05:19:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADB421F856E for ; Tue, 30 Oct 2012 05:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4852; q=dns/txt; s=iport; t=1351599564; x=1352809164; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tprmSNsHMoh90qgAvKhS6rhSHmbIHDLEeILxnccQwlE=; b=bx/QmnpKAdb3OBJIhEzalIHJ8JUGz/hZCs6ExaScRlwvIDtd5FH1VGe+ PJA+7yXPsFiSba6D6E+HwiidhEpBTEsLRWh4CPFtWrJ4w8XQItZrtVVk3 GaYRVXSU0zfZWV+/RIjn+xdW607hYuKXRru/1ylMR+cwQEaEsb0IMGtsM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKrEj1CQ/khN/2dsb2JhbABEwzWBCIIeAQEBBBIBJUABEAsYCRYPCQMCAQIBRQYNAQcBAR6HZAucVY9nkDaLdYZdA5JCgzKBGoRPiG6Ba4Jw X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="146017316" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2012 12:19:14 +0000 Received: from [10.54.86.36] (dhcp-10-54-86-36.cisco.com [10.54.86.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9UCJDB8014050; Tue, 30 Oct 2012 12:19:13 GMT Message-ID: <508FC5C1.4040702@cisco.com> Date: Tue, 30 Oct 2012 13:19:13 +0100 From: Tom Kristensen 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: Gonzalo Camarillo References: <5087FAE4.5010900@ericsson.com> <508FA129.1090802@cisco.com> <508FBF31.8000906@ericsson.com> In-Reply-To: <508FBF31.8000906@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:19:26 -0000 Gonzalo, I'll add a definition of "BFCP connection" in rfc4582bis to avoid confusion. Regarding the setup attr. I merely reflected in rfc4583bis what has been part of rfc4582 for a while. - Cf. http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06#section-7 - Note that the setup attr. is also used in DTLS-SRTP, cf. RFC 5763. -- Tom On 10/30/2012 12:51 PM, Gonzalo Camarillo wrote: > Hi Tom, > > thanks for your answers. > > With respect to the term BFCP connection, in addition to making a > consistent use of it across both documents, make sure it is defined > somewhere so that implementers are clear on what it means. > > Regarding UDP, we cannot really use the setup attribute for that. That > attribute is defined for connection oriented protocols. Additionally, we > need to be consistent regarding DTLS and TLS server determination. > Section 8 explains how to determine the endpoint acting as the TLS > server (i.e., the answerer). We cannot determine which endpoint acts as > the DTLS server in a different way. > > Cheers, > > Gonzalo > > > On 30/10/2012 11:43 AM, Tom Kristensen wrote: > >> On 10/24/2012 04:27 PM, Gonzalo Camarillo wrote: >> >>> Folks, >>> >>> >> [...] >> >>> Comments on draft-ietf-bfcpbis-rfc4583bis-03 >>> >>> Section 3 includes a discussion about how to set the port field. That >>> discussion is only relevant to TCP. The new draft needs to explain that >>> and add a discussion about port handling in UDP. >>> >>> >> Good catch. Reorganizing the text and adding this for UDP: >> >> "When UDP is used as transport, the port field contains the >> port to which the remote endpoint will direct BFCP messages >> regardless of the value of the 'setup' attribute." >> >> >>> Also, the document needs to discuss what is the equivalent of >>> establishing a TCP connection (i.e., it allows endpoints to start >>> exchanging BFCP messages) in UDP. >>> >>> >> The term "BFCP connection" is used in rfc4582bis/rfc4583bis independent >> of underlying transport. >> >> (For rfc4582bis: I propose we keep this common term regardless of >> underlying transport and change the three occurrences of "BFCP >> association" in Section 6.2 and 8.31 to "BFCP connection" as well.) >> >> However, we do indeed need to specify the counterpart of Section 7 "TCP >> Connection Management" for UDP as transport. Will add a sentence or two, >> since using UDP as transport is quite straight forward. Will also need >> to add a UDP description to Section 8, i.e. mandate using the 'setup' >> attribute when DTLS is used. >> >> Added to start of Section 7, now renamed to "BFCP Connection Management": >> "BFCP connections may use TCP or UDP as underlying transport. BFCP >> entities exchanging BFCP messages over UDP will direct the BFCP >> messages to the peer side connection address and port provided in >> the SDP 'm' line. TCP connection management is more complicated >> and is described below." >> And the subsection named "TCP Connection Management" follows. >> >> Added this sentence at the end of Section 8: >> "Endpoints that use the offer/answer model to establish a DTLS >> association MUST >> support the 'setup' attribute, as defined in RFC 4145. When >> DTLS is used with UDP, the 'setup' attribute indicates which of the >> endpoints >> (client or floor control server) initiates the DTLS association setup." >> >> >>> Section 6 contains the following new paragraph: >>> >>> " Note: In [15] 'm-stream' was erroneously used in Section 9. Although >>> the example was non-normative, it is implemented by some vendors. >>> Therefore, it is RECOMMENDED to support parsing and interpreting >>> 'm-stream' the same way as 'mstrm' when receiving." >>> >>> The text should clarify (or be more explicit about) whether existing >>> implementations are floor control server implementations or client >>> implementations. The idea is that new implementers know clearly what >>> exactly they need to support in order to be backwards compatible with >>> those legacy implementations (whose implementers did not read RFCs but >>> only the examples :-) ). >>> >>> >> Yeah, what kind of developers do this kind of things? :-P >> >> Usage of a=floorid (and mstrm/m-stream) applies to endpoints willing to >> act as server, will add this to the second sentence in the note: >> "[...] some vendors and occurs in cases where the endpoint is willing >> to act as an server." >> >> >>> The last paragraph of Section 8 discusses which entity behaves as the >>> TLS server. Do we need a similar discussion for DTLS? >>> >>> >> Indeed. Handled above. >> >> -- Tom >> >> >