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

[Tom Kristensen <[e-mail]>]

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
>>
>>      
>