Subject: [bfcpbis] [IANA #809493] Last Call: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BFCP)) to Proposed Standard

From: "Pearl Liang via RT" <[email-masked]>
Date: Mon, 02 Mar 2015 18:42:29 +0000

(BEGIN IANA LAST CALL COMMENTS)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-bfcpbis-rfc4582bis-13.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has some questions about the IANA actions requested in this draft.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document there are four actions which IANA must complete.

First, the document directs IANA to establish a Attribute subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at:

http://www.iana.org/assignments/bfcp-parameters/

IANA observes that the initial values provided in the document being considered are already in the existing Attribute subregistry.  Thus:

- IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ].
- This draft revises the registration procedure from "Standards-Track RFC" to "Specification
Required" as defined in RFC5226.  Please note that Specification Required, when 
used, also implies use of a Designated Expert.

Questions: Is value 0 the first value of BFCP attributes?  And if so, should value 0
be marked as Reserved in the registry?   Is there a maximum value of this registry?  
32-bit?  Or is this an unlimited resource registry?

Second, the document directs IANA to establish a Primitive subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at:

http://www.iana.org/assignments/bfcp-parameters/

IANA observes that the initial values provided in the document being considered, with four exceptions, are already in the existing Primitive subregistry.  Thus:

- IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ].
- This draft revises the registration procedure from "Standards-Track RFC" to "Specification
Required" as defined in RFC5226.  Please note that Specification Required, when 
used, also implies use of a Designated Expert.
- In addition, IANA will add four new values to the registry as follows:

Value: 14
Primitive: FloorRequestStatusAck
Reference: [ RFC-to-be ]

Value: 15
Primitive: FloorStatusAck 
Reference: [ RFC-to-be ]

Value: 16
Primitive: Goodbye 
Reference: [ RFC-to-be ]

Value: 17
Primitive: GoodbyeAck
Reference: [ RFC-to-be ]

Questions: Is value 0 the first value of BFCP primitives?  And if so, should value 0
be marked as Reserved in the registry?   Is there a maximum value for this registry?
Or is this an unlimited resource registry?

Third, the document directs IANA to establish a Request Status subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at:

http://www.iana.org/assignments/bfcp-parameters/

IANA observes that the initial values provided in the document being considered, are already in the existing Request Status subregistry. Thus:

- IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. 
- This draft revises the registration procedure from "Standards-Track RFC" to "Specification
Required" as defined in RFC5226.  Please note that Specification Required, when 
used, also implies use of a Designated Expert.

Questions: Is value 0 the first value of BFCP request status values?  And if so, should 
value 0 be marked as Reserved in the registry?   Is there a maximum value for this 
registry? 8-bit?  Or is this an unlimited resource registry?

Fourth, the document directs IANA to establish a Error Code subregistry of the The Binary Floor Control Protocol (BFCP) Parameters registry located at:

http://www.iana.org/assignments/bfcp-parameters/

IANA observes that the initial values provided in the document being considered, with five exceptions, are already in the existing Error Code subregistry.  Thus:

- IANA will simply change the reference for the subregistry and its registrations from RFC 4582 to [ RFC-to-be ]. 
- This draft revises the registration procedure from "Standards-Track RFC" to "Specification
Required" as defined in RFC5226.  Please note that Specification Required, when 
used, also implies use of a Designated Expert.
- In addition, IANA will add five new values to the registry as follows:

Value: 10
Meaning: Unable to parse message 
Reference: [ RFC-to-be ]

Value: 11
Meaning: Use DTLS
Reference: [ RFC-to-be ]

Value: 12
Meaning: Unsupported Version
Reference: [ RFC-to-be ]

Value: 13
Meaning: Incorrect Message Length
Reference: [ RFC-to-be ]

Value: 14
Meaning: Generic Error
Reference: [ RFC-to-be ]

Questions: Is value 0 the first value of BFCP request status values?  And if so, should 
value 0 be marked as Reserved in the registry?   Is there a maximum value for this 
registry?  32-bit?  Or is this an unlimited resource registry?

IANA understands that these four actions are the only ones 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 only to confirm what actions will be performed.  

Thanks,

Pearl Liang
ICANN

(END IANA LAST CALL COMMENTS)

On Thu Feb 19 17:42:40 2015, [email-masked] wrote:
> 
> The IESG has received a request from the Binary Floor Control Protocol
> Bis  WG (bfcpbis) to consider the following document:
> - 'The Binary Floor Control Protocol (BFCP)'
>   <draft-ietf-bfcpbis-rfc4582bis-13.txt> 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
> [email-masked] mailing lists by 2015-03-05. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    Floor control is a means to manage joint or exclusive access to
>    shared resources in a (multiparty) conferencing environment.
>    Thereby, floor control complements other functions -- such as
>    conference and media session setup, conference policy manipulation,
>    and media control -- that are realized by other protocols.
> 
>    This document specifies the Binary Floor Control Protocol (BFCP).
>    BFCP is used between floor participants and floor control servers,
>    and between floor chairs (i.e., moderators) and floor control
>    servers.
> 
>    This document obsoletes RFC 4582.  Changes from RFC 4582 are
>    summarized in Section 16.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Mon, 02 Mar 2015 18:42:29 +0000

IESG/Authors/WG Chairs:

Value: 14

Value: 15

Value: 16
Primitive: Goodbye 
Reference: [ RFC-to-be ]

Value: 17
Primitive: GoodbyeAck
Reference: [ RFC-to-be ]

Value: 10

Value: 11
Meaning: Use DTLS
Reference: [ RFC-to-be ]

Value: 12

Value: 13

Value: 14
Meaning: Generic Error
Reference: [ RFC-to-be ]

Thanks,

Pearl Liang
ICANN