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

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 24 Oct 2018 07:51:29 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-bfcpbis-rfc4583bis-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

2) Section 6 provides multiplexing considerations for bfcpver, however all
other attributes also have a Mux Category: TBD. When will these be defined?

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?

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?

Also in section 10.2 and 10.3 'active' is used a well but with quotes, however,
it is never really defined.

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?

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Oct 2018 16:05:31 +0000

Hi Mirja,

Thank You for the review! Please see inline.
   
>    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.
  
---

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

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

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

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

---

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

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

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Oct 2018 14:31:19 -0400

Hi Mirja,

On Wed, Oct 24, 2018 at 12:05 PM Christer Holmberg <
[email-masked]> wrote:

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

Christer is correct here: I have proposed to use 'UDP/DTLS/BFCP‘ but I was
told there are existing implementations which use 'UDP/TLS/BFCP‘ and this
cannot be changed for backwards compatibility reasons.

Regards,
______________
Roman Shpount

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 25 Oct 2018 12:24:54 +0200

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 <[email-masked]>:
> 
> Hi Mirja,
> 

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

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

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

Okay..

> The active endpoint is responsible for initiating the TCP connection. It is defined in RFC 4145, and we should add a reference.

Yes, thanks!

> 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