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

["Amanda Baber via RT" <[e-mail]>]

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, [e-mail] wrote:
> Answers inline below.
> 
> On 2 March 2015 at 19:42, Pearl Liang via RT <drafts-
> [e-mail]>
> 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, [e-mail] 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
> > > [e-mail] mailing lists by 2015-03-05. Exceptionally, comments
> > > may
> > be
> > > sent to [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bfcpbis
> >