Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
draft-ietf-bfcpbis-rfc4583bis-27

[Ballot comment]
Update: The RFC Editor is updating the mux-attribute draft to match the mux-categories described in this draft. Therefore I have cleared my DISCUSS position. Thanks to all involved! I have left my previous non-blocking comments below for reference purposes.

---------------------------

The following point was part of my DISCUSS position. Since the problem seems broader than for just this draft,  I won't hold the draft hostage to it's solution. But I hope we can find a cleaner approach in general:



This document lists all the SDP attributes as having an a Mux Category of "TBD". draft-ietf-mmusic-sdp-mux-attributes did indeed assign a category of "TBD" to all the attributes, save for bfcpver, which didn't exist at the time. But the point of "TBD" was to say that draft-ietf-mmusic-sdp-mux-attributes did not actually analyze the attributes to determine a "real" mux category. It's not intended as free pass to let other attribute definitions skip that analysis. 

Ideally, I think that this draft should assign a "real" mux category for each attribute in it. Failing that, it at least needs to do so for "bfcpver". I'm guessing that should be "caution" or "special". (Perhaps unfortunately, draft-ietf-mmusic-sdp-mux-attributes did not define a category of "nope" :-) )

Update: After a bit of discussion and a re-read of draft-ietf-mmusic-sdp-mux-attributes, I see that, while the use of "TBD" does not seem consistent with the definition of TBD, it does seem consistent with the practice in mux-attributes of assigning a category of TBD to attributes associated with non-muxable protocols. I've sent an email to the MMUSIC WG for guidance on the intended use.




*** Substantive Comments ***

§4: "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 MUST
contain a single "*" character. If the the fmt list contains any
other value it is ignored."

It seems like the last sentence should use a MUST to match the one in the previous sentence.

*** Editorial Comments ***

§3: "Typically, a client that establishes a BFCP
stream with a conference server will act as a floor control client,
while the conference server will act as a floor control server."

The use of "typically" seems odd without a discussion of when it might not. Perhaps a forward reference to section 7 would help?

§6: "[I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for
the SDP attributes defined in this specification. Table 2 defines
the mux category for the ’bfcpver’ attribute:"

I assume the first sentence should say "... except for bfcpver."?

§10, 3rd paragraph: Incorrect comma use in "... SDP), in ..."
§10.1, last paragraph: "... value, in the offer, ...": The first comma is incorrect.
§10.3: First paragraph: "When the offerer receives an answer, which contains an ’m’ line..."
s/ ", which" / "that"

§16.2: It seems like [I-D.ietf-mmusic-sdp-mux-attributes] should be a normative reference.

[Ballot discuss]

The category assignments in this draft do not match the existing assignments in mux-attributes, which marks "floorctrl" as "TBD", and the others as "NORMAL". This draft marks all attributes as "TBD".

[Ballot comment]
The following point was part of my DISCUSS position. Since the problem seems broader than for just this draft,  I won't hold the draft hostage to it's solution. But I hope we can find a cleaner approach in general:



This document lists all the SDP attributes as having an a Mux Category of "TBD". draft-ietf-mmusic-sdp-mux-attributes did indeed assign a category of "TBD" to all the attributes, save for bfcpver, which didn't exist at the time. But the point of "TBD" was to say that draft-ietf-mmusic-sdp-mux-attributes did not actually analyze the attributes to determine a "real" mux category. It's not intended as free pass to let other attribute definitions skip that analysis. 

Ideally, I think that this draft should assign a "real" mux category for each attribute in it. Failing that, it at least needs to do so for "bfcpver". I'm guessing that should be "caution" or "special". (Perhaps unfortunately, draft-ietf-mmusic-sdp-mux-attributes did not define a category of "nope" :-) )

Update: After a bit of discussion and a re-read of draft-ietf-mmusic-sdp-mux-attributes, I see that, while the use of "TBD" does not seem consistent with the definition of TBD, it does seem consistent with the practice in mux-attributes of assigning a category of TBD to attributes associated with non-muxable protocols. I've sent an email to the MMUSIC WG for guidance on the intended use.




*** Substantive Comments ***

§4: "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 MUST
contain a single "*" character. If the the fmt list contains any
other value it is ignored."

It seems like the last sentence should use a MUST to match the one in the previous sentence.

*** Editorial Comments ***

§3: "Typically, a client that establishes a BFCP
stream with a conference server will act as a floor control client,
while the conference server will act as a floor control server."

The use of "typically" seems odd without a discussion of when it might not. Perhaps a forward reference to section 7 would help?

