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

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Sep 2018 19:47:10 +0000

Hi,

...

>§7.1 (BLOCKING):
>
>  When the existing TCP connection is closed and re-established  following the rules in [16], the floor control 
>  client MUST send an offer towards the floor control server in order to re-establish the  connection.
>
> The behavior here is ambiguous in the case that "a=floorctrl:c-s" is negotiated.
> This needs to be clarified. Perhaps something like:
>
>    If the peers are acting as both floor control client and floor control
>    server (i.e., if "a=floorctrl:c-s" has been negotiated), then the peer that
>    most recently sent a successfully answered offer MUST send an offer.

I think this was discussed at some point. If I remember correctly, in the case of 'c-s' in the answer the actual roles will be determined on BFCP level.

When I look at 4582bis, I does describe client and server procedures, but I do NOT find any procedures regarding determining the roles. In fact, 4582bis says:

   "BFCP roles are negotiated in the offer/answer exchange as specified
   in [10], resulting in one endpoint being responsible for opening the
   TCP connection used for the BFCP communication."

...which raises the question whether 'c-s' should be allowed in the answer to begin with?

Removing it would of course not be backward compatible with 4583, but if it is unclear how it would work it may not matter?

Regards,

Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 11 Sep 2018 20:59:20 +0000

RFC 4583 is underspecified in this regard, and currently rfc4583bis is as well.

This was a point of much debate years ago within the IMTC. No one with the IMTC used "c-s" for its intended purpose, though some implementations were known to use "c-s" incorrectly to mean "c-only, s-only". We agreed to not use "c-s" and to interpret "c-s" as meaning "c-only, s-only" if it was ever received. This worked well it is documented in this liaison statement:
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2012-05-31-imtc-the-ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf

Cheers,
Charles

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Tuesday, September 11, 2018 at 12:47 PM
To: Adam Roach <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
Resent-From: <[email-masked]>
Resent-To: Gonzalo Camarillo <[email-masked]>, <[email-masked]>, Christer Holmberg <[email-masked]>, Charles Eckel <[email-masked]>, Keith Drage <[email-masked]>, <[email-masked]>, Adam Roach <[email-masked]>, <[email-masked]>, Mary Barnes <[email-masked]>
Resent-Date: Tuesday, September 11, 2018 at 12:47 PM

    Hi,
    
    ...

    

    
    
    Regards,
    
    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Sep 2018 22:17:58 +0000

Hi,

Based on my reading, an endpoint being both client and server is unclear even in 4582/4582bis. My understanding is that one endpoint acts as client and one endpoints acts as server. Of course, the roles can be re-negotiated, but at any given time an endpoint only has ONE role.

Or, have I missed something?

Regards,

Christer 

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: 11 September 2018 15:59
To: Christer Holmberg <[email-masked]>; Adam Roach <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

Cheers,
Charles

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Tuesday, September 11, 2018 at 12:47 PM
To: Adam Roach <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue
Resent-From: <[email-masked]>
Resent-To: Gonzalo Camarillo <[email-masked]>, <[email-masked]>, Christer Holmberg <[email-masked]>, Charles Eckel <[email-masked]>, Keith Drage <[email-masked]>, <[email-masked]>, Adam Roach <[email-masked]>, <[email-masked]>, Mary Barnes <[email-masked]>
Resent-Date: Tuesday, September 11, 2018 at 12:47 PM

    Hi,
    
    ...

    

    
    
    Regards,
    
    Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 11 Sep 2018 20:37:57 -0500

> Or, have I missed something?

I think so. From §3:

    Furthermore, there are situations where both endpoints act as both
    floor control client and floor control server within the same
    session.  For example, in a two-party session that involves an audio
    stream and a shared whiteboard, one endpoint acts as the floor
    control server for the audio stream and the other endpoint acts as
    the floor control server for the shared whiteboard.

I note that this text exists in RFC 4583 as well, so this has 
conceptually been part of the protocol at least since its first 
publication. The way I read this, to implement the above-described 
scenario, both sides would negotiate a c-s role. Client A would send 
FloorRequest messages to Client B to ask for the audio floor, and Client 
B would send FloorRequest messages to Client A to ask for the whiteboard 
floor. This would all take place over the same BFCP stream.

Now, what I'm hearing you and Charles say is that this "both client and 
server" behavior was under-specified in RFC 4582, and so the RFC 4583 
behavior was consequently mis-implemented, with implementations failing 
to distinguish between "c-only, s-only" and "c-s" (which, based on my 
description above, would mean radically different things from each 
other); and that the confusion here was so profound that an external 
consortium has issued its own guidance that effectively deprecates the 
original meaning of "c-s" altogether.

