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

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

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.

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

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.

Regards,

_____________
Roman Shpount

On Mon, Jul 17, 2017 at 4:10 AM, Charles Eckel (eckelcu) <eckelcu@cisco.com>
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 <bfcpbis-bounces@ietf.org> on behalf of Charles Eckel <
> eckelcu@cisco.com>
> Date: Wednesday, July 5, 2017 at 5:59 PM
> To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
> 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
>     bfcpbis@ietf.org
>     https://www.ietf.org/mailman/listinfo/bfcpbis
>
>
>