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

Answers inline below.

On 2 March 2015 at 19:42, Pearl Liang via RT <drafts-lastcall@iana.org>
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, iesg-secretary@ietf.org 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
> > ietf@ietf.org mailing lists by 2015-03-05. 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
> >
> >
> >    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
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/