Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

From: Tom Kristensen <[email-masked]>
Date: Mon, 25 Sep 2017 18:28:52 +0200

Answers inline.

On 19 July 2017 at 01:37, Roman Shpount <[email-masked]> wrote:

> Hi All,
>
> I have reviewed the document and have the following comments:
>
> Section 8 BFCP Connection Management:
>
> It specifies that BFCP can use TCP or UDP as underlying transport. It does
> not specify what happens when ICE, TCP/DTLS/BFCP, TCP/TLS/BFCP, or
> UDP/TLS/BFCP are used. I suggest to explicitly specify that ICE,
> TCP/DTLS/BFCP, and UDP/TLS/BFCP follow the same procedures for connection
> management as UDP/BFCP. TCP/TLS/BFCP follows the same procedures as TCP/BFCP
>

TK: :) Yes, stating just that for a clear definition of behaviour to use
and expect.

> Section 9 Authentication:
>
> Not sure why we are talking about SIP here. I think we should restate
>
> When SDP is used to perform an offer/answer exchange, the initial mutual
> authentication takes place at the SIP level. Additionally, SIP uses S/MIME
> [6] to provide an integrity-protected channel with optional confidentiality
> for the offer/answer exchange.
>
> as
>
> When SDP is used to perform an offer/answer exchange, the initial mutual
> authentication SHOULD take place at the signaling level. Additionally,
> signaling can use S/MIME [6] to provide an integrity-protected channel with
> optional confidentiality for the offer/answer exchange.
>

 TK: :) Yes, we may very well generalize from stating SIP to use the term
signaling (of some sort).

> This section specifies that "This implies that unless a 'fingerprint'
> attribute is included in the session description, the certificate provided
> at the TLS-/DTLS-level MUST either be directly signed by one of the other
> party's trust anchors or be validated using a certification path that
> terminates at one of the other party's trust anchors [5]". I thought
> "fingerprint" attribute are required and certificate signature by trust
> anchor is irrelevant.
>
> Not sure what "When using UDP, the procedure above was preferred since it
> adheres to [16] as used for DTLS-SRTP" means, especially since [16} is not
> specific to SRTP-DTLS, but specifies generic rules for all DTLS based
> protocols. The whole logic is circular since it proposes to follow
> procedures from [16] since they are compliant with procedures from [16].
>

TK: I'm currently trying to remember the background for this text, it was
altered and added in one of the many rounds earlier on. I agree that this
is not clear and a bit confusing.

> Section 10. ICE Considerations
>
> Please synchronize text with text in https://tools.ietf.org/html/
> draft-ietf-mmusic-sctp-sdp-26#section-12.2 . This section was updated
> during WGLC for draft-ietf-mmusic-sctp-sdp, so it would make sense to
> synchronize those changes here. Let me know if you need help with this.
>

TK: I'll draft a sketch of this.

>
> Regards,
>
> _____________
> Roman Shpount
>
> On Mon, Jul 17, 2017 at 4:10 AM, Charles Eckel (eckelcu) <
> [email-masked]> wrote:
>
>> (As WG co-chair)
>>
>> This is a reminder that WGLC ends tomorrow. I realize the time to review
>> overlaps with IETF prep and meeting times. If you require more time to
>> review the draft, please let me know. Otherwise, please share your review
>> comments by the end of tomorrow.
>>
>> Thanks,
>> Charles
>>
>> -----Original Message-----
>> From: bfcpbis <[email-masked]> on behalf of Charles Eckel <
>> [email-masked]>
>> Date: Wednesday, July 5, 2017 at 5:59 PM
>> To: "[email-masked]" <[email-masked]>
>> Subject: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis
>>
>>     (As WG co-chair)
>>
>>     This is to announce an additional working group last call for
>> draft-ietf-bfcpbis-rfc4583bis, "Session Description Protocol (SDP) Format
>> for Binary Floor Control Protocol (BFCP) Streams".
>>     http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/
>>
>>     This is intended as a Standards Track RFC, obsoleting RFC 4583.
>>     Please respond to the list by July 18th (i.e. 2 weeks) with any
>> comments.
>>
>>     We had a working group last call previous, but a significant amount
>> of time and some substantial changes and additions have occurred to justify
>> another review of the draft in its entirely. It is helpful to attempt to
>> categorize your comment (e.g. technical issue vs. editorial), and also to
>> provide any replacement text you feel is necessary.
>>     If you review the document and have no comments, please tell the
>> chairs that you have reviewed it. This is always useful information in
>> assessing the degree of WG review and consensus behind the document.
>>     Note, we have not scheduled a working group session for IETF 99 in
>> Prague. This WGLC will close during IETF 99. If helpful, we can arrange a
>> side meeting to discuss any significant issues, or with any luck, gather at
>> a bar to celebrate the draft being ready to advance to the next step toward
>> RFC.
>>
>>     Cheers,
>>     Charles
>>
>>
>>     _______________________________________________
>>     bfcpbis mailing list
>>     [email-masked]
>>     https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>>
>>
>
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>

