Re: [bfcpbis] IESG AD reviews of draft-ietf-bfcpbis-rfc4583bis-26: The Pull Request

[Christer Holmberg <[e-mail]>]

Hi,

>>> I have reviewed the pull requests. All the changes look good to me. Just a few things I suggest updating,
>>>
>>> Line 184/5, I do not understand the point this sentence is making and think it can be removed, "As a result, each
>>> endpoint will take the same role for each BFCP-controlled media stream associated with the BFCP stream."
>>
>> In RFC 4583 is was allowed (eventhough the procedures were underspecified) for endpoint to have different roles for
>> different media streams. We agreed to change that in 4583bis, and the statement above reflects that decision. Since
>> it is a change from 4583, I think it is useful to have it.
>
> I agree we need to say something about c-s. The complete text is as follow.
>
> In <xref target="RFC4583"/>, there was a third attribute specified, "c-s", which meant that an endpoint was willing to act as both floor
> control client and floor control server at the same time for the BFCP stream, taking different roles for different BFCP-controlled media
> streams. The feature 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”). An implementation compliant to this specification
> MUST NOT include the "c-s" floorctl attribute value in an offer or in an answer, but MUST accept the attribute value in an offer and process
> it as equivalent to "c-only s-only" (or "s-only c-only"). As a result, each endpoint will take the same role for each BFCP-controlled media stream
> associated with the BFCP stream.
>
> Overall, I like this paragraph and agree it is useful. The issue I have is with the last sentence only. Is it saying that as a result of
> interpreting "c-s" as "c-only, s-only" the end result will be the same as what was intended by the offerer when they stated "c-s"? That
> may be true, but the wording is subject to interpretation and I think the paragraph stands up fine without this sentence.

Ok, I think I understand now. It's not very clear how the second last sentence will lead to the result stated in the last sentence.

It's the fact that the answerer is allowed to only include 'c-only' OR 's-only' in the answer (in RFC 4583 the answerer was allowed to
include 'c-s' in the answer) that results in each endpoint only taking one role.
>
> I suggest reducing to the following:
>
> In <xref target="RFC4583"/>, there was a third attribute specified, "c-s", which meant that an endpoint was willing to act as both floor control
> client and floor control server at the same time for the BFCP stream, taking different roles for different BFCP-controlled media streams. The feature
> 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”). An implementation compliant to this specification MUST NOT include the "c-s" floorctl
> attribute value in an offer or in an answer, but MUST accept the attribute value in an offer and process it as equivalent to "c-only s-only" (or "s-only c-only").

I still think it would be used to include the following, modified, sentence:

"Also, as an implementation compliant to this specification is only allowed to include one role,  either 'c-only' or 's-conly', in an answer, each endpoint will
only take one role, and as a result the endpoint will take the same role for each BFCP-controlled media stream associated with the BFCP stream."

Regards,

Christer