§6: "[I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for
the SDP attributes defined in this specification. Table 2 defines
the mux category for the ’bfcpver’ attribute:"

I assume the first sentence should say "... except for bfcpver."?

§10, 3rd paragraph: Incorrect comma use in "... SDP), in ..."
§10.1, last paragraph: "... value, in the offer, ...": The first comma is incorrect.
§10.3: First paragraph: "When the offerer receives an answer, which contains an ’m’ line..."
s/ ", which" / "that"

§16.2: It seems like [I-D.ietf-mmusic-sdp-mux-attributes] should be a normative reference.

[Ballot comment]
It seems that my DISCUSS points have been adequately discussed already; thanks.
For posterity, they were:

I will go ahead and say that we should discuss the "UDP/TLS/BFCP" naming.
In particular, while I see the previous discussion that there may be
existing deployments out there, why can we not give it the same treatment
as "mstrm", and make the official name "UDP/DTLS/BFCP" while documenting
that you should accept the old name?

We also had a very long discussion about the usage of the term "initial
offer" in the context of draft-ietf-mmusic-sdp-bundle-negotiation; I do not
propose to rehash that discussion, but want to ask whether we should stick
to the established precedent with regard to the use of the term (which,
IIUC, would involve a change to this document).

Original COMMENT preserved below

Section 4

      m=    ...

  The media field MUST have a value of "application".

This is "For BFCP streams, the media field MUST have a value of
application", right?  I might just swap the "This section describes [...]"
paragraph to be after the exerpt from RFC4566 to avoid confusion.

  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 MUST
  contain a single "*" character.  If the the fmt list contains any
  other value it is ignored.

The fmt list is ignored, or the whole m= line (and section)?

Section 5.1

The interpretation of the "c-s" value is not mentioned prior to the table
in which it appears, which kind of leaves the reader hanging.  (But I guess
that is still a style matter, so I should have no say on it.)

Table 1 could probably benefit from some discussion of how it is applied,
since (e.g.) an offer could include both c-only and c-s, and if the answere
includes s-only, the offerer needs to know which role it is performing.
It seems like this would be "the offerer proceeds through the following
table, and if the offer and answer included the values present in the
current line of the table, that line is a match and determines what role
the offerer will use".
(This would be a DISCUSS but I am not convinced that there is a way to
actually do the wrong thing as an implementation.)

  Endpoints compliant with [RFC4583] might not include the 'floorctrl'
  attribute in offers and answerer.  If the 'floorctrl' attribute is
  not present the offerer will act as floor control client, and the
  answerer will act as floor control server.

I assume this is going to be backwards compatible, but it might be worth
explicitly saying so.

Section 5.4, 5.5

I'd go with "decimal integer representation" for consistency with the
preceding sections.