-- 
# http://folk.uio.no/tomkri/ | +47 9516 1107 (m)
## http://facebook.com/tomkri/ | xmpp:[email-masked]
### "Å leve er å ta stilling. Jeg hater likegyldige mennesker.", A. Gramsci

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Sep 2017 20:30:46 +0000

Please see inline.

From: Tom Kristensen <[email-masked]>
Date: Monday, September 25, 2017 at 11:28 AM
To: Roman Shpount <[email-masked]>
Cc: Charles Eckel <[email-masked]>, Tom Kristensen <[email-masked]>, Alan Ford <[email-masked]>, "[email-masked]" <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

Answers inline.

On 19 July 2017 at 01:37, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

It specifies that BFCP can use TCP or UDP as underlying transport. It does not specify what happens when ICE, TCP/DTLS/BFCP, TCP/TLS/BFCP, or UDP/TLS/BFCP are used. I suggest to explicitly specify that ICE, TCP/DTLS/BFCP, and UDP/TLS/BFCP follow the same procedures for connection management as UDP/BFCP. TCP/TLS/BFCP follows the same procedures as TCP/BFCP

TK: :) Yes, stating just that for a clear definition of behaviour to use and expect.

When SDP is used to perform an offer/answer exchange, the initial mutual authentication takes place at the SIP level. Additionally, SIP uses S/MIME [6] to provide an integrity-protected channel with optional confidentiality for the offer/answer exchange.

as

When SDP is used to perform an offer/answer exchange, the initial mutual authentication SHOULD take place at the signaling level. Additionally, signaling can use S/MIME [6] to provide an integrity-protected channel with optional confidentiality for the offer/answer exchange.

 TK: :) Yes, we may very well generalize from stating SIP to use the term signaling (of some sort).

This section specifies that "This implies that unless a 'fingerprint' attribute is included in the session description, the certificate provided at the TLS-/DTLS-level MUST either be directly signed by one of the other party's trust anchors or be validated using a certification path that terminates at one of the other party's trust anchors [5]". I thought "fingerprint" attribute are required and certificate signature by trust anchor is irrelevant.

Not sure what "When using UDP, the procedure above was preferred since it adheres to [16] as used for DTLS-SRTP" means, especially since [16} is not specific to SRTP-DTLS, but specifies generic rules for all DTLS based protocols. The whole logic is circular since it proposes to follow procedures from [16] since they are compliant with procedures from [16].

TK: I'm currently trying to remember the background for this text, it was altered and added in one of the many rounds earlier on. I agree that this is not clear and a bit confusing.
[cue] After consulting the archives, it seems this was introduced in version -04 of the draft as a result of an issue raised by Gonzalo.
https://mailarchive.ietf.org/arch/msg/bfcpbis/emDvYolUyI4VjEiVuBqNoWMgz40/?qid=0e356a8b7a948f87669c6d992f6214db

Cheers,
Charles

Please synchronize text with text in https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2 . This section was updated during WGLC for draft-ietf-mmusic-sctp-sdp, so it would make sense to synchronize those changes here. Let me know if you need help with this.

Regards,

_____________
Roman Shpount

On Mon, Jul 17, 2017 at 4:10 AM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
(As WG co-chair)

This is a reminder that WGLC ends tomorrow. I realize the time to review overlaps with IETF prep and meeting times. If you require more time to review the draft, please let me know. Otherwise, please share your review comments by the end of tomorrow.

Thanks,
Charles

