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

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" <drafts-lastcall@iana.org>
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.
>
>If the maximum value is 127/255, would you want us to list the 0 as
>"Reserved," or just start from 1?
>
>thanks,
>Amanda
>
>
>On Thu Aug 20 13:07:42 2015, 2mkristensen@gmail.com wrote:
>> 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
>> >
>
>
>