Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
draft-ietf-mmusic-sdp-bfcp-03

IANA Last Call Comments:
Upon approval of this document the IANA will register 2 values for the SDP parameters for the 'proto' field, 5 SDP Attritribute types (media level).  These registrations will go in the following registry:
http://www.iana.org/assignments/sdp-parameters

In section 11.7 there is a request for a crypto-suite registration.  In which registry should this go?
We have the following crypto-suites registry:
http://www.iana.org/assignments/crypto-suites

Does it go there or somewhere else?  Need clarification.
Also need clarification for Bill's port number question.

[Ballot discuss]
Port 20000 belongs to a protocol named 'DNP'; should this example be from the dynamic port range (49152-65535) or should bfcp have an IANA-assigned port number?

[Ballot discuss]
The value "c2hhcmVkLXNlY3JldA==" is used throughout the document
  as the shared secret example value.  While the ASCII string that was
  encoded to make this value is cute, the string is not long enough.
  RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets.

  I find the structure of section 8 very confusing.  The authentication
  of the SIP session that is used to perform an offer/answer exchange
  is not clearly separated from the authentication of the BFCP protocol
  entities.  Further, if the 'fingerprint' attribute is not present,
  what checks must be performed to ensure that the non-self-signed
  certificate used for offer/answer exchange authentication belongs to
  to the same party as the non-self-signed certificate used with
  BFCP/TLS/TCP.  This (and perhaps other related topics) belong in a
  subsection that does not currently exist.

  Section 8 says:
  >
  > Note that when mutual authentication is performed using TLS, it is
  > not necessary to use this digest mechanism.
  >
  This does not agree with draft-ietf-xcon-bfcp-05, which says that the
  digest mechanism must be used for the first message, even when TLS is
  employed.

  Section 8.1 says:
  >
  > ... the certificate provided at the TLS-level must be signed by a
  > certificate authority known to other party.
  >
  This is not quite correct, and the terminology does not align with
  RFC 3280.  I suggest:
  >
  > ... the certificate provided at the TLS-level MUST either be
  > directly signed by one of the other party's trust anchors or be
  > validated using a certification path that terminates at one of
  > the other party's trust anchors.
  >
  Also, a normative reference to RFC 3280 in this section is desirable.

  Section 8.2.1 says:
  >
  > The key-params field SHOULD use the 'inline' key method followed by
  > a base64-encoded [6] unguessable secret [1].
  >
  Please state the size of the shared secret value.  I suspect that the
  size depends on the selected integrity check function.

[Ballot comment]
This document has a normative reference:
  [9]  Levin, O. and G. Camarillo, "The SDP (Session Description
        Protocol) Label Attribute",
        draft-levin-mmmusic-sdp-media-label-00 (work in progress),
        July 2004.

and that document is an individual Internet-Draft, that also has expired.
So what impact does this have?

[Ballot comment]
I'm not sure I see a way that a server can offer both a TLS and
non-TLS stream using this media type.  If clients end up being
required to support TLS tihs probably doesn't matter.  However it may
be an issue if clients are not required to support TLS.  Perhaps I'm
missing some information about how offer/answer works.  It definitely
seems that two m lines would be wrong because then a client could
accept both of them.

[Ballot discuss]
1) Please replace the RFc 1750 reference with  RFC 4086.

2) RFC 3548 is an informational RFC but is referenced as a normative
reference; RFC 3967 requires that this fact be mentioned in the last
call.  It was not. This document needs to be last called again or
that reference changed.  [Yes, I think this requirement is wrong; I
also understand the argument that we should follow our rules
consistently]
3) I'm uncomfortable with this document being approved before
draft-ietf-mmusic-media-tls.  Based on how this protocol works, I
suspect I have comments on that draft and depending on how those
comments are resolved, I think this draft may change.  In
particular, I'm concerned about cases where the active open side of
the connection is the TLS server, the handling of the fingerprint
attribute and some concerns about asymmetry in this protocol.


4) This document is not aligned with the main BFCP document.  First,
if the server can do active opens then section 6 and 14 of the BFCP
document need to discuss that.  If the authors of this document
confirm that this document's behavior is correct, then I can amend
my BFCP discuss.


5) The authentication handling in this document is not aligned with
BFCP.  Section 8.1 of this document implies that digest is not used
if TLS is used; as discussed by section 9.2 of the BFCP document,
BFCP seems to support modes where both TLS and digest are used. 
Similarly, section 8.2.1 only allows the digest shared secret to be
negotiated for tcp/bfcp not tcp/tls/bfcp.  Again, I'm happy if these
document are aligned in either direction.

6)  IT seems like the attributes discussed in section 8.1 need to be
integrity protected.  However the security considerations does not
discuss this issue.

[Note]: 'PROTO shepherd Colin Perkins csp@csperkins.org
IETF Last Call for this document ends 9/1.  If there IETF wide issues arise, it is possible to remove
the document from the closely following IESG consideration.  IETF Last Call review is encouraged!' added by Allison Mankin

[Note]: 'PROTO shepherd Colin Perkins csp@csperkins.org
IETF Last Call for this document ends 9/1.  If there IETF wide issues arise, it is possible to remove
the document from the closely following IESG consideration.  IETF Last Call review is encouraged!' added by Allison Mankin