Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue - The pull request

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Sep 2018 15:43:18 +0000

Hi,

I have created a pull request for the role issue. 

https://github.com/cdh4u/draft-bfcp-4583bis/pull/10

The pull request also updates references but does not address Adam's other issues.

Regards,

Christer

Ps. Note that I do not intend to submit a pull request for 4582bis. If changes are needed, I assume one of the authors will handle that.

---

From: Alan Ford <[email-masked]>
Date: Wed, 19 Sep 2018 17:45:24 +0100

Hi Christer, all,

I’ve just added some review comments to the PR. One sentence still needs to be removed, and I think we need to be stronger with the clarification of the deprecation, I propose a paragraph along the lines of:

In RFC4583, there was a third option specified, "c-s", which meant that an endpoint was willing to act as floor control client and floor control server. This feature was not implemented as specified, and the implementations which did signal "c-s" used it to mean that the endpoint is willing to act as floor control client or floor control server. An implementation of BFCPv2 MUST NOT send "c-s" as a floorctl attribute value, but MAY accept "c-s" as equivalent to "c-only s-only".

Regards,
Alan

> On 13 Sep 2018, at 16:43, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Sep 2018 18:06:38 +0000

Hi Alan,

A few points regarding your suggested text:

1)      There is no BFCPv2. We need to talk about “An implementation compliant to this specification”, or something like that.

2)      I think we shall say “MUST accept "c-s" as equivalent to "c-only s-only", because that is consistent and testable.

3)      Instead of saying “was not implemented as specified”, I would say “was underspecified, and implemented in different ways, e.g., some implementations interpreted ”c-s” meaning that endpoint is willing to act as either client or server (equivalent to “c-only s-only”).”.

Regards,

Christer

From: Alan Ford [mailto:[email-masked]]
Sent: 19 September 2018 19:45
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue - The pull request

Hi Christer, all,

In RFC4583, there was a third option specified, "c-s", which meant that an endpoint was willing to act as floor control client and floor control server. This feature was not implemented as specified, and the implementations which did signal "c-s" used it to mean that the endpoint is willing to act as floor control client or floor control server. An implementation of BFCPv2 MUST NOT send "c-s" as a floorctl attribute value, but I
Regards,
Alan

On 13 Sep 2018, at 16:43, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Alan Ford <[email-masked]>
Date: Wed, 19 Sep 2018 20:26:40 +0100

Sounds good to me! Minor wordsmithing...

“was underspecified and implemented in different ways, in particular many implementations interpreted "c-s” to mean that the endpoint is willing to act as either client or server (equivalent to “c-only s-only”).”

Regards,
Alan

> On 19 Sep 2018, at 19:06, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Alan,
>  
>   <>
> From: Alan Ford [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On 13 Sep 2018, at 16:43, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> 
> https://github.com/cdh4u/draft-bfcp-4583bis/pull/10 <https://github.com/cdh4u/draft-bfcp-4583bis/pull/10>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bfcpbis <https://www.ietf.org/mailman/listinfo/bfcpbis>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 09:25:28 +0000

Hi,

>1) There is no BFCPv2. We need to talk about “An implementation compliant to this specification”, or something like that.

There may be different versions of the BFCP protocol. However,  the draft does not define the BFCP protocol, but the O/A procedures for establishing a BFCP stream :)

Regards,

Christer

Hi Christer, all,

On 13 Sep 2018, at 16:43, Christer Holmberg <mailto:[email-masked]> wrote:
 
Hi,

Regards,

Christer

mailto:[email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 09:40:41 +0000

Hi,

I  have updated the pull request, based on the comments from Alan.

Regards,

Christer

From: Alan Ford <[email-masked]>
Date: Wednesday 19 September 2018 at 22:26
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue - The pull request

Regards,
Alan

On 19 Sep 2018, at 19:06, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alan,

Regards,

Christer

From: Alan Ford [mailto:[email-masked]]
Sent: 19 September 2018 19:45
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue - The pull request

Hi Christer, all,

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Sep 2018 14:14:22 +0000

Hi Alan,

> “was underspecified and implemented in different ways, in particular many implementations interpreted "c-s” to mean
> that the endpoint is willing to act as either client or server (equivalent to “c-only s-only”).”

Sounds good.

Regards,
Alan

Hi Alan,

Regards,

Christer

Hi Christer, all,

Hi,

Regards,

Christer