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

Please see inline [cue]

From: Alan Ford <alan.ford@gmail.com>
Date: Sunday, July 23, 2017 at 1:01 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Tom Kristensen <tomkrist@cisco.com>, Roman Shpount <rshpount@turbobridge.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>
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) <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> 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 <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org>> on behalf of Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>
Date: Monday, July 17, 2017 at 10:10 AM
To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>
Cc: Tom Kristensen <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>, Roman Shpount <rshpount@turbobridge.com<mailto:rshpount@turbobridge.com>>, Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com<mailto:Gonzalo.Camarillo@ericsson.com>>, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

   (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

   _______________________________________________
   bfcpbis mailing list
   bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>
   https://www.ietf.org/mailman/listinfo/bfcpbis