Section 7

      Note: When using Interactive Connectivity Establishment (ICE)
      [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward
      procedures for connection management as UDP/BFCP described above
      apply.  [...]

nit: this sentence as written applies only when all three of ICE,
TCP/DTLS/BFCP, and UDP/TLS/BFCP apply (which is nonsensical).  I assume the
intended grouping is: (1) ICE is used, and (2) either TCP/DTLS/BFCP or
UDP/TLS/BFCP is used.

Section 8

  When TLS is used with TCP, once the underlying connection is
  established, the answerer always acts as the TLS server.  If the TCP
  connection is lost, the active endpoint is responsible for re-
  establishing the TCP connection.  Unless a new TLS session is
  negotiated, subsequent SDP offers and answers will not impact the
  previously negotiated TLS roles.

IMPORTANT: "TLS session" is a term of art, and is in fact nonsensical here.
I think that you mean "TLS connection" or maybe "TLS handshake".

Section 10

  If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or
  'UDP/TLS/BFCP', the offerer and answerer follow the generic
  procedures defined in [RFC8122].

Why is 8122 the reference even for the DLTS values (as opposed to
mmusic-dtls-sdp)?

Section 10.2

So the answerer can indicate multiple BFCP versions in the bfcpver
attribute and is not using that attribute to indicate the selected BFCP
version in use?

A ref to RFC 4145 for the 'active' endpoint might be helpful.

Section 10.3

The "Note" is indented as if it is part of the list, but it should not be
part of the list.

Section 10.4

  When an offerer sends an updated offer, in order to modify a

My knowledge of SDP is rusty (and was sparse to begin with), but can't the
answerer also send a mid-session offer to start renegotiation of various
parameters?  That is, it is not just the offerer that can send an offer
during an existing session.

Section 12

It's probably worth noting explicitly that the non-(D)TLS proto values
offer neither integrity protection nor confidentiality protection to the
BFCP stream.

An attacker able to view the SDP exchanges can determine which media flows
contain which content, which could exacerbate existing metadata leakage
channels in some circumstances.

As Ekr notes in his comment, the potential for privacy considerations
relating to the various identifiers transmitted in the session description
should be discussed.  If the various integer IDs are just local to the
physical premises (even better if they're periodically randomized!), the
impact is going to be fairly limited, but should still be covered.

Section 14

  2.  Authentication (Section 8):
      In last paragraph, made clear that a TCP connection was
      described.

I'm rather confused at what this is attempting to describe.

[Ballot discuss]
I will go ahead and say that we should discuss the "UDP/TLS/BFCP" naming.
In particular, while I see the previous discussion that there may be
existing deployments out there, why can we not give it the same treatment
as "mstrm", and make the official name "UDP/DTLS/BFCP" while documenting
that you should accept the old name?

We also had a very long discussion about the usage of the term "initial
offer" in the context of draft-ietf-mmusic-sdp-bundle-negotiation; I do not
propose to rehash that discussion, but want to ask whether we should stick
to the established precedent with regard to the use of the term (which,
IIUC, would involve a change to this document).

[Ballot comment]
Section 4

      m=    ...

  The media field MUST have a value of "application".

This is "For BFCP streams, the media field MUST have a value of
application", right?  I might just swap the "This section describes [...]"
paragraph to be after the exerpt from RFC4566 to avoid confusion.

  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 MUST
  contain a single "*" character.  If the the fmt list contains any
  other value it is ignored.

The fmt list is ignored, or the whole m= line (and section)?

Section 5.1

The interpretation of the "c-s" value is not mentioned prior to the table
in which it appears, which kind of leaves the reader hanging.  (But I guess
that is still a style matter, so I should have no say on it.)

Table 1 could probably benefit from some discussion of how it is applied,
since (e.g.) an offer could include both c-only and c-s, and if the answere
includes s-only, the offerer needs to know which role it is performing.
It seems like this would be "the offerer proceeds through the following
table, and if the offer and answer included the values present in the
current line of the table, that line is a match and determines what role
the offerer will use".
(This would be a DISCUSS but I am not convinced that there is a way to
actually do the wrong thing as an implementation.)

  Endpoints compliant with [RFC4583] might not include the 'floorctrl'
  attribute in offers and answerer.  If the 'floorctrl' attribute is
  not present the offerer will act as floor control client, and the
  answerer will act as floor control server.

I assume this is going to be backwards compatible, but it might be worth
explicitly saying so.

Section 5.4, 5.5

I'd go with "decimal integer representation" for consistency with the
preceding sections.

Section 7

      Note: When using Interactive Connectivity Establishment (ICE)
      [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward
      procedures for connection management as UDP/BFCP described above
      apply.  [...]

nit: this sentence as written applies only when all three of ICE,
TCP/DTLS/BFCP, and UDP/TLS/BFCP apply (which is nonsensical).  I assume the
intended grouping is: (1) ICE is used, and (2) either TCP/DTLS/BFCP or
UDP/TLS/BFCP is used.

Section 8

  When TLS is used with TCP, once the underlying connection is
  established, the answerer always acts as the TLS server.  If the TCP
  connection is lost, the active endpoint is responsible for re-
  establishing the TCP connection.  Unless a new TLS session is
  negotiated, subsequent SDP offers and answers will not impact the
  previously negotiated TLS roles.

IMPORTANT: "TLS session" is a term of art, and is in fact nonsensical here.
I think that you mean "TLS connection" or maybe "TLS handshake".

Section 10

  If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or
  'UDP/TLS/BFCP', the offerer and answerer follow the generic
  procedures defined in [RFC8122].

Why is 8122 the reference even for the DLTS values (as opposed to
mmusic-dtls-sdp)?

Section 10.2

So the answerer can indicate multiple BFCP versions in the bfcpver
attribute and is not using that attribute to indicate the selected BFCP
version in use?

A ref to RFC 4145 for the 'active' endpoint might be helpful.

Section 10.3

The "Note" is indented as if it is part of the list, but it should not be
part of the list.

Section 10.4

  When an offerer sends an updated offer, in order to modify a

My knowledge of SDP is rusty (and was sparse to begin with), but can't the
answerer also send a mid-session offer to start renegotiation of various
parameters?  That is, it is not just the offerer that can send an offer
during an existing session.

Section 12

It's probably worth noting explicitly that the non-(D)TLS proto values
offer neither integrity protection nor confidentiality protection to the
BFCP stream.

An attacker able to view the SDP exchanges can determine which media flows
contain which content, which could exacerbate existing metadata leakage
channels in some circumstances.

As Ekr notes in his comment, the potential for privacy considerations
relating to the various identifiers transmitted in the session description
should be discussed.  If the various integer IDs are just local to the
physical premises (even better if they're periodically randomized!), the
impact is going to be fairly limited, but should still be covered.

Section 14

  2.  Authentication (Section 8):
      In last paragraph, made clear that a TCP connection was
      described.

I'm rather confused at what this is attempting to describe.

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4457



DETAIL
S 9.
>      transport is used for the default candidate, then the 'm' line proto
>      value MUST be 'UDP/TLS/BFCP'.  If TCP transport is used for the
>      default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'.
> 
>        Note: Usage of ICE with protocols other than UDP/TLS/BFCP and
>        TCP/DTLS/BFCP is outside of scope for this specification.

this is very different from any other use of ICE, and I'm not sure
it's interoperable, unless you require that only TCP or only UDP
candidates be offered (which you do not seem to). The reason is that
with ICE you can flip between different candidates as part of the
negotiation. So what happens if I initially get a UDP candidate and
then via aggressive nomination settle on TCP (or vice versa). DTLS and
TLS aren't really interoperable in that way. It would be far better to
do what WebRTC does and when you do ICE, always do DTLS even if it's
over TCP.

[Ballot comment]
S 5.3.
>      The SDP Offer/Answer procedures for the 'confid' attribute are
>      defined in Section 10.
> 
>  5.3.  SDP 'userid' Attribute
> 
>      This section defines the SDP userid' media-level attribute.  The

Are there any security considerations around this attribute?


S 5.5.
>      'bfcpver' attribute in offers and answers.  The attribute value, if
>      present, MUST be in accordance with the definition of the Version
>      field in [I-D.ietf-bfcpbis-rfc4582bis].  If the attribute is not
>      present, endpoints MUST assume a default value in accordance with
>      [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
>      the default attribute value is "1", and when used over an unreliable

Just for clarity: UDP over TURN-TCP is an unreliable transport, right?


S 7.1.
>      deliver a BFCP message and times out, the endpoint that attempted to
>      send the message (i.e., the one that detected the TCP timeout) MUST
>      send an offer in order to re-establish the TCP connection.
> 
>      Endpoints that use the offer/answer mechanism to negotiate TCP
>      connections MUST support the 'setup' and 'connection' attributes.

You probably need a reference here.


S 10.1.
> 
>      o  MUST associate an SDP 'floorid' attribute (Section 5.4) with the
>        'm' line; and
> 
>      o  MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm'
>        line of each BFCP-controlled media stream.

We managed to mostly purge "associate" from BUNDLE. Can we do it here
too?


S 10.2.
>      o  MUST insert a corresponding 'm' line in the answer, with an
>        identical 'm' line proto value [RFC3264]; and
> 
>      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
>        answerer only indicates support of BFCP versions also supported by
>        the offerer; and

Is this an odd way of saying you must subset what the offer contained?

[Ballot discuss]
Update:

After a bit of discussion and a re-read of draft-ietf-mmusic-sdp-mux-attributes, I see that, while the use of "TBD" does not seem consistent with the definition of TBD, it does seem consistent with the practice in mux-attributes of assigning a category of TBD to attributes associated with non-muxable protocols. I've sent an email to the MMUSIC WG for guidance on the intended use.

In the process, I noticed that the category assignments in this draft do not match the existing assignments in mux-attributes, which marks "floorctrl" as "TBD", and the others as "NORMAL". This draft marks all attributes as "TBD".

I am going to hold the DISCUSS position for now, until discussion of the use of TBD resolves a bit further, and until the assignment mismatch is corrected.

Original DISCUSS text:

Thanks for the work on this document. I have one item that I want to make sure is discussed prior to publication, thus the DISCUSS position:

This document lists all the SDP attributes as having an a Mux Category of "TBD". draft-ietf-mmusic-sdp-mux-attributes did indeed assign a category of "TBD" to all the attributes, save for bfcpver, which didn't exist at the time. But the point of "TBD" was to say that draft-ietf-mmusic-sdp-mux-attributes did not actually analyze the attributes to determine a "real" mux category. It's not intended as free pass to let other attribute definitions skip that analysis. 

Ideally, I think that this draft should assign a "real" mux category for each attribute in it. Failing that, it at least needs to do so for "bfcpver". I'm guessing that should be "caution" or "special". (Perhaps unfortunately, draft-ietf-mmusic-sdp-mux-attributes did not define a category of "nope" :-) )

[Ballot comment]
1) Section 4:
„This is one of the options when ICE is used (Section 9).“
Maybe you can make this sentence slightly more specific because that was one thing I was wondering about all the time until I read 9 (why TCP/DTLS/BFCP is needed), e.g.
„This is one of the options where when ICE is used only one DTLS session is established but there are candidate pairs for UDP and TCP (Section 9).“

Also why is 'UDP/TLS/BFCP' not called 'UDP/DTLS/BFCP‘?

2) Section 6 provides multiplexing considerations for bfcpver, however all other attributes also have a Mux Category: TBD. When will these be defined?

3) Section 7.1: Sorry for the lack of understanding here, but why does the reconnecting endpoint need to send a new offer at all, instead of just re-opening a new TCP connection with the same parameters as before?

4) Section 8:
„If the TCP connection is lost, the active endpoint is responsible for re-
  establishing the TCP connection.“
What does active mean here?

Also in section 10.2 and 10.3 'active' is used a well but with quotes, however, it is never really defined.

5) Section 8:
„Unless a new TLS session is
  negotiated, subsequent SDP offers and answers will not impact the
  previously negotiated TLS roles.“
