Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis - Christer's review

["Charles Eckel (eckelcu)" <[e-mail]>]

-----Original Message-----
From: Christer Holmberg <[e-mail]>
Date: Saturday, August 5, 2017 at 2:09 AM
To: Charles Eckel <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Tom Kristensen <[e-mail]>, Roman Shpount <[e-mail]>, Alan Ford <[e-mail]>, Gonzalo Camarillo <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis - Christer's review

    Hi,
    
    See inline.
    
    >SECTION 3:
    >---------------
    >    
    > Q3_1: I suggest saying that the fmt value MUST be '*', and that a receiver MUST ignore any other value. There is no reason for a SHOULD, AFAIK.
    >
    > [cue] This is a carryover from RFC 4583. I do not know why it was defined this way originally.
       
    A change to MUST would still be backward compatible with RFC 4583.

[cue] I am ok with changing it to a MUST.

    
    >SECTION 4:
    >---------------
    >    
    >Q4_1: Is there a reason why including the 'floorctrl' attribute is only a SHOULD, instead of a MUST?
    >
    >[cue] This is a carryover from RFC 4583. My guess is it is stated this way for B2BUAs.
      
    Let's see if Tom has an answer, but I think it should be clear in what cases the attribute is not included.
    
    And, again, from a backward compatibility perspective "MUST send" would still work, as long as one is prepared to not receive it.
    
    From a testing perspective, it's always much better to have MUST instead of SHOULD. SHOULD is only to be used when there are clear use-cases that mandate it.

[cue] I agree. Let’s see if Tom or others know a reason to keep it as SHOULD.

      
    >SECTION 5:
    >---------------
    >   
    >Q5_1: In section 4, the name of the section is "Floor Control Server Determination", and then section 4.1 defines the associated SDP attribute.
    >    
    >However, in section 5 you start by defining the 'confid' and 'userid' attributes. I think it would be good to have a similar structure as 
    >in section 4, where you first give an overview of the feature, and then define the attributes in subsections.
    > 
    >[cue] This is a carryover from RFC 4583. While I agree with you, I’m not sure it is worth changing at this point. Do you have text you 
    >think would be helpful as an intro to the section?   
      
    I don't have text here and now, but I think there should be a short description about the feature/function provided by the attribute, before defining the attribute details.
        
    >Q_11_2: The text in section 11.2 says that, if the offer does NOT contain a floorctrl attribute, the answerer SHOULD 
    >still include it. Why is that? Doesn't the text (using default roles) in section 4 apply? 
    >
    >[cue] Yes, it does. I believe the SHOULD is there to be consistent with RFC 4583 yet favor being explicit about the floorctrl 
    >roles. Making it a MUST would break backward compatibility unnecessarily. 
    
    Why? 4583 endpoints must be prepared to receive the attribute, don't they?
    
    In any case, no matter if it is SHOULD or MUST, if the attribute is included it needs to be clear the value MUST be set according to the default roles in section 4.

[cue] I agree on both counts. I was viewing backward compatibility requirements too strictly, as you point out.

Cheers,
Charles
    
    Regards,
    
    Christer
       
        
        -----Original Message-----
        From: Charles Eckel (eckelcu) [mailto:[e-mail]] 
        Sent: 19 July 2017 12:23
        To: [e-mail]
        Cc: Tom Kristensen (tomkrist) <[e-mail]>; Roman Shpount <[e-mail]>; Alan Ford <[e-mail]>; Gonzalo Camarillo <[e-mail]>; Christer Holmberg <[e-mail]>; [e-mail]
        Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis
        
        (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 <[e-mail]> on behalf of Charles Eckel <[e-mail]>
        Date: Monday, July 17, 2017 at 10:10 AM
        To: "[e-mail]" <[e-mail]>
        Cc: Tom Kristensen <[e-mail]>, Roman Shpount <[e-mail]>, Alan Ford <[e-mail]>, Gonzalo Camarillo <[e-mail]>, Christer Holmberg <[e-mail]>
        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 <[e-mail]> on behalf of Charles Eckel <[e-mail]>
            Date: Wednesday, July 5, 2017 at 5:59 PM
            To: "[e-mail]" <[e-mail]>
            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
                [e-mail]
                https://www.ietf.org/mailman/listinfo/bfcpbis
                
            
            _______________________________________________
            bfcpbis mailing list
            [e-mail]
            https://www.ietf.org/mailman/listinfo/bfcpbis