Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03

Tom Kristensen <> Tue, 30 October 2012 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 152E021F84B6 for <>; Tue, 30 Oct 2012 02:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ipk-JwF4klbY for <>; Tue, 30 Oct 2012 02:43:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EAE0421F84B9 for <>; Tue, 30 Oct 2012 02:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3413; q=dns/txt; s=iport; t=1351590207; x=1352799807; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IjnfYvQymaZxnE4eg0QsTfjZTjTwXkn2X7LNN68zf7E=; b=k64mJxEnfEXL4hLdH4G+H/6C4xUz63sKUWyhCoKelwPgg0Ba5o0whV9N 72mFOhJ7NGVPiglfF8BrbwVyYKJ1biBjTuy5BZrYL9Ypt/1aIZTV58UJF JqScQ27hmt7koYYzD73WH5lGMFGyDnFMDP48KFREvWwl2mvdBKhsRyo2M 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="9197870"
Received: from ([]) by with ESMTP; 30 Oct 2012 09:43:06 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id q9U9h6ca031445; Tue, 30 Oct 2012 09:43:06 GMT
Message-ID: <>
Date: Tue, 30 Oct 2012 10:43:05 +0100
From: Tom Kristensen <>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Gonzalo Camarillo <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2012 09:43:28 -0000

On 10/24/2012 04:27 PM, Gonzalo Camarillo wrote:
> Folks,
> Comments on draft-ietf-bfcpbis-rfc4583bis-03
> Section 3 includes a discussion about how to set the port field. That
> discussion is only relevant to TCP. The new draft needs to explain that
> and add a discussion about port handling in UDP.

Good catch. Reorganizing the text and adding this for UDP:

   "When UDP is used as transport, the port field contains the
    port to which the remote endpoint will direct BFCP messages
    regardless of the value of the 'setup' attribute."

> Also, the document needs to discuss what is the equivalent of
> establishing a TCP connection (i.e., it allows endpoints to start
> exchanging BFCP messages) in UDP.

The term "BFCP connection" is used in rfc4582bis/rfc4583bis independent 
of underlying transport.

  (For rfc4582bis: I propose we keep this common term regardless of 
underlying transport and change the three occurrences of "BFCP 
association" in Section 6.2 and 8.31 to "BFCP connection" as well.)

However, we do indeed need to specify the counterpart of Section 7 "TCP 
Connection Management" for UDP as transport. Will add a sentence or two, 
since using UDP as transport is quite straight forward. Will also need 
to add a UDP description to Section 8, i.e. mandate using the 'setup' 
attribute when DTLS is used.

Added to start of Section 7, now renamed to "BFCP Connection Management":
   "BFCP connections may use TCP or UDP as underlying transport. BFCP
    entities exchanging BFCP messages over UDP will direct the BFCP
    messages to the peer side connection address and port provided in
    the SDP 'm' line. TCP connection management is more complicated
    and is described below."
And the subsection named "TCP Connection Management" follows.

Added this sentence at the end of Section 8:
   "Endpoints that use the offer/answer model to establish a DTLS 
association MUST
    support the 'setup' attribute, as defined in RFC 4145. When
    DTLS is used with UDP, the 'setup' attribute indicates which of the 
    (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