Re: [bfcpbis] Mirja Kühlewind's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Christer,

thanks for you reply. Please so the right thing in addressing any points in the draft as needed. As few minor additional comments below.

> Am 24.10.2018 um 18:05 schrieb Christer Holmberg <[e-mail]>:
> 
> Hi Mirja,
> 
> Thank You for the review! Please see inline.
> 
>>   1) Section 4:
>>   „This is one of the options when ICE is used (Section 9).“
>>   Maybe you can make this sentence slightly more specific because that was one
>>   thing I was wondering about all the time until I read 9 (why TCP/DTLS/BFCP is
>>   needed), e.g. „This is one of the options where when ICE is used only one DTLS
>>   session is established but there are candidate pairs for UDP and TCP (Section
>>   9).“
>> 
>>   Also why is 'UDP/TLS/BFCP' not called 'UDP/DTLS/BFCP‘?
> 
> It's mainly for backward compatibility reasons (this draft has been around for many years, and have been implemented and deployed), because for some reasons people thought 'UDP/TLS/BFCP' was correct at some point. 
> 
> I guess someone else may have more information, because I don't remember the details of the discussions that took place at the time.

Okay. I guess that could be noted in the draft but it doesn’t have to.

> 
> ---
> 
>>   2) Section 6 provides multiplexing considerations for bfcpver, however all
>>   other attributes also have a Mux Category: TBD. When will these be defined?
> 
> Whenever someone defines how to multiplex BFCP streams with other streams. 
> 
> The WG decided not to do that within 4583bis, because nobody saw any need for that.

It at least looks confusing to have a TBD in the doc. But I guess you have to further discuss this with Ben.

> 
> ---
> 
>>   3) Section 7.1: Sorry for the lack of understanding here, but why does the
>>   reconnecting endpoint need to send a new offer at all, instead of just
>>   re-opening a new TCP connection with the same parameters as before?
> 
> That is how it has been defined for TCP negotiated using SDP offer/answer, in RFC 4145: you always signal when you want to establish a connection (even if it is re-establishing a previous connection).

Okay..

> 
> ---
> 
>>   4) Section 8:
>>   „If the TCP connection is lost, the active endpoint is responsible for re-
>>      establishing the TCP connection.“
>>   What does active mean here?
> 
> The active endpoint is responsible for initiating the TCP connection. It is defined in RFC 4145, and we should add a reference.


Yes, thanks!

> 
>>   Also in section 10.2 and 10.3 'active' is used a well but with quotes, however,  it is never really defined.
> 
> See above regarding the definition/reference.
> 
> The quotes should be removed, because the text is not talking about a value.
> 
> ---
> 
>>   5) Section 8:
>>   „Unless a new TLS session is
>>      negotiated, subsequent SDP offers and answers will not impact the
>>      previously negotiated TLS roles.“
>>   Quick question: Does that mean that when the TCP connection breaks and is
>>   re-opened, there is no new TLS handshake?
> 
> When the TLS connection is established, the answerer acts as TLS server. However, in subsequent offer/answer transactions both endpoint can act as answerer, and the text simply clarifies that the TLS roles don't change just because the offerer/answerer roles change.
> 
> The text does not change the TLS procedures, so if a new handshake is needed then it will be sent.
> 
> ---
> 
>>   6) Section 10.4:
>>   „if the offerer
>>         does not want to re-establish an existing TCP connection, the
>>         offerer MUST associate an SDP 'connection' attribute with a value
>>         of "existing", with the 'm' line;“
>>   Just double-checking: Is this correct that If the offerer does NOT what to use
>>   the existing TCP connection, it adds the „existing“ attribute…?
> 
> No, the other way around: if the offerer DOES want to use the existing TCP connection, it adds 'existing‘.

Okay, that makes more sense :-). I think the use of the word "re-establish" is really confusing here. What about

„if the offerer wants to re-use an existing TCP connection…“?

Mirja


> 
> Regards,
> 
> Christer
> 
> 
>