Quick question: Does that mean that when the TCP connection breaks and is re-opened, there is no new TLS handshake?

6) Section 10.4:
„if the offerer
      does not want to re-establish an existing TCP connection, the
      offerer MUST associate an SDP 'connection' attribute with a value
      of "existing", with the 'm' line;“
Just double-checking: Is this correct that If the offerer does NOT what to use the existing TCP connection, it adds the „existing“ attribute…?

[Ballot discuss]
Thanks for the work on this document. I have one item that I want to make sure is discussed prior to publication, thus the DISCUSS position:

This document lists all the SDP attributes as having an a Mux Category of "TBD". draft-ietf-mmusic-sdp-mux-attributes did indeed assign a category of "TBD" to all the attributes, save for bfcpver, which didn't exist at the time. But the point of "TBD" was to say that draft-ietf-mmusic-sdp-mux-attributes did not actually analyze the attributes to determine a "real" mux category. It's not intended as free pass to let other attribute definitions skip that analysis. 

Ideally, I think that this draft should assign a "real" mux category for each attribute in it. Failing that, it at least needs to do so for "bfcpver". I'm guessing that should be "caution" or "special". (Perhaps unfortunately, draft-ietf-mmusic-sdp-mux-attributes did not define a category of "nope" :-) )

[Ballot comment]
*** Substantive Comments ***

