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

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

Please see inline [cue]

-----Original Message-----
From: Christer Holmberg <[e-mail]>
Date: Friday, July 21, 2017 at 9:12 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,
    
    Below is my WGLC review. Note that, due to the long periods between the reviews, some issues may already have been addressed. If so, please refer to associated e-mail discussion.
    
    GENERIC:
    -------------
    
    QG_1: I echo Roman's comments and suggestions. And, IF you want to talk about SIP specifics in the document, you should have a dedicated "SIP Considerations" section.
    
    QG_2: The title, Abstract etc talks about "describing BFCP streams in SDP". I think the text should talk about "negotiating establishment of BFCP streams using SDP Offer/Answer".
    
    QG_3: You are using the "old format" of defining SDP attributes. You can look e.g., in section 4 of https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-26.txt to see how it is done nowadays.
    
    QG_4: For TLS and DTLS, I think the draft should reference https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-26.txt for the generic offer/answer procedures, and then only describe the BFCP specifics. Hence, the draft does not need to talk about the 'setup' attribute, the 'fingerprint' attribute etc, because that is all covered in draft-dtls-sdp.

[cue] This all sounds good to me.
    
    
    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.
    
    
    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.
    
    
    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?   
    
    SECTION 6:
    ---------------
    
    Q6_1: See comment Q5_1.
    
    
    SECTION 7:
    ---------------
    
    Q7_1: See comment Q5_1.
    
    
    SECTION 11:
    -----------------
    
    Q11_1: I think the mux category for the 'bfcpver' attribute should be defined in the section that defines the attribute - not in the offer/answer procedures.

[cue] Sounds good to me.
    
    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. 
    
    SECTION 12.
    -----------------
    
    Q12_1: Some of the examples are not aligned with the O/A procedures. For example, there is an offer with a setup:passive value, eventhough section 11 says that the offer MUST contain an actpass value.

[cue] This is a carryover from RFC 4583. I agree it is should be changed.

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