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

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Dec 2018 11:32:08 +0000

Hi,

I have created a pull request that will include the changes based on the AD reviews.

The first commit includes changes based on Alexey's review.

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

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Dec 2018 11:34:26 +0000

Hi,

The second commit includes changes (all but the one related to the MUX category) based on Ben's review.

Regards,

Christer

On 02/12/2018, 13.32, "Christer Holmberg" <[email-masked]> wrote:

    Hi,

    
    
    Regards,
    
    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 07:53:29 +0000

Hi,

The third commit includes changes based on Benjamin's and Ekr's reviews.

Regards,

Christer

On 02/12/2018, 13.34, "bfcpbis on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Regards,
    
    Christer

    
        Hi,

        
        
        Regards,
        
        Christer

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 15:48:42 +0000

Hi,

The fourth commit includes additional changes based on Benjamin's and Ekr's reviews, and changes based on Pete's gen-art review.

At this point I do NOT intend to make further changes based on the IESG review, so please take a look and let me know whether I have forgotten something, or whether I did something wrong.

Regards,

Christer

Ps. Ekr, I got rid of most of the "associated" terminology from the O/A section. There is still some, but the text now talks about "including attributes in m sections", similar to BUNDLE.

On 03/12/2018, 9.53, "bfcpbis on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Regards,
    
    Christer

        Hi,

        Regards,
        
        Christer

        
            Hi,

            
            
            Regards,
            
            Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 15:57:03 +0000

Correct e-mail address for Pete.

On 03/12/2018, 17.51, "Christer Holmberg" <[email-masked]> wrote:

    Hi,

    
    
    Regards,
    
    Christer

    

        Hi,

        Regards,
        
        Christer

            Hi,

            Regards,
            
            Christer

            
                Hi,

                
                
                Regards,
                
                Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 5 Dec 2018 06:32:16 +0000

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

Line 551, s/corresponding offer.; and/corresponding offer; and

Line 586, s/an answer, that contains/an answer that contains

Lines 710/11, I disputed the accuracy of this statement in another thread, "nor do they reveal which media streams will be BFCP controlled." I think this last statement should be removed.

Cheers,
Charles

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Tuesday, December 4, 2018 at 12:57 AM
To: Ben Campbell <[email-masked]>, Charles Eckel <[email-masked]>, Benjamin Kaduk <[email-masked]>, Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Mary Barnes <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] IESG AD reviews of draft-ietf-bfcpbis-rfc4583bis-26: The Pull Request

    
        Hi,

        
        
        Regards,
        
        Christer

        

            Hi,

            Regards,
            
            Christer

                Hi,

                Regards,
                
                Christer

                
                    Hi,

                    
                    
                    Regards,
                    
                    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Dec 2018 10:49:25 +0000

Hi,

> 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.
    
> Line 551, s/corresponding offer.; and/corresponding offer; and

Will fix.
    
> Line 586, s/an answer, that contains/an answer that contains

Will fix.
    
> Lines 710/11, I disputed the accuracy of this statement in another thread, "nor do they reveal which media streams will be 
> BFCP controlled." I think this last statement should be removed.

I suggested new text in a separate reply.

Regards,

Christer

    -----Original Message-----
    From: Christer Holmberg <[email-masked]>
    Date: Tuesday, December 4, 2018 at 12:57 AM
    To: Ben Campbell <[email-masked]>, Charles Eckel <[email-masked]>, Benjamin Kaduk <[email-masked]>, Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, Mary Barnes <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [bfcpbis] IESG AD reviews of draft-ietf-bfcpbis-rfc4583bis-26: The Pull Request

        
            Hi,

            
            
            Regards,
            
            Christer

            

                Hi,

                Regards,
                
                Christer

                    Hi,

                    Regards,
                    
                    Christer

                    
                        Hi,

                        
                        
                        Regards,
                        
                        Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 5 Dec 2018 23:01:35 +0000

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Wednesday, December 5, 2018 at 7:49 PM
To: Charles Eckel <[email-masked]>, Ben Campbell <[email-masked]>, Benjamin Kaduk <[email-masked]>, Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Mary Barnes <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] IESG AD reviews of draft-ietf-bfcpbis-rfc4583bis-26: The Pull Request

    Hi,

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

Cheers,
Charles

    Will fix.

    Will fix.

    
    Regards,
    
    Christer

        -----Original Message-----
        From: Christer Holmberg <[email-masked]>
        Date: Tuesday, December 4, 2018 at 12:57 AM
        To: Ben Campbell <[email-masked]>, Charles Eckel <[email-masked]>, Benjamin Kaduk <[email-masked]>, Eric Rescorla <[email-masked]>, "[email-masked]" <[email-masked]>
        Cc: "[email-masked]" <[email-masked]>, Mary Barnes <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
        Subject: Re: [bfcpbis] IESG AD reviews of draft-ietf-bfcpbis-rfc4583bis-26: The Pull Request

            
                Hi,

                
                
                Regards,
                
                Christer

                

                    Hi,

                    Regards,
                    
                    Christer

                        Hi,

                        Regards,
                        
                        Christer

                        
                            Hi,

                            
                            
                            Regards,
                            
                            Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Dec 2018 11:11:56 +0000

Hi,

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 6 Dec 2018 12:38:08 +0000

Please see inline.

Date: Thursday, December 6, 2018 at 8:12 PM

Hi,

Okay, that is a good clarification to add.

I understand the point you are emphasizing now. This new text works for me.

Thanks,
Charles

Regards,

Christer