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

[Tom Kristensen <[e-mail]>]

On 14 January 2014 03:05, Charles Eckel (eckelcu) <[e-mail]> wrote:

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

I assume Ali and Charles are right, so we better brush up the mandatory
language before issuing the next (and hopefully last) version of the draft.


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

Yes, but we have seen an implementation (old, but might be out in the wild)
using a digit and not *. So, I propose we use the SHOULD here still, but
introduce the text proposed by Mary Barnes in the accompanying BFCPbis WG
PROTO review thread:

  "The fmt (format) list is not applicable to BFCP. The fmt list of 'm'
   lines in the case of any proto field value related to BFCP SHOULD
   contain a single "*" character. If the the fmt list contains any other
   value it is ignored."


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

I agree, since the default behaviour is specified.


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

Yes, I agree that the floor control server must include these
identificators.


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

Yes, I agree here as well.


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

True, and as proposed in the accompanying BFCPbis WG PROTO review thread
merging in this requirement for implementations of the upcoming RFCXXX of
this draft. The paragraph will then read:

  "Endpoints that use the offer/answer model to establish BFCP
   connections SHOULD support the 'bfcpver' attribute. A floor control
   server acting as an offerer or as an answerer SHOULD include
   this attribute in its session descriptions.   However, endpoints that
   support RFCXXXX, and not only the RFC 4583 subset, are
   REQUIRED to support and, when acting as a floor control server
   to use the 'bfcpver' attribute.  [...]"


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

Yes, will be done.


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

This might be considered being part of application logic/policy, but I
can't see a reason for not trying to reestablish the connection here and
now. Anyway, I'll leave these two as "SHOULD". Shout out if you disagree.


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


To actually get the security/authentication from TLS and establish a secure
channel, the fingerprint attribute must be used of course. So, I'm fine
with mandating the use of it. Will change to "MUST".

 Thanks to Charles for going through all the "SHOULDs" in the draft an
discuss them, the fixes will be in the upcoming version of the draft to be
issued very very soon.

In addition Ali's original review issue #1 is fixed, but #2 is considered
taken care of in the existing text as described earlier.

-- Tom