§4: "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 MUST
contain a single "*" character. If the the fmt list contains any
other value it is ignored."

It seems like the last sentence should use a MUST to match the one in the previous sentence.

*** Editorial Comments ***

§3: "Typically, a client that establishes a BFCP
stream with a conference server will act as a floor control client,
while the conference server will act as a floor control server."

The use of "typically" seems odd without a discussion of when it might not. Perhaps a forward reference to section 7 would help?

§6: "[I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for
the SDP attributes defined in this specification. Table 2 defines
the mux category for the ’bfcpver’ attribute:"

I assume the first sentence should say "... except for bfcpver."?

§10, 3rd paragraph: Incorrect comma use in "... SDP), in ..."
§10.1, last paragraph: "... value, in the offer, ...": The first comma is incorrect.
§10.3: First paragraph: "When the offerer receives an answer, which contains an ’m’ line..."
s/ ", which" / "that"

§16.2: It seems like [I-D.ietf-mmusic-sdp-mux-attributes] should be a normative reference.

[Ballot comment]
I have one small issue with this document which applies to several sections:

5.2.  SDP 'confid' Attributes

      The Augmented BNF syntax [RFC5234] for the attribute is:

        conference-id = 1*DIGIT

Is there any limit on the maximum allowed value of this attribute?


The same issue in all the following sections where "1*DIGIT" construct is used:

5.3.  SDP 'userid' Attribute

5.4.  SDP 'floorid' Attribute

5.5.  SDP 'bfcpver' Attribute

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-bfcpbis-rfc4583bis-26. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

IANA understands that, in the current draft, sections 13.2, 13.3, 13.4 and 13.5 are restatements of actions that were already completed by IANA in response to the publication of RFC 4583. As a result, our understanding is that only sections 13.1 and 13.6 represent new actions that IANA needs to execute upon publication of the current draft as an RFC.

