From gonzalo.camarillo@ericsson.com Sun Nov 4 07:52:11 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 CEBD621F85E3 for ; Sun, 4 Nov 2012 07:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.874 X-Spam-Level: X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 j8icXopxlmKU for ; Sun, 4 Nov 2012 07:52:11 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4C21F8503 for ; Sun, 4 Nov 2012 07:52:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-9d-50968f294ecc Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 96.C3.11564.92F86905; Sun, 4 Nov 2012 16:52:09 +0100 (CET) Received: from [131.160.126.137] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 4 Nov 2012 16:52:08 +0100 Message-ID: <50968F26.9080403@ericsson.com> Date: Sun, 4 Nov 2012 10:52:06 -0500 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Kristensen References: <5087FAE4.5010900@ericsson.com> <508FA129.1090802@cisco.com> <508FBF31.8000906@ericsson.com> <508FC5C1.4040702@cisco.com> In-Reply-To: <508FC5C1.4040702@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rlezf1qAwf0Dihb/1h1lsrhy5Beb A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx5m5KwXnNirbnDUwNjOcVuhg5OCQETCT6 X/h0MXICmWISF+6tZ+ti5OIQEjjJKPHt43QmCGcNo8TractYQKp4BbQlLrxdzAxiswioSJz6 /JwJxGYTsJDYcus+WI2oQJTEoY0H2SHqBSVOznwCFhcRUJfo2/sdLM4sICKx4PlvFpAjhAWc JXbuT4LY1coocX3nCrD5nAKaEpuP32ODuE5S4u37V8wQvXoSU662MELY8hLb384BiwsB3bb8 WQvLBEahWUhWz0LSMgtJywJG5lWM7LmJmTnp5YabGIGBenDLb90djKfOiRxilOZgURLn5Ura 7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBseT1i59m7a5ru9+EaKh/W8qSe5Dl2PIC/e0r Zxde+jaB2VZDOfSf9A+15yL2NmnC0v179NMK+7Ju7yyxfBpeGXzWvLh/d7yz9K45R+arzXPu 3Oq83SBF0O+rwcROqaOqDd+k/rBtWppdf85csNV6SdatLSksrJdDlk7KFN+Vf7Xn2NmQaoY+ JZbijERDLeai4kQAZkZzsiICAAA= 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: Sun, 04 Nov 2012 15:52:11 -0000 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 >>> >>> >> > From eckelcu@cisco.com Sun Nov 4 15:44: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 6B18D21F87F7 for ; Sun, 4 Nov 2012 15:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.074 X-Spam-Level: X-Spam-Status: No, score=-9.074 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 UNNNoj0LbNWo for ; Sun, 4 Nov 2012 15:44:24 -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 C317B21F85F0 for ; Sun, 4 Nov 2012 15:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7549; q=dns/txt; s=iport; t=1352072663; x=1353282263; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RpQHTZx05iDEat3e27+eff31FzEA1Uwan1tsSk3EXHg=; b=IS6IJk/hqSinMfwbWv8HeQbESVqTNwIU2Uv+rWKEsHCh6TwBBl6bwVfG YrwlxRtkz3uj4slEqFD/3yuV97pyDCvo1Em50uL4hJYL2R9iF9S9zs6+k Sp2NvWNZpFR9KZH+FlFQOyrjfARm62+AqvXOfTHgOLht4u43+svTg9Qss 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPb8llCtJV2Z/2dsb2JhbABDwzqBCIIeAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCAEZh2gLmUSfCYwBGoVBYQOSSYROjT2Ba4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,712,1344211200"; d="scan'208";a="138685804" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2012 23:44:23 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA4NiNJO024561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 23:44:23 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 17:44:22 -0600 From: "Charles Eckel (eckelcu)" To: Gonzalo Camarillo , "Tom Kristensen (tomkrist)" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 Thread-Index: AQHNsfSO4+3wdAt3DEKwiaDvAG4G1ZfR9dSAgAAjzYCAAAfSgIAIJ+cAgAAZjRA= Date: Sun, 4 Nov 2012 23:44:22 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882810742E@xmb-aln-x08.cisco.com> References: <5087FAE4.5010900@ericsson.com> <508FA129.1090802@cisco.com> <508FBF31.8000906@ericsson.com> <508FC5C1.4040702@cisco.com> <50968F26.9080403@ericsson.com> In-Reply-To: <50968F26.9080403@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.252] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--62.519600-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] 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: Sun, 04 Nov 2012 23:44:25 -0000 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 current= ly defined) 2.The BFCP server always acts as the TLS/DTLS server 3.The offerer always offers setup:actpass and the answerer answers either s= etup:active or setup:passive, where setup:active is RECOMMENDED (per RFC 57= 63) 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 offerl= ess 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=3Dminutes82.html At the time of this decision, we did not consider changing the existing gui= dance in RFC 4582 regarding TLS connection establishment. Doing so would in= troduce 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 >=20 > Hi Tom, >=20 > 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? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > 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 bee= n > > part of rfc4582 for a while. > > - Cf. http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06#secti= on-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 a= s > >> 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. Tha= t > >>>> discussion is only relevant to TCP. The new draft needs to explain t= hat > >>>> 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 nee= d > >>> 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 t= he > >>> 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. Altho= ugh > >>>> 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 wit= h > >>>> 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=3Dfloorid (and mstrm/m-stream) applies to endpoints willin= g > to > >>> act as server, will add this to the second sentence in the note: > >>> "[...] some vendors and occurs in cases where the endpoint is will= ing > >>> to act as an server." > >>> > >>> > >>>> The last paragraph of Section 8 discusses which entity behaves as th= e > >>>> TLS server. Do we need a similar discussion for DTLS? > >>>> > >>>> > >>> Indeed. Handled above. > >>> > >>> -- Tom > >>> > >>> > >> > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From tomkrist@cisco.com Sun Nov 4 23:32:04 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 7768A21F8994 for ; Sun, 4 Nov 2012 23:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 8zPvy1QWnWa9 for ; Sun, 4 Nov 2012 23:32:03 -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 A905821F8987 for ; Sun, 4 Nov 2012 23:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8332; q=dns/txt; s=iport; t=1352100722; x=1353310322; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WBoKheyHELsCH6Vapfms34H+Bb1I01IUaAo8Rtq0zHw=; b=TVBJzCoUNlQrR7nh+JKxIh1foa+T8IIyCghXi3PrIio2SCebdeKk1Ur+ X9wqx6Apd8/UxbG6ZtqcivSy3OgsvSwSGSA5iq3UaxBrzuaxVq/U1Gd89 WMMRKEYaScl5V5ECABlyQOZnskGRGDdjdAJG1ENZxji09cxnA/WZlSqvo 4=; X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208,223";a="9334334" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 05 Nov 2012 07:31:57 +0000 Received: from [10.54.86.33] (dhcp-10-54-86-33.cisco.com [10.54.86.33]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA57VvQe029544; Mon, 5 Nov 2012 07:31:57 GMT Message-ID: <50976B6C.5030407@cisco.com> Date: Mon, 05 Nov 2012 08:31:56 +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> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882810742E@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" , 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: Mon, 05 Nov 2012 07:32:04 -0000 From Charles' explanation and recap, I now see that we may add to rfc4583bis text describing the mandated use of setup:actpass in offers and recommended use of setup:active in answers. -- Tom On 11/05/2012 12:44 AM, 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 gonzalo.camarillo@ericsson.com Mon Nov 5 05:00: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 6D3AD21F8419 for ; Mon, 5 Nov 2012 05:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.263 X-Spam-Level: X-Spam-Status: No, score=-105.263 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=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 D+J3fwxwgoum for ; Mon, 5 Nov 2012 05:00:24 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D8FE321F86B1 for ; Mon, 5 Nov 2012 05:00:23 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-cd-5097b866e90f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id FC.64.06323.668B7905; Mon, 5 Nov 2012 14:00:22 +0100 (CET) Received: from [131.160.126.138] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 14:00:20 +0100 Message-ID: <5097B862.6050200@ericsson.com> Date: Mon, 5 Nov 2012 08:00:18 -0500 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 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> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882810742E@xmb-aln-x08.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUyM+JvjW7ajukBBue/Wlj8W3eUyWLTrC9s FleO/GJzYPaY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDL695xjLrhjWzHjzQyWBsY3hl2M nBwSAiYSD/6tZYewxSQu3FvP1sXIxSEkcJJR4uqy9ywgCSGBNYwSi1usQGxeAW2J5Zu/AcU5 OFgEVCTOXVcBCbMJWEhsuXUfrFxUIEri0MaD7BDlghInZz4Bi4sIGEosmrQOzGYWiJNYMOE2 I8gYYQFniZ37kyDWPmGUWLnkKCtIDaeAt0TbwR/MELdJSrx9/4oZoldPYsrVFkYIW15i+9s5 zBBnAp32rIVlAqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cvNNjMCQPbjlt8EOxk33xQ4xSnOw KInz6qnu9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuOKUWLYtB+MXo7v/D7VFTzrzuLHA Ze/L1clXRBc8X7cz9OKutz9W3b/zxvKPW7nh77U+Hy+GJquqfbdeKH/kfpKC+de+u9N3Nk6X 1ldQOGrUPSOUS8Bbs3hO48d17HreR28WzFih+m3/4SW/nv1OOLzlzM07S5fF6FxRDTzVeD44 4f6hrzNXn7ygxFKckWioxVxUnAgALPndZycCAAA= Cc: "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" 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: Mon, 05 Nov 2012 13:00:25 -0000 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 eckelcu@cisco.com Mon Nov 5 15:01: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 9F4DD11E80A2 for ; Mon, 5 Nov 2012 15:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.417 X-Spam-Level: X-Spam-Status: No, score=-9.417 tagged_above=-999 required=5 tests=[AWL=-0.618, 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 YlStb68P-o3D for ; Mon, 5 Nov 2012 15:01:21 -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 7BCA711E8097 for ; Mon, 5 Nov 2012 15:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8740; q=dns/txt; s=iport; t=1352156481; x=1353366081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bFQDsqR5x5YnoNViGZQpfl1cEO/ulZAEYbZ1A2rgsHY=; b=O02mEDtNV+Ic6D1MT8A23tng6VmQR5vf5t9zwEJj6ZkfbhwK33M2VK5j fcwws4LTrS3vdcG1rDrFVBgk+nq1rdW7wfgGme4W0//oGqBLUUjXT3FI9 vXoJeN2Bh++6szbGKOEjqCEKoiKxAuh7Pt/HJrLj0jZfUwWPzu6r9B5hk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAREmFCtJXG+/2dsb2JhbABEwzOBCIIeAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIARmHaAuae6AVjAEag0iBeWEDkkmETo09gWuCYg2BZBce X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139074740" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 05 Nov 2012 23:01:20 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA5N1Kil014704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:01:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:01:20 -0600 From: "Charles Eckel (eckelcu)" To: Gonzalo Camarillo Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03 Thread-Index: AQHNsfSO4+3wdAt3DEKwiaDvAG4G1ZfR9dSAgAAjzYCAAAfSgIAIJ+cAgAAZjRCAAUjHAIAAQxlQ Date: Mon, 5 Nov 2012 23:01:19 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828107F45@xmb-aln-x08.cisco.com> 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> In-Reply-To: <5097B862.6050200@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.191] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--68.184600-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" , "Tom Kristensen \(tomkrist\)" 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: Mon, 05 Nov 2012 23:01:22 -0000 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 >=20 > Hi Charles, >=20 > 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). >=20 > Thanks, >=20 > Gonzalo >=20 > 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 eith= er > 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=3Dminutes82.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 th= e > >> 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 b= een > >>> part of rfc4582 for a while. > >>> - Cf. http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06#sec= tion- > 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. Th= at > >>>> 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. T= hat > >>>>>> 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 n= eed > >>>>> to add a UDP description to Section 8, i.e. mandate using the 'setu= p' > >>>>> 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 interpreti= ng > >>>>>> 'm-stream' the same way as 'mstrm' when receiving." > >>>>>> > >>>>>> The text should clarify (or be more explicit about) whether existi= ng > >>>>>> 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=3Dfloorid (and mstrm/m-stream) applies to endpoints will= ing > >> to > >>>>> act as server, will add this to the second sentence in the note: > >>>>> "[...] some vendors and occurs in cases where the endpoint is wi= lling > >>>>> 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 tomkrist@cisco.com Mon Nov 12 06:04: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 96B1821F85AD for ; Mon, 12 Nov 2012 06:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, GB_SUMOF=5, 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 W3iRozLRofEo for ; Mon, 12 Nov 2012 06:04:31 -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 0FE8F21F85AC for ; Mon, 12 Nov 2012 06:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35191; q=dns/txt; s=iport; t=1352729070; x=1353938670; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=sM6G06MsXsQD2q1LwladF+ZqUF5DVrO8/1Baetb2DPU=; b=cVrU9SVvB03SK+GFiSU03j0vVsNz58o2ZaCpJ15NLaFh40kg2gLFrRAm iriCULhSJDwSZJItIvDRh+0L7evnGGSRqF9X4R68xfKl8cz6UulkYBQHk 3SvLmuPK/qzAhAl66uTxvWt2ZQ/+Xum2YfdoFJUrQ1H8sZqhSwVEUEVzD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIUBoVCQ/khR/2dsb2JhbAA6AQnDV4EIgh4BAQEDAQEBAQ8BBwEdMAYKEQsVAwkMAQkPCQMCAQIBFTAGAQwEAgIBARcHh2IGC5sGn06MFRABAwEFgn0IDIMfA5V8gRyET4htgWuCcD6BHAEFAxc X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="9508171" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 12 Nov 2012 14:04:27 +0000 Received: from [10.55.85.193] (dhcp-10-55-85-193.cisco.com [10.55.85.193]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qACE4QFJ020990; Mon, 12 Nov 2012 14:04:27 GMT Message-ID: <50A101EA.4060903@cisco.com> Date: Mon, 12 Nov 2012 15:04:26 +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 , "bfcpbis@ietf.org" 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 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: Mon, 12 Nov 2012 14:04:34 -0000 Commments and proposed solutions to the issues and questions raised by Gonzalo below. Prefixed with "TK:". Note: There's five issues with a TBD (To be done). I'll initiate a separate mail to discuss these unresolved issues. The other issues may be handled in this mail thread. -- Tom 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 > > 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... -- TK: Changed all occurrences with transport in singular. -- > Abstract: > > OLD: > > Changes from RFC 4582 are summarized in section 16. > > NEW: > > Changes from RFC 4582 are summarized in Section 16. -- TK: Fixed. -- > 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." -- TK: Thanks for the input. Since CCMP is finished and the outcome of XCON, this is natural. Split the text in two and used some of it in the two sections. -- > Section 3.2: > > Add a reference to RFC 5018. -- TK: Sentence with reference added. -- > 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. -- TK: Adopted. -- > 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. -- TK: Adopted. -- > 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. -- TK: 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!?! TBD #1. -- > 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. -- TK: Done. -- > 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. -- TK: RFC 5018 added. Further discussion TBD #2. -- > 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; -- TK: Adopted. -- > 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. -- TK: Adopted. -- > 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. -- TK: Adopted. -- > 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. -- TK: Adopted. -- > 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. -- TK: Nicely crafted. Adopted. -- > 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." -- TK: 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. Removal TBD #3. -- > 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? -- TK: No real random numbers are needed. Might change the word 'random' to something else. What is important, is that the Transaction ID chosen is unique amongst the outstanding transactions. And over UDP only one outstanding transaction is allowed. Will rework the text: From: "Transaction ID values are non-sequential and entities are at liberty to select values at random" To: "Transaction ID values are non-sequential and entities are at liberty to select arbitrary values, as long as the values are unique in the context of outstanding transactions." Safer scheme to pick sequence number TBD #4. (To avoid late arriving retransmissions cause confusion). -- > What is a "delinquent" response? -- TK: "Not-behaving" response?! In Section 6.2. Well, we may rename it to "conveyed in any such late arriving response" or "conveyed in any such late out-of-sequence sequence arriving response". I prefer the first version; added to upcoming version of the draft. -- > Section 6.2.2 deals with ICMP errors for UDP. We should also specify > how to handle ICMP errors for TCP, for consistency. -- TK: The main idea is to not change any TCP/BFCP semantics. However, we may add an ICMP part to the sentence of interest in Section 6.1, so that it reads: "Similarly, if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-conversation, the TCP connection SHOULD be reestablished." -- > 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." -- TK: Defined the term "BFCP connection" in Section 2, used regardless of transport. Changing "conversation" and "connection" to this term. -- > 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. -- TK: First two paragraphs of Section 6.2.2 rewritten, and read as follows: "Informational note: The recommendation to treat the connection as closed in this case, stems from the fact that 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 identity the entity previously was assigned (i.e., a User ID) be acceptable due to session hijacking." -- > 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). -- TK: Done. The word "firewall" now present only in a reference title and to describe IPv6 firewalls discarding ICMP (in the context of Teredo requiring ICMP6). -- > 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? -- TK: Indeed. Moving the mentioned sentence to Section . And adding the following note for the Payload Length field specification: "Note: BFCP is designed to a achieve small message size, as explained in Section 1 and BFCP entities are REQUIRED to keep the BFCP message size smaller than the size limited by the 16-bit Payload Length field. To convey information not strictly related to floor control, other protocols should be used such as the XCON framework (cf. Section 3)." -- > 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. -- TK: Done. Added the sentence "To avoid this happening at the IP layer, a fragmentation scheme for BFCP is defined below" in the first paragraph of Section 6.2.3. Using "path MTU" across the draft. -- > 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. -- TK: Yes, MUST added. -- > Where does the document talk about path MTU discovery? How do BFCP > entities discover what is the path MTU? -- TK: Path MTU discovery is not mentioned. Will add a sentence pointing to RFC 4821, RFC 1981 and RFC 1191 if appropriate. (However, in practice most vendors will use the same simplistic approach as for RTP. And discovery not mentioned in RFC 3550 and only mentioned as "SHOULD run MTU discovery for this purpose" in RFC 6184, as examples.) Adding: "BFCP entities should consider the MTU size available between the sender and the receiver and MAY run MTU discovery, such as [20][21][22], for this purpose." -- > 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. -- TK: Adding the following text: "A Denial of Service (DoS) attacks utilizing the fragmentation scheme described above is mitigated by the fact that the Response Retransmission Timer is started after receipt of the first BFCP message fragment. In addition, the Payload Length field may be compared with the Fragment Offset and Fragment Length fields to verify the message fragments as they arrive. To make DoS attacks with spoofed IP addresses difficult, BFCP entities should use the cookie exchange mechanism in DTLS [RFC6347]" A verification using Payload Length and so on might be hard to do right, but might be worth considering for implementers. Right?! -- > 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. -- TK: s/ACK/acknowledgement/ or s/ACK/acknowledgement message/. Normative statements changed/fixed; s/MUST/must/ + s/can/MAY/ -- > 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). -- TK: Added the following: "BFCP is designed for achieveing small message size, due to the binary encoding as described in . The fragmentation scheme is therefore deliberately kept simple and straightforward, since the probability of fragmentation of BFCP messages being required is small. By design, the fragmentation scheme does not acknowledge individual BFCP message fragments. The whole BFCP message is acknowledged if received completely." -- > Section 6.2.3 needs to talk about the interactions of using DTLS and > fragmentation. -- TK: Fragments are exchanged as datagrams over DTLS, just as ordinary unfragmented BFCP messages - right? However, I'll add a sentence about the path MTU considerations wrt. the overhead added by DTLS. Adding: "When deciding message fragment size based on path MTU, the BFCP fragmentation handling should take into account how the DTLS record framing expands the datagram size as described in Section 4.1.1.1 of RFC6347." -- > 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. -- TK: Fixed. -- > 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. -- TK: Clarified for the different transports. (A bit of text duplication, since the behaviour of the client-initiated trans. and the server-initiated trans. over unreliable transport is the same.) "When using reliable transport, server-initiated transactions consist of a single message from a floor control server to a client. And since they do not trigger any response, their Transaction ID is set to 0 when used over reliable transports. 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 client copies the Transaction ID into the response and the floor control server use Transaction ID values to match responses with previously issued requests." -- > 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. -- TK: Fixed. -- > 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. -- TK: 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. TBD #5. What do people think? -- > 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." -- TK: Agree. No reason mentioning this. -- > 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. -- TK: Sentence moved. Adding a description of why 10 sec default for T2 was choosed, the resulting paragraph in 8.3.3 reads something like: "T2 SHALL be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities. The default value is based on the sum of the three retransmissions related to T1 using its default value (7.5s) and an extra 2.5s is added to take into account potential messages in transit due to latency." -- > > 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. > > > > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From gonzalo.camarillo@ericsson.com Tue Nov 13 00:12: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 6A55021F88E2 for ; Tue, 13 Nov 2012 00:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.605 X-Spam-Level: X-Spam-Status: No, score=-103.605 tagged_above=-999 required=5 tests=[AWL=-2.356, BAYES_00=-2.599, GB_SUMOF=5, 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 r+STj12MDUmv for ; Tue, 13 Nov 2012 00:12:23 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9921F88E0 for ; Tue, 13 Nov 2012 00:12:21 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-00-50a200e45b32 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 07.EC.06323.4E002A05; Tue, 13 Nov 2012 09:12:20 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 09:12:20 +0100 Message-ID: <50A200E3.8020403@ericsson.com> Date: Tue, 13 Nov 2012 10:12:19 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Kristensen References: <5087C125.2050109@ericsson.com> <50A101EA.4060903@cisco.com> In-Reply-To: <50A101EA.4060903@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvje4ThkUBBt8W6Fr8W3eUyeLKkV9s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGxa0f2At+z2aq+PTsClMD47v7jF2MnBwS AiYSd/fdYYGwxSQu3FvP1sXIxSEkcJJRYv3750wQzmpGiY7mB+wgVbwC2hL7Vn9hArFZBFQl rjeeZAWx2QQsJLbcug82SVQgSuLQxoNQ9YISJ2c+AYuLCKhL9O39DhZnFtCUuHp4F9gVwgLO Es92LgWbIyTgITG/7T4ziM0JVPP21XWoSyUl3r5/xQzRqycx5WoLI4QtL7H97RxmiF5tieXP WlgmMArNQrJ6FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAzYg1t+G+xg3HRf7BCjNAeLkjivnup+ fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MoaU9akbBAivPOLRcaVwx99p7HTY2lRPzr36a Ixe0fcPMd2J23/5yVm71ioz1Ncy8fDVTjLnmRHWP5nKBSRe+aLCpHgz3Dg/sWlEZ7T6xZvO2 5a5pkpPUNU5Zvc26WXb1Nu/x4t7MK9q1i+8vbTxzJOPr5d3ML5jq5u1/5Oy8NzbX/1faxQl8 SizFGYmGWsxFxYkAQikjUiYCAAA= Cc: "bfcpbis@ietf.org" 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: Tue, 13 Nov 2012 08:12:25 -0000 Thanks for your answers, Tom. Gonzalo On 12/11/2012 4:04 PM, Tom Kristensen wrote: > Commments and proposed solutions to the issues and questions raised by > Gonzalo below. Prefixed with "TK:". > > Note: There's five issues with a TBD (To be done). I'll initiate a > separate mail to discuss these unresolved issues. > > The other issues may be handled in this mail thread. > > -- Tom > > 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 >> >> 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... > > -- > TK: Changed all occurrences with transport in singular. > -- > > >> Abstract: >> >> OLD: >> >> Changes from RFC 4582 are summarized in section 16. >> >> NEW: >> >> Changes from RFC 4582 are summarized in Section 16. > > -- > TK: Fixed. > -- > > >> 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." > > -- > TK: Thanks for the input. Since CCMP is finished and the outcome of > XCON, this is natural. Split the text in two and used some of it in the > two sections. > -- > > >> Section 3.2: >> >> Add a reference to RFC 5018. > > -- > TK: Sentence with reference added. > -- > > >> 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. > > -- > TK: Adopted. > -- > > >> 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. > > -- > TK: Adopted. > -- > > >> 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. > > -- > TK: 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!?! > > TBD #1. > -- > > >> 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. > > -- > TK: Done. > -- > > >> 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. > > -- > TK: RFC 5018 added. > > Further discussion TBD #2. > -- > > >> 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; > > -- > TK: Adopted. > -- > > >> 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. > > -- > TK: Adopted. > -- > > >> 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. > > -- > TK: Adopted. > -- > > >> 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. > > -- > TK: Adopted. > -- > > >> 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. > > -- > TK: Nicely crafted. Adopted. > -- > > >> 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." > > -- > TK: 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. > > Removal TBD #3. > -- > > >> 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? > > -- > TK: No real random numbers are needed. Might change the word 'random' to > something else. What is important, is that the Transaction ID chosen is > unique amongst the outstanding transactions. And over UDP only one > outstanding transaction is allowed. Will rework the text: > > From: > "Transaction ID values are non-sequential and entities are at liberty to > select values at random" > To: > "Transaction ID values are non-sequential and entities are at liberty to > select arbitrary values, as long as the values are unique in the context > of outstanding transactions." > > Safer scheme to pick sequence number TBD #4. (To avoid late arriving > retransmissions cause confusion). > -- > > >> What is a "delinquent" response? > > -- > TK: "Not-behaving" response?! In Section 6.2. Well, we may rename it to > "conveyed in any such late arriving response" or "conveyed in any such > late out-of-sequence sequence arriving response". I prefer the first > version; added to upcoming version of the draft. > -- > > >> Section 6.2.2 deals with ICMP errors for UDP. We should also specify >> how to handle ICMP errors for TCP, for consistency. > > -- > TK: The main idea is to not change any TCP/BFCP semantics. However, we > may add an ICMP part to the sentence of interest in Section 6.1, so that > it reads: > > "Similarly, if a TCP connection cannot deliver a BFCP message and times > out or receives an ICMP port unreachable message mid-conversation, the > TCP connection SHOULD be reestablished." > -- > > >> 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." > > -- > TK: Defined the term "BFCP connection" in Section 2, used regardless of > transport. Changing "conversation" and "connection" to this term. > -- > > >> 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. > > -- > TK: First two paragraphs of Section 6.2.2 rewritten, and read as follows: > > "Informational note: The recommendation to treat the connection as > closed in this case, stems from the fact that 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 > identity the entity previously was assigned (i.e., a User ID) be > acceptable due to session hijacking." > -- > > >> 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). > > -- > TK: Done. The word "firewall" now present only in a reference title and > to describe IPv6 firewalls discarding ICMP (in the context of Teredo > requiring ICMP6). > -- > > >> 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? > > -- > TK: Indeed. Moving the mentioned sentence to Section . And adding the > following note for the Payload Length field specification: > > "Note: BFCP is designed to a achieve small message size, as > explained in Section 1 and BFCP entities are REQUIRED to keep the BFCP > message size smaller than the size limited by the 16-bit Payload Length > field. To convey information not strictly related to floor control, > other protocols should be used such as the XCON framework (cf. Section 3)." > -- > >> 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. > > -- > TK: Done. > Added the sentence "To avoid this happening at the IP layer, a > fragmentation scheme for BFCP is defined below" in the first paragraph > of Section 6.2.3. > Using "path MTU" across the draft. > -- > > >> 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. > > -- > TK: Yes, MUST added. > -- > > >> Where does the document talk about path MTU discovery? How do BFCP >> entities discover what is the path MTU? > > -- > TK: Path MTU discovery is not mentioned. Will add a sentence pointing to > RFC 4821, RFC 1981 and RFC 1191 if appropriate. (However, in practice > most vendors will use the same simplistic approach as for RTP. And > discovery not mentioned in RFC 3550 and only mentioned as "SHOULD run > MTU discovery for this purpose" in RFC 6184, as examples.) > > Adding: > "BFCP entities should consider the MTU size available between the > sender and the receiver and MAY run MTU discovery, such as > [20][21][22], for this purpose." > -- > > >> 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. > > -- > TK: Adding the following text: > > "A Denial of Service (DoS) attacks utilizing the fragmentation > scheme described above is mitigated by the fact that the > Response Retransmission Timer is started after receipt of the > first BFCP message fragment. In addition, the Payload Length > field may be compared with the Fragment Offset and Fragment > Length fields to verify the message fragments as they arrive. > To make DoS attacks with spoofed IP addresses difficult, > BFCP entities should use the cookie exchange mechanism in > DTLS [RFC6347]" > > A verification using Payload Length and so on might be hard to do right, > but might be worth considering for implementers. Right?! > -- > > >> 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. > > -- > TK: s/ACK/acknowledgement/ or s/ACK/acknowledgement message/. > > Normative statements changed/fixed; s/MUST/must/ + s/can/MAY/ > -- > > >> 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). > > -- > TK: Added the following: > > "BFCP is designed for achieveing small message size, due to > the binary encoding as described in . > The fragmentation scheme is therefore deliberately kept > simple and straightforward, since the probability of > fragmentation of BFCP messages being required is small. > By design, the fragmentation scheme does not acknowledge > individual BFCP message fragments. The whole BFCP message > is acknowledged if received completely." > -- > > >> Section 6.2.3 needs to talk about the interactions of using DTLS and >> fragmentation. > > -- > TK: Fragments are exchanged as datagrams over DTLS, just as ordinary > unfragmented BFCP messages - right? However, I'll add a sentence about > the path MTU considerations wrt. the overhead added by DTLS. Adding: > > "When deciding message fragment size based on path MTU, the BFCP > fragmentation handling should take into account how the DTLS > record framing expands the datagram size as described in > Section 4.1.1.1 of RFC6347." > -- > > >> 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. > > -- > TK: Fixed. > -- > > >> 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. > > -- > TK: Clarified for the different transports. (A bit of text duplication, > since the behaviour of the client-initiated trans. and the > server-initiated trans. over unreliable transport is the same.) > > "When using reliable transport, server-initiated transactions > consist of a single message from a floor control server to a client. And > since they do not trigger any response, their Transaction ID is set to 0 > when used over reliable transports. > 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 client copies the Transaction ID into > the response and the floor control server use Transaction ID values to > match responses with previously issued requests." > -- > > >> 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. > > -- > TK: Fixed. > -- > > >> 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. > > -- > TK: 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. > > TBD #5. What do people think? > -- > > >> 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." > > -- > TK: Agree. No reason mentioning this. > -- > > >> 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. > > -- > TK: Sentence moved. Adding a description of why 10 sec default for T2 > was choosed, the resulting paragraph in 8.3.3 reads something like: > > "T2 SHALL be set such that it encompasses all legal retransmissions > per T1 plus a factor to accommodate network latency between BFCP > entities. The default value is based on the sum of the three > retransmissions related to T1 using its default value (7.5s) and an > extra 2.5s is added to take into account potential messages in transit > due to latency." > -- > > > > > >> >> 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. >> >> >> >> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> > From tomkrist@cisco.com Tue Nov 13 00:23:08 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 2B47E21F88F4 for ; Tue, 13 Nov 2012 00:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.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 kE1rARUKLqwy for ; Tue, 13 Nov 2012 00:23:06 -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 261AD21F88E3 for ; Tue, 13 Nov 2012 00:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=482; q=dns/txt; s=iport; t=1352794986; x=1354004586; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=Z4FPEkNpAdUHeaPddrnB5TZQTkvodE24frDirteJ5lM=; b=h8+X6nyLquwe5jvFYaOktQ0UeVQOKqiEpeRt2XNHLEquQNtW18qHHmYe 6W3gkxfPA3FEhVN++9t8yKmZoo8DQdb9gqMrwdbnz3+yRd5aeadpCc3zC RkZHHgEUWNpyc6sHsRNpif+lldv1pYU0ivMoestO+tuRvEkLdKyImSJEP U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGgAolCQ/khM/2dsb2JhbABEw3OBCII3ASVAATwWGAMCAQIBSw0BBwEBHodomiCPZZA6knUDlXyFa4htgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="9526144" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 13 Nov 2012 08:23:05 +0000 Received: from [10.54.86.33] (dhcp-10-54-86-33.cisco.com [10.54.86.33]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAD8N4Sk023288; Tue, 13 Nov 2012 08:23:05 GMT Message-ID: <50A20368.9050408@cisco.com> Date: Tue, 13 Nov 2012 09:23: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: "BFCPbis WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo Subject: [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, 13 Nov 2012 08:23:08 -0000 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 From tomkrist@cisco.com Tue Nov 13 00:26: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 8599D21F88FB for ; Tue, 13 Nov 2012 00:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 SOgdedvnSqB0 for ; Tue, 13 Nov 2012 00:26:30 -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 B549B21F8857 for ; Tue, 13 Nov 2012 00:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=568; q=dns/txt; s=iport; t=1352795189; x=1354004789; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=oFd4uSaXm2afX78gHj8OPB4tBsc30y7axPX8yVk2F2s=; b=jX2BiLqvCx+YFmtDT2v3Nf4qeQGYUi3aDlhuGcTV1lIU4j0obAynw0fy 5zqYoY7LsVL/Vr1uLBJGQV0xn72q8R/4os3zcqp+XRmP/5RElYFcccP6S XQZB7mEX0XsrQIfaBs6qOd+kMtUzx3YiHemUJXU5dFYYImJXrrrYEyGvF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4JAG4DolCQ/khL/2dsb2JhbABEwm4EBH2BCII3ASVBPDQCTA0BBwEBHodomiSPZZA4knUDlXyFa4htgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="9526185" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 13 Nov 2012 08:26:19 +0000 Received: from [10.54.86.33] (dhcp-10-54-86-33.cisco.com [10.54.86.33]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAD8QIet020778; Tue, 13 Nov 2012 08:26:18 GMT Message-ID: <50A2042A.90805@cisco.com> Date: Tue, 13 Nov 2012 09:26:18 +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 WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo Subject: [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, 13 Nov 2012 08:26:30 -0000 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 gonzalo.camarillo@ericsson.com Tue Nov 13 00:29:46 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 A62D621F8449 for ; Tue, 13 Nov 2012 00:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.967 X-Spam-Level: X-Spam-Status: No, score=-105.967 tagged_above=-999 required=5 tests=[AWL=0.282, 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 lRFZDwlxatiF for ; Tue, 13 Nov 2012 00:29:46 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BA47521F841F for ; Tue, 13 Nov 2012 00:29:40 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-4d-50a204f3beca Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 3C.BF.06323.3F402A05; Tue, 13 Nov 2012 09:29:39 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 09:29:39 +0100 Message-ID: <50A204F3.8000809@ericsson.com> Date: Tue, 13 Nov 2012 10:29:39 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Kristensen References: <50A20368.9050408@cisco.com> In-Reply-To: <50A20368.9050408@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje5nlkUBBo9OW1n8W3eUyeLKkV9s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfG3Y477AVX2CvWNp9na2D8xdrFyMkhIWAi MenuDShbTOLCvfVsXYxcHEICJxkl5l85zgjhrGaUaD/6hKWLkYODV0BbYtopJpAGFgFVif79 K9hAbDYBC4ktt+6zgNiiAlEShzYeZAexeQUEJU7OfAIWFxFQl+jb+x0sziygKHGlqxcsLgw0 5+6ff2C2kICGRPPpr8wgNqeApsTl369YII6TlHj7/hUzRK+exJSrLYwQtrzE9rdzmCF6tSWW P2thmcAoNAvJ6llIWmYhaVnAyLyKkT03MTMnvdx8EyMwVA9u+W2wg3HTfbFDjNIcLErivHqq +/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MK7edPdYyAQZcb8zTl0zFp4PrPAq8yrrUPtx fYHIn7lLOTZ8Ffk4dfmJvTPfLJz5ZBdf1M/F4v8dO+c+VDpyLG7frdNVKVoTXzCrNW6cs89V Nb/zVUWvuXn/sQsHblpsMna+fSOtufpDcIL4pnkyWu8ndur+e9R8/3+HnrW/tNG0TRXtan6b dj9WYinOSDTUYi4qTgQAE1qBxiMCAAA= Cc: BFCPbis WG 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, 13 Nov 2012 08:29:46 -0000 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 From gonzalo.camarillo@ericsson.com Tue Nov 13 00:31:03 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 D6A0A21F8444 for ; Tue, 13 Nov 2012 00:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.985 X-Spam-Level: X-Spam-Status: No, score=-105.985 tagged_above=-999 required=5 tests=[AWL=0.264, 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 W1lQenTMQ7I9 for ; Tue, 13 Nov 2012 00:31:03 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E324F21F8469 for ; Tue, 13 Nov 2012 00:30:57 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-66-50a205409d05 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6B.EF.06323.04502A05; Tue, 13 Nov 2012 09:30:56 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 09:30:56 +0100 Message-ID: <50A2053F.1050708@ericsson.com> Date: Tue, 13 Nov 2012 10:30:55 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Kristensen References: <50A2042A.90805@cisco.com> In-Reply-To: <50A2042A.90805@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvja4D66IAg4Zzqhb/1h1lsrhy5Beb A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWxduYT9oJ1bBV7P71ibWD8wtLFyMkhIWAi sX75AmYIW0ziwr31bF2MXBxCAicZJV5/+8UO4axmlLg85x0bSBWvgLbE5CevwLpZBFQlpu/9 wAhiswlYSGy5dR8sLioQJXFo40F2iHpBiZMzn4DFRQTUJfr2fgeLMwsoSlzp6gWLCwvYS9yZ 0gwWFxJQk7jS0MEEYnMC1b/tX8gGcZ2kxNv3r5ghevUkplxtYYSw5SW2v53DDNGrLbH8WQvL BEahWUhWz0LSMgtJywJG5lWM7LmJmTnp5eabGIHBenDLb4MdjJvuix1ilOZgURLn1VPd7y8k kJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcSnf7Tjjo7E/zWbMC9tU9jdsUo+ZW+XOjxGec7X2 uZkLvdu8TDU8dMc7Q2tHv/diMwu+OgTLF6xYnWHmFfW+ptmU83uk9plWMWkT4SPFS5cbJS/p 0VN9VT/fpWjvwYDw75YaGsmRXjybHjpNbH3C9+BMXKCw0ZyPP5S+/j5zgl94B0eZYNosJZbi jERDLeai4kQA2sVMAiQCAAA= Cc: BFCPbis WG 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, 13 Nov 2012 08:31:04 -0000 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 Tue Nov 13 00:32: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 B8D5921F844B for ; Tue, 13 Nov 2012 00:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 aZqB+x-24c9J for ; Tue, 13 Nov 2012 00:32: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 05D7021F8444 for ; Tue, 13 Nov 2012 00:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1403; q=dns/txt; s=iport; t=1352795546; x=1354005146; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=GWDAi6CTCiR8b5Jwp7vsi9fLsvHkX4MzMpUw7ENAN+U=; b=YEQcwrGGmWUFsGQ4VE4tsidGk81VpxqbWo2tLEJhhS4cwP6zd5mziCLH txU9IJO1Pg0KSK8vx6x/5AkN4bw0hekeNJrDETvjRm/kBFP01UYu8P7V6 ShRjs9c80dV7FJFyVEkEBlNIULhac+67SUQAesfL0hMwT00xa+mds+MHn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADsFolCQ/khR/2dsb2JhbABEw3OBCII3ASVAATwWGAMCAQIBSw0BBwEBHodomiePZZA4knUDlXyFa4htgWuCcIFaBg X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="78188387" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 13 Nov 2012 08:32:24 +0000 Received: from [10.54.86.33] (dhcp-10-54-86-33.cisco.com [10.54.86.33]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAD8WOBO007856; Tue, 13 Nov 2012 08:32:24 GMT Message-ID: <50A20598.6040603@cisco.com> Date: Tue, 13 Nov 2012 09:32: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: "BFCPbis WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo Subject: [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: Tue, 13 Nov 2012 08:32:26 -0000 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 From tomkrist@cisco.com Tue Nov 13 00:43:50 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 6E5F921F8592 for ; Tue, 13 Nov 2012 00:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.028 X-Spam-Level: X-Spam-Status: No, score=-10.028 tagged_above=-999 required=5 tests=[AWL=0.571, 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 AMuxFljKJAaI for ; Tue, 13 Nov 2012 00:43:49 -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 766F221F858C for ; Tue, 13 Nov 2012 00:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2089; q=dns/txt; s=iport; t=1352796229; x=1354005829; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=zY/MC1sGLszaZQpAiThvWNDCaesvoPNV8lDbq7ec1fk=; b=KowxtKIJb8hR+m39M3xR1ZcoMppWHdUd9/QEE7bn9gpDmR7HrIgjv1TR IlAoxLXLlRMn6FkpzRD9kqcnCEqoOvtneFBvV+7qgKPPrkKs/a+lWURkZ RZ1hEQ8xiuOgsETdP4LvmGl6FgdpCuajKA8Jb1fADMC6jmCNILV7UfT4e I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoGAMcFolCQ/khN/2dsb2JhbABEwXUBgX2BCII3ASVAATwWGAMCAQIBSw0BBwEBHodomiiPZZA4knUDkkqDMoVriG2Ba4Jw X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="9526490" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 13 Nov 2012 08:43:48 +0000 Received: from [10.54.86.33] (dhcp-10-54-86-33.cisco.com [10.54.86.33]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAD8hm5D016636; Tue, 13 Nov 2012 08:43:48 GMT Message-ID: <50A20844.3070601@cisco.com> Date: Tue, 13 Nov 2012 09:43:48 +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 WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gonzalo Camarillo Subject: [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: Tue, 13 Nov 2012 08:43:50 -0000 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 From gonzalo.camarillo@ericsson.com Tue Nov 13 00:49:31 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 8B1EB21F84B2 for ; Tue, 13 Nov 2012 00:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106 X-Spam-Level: X-Spam-Status: No, score=-106 tagged_above=-999 required=5 tests=[AWL=0.249, 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 Z31YOCwSfZn6 for ; Tue, 13 Nov 2012 00:49:31 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 85EC821F8488 for ; Tue, 13 Nov 2012 00:49:29 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-2b-50a20996e474 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.B2.06323.69902A05; Tue, 13 Nov 2012 09:49:26 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 09:49:26 +0100 Message-ID: <50A20996.8010503@ericsson.com> Date: Tue, 13 Nov 2012 10:49:26 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Kristensen References: <50A20598.6040603@cisco.com> In-Reply-To: <50A20598.6040603@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rnca56IAg67rBhb/1h1lsrhy5Beb A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxtSu7YBt/xb7Nk5gaGJfxdDFyckgImEgc uL2TFcIWk7hwbz1bFyMXh5DASUaJZV/+MIMkhARWM0qc/6sBYvMKaEvMO3oKrIFFQFVi2atn 7CA2m4CFxJZb91lAbFGBKIlDGw+yQ9QLSpyc+QQsLiKgLtG39ztYnFlAUeJKVy9YXFjAW2L5 0l42iF0aEtMX/QabzymgKbHtZTsTxHGSEm/fv2KG6NWTmHK1hRHClpfY/nYO1J3aEsuftbBM YBSahWT1LCQts5C0LGBkXsXInpuYmZNebr6JERioB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYd2RtKDXzn6TzVXahz+mvQp9/+2uvC5IyOWPxLeM+ X9A0h5bkHffbORnXzFpcqRNYUtd5ec7L5sz1BX6zJkgdYN0bMvGs2qSb5lohH5Z4907pOR/M /EPr2beO9H+5Wnxe3J841a74f5X5KrJ7i8XZLJVLP/ylwkKWvLVX2nFphZrDOoncf6lRSizF GYmGWsxFxYkAMYewSSICAAA= Cc: BFCPbis WG 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: Tue, 13 Nov 2012 08:49:31 -0000 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 > From gonzalo.camarillo@ericsson.com Tue Nov 13 00:55: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 33C2021F85EB for ; Tue, 13 Nov 2012 00:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.014 X-Spam-Level: X-Spam-Status: No, score=-106.014 tagged_above=-999 required=5 tests=[AWL=0.235, 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 ekvhO0wl9Rnc for ; Tue, 13 Nov 2012 00:55:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B087321F8592 for ; Tue, 13 Nov 2012 00:55:26 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-c4-50a20afb569c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7F.0F.26143.BFA02A05; Tue, 13 Nov 2012 09:55:23 +0100 (CET) Received: from [131.160.36.86] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 13 Nov 2012 09:55:23 +0100 Message-ID: <50A20AFA.6050001@ericsson.com> Date: Tue, 13 Nov 2012 10:55:22 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Kristensen References: <50A20844.3070601@cisco.com> In-Reply-To: <50A20844.3070601@cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvje5vrkUBBrN/aVj8W3eUyeLKkV9s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGu3cLGQu6RComrD7I3MD4kb+LkZNDQsBE or/3NQuELSZx4d56ti5GLg4hgZOMEuveP2KGcFYDOWd6mUCqeAW0JW7/fMsOYrMIqEpsmPeR FcRmE7CQ2HLrPtgkUYEoiUMbD7JD1AtKnJz5BCwuIqAu0bf3O1icWUBR4kpXL1hcWMBZ4vmh V2DzhQQ0JJ5sn8oIYnMKaEpsf7wQ6jpJibfvXzFD9OpJTLnawghhy0tsfzuHGaJXW2L5sxaW CYxCs5CsnoWkZRaSlgWMzKsY2XMTM3PSy402MQKD9eCW36o7GO+cEznEKM3BoiTOa711j7+Q QHpiSWp2ampBalF8UWlOavEhRiYOTqkGRiZ3XVkxy40shXq//sh95NqYNP9T76st/xsDj969 /dZ6usLGKd2Hbd7GFjzxedotzO20etPXbz/3XGL4UXzo4KNVkb1+PJvt6mP+3i7LuLm7qoAj 88SKczM2bv3c0hIs9W7NyWchwrfq7id/28Z+7oN/ffSJvufepc0Mi02kbmw5tS9faJ0vt4kS S3FGoqEWc1FxIgDBzRRnJAIAAA== Cc: BFCPbis WG 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: Tue, 13 Nov 2012 08:55:29 -0000 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 From tomkrist@cisco.com Tue Nov 13 00:55: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 DCE5C21F85EB for ; Tue, 13 Nov 2012 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 tSv6MxDn4e3F for ; Tue, 13 Nov 2012 00:55:41 -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 36D8321F865D for ; Tue, 13 Nov 2012 00:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1198; q=dns/txt; s=iport; t=1352796938; x=1354006538; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mQ3s8TlpUhK+Zff/mYEOfK6rPx0TbQLeBhGN7GVjoMw=; b=daE8ObLMK4tcdy9TMrTzjY/WGLhsltQ+m2QnQwas6YHWbxYBXdMSayuK 8Esi8aiCk6jdjzMVngy3W4IVEjy8HO3ohKxsBJjDcfvfzpCF+BygZ1kG1 muZGYaMEzPstec2vq6wKrk6KYAV6v9T25LP9zti9CA30aPFvofDNo0lgc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAKAIolCQ/khM/2dsb2JhbABEwC6DRYEIgh4BAQEEEgElQAEQCxgJFg8JAwIBAgFFBg0BBwEBHodomiuPZZA4jCGGVAOVfIVriG2Ba4JwgWM X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="78188776" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Nov 2012 08:55:35 +0000 Received: from [10.54.86.33] (dhcp-10-54-86-33.cisco.com [10.54.86.33]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAD8tZ7r029167; Tue, 13 Nov 2012 08:55:35 GMT Message-ID: <50A20B06.9080902@cisco.com> Date: Tue, 13 Nov 2012 09:55:34 +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> In-Reply-To: <50A204F3.8000809@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BFCPbis WG 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, 13 Nov 2012 08:55:42 -0000 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 >> > From eckelcu@cisco.com Thu Nov 15 12:10: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 64A6221F8694 for ; Thu, 15 Nov 2012 12:10:03 -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 g0AY-8yvALwW for ; Thu, 15 Nov 2012 12:10:02 -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 CC27A21F8477 for ; Thu, 15 Nov 2012 12:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3590; q=dns/txt; s=iport; t=1353010202; x=1354219802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P7XuatdaMtKLWLo8Br8FD5iBRlukemoG+D6B7iLafb8=; b=ISACQrxn0QxfvzT1rPcDlDlhlwc+yfi907XPBAZPXrWZY8sBTbDIrt/g r8gaal38t4vT5cCArvfArzvO5Y0YWl72t2SlXlsYIVIeXqtETrQSFTp+I 1b5lVsx+RUviK3OHWzIZ20U4NdqzDu+kqnnhQU5/flR/HYkReLdt4O4gI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMRLpVCtJV2a/2dsb2JhbABEwkGBCIIeAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBqHagELnQWgAwSMMYVLYQOkVIFrgm+BWwY4 X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="139918168" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 15 Nov 2012 20:10:01 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFKA1gN020189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 20:10:01 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 14:10:01 -0600 From: "Charles Eckel (eckelcu)" To: Gonzalo Camarillo , "Tom Kristensen (tomkrist)" Thread-Topic: [bfcpbis] TBD issue #3: MAY discard malformed message, not sending Error Thread-Index: AQHNwXltFHq2uSWN2065R5OmloCSOpfn2TQAgAN5NEA= Date: Thu, 15 Nov 2012 20:10:00 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882812C776@xmb-aln-x08.cisco.com> References: <50A20598.6040603@cisco.com> <50A20996.8010503@ericsson.com> In-Reply-To: <50A20996.8010503@ericsson.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-19368.001 x-tm-as-result: No--60.574900-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 WG 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, 15 Nov 2012 20:10:09 -0000 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 n= ot 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 repl= ace it with something warning against retransmitting the original request, = but I don't think that is necessary and it might merely confuse matters mor= e. 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 >=20 > Hi, >=20 > 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. >=20 > Cheers, >=20 > Gonzalo >=20 > 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 secon= d > > sentence, no real functional change. Or we could clarify the sentence b= y > > adding that in this case no Error message is sent. > > > > -- Tom > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From gonzalo.camarillo@ericsson.com Fri Nov 16 09:41: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 B715C21F899A for ; Fri, 16 Nov 2012 09:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.038 X-Spam-Level: X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=0.211, 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 9s0UviEgwpTH for ; Fri, 16 Nov 2012 09:41:09 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 52C5E21F84D8 for ; Fri, 16 Nov 2012 09:41:09 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-d0-50a67ab4a2d1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.EB.26143.4BA76A05; Fri, 16 Nov 2012 18:41:08 +0100 (CET) Received: from [131.160.126.232] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 16 Nov 2012 18:41:07 +0100 Message-ID: <50A67AB3.3070405@ericsson.com> Date: Fri, 16 Nov 2012 19:41:07 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <50A20598.6040603@cisco.com> <50A20996.8010503@ericsson.com> <92B7E61ADAC1BB4F941F943788C0882812C776@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882812C776@xmb-aln-x08.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvje6WqmUBBnt+CFv8W3eUyWLTrC9s FleO/GJzYPaY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKmL2hgKWiRr5g07QBLA+NPiS5G Tg4JAROJ1Q9OsEDYYhIX7q1n62Lk4hASOMkosfTNZyhnLaNE45v/jCBVvALaEr0LpjKD2CwC qhLXr68Bs9kELCS23LoPNklUIEri0MaD7BD1ghInZz4Bi4sIGEosmrQOzGYWCJNY8X4XE4gt LBAu8fbCMrA5QgLtjBIfj/iB2JwC3hK3Ni1lhbhOUuLt+1fMEL16ElOutjBC2PIS29/OgerV llj+rIVlAqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cqNNjMCwPbjlt+oOxjvnRA4xSnOwKInz Wm/d4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsduz/u/pa+uqNE881DlVsHBDa93hQpGe 2z8OVdTOy5y8Y9KWDSl9BUfsL8bpS07Ib/+zp5+FedcpIT0u8wU8zl7CG/lS9yUIdn/9LriN 8fC+/1Kyd2V3b2+4P23aQ4GTXc+/rzjZ0qNhmXEl4U1cy9+a59rqpzg3z7po9bPdvPXwmcaa oxq7+JVYijMSDbWYi4oTAQBWC3gpAgAA Cc: BFCPbis WG , "Tom Kristensen \(tomkrist\)" 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: Fri, 16 Nov 2012 17:41:10 -0000 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 christer.holmberg@ericsson.com Wed Nov 28 00:55: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 B47DF21F84D5 for ; Wed, 28 Nov 2012 00:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 7FYKCu323SfP for ; Wed, 28 Nov 2012 00:55:34 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6064321F846B for ; Wed, 28 Nov 2012 00:55:34 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-fd-50b5d185d218 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.37.11564.581D5B05; Wed, 28 Nov 2012 09:55:33 +0100 (CET) Received: from ESESSHC015.ericsson.se (153.88.183.63) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 09:55:32 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 09:55:32 +0100 From: Christer Holmberg To: "bfcpbis@ietf.org" Thread-Topic: BFCP-UDP and DTLS Thread-Index: Ac3NRJglVoRPliakSkmUjyl/HukRqA== Date: Wed, 28 Nov 2012 08:55:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B047F4F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B047F4FESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW7rxa0BBoc+i1n8W3eUyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYePRRTsk6vonzqTtYFxn1QXIweHhICJxPNfFV2MnECmmMSF e+vZuhi5OIQETjJKbD5+B8rZySjxd0UbO4SzhFHi8v6jLCDdbAIWEt3/tEG6RQQ0JTZvv8sE EhYWkJJY3Z0EEZaX2DsXpBrE1pNYNGMZG4jNIqAq0fuzgR3E5hXwlri25h8jiM0IdMT3U2uY QGxmAXGJW0/mM0EcJyCxZM95ZghbVOLl43+sELaixM6z7cwQ9fkS297sYoaYKShxcuYTsL1C AtoSLYsnsE9gFJmFZOwsJC2zkLRAxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZ OenlhpsYgTFycMtv3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNT qoHRgjPRuUbBLWFz0xp9mz0z//bGebK8fPX44I62qb8uHJ3rv3BOWMDv8E17rju+e+EobPxW xD7v8YX1Sy2WRexYuuXiAmeThmu+Vr8cIvirEnmnfekoff3D/ZN78nWtyX2Lt1/8Z9myXH9T rKlp3M6ghK9bMr80bCmSs7G943jjfW7moSvRl05fVmIpzkg01GIuKk4EAESjHspfAgAA Subject: [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, 28 Nov 2012 08:55:35 -0000 --_000_7594FB04B1934943A5C02806D1A2204B047F4FESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I haven't really been following the BFCPbis work, so I appologize if the fo= llowing has been discussed. draft-ietf-bfcpbis-rfc4583bis-03 refers to section 5 of RFC 5763 for the SD= P 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 passiv= e UA sends a STUN request, in order to open the NAT pin hole, which means b= oth 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 --_000_7594FB04B1934943A5C02806D1A2204B047F4FESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I haven’t really been following the BFCPbis wo= rk, 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 s= ection 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. Ot= herwise it could cause problem, if both are active and end up acting as TLS= clients.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B047F4FESESSMB209ericsso_-- From tomkrist@cisco.com Wed Nov 28 06:35: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 5F4E821F8462 for ; Wed, 28 Nov 2012 06:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 1gmbAhBt7olq for ; Wed, 28 Nov 2012 06:35:52 -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 328EC21F84D2 for ; Wed, 28 Nov 2012 06:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6000; q=dns/txt; s=iport; t=1354113352; x=1355322952; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=qWwjkbliN23UXCCt6qyV7iBrAqtvah3FMsxcLT1b88M=; b=i1AqwhK2L+n/5CEicAqpELOptza/CDW77+JK5y4B223dksXnwjtg1PEx YcMrehJ3Mc5/XiT20TyJLEivFeRp8hlIGJ3mgPGr6eVMUi569oyBwJjQm dCmaPC3nLR3dFDgd+GbmPfHWaigcZCANhbgirrmI5S7in8qzBw7/ydhxC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQGALEgtlCQ/khL/2dsb2JhbABFgkmJQLQMFnOCHgEBAQQBAQEqQQoRCxgJFg8JAwIBAgEVMBMGAgEBiAsMvnAEjD+EQQOST4MyhWuKWYJx X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="9988830" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 28 Nov 2012 14:35:51 +0000 Received: from [10.61.102.228] (dhcp-10-61-102-228.cisco.com [10.61.102.228]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qASEZo4w028396 for ; Wed, 28 Nov 2012 14:35:51 GMT Message-ID: <50B62146.2050707@cisco.com> Date: Wed, 28 Nov 2012 15:35: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: bfcpbis@ietf.org References: <7594FB04B1934943A5C02806D1A2204B047F4F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B047F4F@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------060207080001000900000201" 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, 28 Nov 2012 14:35:54 -0000 This is a multi-part message in MIME format. --------------060207080001000900000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 > --------------060207080001000900000201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 <xref target="RFC5389"/> Binding Indication for keep-alives, as described for ICE <xref target="RFC5245"/>."

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

--------------060207080001000900000201-- From eckelcu@cisco.com Wed Nov 28 13:49: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 46F4421F888D for ; Wed, 28 Nov 2012 13:49:29 -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 f98NFCmMKZ-m for ; Wed, 28 Nov 2012 13:49:22 -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 79F3321F85E2 for ; Wed, 28 Nov 2012 13:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2290; q=dns/txt; s=iport; t=1354139362; x=1355348962; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=flT4H4YLVaRi4ArG2sjLpVUGPT0gQSYbGaeoIWinq/g=; b=OUqW8aZr3+Y1AIvhPxTF+zlYMXV6aCLcR6X+lm6cM2MyagPsljmlE57q VVlspS64QC5GST7x/SW9xekamteDieGKmteBveysCrv1XUQx5E/xFkOz8 ZguuzyVoXbu5L2sqaCeXjHlCUjODyG/62ovFgRvl5NmVUcHkzSJmqB6mn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPeFtlCtJXG9/2dsb2JhbABFwCIWc4IeAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAEBBAESCIgIDL8XBIw/g2BhA5JPk3aCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147313785" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2012 21:49:22 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qASLnL3N010029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Nov 2012 21:49:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 15:49:21 -0600 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] BFCP-UDP and DTLS Thread-Index: Ac3NRJglVoRPliakSkmUjyl/HukRqAAY1vQAAAKB+qA= Date: Wed, 28 Nov 2012 21:49:21 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CC03E@xmb-aln-x08.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B047F4F@ESESSMB209.ericsson.se> <50B62146.2050707@cisco.com> In-Reply-To: <50B62146.2050707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.76.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 28 Nov 2012 21:49:29 -0000 (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 >=20 > Thanks Christer, >=20 > 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 rfc4582= bis > until now. >=20 > In rfc4582bis we say: "In order to facilitate the initial establishment o= f NAT > bindings, and to maintain those bindings once established, BFCP entities > using unreliable transport are RECOMMENDED to use STUN target=3D"RFC5389"/> Binding Indication for keep-alives, as described for= ICE > ." >=20 > 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? >=20 > -- Tom >=20 > On 11/28/2012 09:55 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >=20 >=20 > I haven't really been following the BFCPbis work, so I appologize if > the following has been discussed. >=20 >=20 >=20 > 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). >=20 >=20 >=20 > 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. >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis >=20 >=20