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

Comments inline [cue]

From: Roman Shpount <rshpount@turbobridge.com>
Date: Tuesday, July 18, 2017 at 4:37 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>, Alan Ford <alan.ford@gmail.com>, Tom Kristensen <tomkrist@cisco.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: 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

[cue] Seems a worthwhile clarification to me. Christer voiced agreement in another thread as well.

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.

[cue] Seems a worthwhile clarification to me. Christer voiced agreement in another thread as well.

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.

[cue] This is a carryover from RFC 4583. I agree that it seems unnecessary. I have no objection to removing. Doing so seems to align with Christer’s suggestion as well to rely more on a reference to https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-26.txt

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

[cue] We have gone in circles around this a few times in the past. At this point, I think it is best to remove and refer to https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-26.txt as Christer suggests.

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.

[cue] Sounds good to me. I will leave it to Tom to ask for help if necessary.

Cheers,
Charles

Regards,

_____________
Roman Shpount

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