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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 17 Jul 2017 08:10:35 +0000

(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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 18 Jul 2017 19:37:27 -0400

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 19 Jul 2017 10:22:44 +0000

(As WG co-chair)

Thanks to those who provided reviews. We have decided to extend WGLC an additional week, through July 25, to provide folks tied up with other IETF matters time to complete their reviews.

Cheers,
Charles 

-----Original Message-----
From: bfcpbis <[email-masked]> on behalf of Charles Eckel <[email-masked]>
Date: Monday, July 17, 2017 at 10:10 AM
To: "[email-masked]" <[email-masked]>
Cc: Tom Kristensen <[email-masked]>, Roman Shpount <[email-masked]>, Alan Ford <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

    (As WG co-chair)

    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)

        
        
        Cheers,
        Charles

---

From: Alan Ford <[email-masked]>
Date: Sun, 23 Jul 2017 09:01:19 +0100

Hi Charles, all,

S3

- TCP transport indent is hard to parse. Suggest changing sentence to "Depending on the value of the 'setup' attribute (discussed in Section 8.1), the port field contains either the port to which the remote endpoint will direct BFCP messages, or in the case where the endpoint will initiate the connection towards the remote endpoint, should be set to a value of 9."

S4.1

- "The offerer includes this attribute to state all the roles it would be willing to perform”: add “once negotiation is complete”, for clarity.

- Here, plus S11.1 and S11.2, floorctrl is optional with inferred state of c-only for an offerer if it is not specified. I would advocate taking this opportunity to get rid of ambiguity and making the presence of floorctrl a MUST. Everyone does it already, but it’s one of the most problematic fields for interop as it is.

- Also, given in an answer only one role is present, but in an offer multiple can be present, can this be clearer in the ABNF? Is it possible to specify two ABNFs, one for the offer and one for the answer (the answer being without the *)? If that’s not possible, then could we at least emphasise this point near the start of the section (again coming at this from too many interop issues in this area).

S6

- “…identified by an SDP label attribute”. For consistency, please put ‘label’ in single quotes.

- Why is mstrm: optional in the ABNF, and optional in the paragraph beginning “The floorid attribute…”, yet is mandatory in the “Endpoints that use the offer/answer…” section? If there is a genuine reason for it to be optional please specify this, however I think it would be easier just to make it mandatory.

S11

Is is required to have a BUNDLE table like this now? (I presume given draft-ietf-mmusic-sdp-mux-attributes-16 is in MISSREF it’s too late to make the updates there). As Christer mentioned, It think this would be better in S7. OR, a separate subsection under S11 for “BUNDLE Considerations” that makes it clearer that this is an update to draft-ietf-mmusic-sdp-mux-attributes-16.

I assume we don’t want to go down the rabbit hole of defining BUNDLE for BFCP at this stage? :-)  Since if we did, it probably wouldn’t be too hard - you can demux on confid + userid.

S14.2

The “Allowed attribute values” here is inconsistent compared to others by being ABNF rather than just “A token” or “Tokens”. It’s also wrong - it implies only one value, not multiple as is the case. Suggest either fixing the ABNF or saying “one or more of…” or similar.

Best regards,
Alan

> On 19 Jul 2017, at 11:22, Charles Eckel (eckelcu) <[email-masked]> wrote:
> 
> (As WG co-chair)
>