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

[Tom Kristensen <[e-mail]>]

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

-- Tom

On 20 August 2015 at 20:46, Charles Eckel (eckelcu) <[e-mail]>
wrote:

> 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" <[e-mail]>
> 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, [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
> >> >
> >
> >
> >
>
>


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