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

From: Tom Kristensen <[email-masked]>
Date: Thu, 20 Aug 2015 15:07:19 +0200

Answers inline below.

On 2 March 2015 at 19:42, Pearl Liang via RT <[email-masked]>
wrote:

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

Good.

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

The first value of BFCP attributes is 1 and a 7-bit field is used to
represent the attribute type.

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

Good.

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

The first value of BFCP primitives is 1 and an 8-bit field is used to
represent the primitive type.

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

Good.

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

 The first value of BFCP request status values is 1 and an 8-bit field is
used to represent the request status type.

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

Good.

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

 The first value of BFCP error code values is 1 and an 8-bit field is used
to represent the error code type.

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

Sounds good and should be the action needed when this draft becomes an RFC!

-- Tom

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.
> >
> >
>
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Thu, 20 Aug 2015 17:36:45 +0000

Hi Tom,

For that 7-bit registry, when the first value is 1, would the maximum value be 127 or 128? Same question for the 8-bit registries.

If the maximum value is 127/255, would you want us to list the 0 as "Reserved," or just start from 1?

thanks,
Amanda

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 20 Aug 2015 18:46:30 +0000

My understanding is that the maximum values would be 127/255 for the 7/8
bit registries, and that 0 should be reserved in all cases.

Cheers,
Charles

On 8/20/15, 10:36 AM, "Amanda Baber via RT" <[email-masked]>
wrote:

>Hi Tom,
>
>For that 7-bit registry, when the first value is 1, would the maximum
>value be 127 or 128? Same question for the 8-bit registries.
>

---

From: Tom Kristensen <[email-masked]>
Date: Mon, 24 Aug 2015 15:00:04 +0200

I agree. Noting the 0 value as reserved is probably the way signal "stay
away from using it" too.

-- Tom