All of which tells me that the behavior described by the paragraph I 
quote above is not used in the field, apparently not useful, and too 
confusing to understand; on top of which, IMTC has salted the ground 
even if we wanted to clarify meanings and procedures surrounding "c-s".

My suggestion, then, is:

 1. Remove the above quoted paragraph, replacing it with text that
    clarifies that one peer must be a server for all streams or a client
    for all steams.
 2. Explicitly deprecate the use of "c-s," with a note that some
    implementations are known to treat it as identical to "c-only,
    s-only" (and make the text otherwise consistent on this point; e.g.,
    in §10 and its subsections)
 3. Update the examples to match.

Another alternative would be to add clarification about how to implement 
the scenario I quote above (I think you'd get a lot of mileage by simply 
adding the word "simultaneously" to the end of the description of "c-s" 
in §5.1, which was clearly the original intention), clarify §7.1 to 
indicate who re-establishes connections for "c-s" relationships, pull 
RFC4582bis out of the RFC Editor queue and fix it so it specifies how to 
act as both a client and a server over a single BFCP stream, and ignore 
the fact that the IMTC guidance will lead to incompatibilities anyway. 
This approach seems like a lot more work to clarify a feature that no 
one apparently uses or wants, so I would not recommend it.

/a

---

From: Alan Ford <[email-masked]>
Date: Wed, 12 Sep 2018 11:11:43 +0100

I would be entirely happy with Adam’s suggestions here. c-s is an abomination that I’d be very pleased to see removed from the spec.

Regards,
Alan

> On 12 Sep 2018, at 02:37, Adam Roach <[email-masked]> wrote:
> 
> I note that this text exists in RFC 4583 as well, so this has conceptually been part of the protocol at least since its first publication. The way I read this, to implement the above-described scenario, both sides would negotiate a c-s role. Client A would send FloorRequest messages to Client B to ask for the audio floor, and Client B would send FloorRequest messages to Client A to ask for the whiteboard floor. This would all take place over the same BFCP stream.
> 
> Now, what I'm hearing you and Charles say is that this "both client and server" behavior was under-specified in RFC 4582, and so the RFC 4583 behavior was consequently mis-implemented, with implementations failing to distinguish between "c-only, s-only" and "c-s" (which, based on my description above, would mean radically different things from each other); and that the confusion here was so profound that an external consortium has issued its own guidance that effectively deprecates the original meaning of "c-s" altogether.
> 
> All of which tells me that the behavior described by the paragraph I quote above is not used in the field, apparently not useful, and too confusing to understand; on top of which, IMTC has salted the ground even if we wanted to clarify meanings and procedures surrounding "c-s".
> 
> My suggestion, then, is:
> 
> Remove the above quoted paragraph, replacing it with text that clarifies that one peer must be a server for all streams or a client for all steams.
> Explicitly deprecate the use of "c-s," with a note that some implementations are known to treat it as identical to "c-only, s-only" (and make the text otherwise consistent on this point; e.g., in §10 and its subsections)
> Update the examples to match.
> Another alternative would be to add clarification about how to implement the scenario I quote above (I think you'd get a lot of mileage by simply adding the word "simultaneously" to the end of the description of "c-s" in §5.1, which was clearly the original intention), clarify §7.1 to indicate who re-establishes connections for "c-s" relationships, pull RFC4582bis out of the RFC Editor queue and fix it so it specifies how to act as both a client and a server over a single BFCP stream, and ignore the fact that the IMTC guidance will lead to incompatibilities anyway. This approach seems like a lot more work to clarify a feature that no one apparently uses or wants, so I would not recommend it.
> /a
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 12 Sep 2018 14:47:05 +0000

I am fine with this approach as well.

Cheers,
Charles

From: Alan Ford <[email-masked]>
Date: Wednesday, September 12, 2018 at 3:11 AM
To: Adam Roach <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, Charles Eckel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

Regards,
Alan

On 12 Sep 2018, at 02:37, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I think so. From §3:

I note that this text exists in RFC 4583 as well, so this has conceptually been part of the protocol at least since its first publication. The way I read this, to implement the above-described scenario, both sides would negotiate a c-s role. Client A would send FloorRequest messages to Client B to ask for the audio floor, and Client B would send FloorRequest messages to Client A to ask for the whiteboard floor. This would all take place over the same BFCP stream.
Now, what I'm hearing you and Charles say is that this "both client and server" behavior was under-specified in RFC 4582, and so the RFC 4583 behavior was consequently mis-implemented, with implementations failing to distinguish between "c-only, s-only" and "c-s" (which, based on my description above, would mean radically different things from each other); and that the confusion here was so profound that an external consortium has issued its own guidance that effectively deprecates the original meaning of "c-s" altogether.
All of which tells me that the behavior described by the paragraph I quote above is not used in the field, apparently not useful, and too confusing to understand; on top of which, IMTC has salted the ground even if we wanted to clarify meanings and procedures surrounding "c-s".
My suggestion, then, is:
1.       Remove the above quoted paragraph, replacing it with text that clarifies that one peer must be a server for all streams or a client for all steams.
2.       Explicitly deprecate the use of "c-s," with a note that some implementations are known to treat it as identical to "c-only, s-only" (and make the text otherwise consistent on this point; e.g., in §10 and its subsections)
3.       Update the examples to match.
Another alternative would be to add clarification about how to implement the scenario I quote above (I think you'd get a lot of mileage by simply adding the word "simultaneously" to the end of the description of "c-s" in §5.1, which was clearly the original intention), clarify §7.1 to indicate who re-establishes connections for "c-s" relationships, pull RFC4582bis out of the RFC Editor queue and fix it so it specifies how to act as both a client and a server over a single BFCP stream, and ignore the fact that the IMTC guidance will lead to incompatibilities anyway. This approach seems like a lot more work to clarify a feature that no one apparently uses or wants, so I would not recommend it.
/a
_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Sep 2018 11:31:58 -0400

>  3. Update the examples to match.

ISTM that to go this way the document should be returned to the WG. It 
seems like too big a change to do otherwise.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Sep 2018 19:22:46 +0000

Hi,

For some reason I missed the text Adam referred to. 

Now assuming we would remove the possibility to act as both client and server, for backward compatibility, perhaps we should still allow c-s in the offer, but only allow c-only and s-only in the answer? That way, the semantics of c-s in an offer would not matter, because the sender would always end up as client or server.

Regards,

Christer

-----Original Message-----
From: bfcpbis [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 12 September 2018 10:32
To: [email-masked]
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

On 9/11/18 9:37 PM, Adam Roach wrote:
> FloorRequest messages to Client B to ask for the audio floor, and 
> Client B would send FloorRequest messages to Client A to ask for the 
> whiteboard floor. This would all take place over the same BFCP stream.
> 
> Now, what I'm hearing you and Charles say is that this "both client 
> and server" behavior was under-specified in RFC 4582, and so the RFC 
> 4583 behavior was consequently mis-implemented, with implementations 
> failing to distinguish between "c-only, s-only" and "c-s" (which, 
> based on my description above, would mean radically different things 
> from each other); and that the confusion here was so profound that an 
> external consortium has issued its own guidance that effectively 
> deprecates the original meaning of "c-s" altogether.
> 

ISTM that to go this way the document should be returned to the WG. It seems like too big a change to do otherwise.

> Another alternative would be to add clarification about how to 
> implement the scenario I quote above (I think you'd get a lot of 
> mileage by simply adding the word "simultaneously" to the end of the description of "c-s"
> RFC4582bis out of the RFC Editor queue and fix it so it specifies how 
> to act as both a client and a server over a single BFCP stream, and 
> ignore the fact that the IMTC guidance will lead to incompatibilities anyway.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 12 Sep 2018 19:57:58 +0000

That works for me, and it aligns with what we did within IMTC.

Cheers,
Charles

-----Original Message-----
From: bfcpbis <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Wednesday, September 12, 2018 at 12:22 PM
To: Paul Kyzivat <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

    Hi,

    
    Regards,
    
    Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 12 Sep 2018 20:04:18 +0000

Hi Paul,

Please see inline.

-----Original Message-----
From: bfcpbis <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Date: Wednesday, September 12, 2018 at 8:32 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24: role issue

I agree. This discussion is occurring on the WG list, and any changes/updated versions of the draft(s) will be vetted here as well. Are you suggesting something more formal, like another WGLC?

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Sep 2018 17:20:37 -0400

> I agree. This discussion is occurring on the WG list, and any changes/updated versions of the draft(s) will be vetted here as well. Are you suggesting something more formal, like another WGLC?

Sounds like a good idea. Force more eyeballs onto it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Sep 2018 22:37:16 +0000

Hi.

I assume this would require updates of both 4582bis and 4583bis?

Also, 3GPP reference BFCP for the IMS conference service, so I guess we should check whether a change would impact that.

Regards,

Christer 

Sent from my iPhone

> On 12 Sep 2018, at 16.20, Paul Kyzivat <[email-masked]> wrote:
>