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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 3 Aug 2017 21:32:08 +0000

Comments inline [cue]

From: Roman Shpount <[email-masked]>
Date: Tuesday, July 18, 2017 at 4:37 PM
To: Charles Eckel <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>, Alan Ford <[email-masked]>, Tom Kristensen <[email-masked]>, Gonzalo Camarillo <[email-masked]>
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) <[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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 3 Aug 2017 22:19:12 +0000

Please see inline [cue]

From: Alan Ford <[email-masked]>
Date: Sunday, July 23, 2017 at 1:01 AM
To: Charles Eckel <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tom Kristensen <[email-masked]>, Roman Shpount <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

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

[cue] works for me

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.

[cue] good idea

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

[cue] Christer seemed to agree with you. I have been a proponent of not breaking backward compatibility with RFC 4583 unnecessarily. Anyone from the original RFC 4583 days able to shed some light on this?

S6

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

[cue] good idea

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

[cue] The floorid is defined such that one can specify a floorid yet not associate it with any media stream, thus the mstrm is optional. This is how it was defined in RFC 4583. I am not sure if anyone makes use of this, but that is how it was defined.

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.

[cue] agreed

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.

[cue] We decided previously to leave BUNDLE out of scope. I am happy to keep it that way.

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.

[cue] This is how it was defined in RFC 4583. As I understand it, “1*” means it requires at least one, so can have multiple.

Cheers,
Charles

Best regards,
Alan

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

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

   (As WG co-chair)

   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)

       Cheers,
       Charles

---

From: Alan Ford <[email-masked]>
Date: Mon, 7 Aug 2017 09:37:55 +0100

Hi Charles, all,

Further comments inline…

> On 3 Aug 2017, at 23:19, Charles Eckel (eckelcu) <[email-masked]> wrote:
> 
> Please see inline [cue]
>  
> From: Alan Ford <[email-masked] <mailto:[email-masked]>>
> To: Charles Eckel <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Tom Kristensen <[email-masked] <mailto:[email-masked]>>, Roman Shpount <[email-masked] <mailto:[email-masked]>>, Gonzalo Camarillo <[email-masked] <mailto:[email-masked]>>, Christer Holmberg <[email-masked] <mailto:[email-masked]>>

I agree with Christer here - it’s not a break in backward compatibility to mandate it from a offerer's point of view in the new spec, since this is all which is changing. An old answerer can cope. The only issue is a new-spec-compliant answerer with an old receiver. To be fully belt-and-braces here, the receiver should be able to cope without one and infer it, but the sender MUST always send it.

BTW just to flag up my second point there was unrelated to the first, which you answered… I’m not sure how best to present this information but I think it’s important it’s clearer near the ABNF definition that multiple roles are possible in an offer.

> [cue] The floorid is defined such that one can specify a floorid yet not associate it with any media stream, thus the mstrm is optional. This is how it was defined in RFC 4583. I am not sure if any…

It would be useful to understand what the use case is for this, but whether or not it’s required the text is still inconsistent. "It defines a floor identifier and, possibly, associates it with one or more media streams.” makes it sound optional, whereas "A floor control server acting as an offerer or as an answerer MUST include these attributes in its session descriptions.” says “these attributes” which I took to mean both label and floorid, and once you’re including label the inference is that mstrm: should be added.

I think it would be beneficial to clarify one way or the other. Either mstrm: is a MUST, or clarify why and how it could be used optionally.

> [cue] This is how it was defined in RFC 4583. As I understand it, “1*” means it requires at least one, so can have multiple.

Quite right, brain fart :)

Regards,
Alan

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 7 Aug 2017 18:56:51 +0000

Date: Monday, August 7, 2017 at 1:37 AM

Hi Charles, all,

Further comments inline…

On 3 Aug 2017, at 23:19, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:

Please see inline [cue]

From: Alan Ford <[email-masked]<mailto:[email-masked]>>
Date: Sunday, July 23, 2017 at 1:01 AM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tom Kristensen <[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>, Gonzalo Camarillo <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

Hi Charles, all,

S3

[cue] works for me

S4.1

[cue] good idea

[cue] Yes, you and Christer are correct about the backward compatibility part. I had it wrong.

[cue] Section includes this example:

   The following is an example of a 'floorctrl' attribute in an offer.
   When this attribute appears in an answer, it only carries one role:

             a=floorctrl:c-only s-only c-s

Do you think it would help if we added another role to one of the offers in the examples in section 12?
e.g.
   The following is an example of an offer sent by a conference server
   to a client.

   m=application 50000 TCP/TLS/BFCP *
   a=setup:passive
   a=connection:new
   a=fingerprint:sha-256 \
        19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \
        BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
   a=floorctrl:c-only s-only

S6

[cue] good idea

[cue] I see now. If “label” is required it seems you need at least one “mstrm”, right?
So how about if we change as follows:

OLD : floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]
NEW: floor-id-attribute = "a=floorid:" token " mstrm:" token [*(SP token)]
OLD: It defines a floor identifier and, possibly, associates it with one or more media streams.
NEW: It defines a floor identifier and associates it with one or more media streams.

Although I likely botched the ABNF.

Cheers,
Charles

S11

[cue] agreed

S14.2

Regards,
Alan

---

From: Alan Ford <[email-masked]>
Date: Tue, 8 Aug 2017 09:52:44 +0100

Hi Charles, all,

Inline…

> On 7 Aug 2017, at 19:56, Charles Eckel (eckelcu) <[email-masked]> wrote:
> 
>  
>> On 3 Aug 2017, at 23:19, Charles Eckel (eckelcu) <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Please see inline [cue]
>>  

Yes, I think that would be beneficial. I would also propose adding the following sentence directly after the ABNF in S4.1: “The offer will include one or more roles in its offer; the answerer MUST include only one role”. (The section then goes on to describe why… But this is probably the top issue in BFCP interop I want to see it totally clear). It may also be worth adding a final sentence that “If the answerer does not support any corresponding role, it MUST zero-port the m-line”.

> Although I likely botched the ABNF.

My issue is not so much that this is permitted without mstrm:, just that it is inconsistent.

I am not familiar with a scenario where it would be valid without mstrm: … If there is one I have no problem with this being permitted, but then I would suggest changing “A floor control server acting as an offerer or as an answerer MUST include these attributes in its session descriptions.” to be “A floor control server acting as an offerer or as an answerer MUST include the `floorid` attribute, and the `label` attribute if using the `mstrm` parameter, in its session descriptions.”.

If there must always be a mstrm: , then your proposal would be the appropriate fix.

One or the other - at the moment I think the text is a little confusing.

Regards,
Alan