IANA Question --> should any of the registries that are affected by registrations from sections 13.2, 13.3, 13.4 and 13.5 be updated with references to [ RFC-to-be ]?

First, in the proto registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

three, new 'proto' values are to be registered as follows:

Type: proto
SDP Name: TCP/DTLS/BFCP
Reference: [ RFC-to-be ]

Type: proto
SDP Name: UDP/BFCP
Reference: [ RFC-to-be ]

Type: proto
SDP Name: UDP/TLS/BFCP
Reference: [ RFC-to-be ]

for the two existing registrations:

Type: proto
SDP Name: TCP/BFCP
Reference: RFC4853

Type: proto
SDP Name: TCP/TLS/BFCP
Reference: RFC4853

should the references be updated to [ RFC-to-be ]?

Second, in the att-field (media level only) also on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a single, new value is to be registered as follows:

Type: att-field (media level only)
SDP Name: bfcpver
Mux Category: TBD
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-10-17):

From: The IESG
To: IETF-Announce
CC: mary.ietf.barnes@gmail.com, bfcpbis@ietf.org, adam@nostrum.com, draft-ietf-bfcpbis-rfc4583bis@ietf.org, bfcpbis-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams) to Proposed Standard


The IESG has received a request from the Binary Floor Control Protocol Bis WG
(bfcpbis) to consider the following document: - 'Session Description Protocol
(SDP) Format for Binary Floor Control
  Protocol (BFCP) Streams'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines the Session Description Protocol (SDP) offer/
  answer procedures for negotiating and establishing Binary Floor
  Control Protocol (BFCP) streams.

  This document obsoletes RFC 4583.  Changes from RFC 4583 are
  summarized in Section 14.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD review of draft-ietf-bfcpbis-rfc4583bis. Thanks to everyone who
worked on this document. It looks generally in good shape, but there are two
issues that I think need to be addressed before placing the document into IETF
last call. I believe these should be pretty easy to address.

NOTE: If you think I am wrong about either blocking point, please speak up. It
is entirely possible that I've misunderstood something, and that the things I
believe are issues are actually okay.

---------------------------------------------------------------------------

§4 (BLOCKING):

>  This document defines five values for the proto field: TCP/BFCP,
>  TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP.

Generally, having more ways to do the same things in a protocol leads to less
interoperability rather than more. While the rationale for the four-way split
caused by TLS-versus-plaintext and UDP-versus-TCP is pretty self evident, there
appears to be no rationale in this document for having both TCP/DLTS/BFCP and
TCP/TLS/BFCP; more importantly, the document offers no guidance to implementors
regarding which to use. This is likely to lead to some implementations choosing
one encoding and others choosing the other somewhat arbitrarily. This decreases
the chances of the protocol interoperating.

Minimally, please include guidance regarding which of these two variations
implementations should use, and under which conditions. On a first glance, it
would appear that the guidance might be that non-ICE uses should use
TCP/TLS/BFCP for maximal compatibility with RFC 4583 implementations, and that
ICE uses need to use TCP/DTLS/BFCP, as outlined in section 9.


---------------------------------------------------------------------------

§7.1 (BLOCKING):

>  When the existing TCP connection is closed and re-established
>  following the rules in [16], the floor control client MUST send an
>  offer towards the floor control server in order to re-establish the
>  connection.

The behavior here is ambiguous in the case that "a=floorctrl:c-s" is negotiated.
This needs to be clarified. Perhaps something like:

  If the peers are acting as both floor control client and floor control
  server (i.e., if "a=floorctrl:c-s" has been negotiated), then the peer that
  most recently sent a successfully answered offer MUST send an offer.

---------------------------------------------------------------------------



The remaining comments are editorial, and can be handled as part of IETF last
call, or prior to last call, at the authors' convenience.

---------------------------------------------------------------------------

Abstract:

>  This document obsoletes RFC 4583.  Changes from RFC 4583 are
>  summarized in Section 15.

Nit: update to "Section 14."

---------------------------------------------------------------------------

§1:

>  Following this model, a
>  BFCP connection is described as any other media stream by using an
>  SDP 'm' line, possibly followed by a number of attributes encoded in
>  'a' lines.

