[bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 18 December 2013 22:38 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5CF761AD6A4 for <bfcpbis@ietfa.amsl.com>; Wed, 18 Dec 2013 14:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SFnndJeu0lAT for <bfcpbis@ietfa.amsl.com>; Wed, 18 Dec 2013 14:38:06 -0800 (PST)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id D31AB1A8028 for <bfcpbis@ietf.org>; Wed, 18 Dec 2013 14:38:05 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id en1so1363492wid.9 for <bfcpbis@ietf.org>; Wed, 18 Dec 2013 14:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4z7dBZXo08sgzDLz23qV6V2VBiirUHeIYvxJyqpynJM=; b=yJB4Ef8s8U2VEhSJDHZbgorlIHrnNDDDOl22heopECHdrP5SqOr1HQ69xITjfjpVud WlFNTbOgll2WdPwP3PLqWrqPBkA1+cUDy4blP5mCQyF9loPNGYv49ogtp7VPp+dLl5kG W5WqIrwHqcNYC7u/H11EAAaTF5U1mUsrF28FUeWcc19o2q2zHhKcHuMsDtr74CphlBrt isZ7OFvuliQgb916Od63CFkXXLrf2IbjIon35LqoY1pGzizpesyV65yjiyJuixXgvJD0 x1E+9TjpgekeMx8pHCWp4efu3NSZyiLM9iS0Qr7WgxaJv8N9AwaJC/5VSRCzfx7xAHeW cxKA==
MIME-Version: 1.0
X-Received: by with SMTP id i10mr2418349wic.36.1387406283791; Wed, 18 Dec 2013 14:38:03 -0800 (PST)
Received: by with HTTP; Wed, 18 Dec 2013 14:38:03 -0800 (PST)
Date: Wed, 18 Dec 2013 16:38:03 -0600
Message-ID: <CAHBDyN58t7b0jJC3UcWB8fEASSApjje_Raz-06k88n90ZoKK7w@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c242e0b464cf04edd6b2eb
Cc: Richard Barnes <rlb@ipv.sx>, draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org, "bfcpbis-chairs@tools.ietf.org" <bfcpbis-chairs@tools.ietf.org>
Subject: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2013 22:38:08 -0000

Hi all,

I have agreed to shepherd this document on behalf of the WG.  I have
reviewed this document in preparation for doing the PROTO write-up.

I think the document needs a bit of work before it's ready to progress.  I
have a few questions/comments, as well as editorial nits which I think
would improve readability and ease of understanding.

*General Comments:*

The document requires an SDP directorate review prior to progressing.  I
have requested that of the MMUSIC WG chairs.   At the time of this review,
Ali Begen has agreed to do that review.


1) I am slightly puzzled by the following in section 3:

m=<media> <port> <transport> <fmt> ...

Section  5.14 of RFC 4566 states the following:

m=<media> <port> <proto> <fmt> ...

So, this looks to be like the RFC 2327 ABNF for m lines is being used
(rather than RFC 4566 which is the normative SDP specification for this

m=<media> <port> <transport> <fmt list>

Note, that the IANA registration section appears to be based on RFC 4566 as
the values are specified as being applicable to the 'pro to' field.  So,
 my guess is that this is a bug from RFC 4583.

2) Section 3, next to last paragraph. I think it would be more precise to
reword this as:


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


   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

3)  Section 4, paragraph above table 1, 1st sentence.  I suggest for
clarification to make the following change:


    MUST include one in the corresponding media description


    MUST include a 'floorctrl' attribute in the corresponding media

4) Section 4, 3rd paragraph from the end:

    "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 the attribute in its
session descriptions."

Since the latter is a SHOULD what happens if the attribute is NOT included?
Under what circumstances is it okay for the server not to include it?    IF
bad things happen if it's not included, then this probably ought to be a
MUST.   Or, if there's reasonable situations in which the floor control
server doesn't include the attribute, those should be explained or at least
an example provided.

5)  Section  7.

a)  1st paragraph after ABNF.  "..versions SHOULD be integers..".   I would
think that ought to be a MUST.  What happens if the token isn't an integer
and what was the motivation for not defining the version as an integer
versus a token?   If non-integers can be used, the scope of what is
acceptable for the field needs to be explained.

b) 2nd paragraph after ABNF.  I can see why supporting the version is a
SHOULD (since it is a new field) and RFC 4583 did not define a version, but
I think that needs to be more clearly documented and I think it ought to be
REQUIRED for anyone that is using UDP and obviously, older implementations
of TCP (i.e., those only compliant to RFC 4583 and not this document) ought
to be the only ones that aren't using the version field.

c) last paragraph.  Related to b, I would think that in the case of
unreliable transports, it's not that an endpoint MUST "assume".  An
endpoint MUST "use" and signal a version number of 2.   In the case of a
reliable transport, if the endpoint does not signal a
bfcpversion-attribute, then the floor control server MUST use a value of 1.
  I'm recalling a fair amount of mailing list discussion on this one, so if
you can point to the thread where this text was agreed, I can let this one
go.  I still think it's not specified quite right, but I can live with it.

6) Section 8.  1st sentence.  I think this should be a "can use TCP or UDP"
and not a "may use TCP or UDP". Note, there is the perennial debate with
regards to whether something is normative even when it's not CAPS.  I
prefer to just use a different word to remove any confusion, particularly
when a different word is actually more correct.

7) Section 8.1,  4th paragraph, 1st sentence and last sentence.  I think
the two "SHOULD generate and offer" ought to be a MUST generate an offer OR
you need to specify the circumstances under which a client would not
generate an offer.

8) Section 9, 1st paragraph.  You're going to have to be more specific
about the potential mechanisms for authentication - at least provide an
example of mechanisms - i.e., I don't think "some mechanism" will fly with
the SecDir folks.

9) Section 11, 2nd paragraph.  I think that the assumes in the following
statement needs to be a required.  I suggest the following change:


  BFCP assumes that an initial integrity-protected channel is used to


 An initial integrity-protected channel is REQUIRED for BFCP to exchange...

10) Related to item 7, this list of changes has no mention of the new
"bfcpver" attribute.  That definitely should be on this list.

*Editorial nits:*

1) Introduction.  "These data includes..." -> "This data includes...."
 (data is now grammatically considered to be a singular noun).

2) Section 3.  1st paragraph after the indented text.  This could be
written more concisely (and per technical doc standards not as the 1st
person) as follows (and per comment 1) above, I think this should be the
'proto' field:


     We define four new values for the transport field:


      This document defines four values for the proto field:

3) Section 5.  I suggest the following change:


     We define the 'confid' and the 'userid' SDP media-level attributes.


   This document defines two SDP media-level attributes: 'confid' and

4) Section 6. I suggest the following change:


    We define the 'floorid' SDP media-level attribute.


   This document defines the 'floorid' SDP media-level attribute.

5) Section 13.  I found this really, really hard to read.  I suggest you
use a bulleted or numbered list versus this hanging list style.