Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-bfcpbis-rfc4583bis-08

From: Tom Kristensen <[email-masked]>
Date: Fri, 10 Jan 2014 11:50:20 +0100

Great. Thanks for the review. Comments inline.

On 20 December 2013 14:26, Ali C. Begen (abegen) <[email-masked]> wrote:

> I am the assigned SDP directorate reviewer for this draft. For background
> on the SDP directorate, please see the FAQ at
>
> http://www.ietf.org/iesg/directorate/sdp.html
>
> Please wait for direction from your document shepherd or AD before posting
> a new version of the draft.
>

Aye aye, Captain!

Summary:
> - There are a few minor issues as indicated below.
>
> Issues:
> 1) Section 3 uses m=<media> <port> <transport> <fmt> and refers to 4566
> but 4566 actually uses m=<media> <port> <proto> <fmt> .
>
> The newly defined 4 values (TCP/BFCP, TCP/TLS/BFCP and the UDP
> equivalents) are actually the proto values that are registered with IANA
> (not transport values). Thus, I recommend changing the text to reflect this.
>

 I agree. This is inherited from RFC 4583, but as long as RFC 4566 is
referenced we should use a corresponding definition. I will change.

> 2) Definition of "floorctrl" attribute. I think the answer has to include
> only one role if the offer had this attribute. If that is correct, I
> suggest the following change:
>
> OLD:
>    If an SDP media description in an offer contains a 'floorctrl'
>    attribute, the answerer accepting that media MUST include one in the
>    corresponding media description of the answer.
>
> NEW:
>    If an SDP media description in an offer contains a 'floorctrl'
>    attribute, the answerer accepting that media MUST include only one in
> the
>    corresponding media description of the answer.
>

Yes, the answer must have one - and only one - floorctrl attribute value,
i.e. role. However, in the last sentence of Section 4 it is stated that:

   The following is an example of a 'floorctrl' attribute in an offer.
   When this attribute appears in an answer, it only carries one role:

I think that is sufficient and we haven't seen any cases of
misinterpretation of this in the field!

3) There are a few "SHOULD"s. I think they are OK but it is not clear when
> it is OK to ignore that SHOULD. If there are no such use cases, maybe they
> can be replaced with a "MUST"?
>

This is inherited from the original RFC 4583, that's the main reason for me
to suggest not changing this in this draft. Hopefully, that's fine?

-- Tom

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 10 Jan 2014 17:34:32 +0000

On Jan 10, 2014, at 2:50 AM, Tom Kristensen <[email-masked]> wrote:

> 3) There are a few "SHOULD"s. I think they are OK but it is not clear when it is OK to ignore that SHOULD. If there are no such use cases, maybe they can be replaced with a "MUST"?
> 
> This is inherited from the original RFC 4583, that's the main reason for me to suggest not changing this in this draft. Hopefully, that's fine?

Well I guess IESG will have issues with this, so take this as a warning :)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 14 Jan 2014 02:05:21 +0000

I am afraid Ali is right. Let's take the SHOULDs 1 by 1 and see how to
deal with them.

1) From section 3:
"The fmt (format) list is ignored for BFCP.  The fmt list of BFCP 'm'
The fmt (format) list is ignored for BFCP.  The fmt list of BFCP 'm'
         lines SHOULD contain a single "*" character."

This is inherited from RFC 4583. I see no reason to not use '*'. Unless
someone can identify one, I suggest changing to "MUST".

2) From section 4:
"Endpoints that use the offer/answer model to establish BFCP
   connections MUST support the 'floorctrl' attribute.  A floor control
   server acting as an offerer or as an answerer SHOULD include this
   attribute in its session descriptions.
   If the 'floorctrl' attribute is not used in an offer/answer exchange,
   by default the offerer and the answerer will act as a floor control
   client and as a floor control server, respectively."

I think this is okay as is.

3) From section 5:
"Endpoints that use the offer/answer model to establish BFCP
   connections MUST support the 'confid' and the 'userid' attributes.  A
   floor control server acting as an offerer or as an answerer SHOULD
   include these attributes in its session descriptions."

This is inherited form RFC 4583. I have seen clients not including these
in an offer, but I cannot think of a case in which a server would not
include them these. I suggest changing to "MUST".

4) From section 6:
"Endpoints that use the offer/answer model to establish BFCP
   connections MUST support the 'floorid' and the 'label' attributes.  A
   floor control server acting as an offerer or as an answerer SHOULD
   include these attributes in its session descriptions."

This is inherited form RFC 4583. I cannot think of a case in which a
server would not include these. I suggest changing to "MUST".

5) There are several SHOULDs in section 7, which defines the new bfcpver
attribute. As this attribute did not exist in RFC 4583, the SHOULDs are
warranted for backward compatibility. However, they can be made mandatory
for implementations of BFCP/UDP as well as those compliant with this
update to RFC 4583.

The only should for which this is not the case is the following:

"Tokens representing versions SHOULD be
   integers matching the "Version" field that would be presented in the
   BFCP COMMON-HEADER [8
<http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-08#ref-8>]."

I think this can be changed to "MUST" for all cases.

6) From section 8.1:
"When the existing TCP connection is reset following the rules in [8
<http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-08#ref-8>],
   the client SHOULD generate an offer towards the floor control server
   in order to reestablish the connection.  If a TCP connection cannot
   deliver a BFCP message and times out, the entity that attempted to
   send the message (i.e., the one that detected the TCP timeout) SHOULD
   generate an offer in order to reestablish the TCP connection."

I am not sure about these. I think they could be changed to "MUST".
Hopefully others can chime in.

7) Section 9 reads as follows:
"Endpoints that use the offer/
   answer model to establish BFCP connections MUST support the
   'fingerprint' attribute and SHOULD include it in their session
   descriptions."

I think this can be changed to "MUST"; however, I would appreciate
additional opinions on this one as well.

Cheers,
Charles

On 1/10/14 9:34 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

>> 3) There are a few "SHOULD"s. I think they are OK but it is not clear
>>when it is OK to ignore that SHOULD. If there are no such use cases,
>>maybe they can be replaced with a "MUST"?
>> 
>> This is inherited from the original RFC 4583, that's the main reason
>>for me to suggest not changing this in this draft. Hopefully, that's
>>fine?
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic