From tomkrist@cisco.com Tue Dec 11 02:07: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 D32C021F852B for ; Tue, 11 Dec 2012 02:07:26 -0800 (PST) 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 hCTlX17gPTE1 for ; Tue, 11 Dec 2012 02:07:26 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2E21F8528 for ; Tue, 11 Dec 2012 02:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1355220446; x=1356430046; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j6b2YN9APtgzadro+N+EV8QD7w3uuUOy6Qj8hLptmFk=; b=E2XDHIlZjrFWpQwmaJTKTmetAUdjIhhY3+W4Q/N0cof4ZgSWr96Z/e2x MvlWL/gXULL8ZbpbLX7+7HtJQnBUPExfyM2cI/7CL1OirunQCTI+gkWN3 npSbhh5LYApfy+D3n0JgVWeoR9Ii6T3d8NdkQtdgfy0Sg5NKMypPPf9P8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsGAIsFx1CQ/khL/2dsb2JhbABFg0i6fRZzgh4BAQEEAQEBNTYKARALGAkWDwkDAgECARUwBg0BBQIBAYgNDKhokEkEjEoLhDgDlgeFa4pdgnSBbA X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="78980582" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Dec 2012 10:07:24 +0000 Received: from [10.47.38.157] ([10.47.38.157]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBBA7OQ9014749; Tue, 11 Dec 2012 10:07:24 GMT Message-ID: <50C705DC.5090208@cisco.com> Date: Tue, 11 Dec 2012 11:07:24 +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: <50A20368.9050408@cisco.com> <50A204F3.8000809@ericsson.com> <50A20B06.9080902@cisco.com> In-Reply-To: <50A20B06.9080902@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BFCPbis WG , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] TBD issue #1: Subsequent 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, 11 Dec 2012 10:07:27 -0000 In Sections 5.3.14/5.3.15 I'll simply add a reference to the sections describing the generation of these subsequent messages from the server (Sections 13.1.2 and 13.5.2 respectively). This way: "When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorRequestStatus message from the floor control server (cf. Section 13.1.2) by sending a FloorRequestStatusAck message." -- Tom On 11/13/2012 09:55 AM, Tom Kristensen wrote: > I see your point. I'll reread the text once more and find out what to do! > > -- Tom > > On 11/13/2012 09:29 AM, Gonzalo Camarillo wrote: >> Hi Tom, >> >> thanks for initiating the discussion on the points you identified in >> your other email. >> >> With respect to this one, the important issue is not whether or not we >> keep "subsequent" in those sentences. The issue is that the text needs >> to be clear about what it means. So, if you prefer to explain the >> meaning of the sentence instead of removing the word, that would >> certainly be OK. >> >> Cheers, >> >> Gonzalo >> >> >> On 13/11/2012 10:23 AM, Tom Kristensen wrote: >>> Minor issue. Anyway, here we go: >>> >>> Gonzalo: >>>> 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. >>> Tom: >>> | It is subsequent in that it's not the initial FloorRequestStatus >>> | acknowleding the associated FloorRequest. The word might not >>> | be needed in Sections 5.3.14 and 5.3.15, but I'll remove it just if >>> | it is really confusing!?! >>> >>> Should it stay or should it go? >>> >>> -- Tom > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From tomkrist@cisco.com Tue Dec 11 06:47:13 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 9019221F8468 for ; Tue, 11 Dec 2012 06:47:13 -0800 (PST) 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 Pb6gKXOWnt64 for ; Tue, 11 Dec 2012 06:47:13 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B597B21F8439 for ; Tue, 11 Dec 2012 06:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2126; q=dns/txt; s=iport; t=1355237232; x=1356446832; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lkFUjilnOaUa2PZV5w/Uup5sCRQdOY+E/YRUyrGUYGE=; b=HrvzxfIIpjdm1+9yxTRttXwDAXWFwPXPG6mnnivLzWASYMcd+uZVJlrw nFQmgAxxJQ4HUFU7kAQul8tct3uEEyWd018VbsNv8fcIvvymlxNBixF/1 nskLAjE+wjl4nkmnOHuN2RkHNYo8Zjy5fLkIgd212O2P42oyDGjZO7ocJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwGAF1Gx1CQ/khR/2dsb2JhbABFg0i3K4NRFnOCHgEBAQQ4MBABEAsYCRYPCQMCAQIBRQYNAQcBAYgNqliQZoxKhEMDlgeFa4pdgnQ X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="78986883" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 11 Dec 2012 14:47:09 +0000 Received: from [10.47.38.157] ([10.47.38.157]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBEl8Wk021496; Tue, 11 Dec 2012 14:47:08 GMT Message-ID: <50C7476C.2000403@cisco.com> Date: Tue, 11 Dec 2012 15:47:08 +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: <50A2042A.90805@cisco.com> <50A2053F.1050708@ericsson.com> In-Reply-To: <50A2053F.1050708@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BFCPbis WG , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] TBD issue #2: Discuss usage of RFC 5018 mechanisms 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, 11 Dec 2012 14:47:13 -0000 Adding something along these lines at the end of Section might be what is needed: ---- "RFC 5018 specifies how to establish a TCP connection to a floor control server outside the context of an offer/answer exchange. When using UDP the same set of data is needed for a BFCP connection as listed in RFC 5018, Section 3, i.e. transport address of the server, the conference identifier, and the user identifier. The procedures and considerations for resolving a host name into an IP address also applies to BFCP over an unreliable transport. In RFC 5018, Section 4 applies, but when using BFCP over an unreliable transport the floor control server that receives a BFCP message over UDP (no DTLS) SHOULD request the use of DTLS by generating an Error message with an Error code with a value of 11 (Use DTLS). The recommendations for authentication in RFC 5018, Section 5 and the security considerations in Section 6 also applies when an unreliable transport is used, both for certificate-based server authentication and for client authentication based on a pre-shared secret." ---- Fine with this? Something to clarify or expand upon? -- Tom On 11/13/2012 09:30 AM, Gonzalo Camarillo wrote: > Hi Tom, > > yes, per my original comments, I believe the spec needs to include a > discussion about what happens when the mechanism in RFC 5018 is used. > > Thanks, > > Gonzalo > > On 13/11/2012 10:26 AM, Tom Kristensen wrote: > >> An issue that needs further work, if a discussion of RFC 5018 usage is >> needed of course. >> >> Gonzalo: >> >>> 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. >>> >> Tom: >> | Reference to RFC 5018 added in upcoming version. >> | Text discussing impact of using the RFC 5018 mechanism will be done >> | and added as a paragraph of Section 6.1. Reliable Transport I'd imagine. >> >> -- Tom >> > > From tomkrist@cisco.com Thu Dec 13 01:15:53 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 C81F821F8945 for ; Thu, 13 Dec 2012 01:15:53 -0800 (PST) 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 UHtG-JA8Unju for ; Thu, 13 Dec 2012 01:15:52 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE9021F88ED for ; Thu, 13 Dec 2012 01:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4309; q=dns/txt; s=iport; t=1355390152; x=1356599752; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vH46+WBt9Jk4eek++5E70AG63RARlGnv43GfBR/k2A4=; b=bSdiiuNUi+XqrD3doobZ7zrI7SsDEzkDXo/3akggCWIaTwxwjaqG/elI kpVUSFkpzZ7d9H6pzZc1bT/DJH3UQvxDLq68P+iJwPDn+rqlat+lTO+fN SkV6ZsIXhaPy6Z7r8BpzTPc3kkM2tiPejjpMWUtP8hCo5/ltpE9Tmfpew g=; X-IronPort-AV: E=Sophos;i="4.84,273,1355097600"; d="scan'208";a="10408032" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 13 Dec 2012 09:15:51 +0000 Received: from [10.61.82.65] (ams3-vpn-dhcp4674.cisco.com [10.61.82.65]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBD9FpVZ011638; Thu, 13 Dec 2012 09:15:51 GMT Message-ID: <50C99CC6.8080205@cisco.com> Date: Thu, 13 Dec 2012 10:15:50 +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: <50A20598.6040603@cisco.com> <50A20996.8010503@ericsson.com> <92B7E61ADAC1BB4F941F943788C0882812C776@xmb-aln-x08.cisco.com> <50A67AB3.3070405@ericsson.com> In-Reply-To: <50A67AB3.3070405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BFCPbis WG , 'Tom Kristensen' <2mkristensen@gmail.com>, "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] TBD issue #3: MAY discard malformed message, not sending Error 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, 13 Dec 2012 09:15:53 -0000 Indeed, troublesome sentence removed in upcoming version. -- Tom On 11/16/2012 06:41 PM, Gonzalo Camarillo wrote: > Hi, > > if you want to describe a procedure that is likely to have the system > recover from the error, I am OK with that. Otherwise, describing a > procedure that is not likely to help and will confuse implementers is > clearly not a good idea ;-) In short, I am fine with removing the text. > > Cheers, > > Gonzalo > > On 15/11/2012 10:10 PM, Charles Eckel (eckelcu) wrote: > >> I agree that we need to do something here. The text reads: >> >> 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. >> >> If the message is determined to be a response, then in general there will not be any retransmission, correct? I think the real question is whether or not the receiver of such a response should send its original request again in hopes of it resulting in a response that can be parsed. This seems like a bad idea as it is likely to result in receiving the same response again. This could go on indefinitely. >> My preference is to remove the sentence entirely. We could and perhaps replace it with something warning against retransmitting the original request, but I don't think that is necessary and it might merely confuse matters more. >> >> Cheers, >> Charles >> >> >>> -----Original Message----- >>> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >>> Behalf Of Gonzalo Camarillo >>> Sent: Tuesday, November 13, 2012 12:49 AM >>> To: Tom Kristensen (tomkrist) >>> Cc: BFCPbis WG >>> Subject: Re: [bfcpbis] TBD issue #3: MAY discard malformed message, not >>> sending Error >>> >>> Hi, >>> >>> the point here is that a retransmission is, by definition, identical to >>> the original message. So, if you receive a message and do nothing, when >>> you receive the retransmission you will behave in an identical manner >>> (i.e., you will do nothing), since the retransmission will be identical >>> to the original message... and detecting an error and letting the client >>> retransmit a few messages instead of reporting the error does not seem >>> like a good strategy. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 13/11/2012 10:32 AM, Tom Kristensen wrote: >>> >>>> Minor issue, just need a decision! >>>> >>>> Gonzalo: >>>> >>>>> 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." >>>>> >>>> Tom: >>>> | My understanding is that one might skip sending the Error message >>>> | and just wait for the retransmission, that will come. However, this >>>> | sort of optimization might be removed. Not needed and even >>>> >>> mentioned >>> >>>> | just as a MAY. >>>> >>>> So again, should it stay or should it go? No problem removing the second >>>> sentence, no real functional change. Or we could clarify the sentence by >>>> adding that in this case no Error message is sent. >>>> >>>> -- Tom >>>> >>>> >>> _______________________________________________ >>> bfcpbis mailing list >>> bfcpbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/bfcpbis >>> > > From eckelcu@cisco.com Thu Dec 13 08:25:43 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 A4C7421F8B1B for ; Thu, 13 Dec 2012 08:25:43 -0800 (PST) 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 hu-RPrl0Qb59 for ; Thu, 13 Dec 2012 08:25:42 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2E41821F8B1A for ; Thu, 13 Dec 2012 08:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2505; q=dns/txt; s=iport; t=1355415942; x=1356625542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wvqipHV/3btHuEyaTMVMKjjRXbZ9oPxn1Kwbr4aOQug=; b=ZYF6ywnoO9O+mMW1vswXpTOzz6X/HDH2IAHDT/VKYVj7CPIAiEKqZ4+k OG2Hf8eA8wLsYrUnilCJp+5qgKYG5K+gsKItnOhKTKgiY1K4K6z/8IP0C 7KfzpzstiKBIRkU3+Ph3TQnTw/urBRbhP2HACx2Q4KrM5lo9tgG42EpD9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIcAylCtJV2Z/2dsb2JhbABFvm4Wc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiICwy9KQSMVwuDV2EDplGCc4FtNQ X-IronPort-AV: E=Sophos;i="4.84,274,1355097600"; d="scan'208";a="152616619" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 13 Dec 2012 16:25:41 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBDGPfda031339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 16:25:41 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 10:25:40 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Gonzalo Camarillo Thread-Topic: [bfcpbis] TBD issue #1: Subsequent Thread-Index: AQHNwXgfBEoaZUqxBUaUB8/PFHBDIJfn06+AgAAHPgCALBVZAIADKZ9g Date: Thu, 13 Dec 2012 16:25:40 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EB378@xmb-aln-x08.cisco.com> References: <50A20368.9050408@cisco.com> <50A204F3.8000809@ericsson.com> <50A20B06.9080902@cisco.com> <50C705DC.5090208@cisco.com> In-Reply-To: <50C705DC.5090208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.128.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: BFCPbis WG , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] TBD issue #1: Subsequent 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, 13 Dec 2012 16:25:43 -0000 Works for me. Cheers, Charles (as an individual) > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Tuesday, December 11, 2012 2:07 AM > To: Gonzalo Camarillo > Cc: BFCPbis WG; 'Tom Kristensen' > Subject: Re: [bfcpbis] TBD issue #1: Subsequent >=20 > In Sections 5.3.14/5.3.15 I'll simply add a reference to the sections > describing the generation of these subsequent messages from the server > (Sections 13.1.2 and 13.5.2 respectively). This way: >=20 > "When communicating over an unreliable transport, floor > participants and chairs acknowledge the receipt of a > subsequent FloorRequestStatus message from the floor > control server (cf. Section 13.1.2) by sending a > FloorRequestStatusAck message." >=20 > -- Tom >=20 > On 11/13/2012 09:55 AM, Tom Kristensen wrote: > > I see your point. I'll reread the text once more and find out what to d= o! > > > > -- Tom > > > > On 11/13/2012 09:29 AM, Gonzalo Camarillo wrote: > >> Hi Tom, > >> > >> thanks for initiating the discussion on the points you identified in > >> your other email. > >> > >> With respect to this one, the important issue is not whether or not we > >> keep "subsequent" in those sentences. The issue is that the text needs > >> to be clear about what it means. So, if you prefer to explain the > >> meaning of the sentence instead of removing the word, that would > >> certainly be OK. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> > >> On 13/11/2012 10:23 AM, Tom Kristensen wrote: > >>> Minor issue. Anyway, here we go: > >>> > >>> Gonzalo: > >>>> 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. > >>> Tom: > >>> | It is subsequent in that it's not the initial FloorRequestStatus > >>> | acknowleding the associated FloorRequest. The word might not > >>> | be needed in Sections 5.3.14 and 5.3.15, but I'll remove it just if > >>> | it is really confusing!?! > >>> > >>> Should it stay or should it go? > >>> > >>> -- Tom > > > > _______________________________________________ > > bfcpbis mailing list > > bfcpbis@ietf.org > > https://www.ietf.org/mailman/listinfo/bfcpbis > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Thu Dec 13 08:30:42 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 7BBF821F8A32 for ; Thu, 13 Dec 2012 08:30:42 -0800 (PST) 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 v1FFUY90A4qp for ; Thu, 13 Dec 2012 08:30:42 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AE59B21F85D2 for ; Thu, 13 Dec 2012 08:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2748; q=dns/txt; s=iport; t=1355416241; x=1356625841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HTsxi6uT2JL8fA4PkLDWttmy0w7Kr2KEhTPI7oqgAJM=; b=egCF2bWUF7xPi5BAuH/8e8Ru4QDtssibLZtqTVJiu28M6G0xrSTdYqYN L7nH6u3nLDJw29EdnTepKlSiNW6O8kPg/Qa810+ebI2myr2nHD+YNu5cw 0+aTyOqpiK90HAkuuGjt8htO+qhCTxfUHrYbPGHnGUOOn980l+9Wk4sZd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAsCylCtJXHB/2dsb2JhbABFvm4Wc4IeAQEFAQE4LgYLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0NiAu9MwSMV4NiYQOmUYJzgiI X-IronPort-AV: E=Sophos;i="4.84,274,1355097600"; d="scan'208";a="152615813" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 13 Dec 2012 16:27:07 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBDGR1bi032048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 16:27:05 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 10:27:01 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Gonzalo Camarillo Thread-Topic: [bfcpbis] TBD issue #2: Discuss usage of RFC 5018 mechanisms Thread-Index: AQHNwXiY8xN0HLrzVUCNBFRrBps9xpfn1AmAgCxqZACAAtvdQA== Date: Thu, 13 Dec 2012 16:27:01 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EB38C@xmb-aln-x08.cisco.com> References: <50A2042A.90805@cisco.com> <50A2053F.1050708@ericsson.com> <50C7476C.2000403@cisco.com> In-Reply-To: <50C7476C.2000403@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.128.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: BFCPbis WG , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] TBD issue #2: Discuss usage of RFC 5018 mechanisms 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, 13 Dec 2012 16:30:42 -0000 Sounds good. Cheers, Charles (as an individual) > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Tuesday, December 11, 2012 6:47 AM > To: Gonzalo Camarillo > Cc: BFCPbis WG; 'Tom Kristensen' > Subject: Re: [bfcpbis] TBD issue #2: Discuss usage of RFC 5018 mechanisms >=20 > Adding something along these lines at the end of Section might be what > is needed: >=20 > ---- > "RFC 5018 specifies how to establish a TCP connection to a floor > control server outside the context of an offer/answer exchange. When > using UDP the same set of data is needed for a BFCP connection as listed > in RFC 5018, Section 3, i.e. transport address of the server, the > conference identifier, and the user identifier. The procedures and > considerations for resolving a host name into an IP address also applies > to BFCP over an unreliable transport. In RFC 5018, Section 4 applies, > but when using BFCP over an unreliable transport the floor control > server that receives a BFCP message over UDP (no DTLS) SHOULD request > the use of DTLS by generating an Error message with an Error code with a > value of 11 (Use DTLS). The recommendations for authentication in RFC > 5018, Section 5 and the security considerations in Section 6 also > applies when an unreliable transport is used, both for certificate-based > server authentication and for client authentication based on a > pre-shared secret." > ---- >=20 > Fine with this? Something to clarify or expand upon? >=20 > -- Tom >=20 > On 11/13/2012 09:30 AM, Gonzalo Camarillo wrote: > > Hi Tom, > > > > yes, per my original comments, I believe the spec needs to include a > > discussion about what happens when the mechanism in RFC 5018 is used. > > > > Thanks, > > > > Gonzalo > > > > On 13/11/2012 10:26 AM, Tom Kristensen wrote: > > > >> An issue that needs further work, if a discussion of RFC 5018 usage is > >> needed of course. > >> > >> Gonzalo: > >> > >>> Section 6 says: > >>> > >>> "(e.g., using an SDP offer/answer exchange [7])" > >>> > >>> We should also add a reference to RFC 5018. Additionally, the documen= t > >>> could discuss at some point what happens when the mechanism in RFC > >>> 5018 is used. > >>> > >> Tom: > >> | Reference to RFC 5018 added in upcoming version. > >> | Text discussing impact of using the RFC 5018 mechanism will be done > >> | and added as a paragraph of Section 6.1. Reliable Transport I'd ima= gine. > >> > >> -- Tom > >> > > > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From tomkrist@cisco.com Wed Dec 19 00:54: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 4F7B921F8948 for ; Wed, 19 Dec 2012 00:54:07 -0800 (PST) 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 EQ9LA927db62 for ; Wed, 19 Dec 2012 00:54:06 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3721F850D for ; Wed, 19 Dec 2012 00:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6937; q=dns/txt; s=iport; t=1355907246; x=1357116846; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=gvXQol5pHzvgBGqKTdOxpl5l84cemA1GIwNxJ3e9gBQ=; b=aDbWijc1fqiKkBiUNincotQjZB04sHOoBwM23ITjRgaihFfb6UgLZeeV fp2lG7DhB0SNE4kJLPjgdqKHLDb7Qd3H1Ccf/ZS8x+HYt0V7Oy0e+jBJD +ry0qrraPZ5WsFlwa0zMzustM09eJbGgQwS8SsMfE/Un3glzKqDho9VO3 Q=; X-Files: section8-asOf2012-12-19.txt : 3407 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUHAJd/0VCtJV2b/2dsb2JhbABEg0iIUq4ugUoBggMWc4IeAQEBBGcBEAEQCxgJDQkPCQMCAQIBRQYNAQcBAYgPuCiMS4EWDIMhA48Gg1GDM4Vril2CdYFs X-IronPort-AV: E=Sophos;i="4.84,313,1355097600"; d="txt'?scan'208";a="154532005" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 19 Dec 2012 08:54:05 +0000 Received: from [10.47.38.141] ([10.47.38.141]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBJ8s4DA028735; Wed, 19 Dec 2012 08:54:04 GMT Message-ID: <50D180AC.3020105@cisco.com> Date: Wed, 19 Dec 2012 09:54:04 +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: <50A20844.3070601@cisco.com> <50A20AFA.6050001@ericsson.com> In-Reply-To: <50A20AFA.6050001@ericsson.com> Content-Type: multipart/mixed; boundary="------------040601000403040504090106" Cc: BFCPbis WG , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] TBD issues #4 and #5: How to pick next sequence number 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, 19 Dec 2012 08:54:07 -0000 This is a multi-part message in MIME format. --------------040601000403040504090106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In order not to duplicate the normative description on how to pick Transaction ID values for unreliable transport, I move the text from 6.2 to Section 8 where the BFCP transaction semantics are defined. New section 8 enclosed. -- Tom On 11/13/2012 09:55 AM, Gonzalo Camarillo wrote: > Hi, > > the text should explain the requirement (i.e., to avoid getting confused > with retransmissions that arrive late). With respect to the mechanism, > you can recommend (i.e., at SHOULD level) to use monotonically > increasing sequence numbers and let implementations choose any other > method that would meet the requirement as well. > > Cheers, > > Gonzalo > > On 13/11/2012 10:43 AM, Tom Kristensen wrote: > >> Issue with picking sequence numbers and making sure it doesn't cause any >> issues with (late) arriving retransmissions. This may happen, even >> though UDP/BFCP requires just one outstanding transaction at the time. >> >> Gonzalo: >> >>> Section 6.2 >>> >> [...] >> >>> 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? >>> >> Tom: >> | No real random numbers are needed. This issue is solved in the >> | upcoming version of the draft. >> | However, we need a safe scheme to pick sequence numbers to avoid >> | late arriving retransmissions cause confusion). >> >> >> Gonzalo: >> >>> 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. >>> >> Tom: >> | OK. This is kept from RFC 4582 using TCP (and no retransmissions). So, >> the >> | idea should be to keep the RFC 4582 semantics for TCP transport and >> | introduce some sort of "sliding window sequence number" reuse or simply >> | add a sequential/wrapping sequence numbering for UDP as transport. >> >> >> So, what do people think? >> >> I feel the simplest here is to at least requring the BFCP entities to >> select >> Transaction ID values in increasing order and a wrap around of the 16 >> bit Transaction ID value. (This will require saying something about >> picking the intial value at random, not to close to wrapping and so on - >> I guess. Similar to RTP sequence numbers). >> >> Or is it sufficient to mandate not reusing the X last Transaction IDs >> used by the BFCP entity? >> Where X == what? >> >> -- Tom >> > --------------040601000403040504090106 Content-Type: text/plain; name="section8-asOf2012-12-19.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="section8-asOf2012-12-19.txt" 8. Protocol Transactions In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions. 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 have different requirements and behavior depending on underlying transport: When using reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). Since they do not trigger any response, their Transaction ID is set to 0. When using unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server. The Transaction ID must be non-zero and unique in the context of outstanding transactions over unreliable transports. The request carries a Transaction ID in its common header, which the client copies into the response. Floor control servers use Transaction ID values to match responses with previously issued requests. When using BFCP over unreliable transport, it is also required to choose values that let the receiver distinguish the reception of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using unreliable transport SHOULD use monotonically increasing values for the Transaction ID. When using BFCP over unreliable transports, all requests will use retransmission timer T1 (see Section 8.3) until the transaction is completed. 8.1. Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously. 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. The client uses the Transaction ID value to match this message with the response from the floor control server. 8.2. Server Behavior A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over reliable transports. Over an unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions: the server 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 server until the appropriate response from the client is received for the transaction. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair. --------------040601000403040504090106-- From tomkrist@cisco.com Wed Dec 19 02:45:19 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 E211621F894D for ; Wed, 19 Dec 2012 02:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 kBitFmpSMXqQ for ; Wed, 19 Dec 2012 02:45:19 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 14D9721F87F2 for ; Wed, 19 Dec 2012 02:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2888; q=dns/txt; s=iport; t=1355913919; x=1357123519; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OeGF8JuSuW1WdxaclxvJAvG4owuMj4ft5mgq7zLEuks=; b=SuVZTrjT09K7TsYn7MV0lDnmcuP+tCtHWCCv5ryV/1zS3AcIlN4zro0w eTlP13B1xHCMPPKVDqeEjEV/BePoOuESiL+8tu4JHt57orVjD8avGBZmc ujsQcchNrmTRqllhZgh8ZAuQp2JjfkD5xnMM1lXhNh/sCha7Cms5qIhja U=; X-IronPort-AV: E=Sophos;i="4.84,316,1355097600"; d="scan'208";a="10577801" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 19 Dec 2012 10:45:17 +0000 Received: from [10.47.38.141] ([10.47.38.141]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBJAjGTn005358; Wed, 19 Dec 2012 10:45:17 GMT Message-ID: <50D19ABC.6040303@cisco.com> Date: Wed, 19 Dec 2012 11:45:16 +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: "Charles Eckel (eckelcu)" References: <7594FB04B1934943A5C02806D1A2204B047F4F@ESESSMB209.ericsson.se> <50B62146.2050707@cisco.com> <92B7E61ADAC1BB4F941F943788C08828046CC03E@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046CC03E@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] BFCP-UDP and DTLS 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, 19 Dec 2012 10:45:20 -0000 Thanks, I've added reference to RFC 5764, Section 6.7 in Section 6.2.4, at end of this second paragraph: In order to facilitate the initial establishment of NAT bindings, and to maintain those bindings once established, BFCP entities using unreliable transport are RECOMMENDED to use STUN Binding Indication for keep-alives, as described for ICE . , Section 6.7 provides useful recommendations for middlebox interaction when DTLS is used. -- Tom On 11/28/2012 10:49 PM, Charles Eckel (eckelcu) wrote: > (as an individual) > Adding a reference to 6.7.2 of RFC 5763 sounds like a good idea to me, and I agree that rfc4582bis is probably a more appropriate place for this than rfc4583bis. > > Cheers, > Charles > > >> -----Original Message----- >> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >> Behalf Of Tom Kristensen (tomkrist) >> Sent: Wednesday, November 28, 2012 6:36 AM >> To: bfcpbis@ietf.org >> Subject: Re: [bfcpbis] BFCP-UDP and DTLS >> >> Thanks Christer, >> >> In the upcoming version of rfc4583bis, the usage of the RFC 4145 'setup' will >> be described (in Section 8). This attribute was just mentioned in rfc4582bis >> until now. >> >> In rfc4582bis we say: "In order to facilitate the initial establishment of NAT >> bindings, and to maintain those bindings once established, BFCP entities >> using unreliable transport are RECOMMENDED to use STUN> target="RFC5389"/> Binding Indication for keep-alives, as described for ICE >> ." >> >> However, we may refer to Section 6.7 (and especially 6.7.2) as well, but that >> may belong to rfc4582bis (where usage of STUN binding indications are >> recommended) instead of rfc4583bis? >> >> -- Tom >> >> On 11/28/2012 09:55 AM, Christer Holmberg wrote: >> >> Hi, >> >> >> >> I haven't really been following the BFCPbis work, so I appologize if >> the following has been discussed. >> >> >> >> draft-ietf-bfcpbis-rfc4583bis-03 refers to section 5 of RFC 5763 for >> the SDP Offer/Answer procedures, and DTLS role selection (TLS >> client/server). >> >> >> >> However, I think it would also be good to refer to section 6.7 of RFC >> 5763. Especially section 6.7.2 is important, in my view. It says that the >> passive UA sends a STUN request, in order to open the NAT pin hole, which >> means both UAs don't have to be active if they are behind NATs, and don't >> support ICE. Otherwise it could cause problem, if both are active and end up >> acting as TLS clients. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> >> > > From tomkrist@cisco.com Wed Dec 19 04:39: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 E3E3821F8A0A for ; Wed, 19 Dec 2012 04:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=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 ynBYTpIby3UB for ; Wed, 19 Dec 2012 04:39:56 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6393A21F8974 for ; Wed, 19 Dec 2012 04:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10531; q=dns/txt; s=iport; t=1355920794; x=1357130394; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Rac00MV8II3F70EgGjyRoL1T5Nga8P+6/G8U9lvXO1M=; b=i9CTflksjzyo0xeQ95idWLMWA0LP7cMnEsvoAKpHlPciT2noHEOjsetq DAxqTpCib6H02D7HI3Tjx8q0smTGqte2T7kpqroHencPbYgZvEK1lG2+h 26TG5pCmnyKhMsSS7Ea9I+QuolqtE2xE/3Oysm7p/6GuXxNNiF+FeFrbu c=; X-IronPort-AV: E=Sophos;i="4.84,316,1355097600"; d="scan'208";a="22341329" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 19 Dec 2012 12:39:52 +0000 Received: from [10.47.38.141] ([10.47.38.141]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBJCdo7j028438; Wed, 19 Dec 2012 12:39:51 GMT Message-ID: <50D1B596.2040207@cisco.com> Date: Wed, 19 Dec 2012 13:39:50 +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: "Charles Eckel (eckelcu)" References: <5087FAE4.5010900@ericsson.com> <508FA129.1090802@cisco.com> <508FBF31.8000906@ericsson.com> <508FC5C1.4040702@cisco.com> <50968F26.9080403@ericsson.com> <92B7E61ADAC1BB4F941F943788C0882810742E@xmb-aln-x08.cisco.com> <5097B862.6050200@ericsson.com> <92B7E61ADAC1BB4F941F943788C08828107F45@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828107F45@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" , 'Tom Kristensen' <2mkristensen@gmail.com>, Gonzalo Camarillo 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: Wed, 19 Dec 2012 12:39:57 -0000 In the upcoming version, I've simply added an informational note at the end of Section 8. Authentication. It reads: "Informational note: How to determine which endpoint to initiate the TLS/DTLS association depends on the selected underlying transport. It was decided to keep the original semantics in [15] for TCP to retain backwards compatibility. When using UDP, the procedure above was preferred since it adheres to [13] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs." Where [15] == RFC 4582 and [13] == RFC 5763. -- Tom On 11/06/2012 12:01 AM, Charles Eckel (eckelcu) wrote: > Works for me. > > Thanks, > Charles > > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Monday, November 05, 2012 8:00 AM >> To: Charles Eckel (eckelcu) >> Cc: Tom Kristensen (tomkrist); bfcpbis@ietf.org >> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 >> >> Hi Charles, >> >> the point is that if we have decided not to be consistent across >> transports, we need to explain why in the RFCs. So, please, add some >> text (a few sentences should be enough) explaining why (i.e., something >> along the lines of your email below). >> >> Thanks, >> >> Gonzalo >> >> On 04/11/2012 6:44 PM, Charles Eckel (eckelcu) wrote: >> >>> Hi Gonzalo, >>> >>> We discussed this at IETF 82. I remember because I presented a slide on it >>> >> :) >> >>> RFC 4582 states the following with regard to TLS: >>> >>> Which party, the client or the floor control server, acts as the TLS >>> server depends on how the underlying TCP connection is established. >>> For example, when the TCP connection is established using an SDP >>> offer/answer exchange [7], the answerer (which may be the client or >>> the floor control server) always acts as the TLS server. >>> >>> For DTLS, we considered the following alternatives: >>> >>> 1.The answerer always acts as the TLS/DTLS server, per RFC 4583 (as >>> >> currently defined) >> >>> 2.The BFCP server always acts as the TLS/DTLS server >>> 3.The offerer always offers setup:actpass and the answerer answers either >>> >> setup:active or setup:passive, where setup:active is RECOMMENDED (per >> RFC 5763) >> >>> The consensus was that (3) was the preferred option, because it adheres >>> >> to RFC 5763, does not overload offer/answer semantics, and it works for >> offerless INVITE with B2BUAs. >> >>> Additional details are available in the alias archive: >>> http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00007.html >>> and also in the meeting minutes: >>> http://tools.ietf.org/wg/bfcpbis/minutes?item=minutes82.html >>> >>> At the time of this decision, we did not consider changing the existing >>> >> guidance in RFC 4582 regarding TLS connection establishment. Doing so >> would introduce a backward compatibility concern. >> >>> Cheers, >>> Charles >>> >>> >>> >>>> -----Original Message----- >>>> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Sunday, November 04, 2012 10:52 AM >>>> To: Tom Kristensen (tomkrist) >>>> Cc: bfcpbis@ietf.org >>>> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 >>>> >>>> Hi Tom, >>>> >>>> the way it is defined right now, how to determine which endpoint is the >>>> TLS or DTLS server is different in TLS (the answerer) and in DTLS >>>> (depends on the setup attribute). Why do you think we should not be >>>> consistent across both transports? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> >>>> On 30/10/2012 8:19 AM, Tom Kristensen wrote: >>>> >>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> bfcpbis mailing list >>>> bfcpbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>> > > From internet-drafts@ietf.org Wed Dec 19 05:20:20 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 0FF9621F8B20; Wed, 19 Dec 2012 05:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 asdy5AG+O-+a; Wed, 19 Dec 2012 05:20:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505F121F8B11; Wed, 19 Dec 2012 05:20:19 -0800 (PST) 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.37 Message-ID: <20121219132019.28896.3533.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 05:20:19 -0800 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.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, 19 Dec 2012 13:20:20 -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-07.txt Pages : 89 Date : 2012-12-19 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4582bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Dec 19 05:21: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 15A5021F8B38; Wed, 19 Dec 2012 05:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 A42zrGf4M3s2; Wed, 19 Dec 2012 05:21:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D3421F8B39; Wed, 19 Dec 2012 05:21:26 -0800 (PST) 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.37 Message-ID: <20121219132126.31139.66098.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 05:21:26 -0800 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.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, 19 Dec 2012 13:21:27 -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-04.txt Pages : 15 Date : 2012-12-19 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4583bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomkrist@cisco.com Wed Dec 19 05:44: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 7E67421F8548 for ; Wed, 19 Dec 2012 05:44:35 -0800 (PST) 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 jKxEI1TuYqjB for ; Wed, 19 Dec 2012 05:44:35 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EEFF421F850D for ; Wed, 19 Dec 2012 05:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1259; q=dns/txt; s=iport; t=1355924675; x=1357134275; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tVv/5Yvt4OV8nl1Y6YR3gl1JpzPTG4tN/Qer1nz3DFY=; b=muEOCnd9uNiF5mkg9kWmZ9wHXeuvEIsVYqNocpa5zzpmY62gvjmrQAZl pz4hB77QDKAJgzP9cXUdlG3M0STILVgT4HROudaifbYS9A2P0LpuT3x5/ ASAn2X3e8Pjt+viwBKPkKBTHbPODwmrxE+CpUqgCjuSRU6Q3UGHB+L4rM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggHANzD0VCtJXHA/2dsb2JhbABFg0i6OhZzgh4BAQEEOEABEAsYCRYPCQMCAQIBRRMBBQIBAYgPuFWMSxt/gykDlgqFa4pdgnWBbA X-IronPort-AV: E=Sophos;i="4.84,316,1355097600"; d="scan'208";a="154597364" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 19 Dec 2012 13:44:34 +0000 Received: from [10.47.38.141] ([10.47.38.141]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBJDiX8Q006215; Wed, 19 Dec 2012 13:44:34 GMT Message-ID: <50D1C4C1.5020104@cisco.com> Date: Wed, 19 Dec 2012 14:44:33 +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: bfcpbis@ietf.org References: <20121219132019.28896.3533.idtracker@ietfa.amsl.com> In-Reply-To: <20121219132019.28896.3533.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.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, 19 Dec 2012 13:44:35 -0000 On 12/19/2012 02:20 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-07.txt > Pages : 89 > Date : 2012-12-19 > Changes from -06: - Language clarification - mail on list from Charles Eckel 2012-10-13 - Language clarification - use "BFCP connection" across the document, change three occurences of "BFCP association". - Resolved a lot of issues, small and large - mail on list 2012-10-24 after WGLC from Gonzalo Camarillo. Also, later mail discussion with regard to 5 of the issues. - Added reference to RFC 5763, Section 6.7 - mail on list from Christer Holmberg 2012-11-28. To my knowledge, in this draft version all the issues from WGLC and after are answered and fixed if appropriate. -- Tom From tomkrist@cisco.com Wed Dec 19 05:44:41 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 97B7C21F883C for ; Wed, 19 Dec 2012 05:44:40 -0800 (PST) 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 Qc-rRDvVdbLV for ; Wed, 19 Dec 2012 05:44:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AE20F21F8B0E for ; Wed, 19 Dec 2012 05:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1044; q=dns/txt; s=iport; t=1355924679; x=1357134279; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GCBkFHJFuZpCiT1AcI3w3zD8+6lDyxMIQwjzyC8t/0Y=; b=LlWVWqsa7y7jbsZuo2+kvQu11jeLkq1/rjEBOum+x+200QGhgak9tnjf HWoN51eYfRAwgAXvAYfie0nt1r8jd0bwxatwv/kvVqw6jeKHD4+L46eCu hhhPKRz6jWMvO6q8RYLaSPpBZDsSG6oh2xCj00tjS7CPCe/fgDpcjETYP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HAKDD0VCtJXG8/2dsb2JhbABFg0iCLLgOFnOCHgEBAQQ4QAEQCxgJFg8JAwIBAgFFEwEFAgEBiA+4VYxLgRqDKQOWCoVril2CdQ X-IronPort-AV: E=Sophos;i="4.84,316,1355097600"; d="scan'208";a="154658068" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 19 Dec 2012 13:44:39 +0000 Received: from [10.47.38.141] ([10.47.38.141]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBJDicCj017487; Wed, 19 Dec 2012 13:44:38 GMT Message-ID: <50D1C4C6.7000501@cisco.com> Date: Wed, 19 Dec 2012 14:44:38 +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: bfcpbis@ietf.org References: <20121219132126.31139.66098.idtracker@ietfa.amsl.com> In-Reply-To: <20121219132126.31139.66098.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.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, 19 Dec 2012 13:44:41 -0000 On 12/19/2012 02:21 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-04.txt > Pages : 15 > Date : 2012-12-19 > Changes from -03: - Fixed according to Camarillo's input and comments on list 2012-10-24 - Use UDP/TLS/BFCP not UDP/DTLS/BFCP in the example. - Added normative reference to RFC 5763, Section 5 also in Section 8 Authentication. - Resolved issue with different way to pick (D)TLS initiator for TCP and UDP, adding informational note. To my knowledge, in this draft version all the issues from WGLC and after are answered and fixed if appropriate. -- Tom From eckelcu@cisco.com Wed Dec 19 14:08:13 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 0BB6D21F8577 for ; Wed, 19 Dec 2012 14:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 5uecEuKftCa5 for ; Wed, 19 Dec 2012 14:08:11 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5FADB21F854F for ; Wed, 19 Dec 2012 14:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2117; q=dns/txt; s=iport; t=1355954890; x=1357164490; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VYae1fKPFa0ssJ/lH1OEW4hz6hdpjk57a+gErlsSwvQ=; b=iNCKXc77TM4p2vu8obJoYuElyeM6/ck6lrORE40/ECjlfpOAIoYUebhA jNhMngz2zkjXmXWCSqdxsqH0mB4il63kOztkVonro1TPftg9FNGum/63h 1rrBhN0/peV//twPaXLy6iPmG8qRE1k5StQDZtAFoVAqn68c7m9w58XRZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAU60lCtJXG8/2dsb2JhbABEvX0Wc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiICgEMuD8EjE0bg0dhA6ZSgnSBbTU X-IronPort-AV: E=Sophos;i="4.84,320,1355097600"; d="scan'208";a="151828410" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 19 Dec 2012 22:08:10 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBJM89hD015298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Dec 2012 22:08:09 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 16:08:09 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.txt Thread-Index: AQHN3eub8/PbTNBNFU+3OIdQdkYCzZgghrKAgAAmeRA= Date: Wed, 19 Dec 2012 22:08:08 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EED5E@xmb-aln-x08.cisco.com> References: <20121219132019.28896.3533.idtracker@ietfa.amsl.com> <50D1C4C1.5020104@cisco.com> In-Reply-To: <50D1C4C1.5020104@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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.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, 19 Dec 2012 22:08:13 -0000 Everyone who submitted WGLC comments, please confirm this version addresses= all your comments satisfactorily. Everyone else, please review the entire draft carefully and share any comme= nt or concerns you have. Thanks to Tom for incorporating all the feedback and posting this update. Happy Holidays! Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Wednesday, December 19, 2012 5:45 AM > To: bfcpbis@ietf.org > Cc: 'Tom Kristensen' > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.txt >=20 > On 12/19/2012 02:20 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-07.txt > > Pages : 89 > > Date : 2012-12-19 > > >=20 > Changes from -06: > - Language clarification - mail on list from Charles Eckel 2012-10-13 > - Language clarification - use "BFCP connection" across the document, > change three occurences of "BFCP association". > - Resolved a lot of issues, small and large - mail on list 2012-10-24 > after WGLC from Gonzalo Camarillo. Also, later mail discussion > with regard to 5 of the issues. > - Added reference to RFC 5763, Section 6.7 - mail on list from Christer > Holmberg 2012-11-28. >=20 >=20 > To my knowledge, in this draft version all the issues from WGLC and > after are answered and fixed if appropriate. >=20 >=20 > -- Tom > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Wed Dec 19 14:08:21 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 6D7E021F89AE for ; Wed, 19 Dec 2012 14:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 JN5zZCxskVvs for ; Wed, 19 Dec 2012 14:08:20 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6620321F88E3 for ; Wed, 19 Dec 2012 14:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1901; q=dns/txt; s=iport; t=1355954900; x=1357164500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gIxFzKzZxWDseAvKQno8KuvYQvSIqimMD9Tb+pol0yc=; b=nDJiAa+46ALtuoXFTBFke0lCwHWCszaVv3r8eMuHl+GoadVkpZ04vEWY x7tF8BKnPi27BrmHWtaBejUNyaiu3gEGqVSf99ELBVEzsaMP/UN4pHL6I 29/johxDEqsG0fMa9BE/WumGUjTz/9T9uLJiyx9/UBnGUDYGfqwJs9LCI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMk50lCtJXG//2dsb2JhbABEvX0Wc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiICgEMuD8EjE2DYmEDplKCdIIi X-IronPort-AV: E=Sophos;i="4.84,320,1355097600"; d="scan'208";a="154825684" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 19 Dec 2012 22:08:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBJM8JGD025262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Dec 2012 22:08:19 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 16:08:19 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.txt Thread-Index: AQHN3evETyMskEE++UyMy56MMMS4e5gghrcAgAAoHqA= Date: Wed, 19 Dec 2012 22:08:18 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EED65@xmb-aln-x08.cisco.com> References: <20121219132126.31139.66098.idtracker@ietfa.amsl.com> <50D1C4C6.7000501@cisco.com> In-Reply-To: <50D1C4C6.7000501@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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.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, 19 Dec 2012 22:08:21 -0000 Everyone who submitted WGLC comments, please confirm this version addresses= all your comments satisfactorily. Everyone else, please review the entire draft carefully and share any comme= nt or concerns you have. Thanks to Tom for incorporating all the feedback and posting this update. Happy Holidays! Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Wednesday, December 19, 2012 5:45 AM > To: bfcpbis@ietf.org > Cc: 'Tom Kristensen' > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.txt >=20 > On 12/19/2012 02:21 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-04.txt > > Pages : 15 > > Date : 2012-12-19 > > >=20 > Changes from -03: > - Fixed according to Camarillo's input and comments on list 2012-10-24 > - Use UDP/TLS/BFCP not UDP/DTLS/BFCP in the example. > - Added normative reference to RFC 5763, Section 5 also in > Section 8 Authentication. > - Resolved issue with different way to pick (D)TLS initiator for TCP and > UDP, adding informational note. >=20 >=20 > To my knowledge, in this draft version all the issues from WGLC and > after are answered and fixed if appropriate. >=20 >=20 > -- Tom >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Wed Dec 26 15:03: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 D542121F8CEF for ; Wed, 26 Dec 2012 15:03:18 -0800 (PST) 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 v7PexOgAw9Ai for ; Wed, 26 Dec 2012 15:03:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C9CB921F8CED for ; Wed, 26 Dec 2012 15:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4716; q=dns/txt; s=iport; t=1356562992; x=1357772592; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uE+ZwItm1re2wUF9Ba0sIYISafHko0QzpFxyeUImoAc=; b=H8nVelmf5JyaCqz0CKtoH9rAFGc0ZpVouGS/z8RBZNbp6LbGNJrv29Vy SKFYg70im+a+sup4CG9BcMKsAyzEbH2eoGLREWE3yQiMM10Vqy6IbDu2r 8sFhb6YQTlU2jX78YIKrSeaE9eI54dbmRr0TpYZN5FJJx68i+xzb9hEbe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO2A21CtJV2Y/2dsb2JhbABFvWEWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiICwy1TASMVxuDR2EDkh86k3uCdIFtNQ X-IronPort-AV: E=Sophos;i="4.84,359,1355097600"; d="scan'208";a="156482023" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 26 Dec 2012 23:03:11 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBQN3Bfo025905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Dec 2012 23:03:11 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 17:03:10 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.txt Thread-Index: AQHN3eub8/PbTNBNFU+3OIdQdkYCzZgghrKAgAAmeRCACuSB4A== Date: Wed, 26 Dec 2012 23:03:09 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046F2256@xmb-aln-x08.cisco.com> References: <20121219132019.28896.3533.idtracker@ietfa.amsl.com> <50D1C4C1.5020104@cisco.com> <92B7E61ADAC1BB4F941F943788C08828046EED5E@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046EED5E@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.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, 26 Dec 2012 23:03:18 -0000 Hi Tom, I had a close look at the changes, and overall they look okay to me. During my review, I did notice a few editorial things that are worth fixing= : 1) many of the references to [16] do not work correctly, including the firs= t reference in section 3.2, as well as those in section 6.2. 2) For the note added in section 5.1, you have an extra 'a' and are missing= a comma: r/BFCP is designed to a achieve small message size, as explained in Section= 1 and BFCP entities/BFCP is designed to achieve small message size, as exp= lained in Section 1, and BFCP entities 3) Section 6.2: r/ security considerations in Section 6 also applies/security consideration= s in Section 6 also apply 4) section 6.2.3: r/A Denial of Service (DoS) attacks/A Denial of Service (DoS) attack 5) Section 8, I think we should rework the following paragraph: When using BFCP over unreliable transport, it is also required to choose values that let the receiver distinguish the reception of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using unreliable transport SHOULD use monotonically increasing values for the Transaction ID. To read as follows: When using BFCP over an unreliable transport, it is important that the i= nitiator=20 of a transaction choose a Transaction ID value that lets the receiver di= stinguish the reception of the next message in a sequence of BFCP messages from a = retransmission of a previous message. Therefore, BFCP entities using an unreliable trans= port SHOULD use monotonically increasing Transaction ID values. 6) Section 8,=20 r/When using BFCP over unreliable transports/When using BFCP over an unreli= able transport Note, a similar change was made in many places in order to address comments= from Gonzalo; however, a global search and replace should be done to catch= numerous other places in which it still occurs. Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, December 19, 2012 2:08 PM > To: Tom Kristensen (tomkrist); bfcpbis@ietf.org > Cc: 'Tom Kristensen' > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.txt >=20 > Everyone who submitted WGLC comments, please confirm this version > addresses all your comments satisfactorily. > Everyone else, please review the entire draft carefully and share any > comment or concerns you have. > Thanks to Tom for incorporating all the feedback and posting this update. >=20 > Happy Holidays! > Charles >=20 > > -----Original Message----- > > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > > Behalf Of Tom Kristensen (tomkrist) > > Sent: Wednesday, December 19, 2012 5:45 AM > > To: bfcpbis@ietf.org > > Cc: 'Tom Kristensen' > > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-07.txt > > > > On 12/19/2012 02:20 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-07.txt > > > Pages : 89 > > > Date : 2012-12-19 > > > > > > > Changes from -06: > > - Language clarification - mail on list from Charles Eckel 2012-10-13 > > - Language clarification - use "BFCP connection" across the document, > > change three occurences of "BFCP association". > > - Resolved a lot of issues, small and large - mail on list 2012-10-24 > > after WGLC from Gonzalo Camarillo. Also, later mail discussion > > with regard to 5 of the issues. > > - Added reference to RFC 5763, Section 6.7 - mail on list from Christer > > Holmberg 2012-11-28. > > > > > > To my knowledge, in this draft version all the issues from WGLC and > > after are answered and fixed if appropriate. > > > > > > -- 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 From eckelcu@cisco.com Wed Dec 26 15:16:24 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 5EE1821F8C98 for ; Wed, 26 Dec 2012 15:16:24 -0800 (PST) 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 w5ZoWFXI40Db for ; Wed, 26 Dec 2012 15:16:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18D21F8CCC for ; Wed, 26 Dec 2012 15:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2923; q=dns/txt; s=iport; t=1356563783; x=1357773383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JKhEP3nZvygnvSSz4S+LQ08ugppM/918/1JwvW/lC7Q=; b=Wpzm6zrDuaAvHpOlVXk3MMloCQ1EXUW2z1r4qTS/QHHSKe4iv7yZhi3i kwCSd8OLBQNZphLgWP8+CKnSS+4hUfzNvg6LjKTqv1K3QFTISqhLRoJVa CT5rrfWvxh4CkdTAQYsajNEFbYAaYRKSeWs9uxYJo7zP2U6wvswkTp0EG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABiE21CtJXG9/2dsb2JhbABFvWEWc4IeAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiICwy1SwSMV4NiYQOmVIJ0giI X-IronPort-AV: E=Sophos;i="4.84,359,1355097600"; d="scan'208";a="156700776" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Dec 2012 23:16:23 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBQNGNJe029677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Dec 2012 23:16:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 17:16:22 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.txt Thread-Index: AQHN3evETyMskEE++UyMy56MMMS4e5gghrcAgAAoHqCACxB/cA== Date: Wed, 26 Dec 2012 23:16:21 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046F2270@xmb-aln-x08.cisco.com> References: <20121219132126.31139.66098.idtracker@ietfa.amsl.com> <50D1C4C6.7000501@cisco.com> <92B7E61ADAC1BB4F941F943788C08828046EED65@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046EED65@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.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, 26 Dec 2012 23:16:24 -0000 The changes look good to me. I do have the following editorial suggestions: 1) Section 3 r/transport field explained below/transport field, as explained below r/of transport used/of the transport used r/ TCP is used as transport/ TCP is used as the transport r/ UDP is used as transport/ UDP is used as the transport 2 Section 7 r/ use TCP or UDP as underlying transport/ use TCP or UDP as the underlying= transport Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, December 19, 2012 2:08 PM > To: Tom Kristensen (tomkrist); bfcpbis@ietf.org > Cc: 'Tom Kristensen' > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.txt >=20 > Everyone who submitted WGLC comments, please confirm this version > addresses all your comments satisfactorily. > Everyone else, please review the entire draft carefully and share any > comment or concerns you have. > Thanks to Tom for incorporating all the feedback and posting this update. >=20 > Happy Holidays! > Charles >=20 > > -----Original Message----- > > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > > Behalf Of Tom Kristensen (tomkrist) > > Sent: Wednesday, December 19, 2012 5:45 AM > > To: bfcpbis@ietf.org > > Cc: 'Tom Kristensen' > > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-04.txt > > > > On 12/19/2012 02:21 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 Bina= ry > > Floor Control Protocol (BFCP) Streams > > > Author(s) : Gonzalo Camarillo > > > Tom Kristensen > > > Filename : draft-ietf-bfcpbis-rfc4583bis-04.txt > > > Pages : 15 > > > Date : 2012-12-19 > > > > > > > Changes from -03: > > - Fixed according to Camarillo's input and comments on list 2012-10-24 > > - Use UDP/TLS/BFCP not UDP/DTLS/BFCP in the example. > > - Added normative reference to RFC 5763, Section 5 also in > > Section 8 Authentication. > > - Resolved issue with different way to pick (D)TLS initiator for TCP an= d > > UDP, adding informational note. > > > > > > To my knowledge, in this draft version all the issues from WGLC and > > after are answered and fixed if appropriate. > > > > > > -- 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