It's probably worth including 'c' and 'b' lines in here as well, or possibly
phrasing it to be more general ("...possibly followed by additional SDP lines
that also apply to the BFCP connection")

---------------------------------------------------------------------------

§2:

Please update this section to match the boilerplate in RFC 8174.

---------------------------------------------------------------------------

§3:

>  conference server will act as floor control server.  However, there
>  are scenarios where both endpoints would be able to act as floor
>  control server.

Nit: "...act as a floor control server."
                ^

---------------------------------------------------------------------------

§4:

>  RFC4571 such that the length field defined in RFC4571 precedes each

Nit: "RFC 4571" (twice). See RFC 7322 §3.5, third bullet.

---------------------------------------------------------------------------

§4:

>  Similarly, UDP/BFCP is used when BFCP runs directly on top of UDP,
>  and UDP/TLS/BFCP is used when BFCP runs on top of DTLS, which in turn
>  runs on top of UDP.

I'm sure there's rationale behind why this is "UDP/TLS/BFCP" rather than
"UDP/DTLS/BFCP". It would benefit the reader to include a one-sentence
explanation.

---------------------------------------------------------------------------

§5.1:

>  This section defines the SDP 'floorctrl' media-level attribute.  The
>  attribute is used to determine the floor control role(s) that the
>  endpoints can take for the BFCP-controlled media streams.  As
>  described in Section 5.1

Nit: "As described in this section..."

---------------------------------------------------------------------------

§5.1, §5.2, §5.3, §5.4:

>      The Augmented BNF syntax [RFC5234] for the attribute is:
...
>        ;DIGIT is defined in [RFC5234]
...
>        ;token is defined in [RFC4566]

The syntax for references in this document are of the style [2] rather than
[RFC5234]. Please either update the references in these sections to match the
rest of the document, or (my suggestion) include the following directive in your
XML source:



---------------------------------------------------------------------------

§5.3:

>    Although the example was non-normative, it is implemented by some
>    vendors and occurs in cases where the endpoint is willing to act
>    as an server.

Nit: "...as a server."

---------------------------------------------------------------------------

§9:

>  multiple valid candidate pairs, and if BFCF media is shifted between

Nit: BFCP

---------------------------------------------------------------------------

§10:

>    Note: The use of source-specific SDP parameters [18] is not
>    defined to BFCP streams.

Nit: "...defined for BFCP streams."

---------------------------------------------------------------------------

§10.1:

>  o  MUST associate an SDP 'label' attribute (Section 5.3) with the 'm'
>    line of each BFCP-controlled media stream.

This is a little confusing, as Section 5.3 does not define the 'label'
attribute. I would suggest replacing "(Section 5.3)" with a reference to RFC
4574.

---------------------------------------------------------------------------

§10.2:

>  When the answerer receives an offer, which contains an 'm' line
>  describing a BFCP stream, the answerer MUST check whether it supports

"Contains an 'm' line describing a BFCP stream" appears to be a restrictive
clause rather than a parenthetical one. This calls for the use of "that" rather
than "which," and the removal of a comma:

  When the answerer receives an offer that contains an 'm' line
  describing a BFCP stream, the answerer MUST check whether it supports

---------------------------------------------------------------------------

§10.4:

>  o  If the BFCP stream is carried on top of TCP, and if the offerer
>    does not want to re-establish an existing TCP connection, the
>    offerer MUST associate an SDP connection attribute with an
>    'existing' value, with the 'm' line; and

Nit: remove quotes around "existing", add quotes around "connection".

PROTO questionnaire for: draft-ietf-bfcpbis-rfc4582bis-24

To be Published as: Standards Track

Prepared by: Mary Barnes (mary.ietf.barnes@gmail.com) on 29 August 2018
  (1) What type of RFC is being requested (BCP, Proposed Standard,
      Internet Standard, Informational, Experimental, or Historic)? 
      Why is this the proper type of RFC?  Is this type of RFC indicated 
      in the title page header?

This document obsoletes an existing standard, thus Proposed
Standard is the proper type of RFC and it is indicated as such in the title page header.

    (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up.
        Recent examples can be found in the "Action" announcements for
        approved documents. The approval announcement contains the
        following sections:

        Technical Summary: 

This document defines the Session Description Protocol (SDP) offer/answer
procedures for negotiating and establishing Binary Floor Control Protocol (BFCP)
steams.  BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control
servers.  Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment.
This document obsoletes RFC 4583. 

        Working Group Summary:

This document was thoroughly reviewed by members of the BFCPBIS WG.
       
        Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

There are existing implementations of RFC 4583 and this document has
been implemented by at least one vendor.  The formation of the BFCPBIS WG
was triggered by the IMTC, who defined the use of BFCP in their SIP Best
Current Practices for Video profile.  The vendors that had implemented BFCP
found the need to also use UDP in certain situations, thus the interested
parties brought the proposal, along with an initial version of this draft
to the IETF (DISPATCH WG). 

        Personnel
        Who is the Document Shepherd? Who is the Responsible Area
        Director?

Mary Barnes is the Document Shepherd.  Adam Roach is the Responsible AD.

    (3) Briefly describe the review of this document that was
        performed by the Document Shepherd.  If this version of
        the document is not ready for publication, please explain
        why the document is being forwarded to the IESG.

The Document Shepherd has thoroughly reviewed the -24 version of this document
and had verified that her comments and those of other reviewers have been
addressed in this version of the document. 
     
    (4) Does the document Shepherd have any concerns about the depth
        or breadth of the reviews that have been performed?

There are no concerns about the depth or breadth of the reviews.  Alan Ford and others
provided detailed reviews over the course of the progression of this document.

    (5) Do portions of the document need review from a particular
        or from broader perspective, e.g., security, operational
        complexity, AAA, DNS, DHCP, XML, or internationalization?
        If so, describe the review that took place.

Yes, this document has been reviewed by a member of the SDP directorate.
Paul Kyzivat performed the SDP review. 

    (6) Describe any specific concerns or issues that the Document
        Shepherd has with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document,
        or has concerns whether there really is a need for it. In any
        event, if the interested community has discussed those issues
        and has indicated that it still wishes to advance the document,
        detail those concerns here.

I have no concerns or issues of which the responsible AD should be aware.

    (7) Has each author confirmed that any and all appropriate IPR
        disclosures required for full conformance with the provisions
        of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes. All the authors have confirmed that there are no IPR disclosures
that ought to have been filed. 

 
    (8) Has an IPR disclosure been filed that references this document?
        If so, summarize any discussion and conclusion regarding the IPR
        disclosures.

No.

    (9) How solid is the consensus of the interested community behind this
        document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

There is WG consensus that this document is ready to progress. All WGLC comments
and subsequent comments have been addressed. No one has expressed concerns about its progression. 

    (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It 
        should be in a separate email because this questionnaire is
        publicly available.)

No.

    (11) Identify any ID nits the Document Shepherd has found in this
        document. (See http://www.ietf.org/tools/idnits/ and the
        Internet-Drafts Checklist). Boilerplate checks are not enough;
        this check needs to be thorough.

The document was checked using idnits 2.15.01.  There is a comment about three RFCs looking like references.  While they aren't actually annotated as references in the XML, there are hyperlinks in the PDF, so that shouldn't be a problem.  There are warnings about
out of date versions of references that will be fixed during the publication process.

    (12) Describe how the document meets any required formal review
        criteria, such as the MIB Doctor, media type, and URI type
        reviews.

This document does not require any formal review. 

    (13) Have all references within this document been identified as
        either normative or informative?

Yes.

    (14) Are there normative references to documents that are not ready
        for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the plan for their
        completion?

No.

    (15) Are there downward normative references references (see RFC 3967)?
        If so, list these downward references to support the Area Director
        in the Last Call procedure.

No.

    (16) Will publication of this document change the status of any
        existing RFCs? Are those RFCs listed on the title page header,
        listed in the abstract, and discussed in the introduction?
        If the RFCs are not listed in the Abstract and Introduction,
        explain why, and point to the part of the document where the
        relationship of this document to the other RFCs is discussed.
        If this information is not in the document, explain why the
        interested community considers it unnecessary.

This document obsoletes RFC 4583.  The differences and additions between
this document and are described in section section 14.

    (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body
        of the document. Confirm that all protocol extensions that the
        document makes are associated with the appropriate reservations
        in IANA registries. Confirm that any referenced IANA registries
        have been clearly identified. Confirm that newly created IANA
        registries include a detailed specification of the initial
        contents for the registry, that allocations procedures for future
        registrations are defined, and a reasonable name for the new
        registry has been suggested (see RFC 5226).

This document clearly identifies the IANA considerations. This document adds
new values to the existing SDP parameters registry.  New values are defined for the
proto field and one new value is added to the attribute field (beyond those defined
in RFC 4583).  The document also indicates that the references
in the existing registries need to be changed to the RFC # assigned when this
document is published. 

    (18) List any new IANA registries that require Expert Review for
        future allocations. Provide any public guidance that the IESG
        would find useful in selecting the IANA Experts for these new
        registries.

This document defines no new IANA registries, thus no expert review is required.

    (19) Describe reviews and automated checks performed by to validate 
        sections of the document written in a formal language, such as
        XML code, BNF rules, MIB definitions, etc.

The portions of the document that use formal language are snippets and thus
haven't been validated.  Examples were created manually and were reviewed
for accuracy by the individual doing the SDP directorate review.