-----Original Message-----
From: bfcpbis <[email-masked]<mailto:[email-masked]>> on behalf of Charles Eckel <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 5, 2017 at 5:59 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

    (As WG co-chair)

    This is to announce an additional working group last call for draft-ietf-bfcpbis-rfc4583bis, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams".
    http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/

    This is intended as a Standards Track RFC, obsoleting RFC 4583.
    Please respond to the list by July 18th (i.e. 2 weeks) with any comments.

    We had a working group last call previous, but a significant amount of time and some substantial changes and additions have occurred to justify another review of the draft in its entirely. It is helpful to attempt to categorize your comment (e.g. technical issue vs. editorial), and also to provide any replacement text you feel is necessary.
    If you review the document and have no comments, please tell the chairs that you have reviewed it. This is always useful information in assessing the degree of WG review and consensus behind the document.
    Note, we have not scheduled a working group session for IETF 99 in Prague. This WGLC will close during IETF 99. If helpful, we can arrange a side meeting to discuss any significant issues, or with any luck, gather at a bar to celebrate the draft being ready to advance to the next step toward RFC.

    Cheers,
    Charles

    _______________________________________________
    bfcpbis mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/bfcpbis

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

--
# http://folk.uio.no/tomkri/ | +47 9516 1107 (m)
## http://facebook.com/tomkri/ | xmpp:[email-masked]<mailto:[email-masked]>
### "Å leve er å ta stilling. Jeg hater likegyldige mennesker.", A. Gramsci

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Sep 2017 16:45:27 -0400

On Mon, Sep 25, 2017 at 4:30 PM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> [cue] After consulting the archives, it seems this was introduced in
> version -04 of the draft as a result of an issue raised by Gonzalo.
>
> https://mailarchive.ietf.org/arch/msg/bfcpbis/
> emDvYolUyI4VjEiVuBqNoWMgz40/?qid=0e356a8b7a948f87669c6d992f6214db
>
>
>

The current text read like this "When DTLS is used with UDP, the
requirements specified in Section 5 of [16] MUST be followed". In
the following paragraph this is explained saying "When using UDP, the
procedure above was preferred since it adheres to [16] as used for
DTLS-SRTP, it does not overload offer/answer semantics, and it works for
offerless INVITE in scenarios with B2BUAs". I am not sure why this
explanation is needed, since it essentially says that procedure from
DTLS-SDP draft is used since it is compatible with procedure from DTLS-SDP
draft.

I think the second sentence can be rewritten to say: "When using UDP,
procedure defined in [16] was selected in order to be compatible with other
DTLS based protocol implementations, such as DTLS-SRTP. Furthermore,
procedure defined in [16] does not overload offer/answer semantics and
works for offerless SIP INVITE in scenarios with B2BUAs.

Regards.
_____________
Roman Shpount

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Sep 2017 20:55:39 +0000

From: Roman Shpount <[email-masked]>
Date: Monday, September 25, 2017 at 3:45 PM
To: Charles Eckel <[email-masked]>
Cc: Tom Kristensen <[email-masked]>, Tom Kristensen <[email-masked]>, Alan Ford <[email-masked]>, "[email-masked]" <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

On Mon, Sep 25, 2017 at 4:30 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
This section specifies that "This implies that unless a 'fingerprint' attribute is included in the session description, the certificate provided at the TLS-/DTLS-level MUST either be directly signed by one of the other party's trust anchors or be validated using a certification path that terminates at one of the other party's trust anchors [5]". I thought "fingerprint" attribute are required and certificate signature by trust anchor is irrelevant.

The current text read like this "When DTLS is used with UDP, the requirements specified in Section 5 of [16] MUST be followed". In the following paragraph this is explained saying "When using UDP, the procedure above was preferred since it adheres to [16] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs". I am not sure why this explanation is needed, since it essentially says that procedure from DTLS-SDP draft is used since it is compatible with procedure from DTLS-SDP draft.

I think the second sentence can be rewritten to say: "When using UDP, procedure defined in [16] was selected in order to be compatible with other DTLS based protocol implementations, such as DTLS-SRTP. Furthermore, procedure defined in [16] does not overload offer/answer semantics and works for offerless SIP INVITE in scenarios with B2BUAs.

Regards.
_____________
Roman Shpount

[cue] Looks good to me, though I suggest replacing “procedure” with “the procedure” both places it appears.

Cheers,
Charles