From nobody Thu Aug 20 05:29:32 2015 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBBB1ACDEF; Thu, 20 Aug 2015 05:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k-GAbnTHQ2z; Thu, 20 Aug 2015 05:29:28 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DEA1A9240; Thu, 20 Aug 2015 05:29:27 -0700 (PDT) Received: by lalv9 with SMTP id v9so21452247lal.0; Thu, 20 Aug 2015 05:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EKLZkf0RYL+F3RXPvi6Op33S+uib20chLgEr3OSsTKU=; b=P41CcWwH+3RTIUvmQF2twWc2qhcm6s54jusFsS7MAbqtK+rdtxryG8dtkw3ODU3jLn FTDV8rdd+a356rtiKHt5bTFDsbfUoV0e7aZdbRDeN1RcR3GJazHGjo4gYBR4llfMLTOs bO0NZKxZZ8deTdo9rAD+hfKKDoMY7LiVLDF+YoQG40xZrWC2oE94BSqXSeVziF0ugn7r ztHS9sdpK+LWVe1cKndpqQ9HdE5il80ul2rIHuVun1o6pfsvBhuR3jZ0vwfh1gf0Ow2E PxfysT3J4MSZ+hFP4t4hmZ8kP2yznOgi2Usp6w5Gr1hACOSjiZN9sIB1c4qWar7OXhl3 JwEQ== MIME-Version: 1.0 X-Received: by 10.112.67.65 with SMTP id l1mr2742538lbt.86.1440073766419; Thu, 20 Aug 2015 05:29:26 -0700 (PDT) Received: by 10.25.85.67 with HTTP; Thu, 20 Aug 2015 05:29:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Aug 2015 14:29:26 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1134800e4c449d051dbd4da4 Archived-At: Cc: "draft-ietf-bfcpbis-rfc4582bis.all@tools.ietf.org" , General Area Review Team , "bfcpbis@ietf.org" , Tom Kristensen Subject: Re: [bfcpbis] Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 12:29:30 -0000 --001a1134800e4c449d051dbd4da4 Content-Type: text/plain; charset=UTF-8 Thanks for the Gen-ART review. Response and hopefully a resolution inline below. On 2 March 2015 at 18:19, Suresh Krishnan wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > > Please wait for direction from your document shepherd or AD before > posting a new version of the draft. > > Document: draft-ietf-bfcpbis-rfc4582bis-13.txt > Reviewer: Suresh Krishnan > Review Date: 2015/03/02 > IESG Telechat date: 2015/03/05 > > Summary: This draft has significant issues that needs to be fixed before > it is ready for publication as a Proposed Standard. > > Major: > > * Section 5.1: > > This section mandates the receiver to ignore the F bit if it is set > while running over reliable transport. In my opinion this is not > sufficient as the length of the header is determined by the bit being > set. I strongly believe that this is an error condition and the packet > should not be processed further. At the bare minimum, the draft needs to > specify if the receiver should process the COMMON-HEADER as having 12 > octets or 16 octets in this case. > A problem here as for other fields is coping with senders implementeing the RFC4582 subset only and not the extensions. I can see the problem, but suggest that we keep the text and solution more or less as is. However, I think it is a good idea to tell the receiver to process the received packet as having 12 octets to definitely ignore the F bit in this case. > * Section 6.2.3: > > This section does not explicitly state that each of the fragments needs > to have the COMMON-HEADER included, but it can be inferred since that is > the most logical thing to do. I would prefer that it be explicitly > stated though. > > If my interpretation is correct, then the formula for calculating the > number of fragments is wrong. Instead of > > N=ceil(message size / MTU size) > > it needs to be > > N = ceil( (message size - X) / (MTU size - X) ) > > where X is the size of the COMMON-HEADER with fragment fields (i.e. 16) > if the MTU size is the MTU for UDP. This is needed because the common > header will be repeated on all the fragments. > > e.g. Assume MTU size=1280 and message size=2560 (COMMON-HEADER 16 + 2544 > message) the current formula will yield N=2, while N should in fact be 3 > as the message will not fit in 2 fragments. > Good catch! Yes, we have to adjust the formula and take into the account the added COMMON-HEADER. I'll also add a clarifying text stating that all the fragments indeed need the COMMON-HEADER (of 16 octets length). -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a1134800e4c449d051dbd4da4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the Gen-ART review. Response and hopefully a re= solution inline below.


On 2 March 2015 at 18:19, S= uresh Krishnan <suresh.krishnan@ericsson.com> wro= te:
I am the assigned Gen-ART reviewer fo= r this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/= wiki/GenArtfaq>

Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-bfcpbis-rfc4582bis-13.txt
Reviewer: Suresh Krishnan
Review Date: 2015/03/02
IESG Telechat date: 2015/03/05

Summary: This draft has significant issues that needs to be fixed before it is ready for publication as a Proposed Standard.

Major:

* Section 5.1:

This section mandates the receiver to ignore the F bit if it is set
while running over reliable transport. In my opinion this is not
sufficient as the length of the header is determined by the bit being
set. I strongly believe that this is an error condition and the packet
should not be processed further. At the bare minimum, the draft needs to specify if the receiver should process the COMMON-HEADER as having 12
octets or 16 octets in this case.

A problem here as for other fields is coping with senders implementei= ng the RFC4582 subset only and not the extensions. I can see the problem, b= ut suggest that we keep the text and solution more or less as is. However, = I think it is a good idea to tell the receiver to process the received pack= et as having 12 octets to definitely ignore the F bit in this case.

=C2=A0
* Section 6.2.3:

This section does not explicitly state that each of the fragments needs
to have the COMMON-HEADER included, but it can be inferred since that is the most logical thing to do. I would prefer that it be explicitly
stated though.

If my interpretation is correct, then the formula for calculating the
number of fragments is wrong. Instead of

N=3Dceil(message size / MTU size)

it needs to be

N =3D ceil( (message size - X) / (MTU size - X) )

where X is the size of the COMMON-HEADER with fragment fields (i.e. 16)
if the MTU size is the MTU for UDP. This is needed because the common
header will be repeated on all the fragments.

e.g. Assume MTU size=3D1280 and message size=3D2560 (COMMON-HEADER 16 + 254= 4
message) the current formula will yield N=3D2, while N should in fact be 3<= br> as the message will not fit in 2 fragments.

=
Good catch! Yes, we have to adjust the formula and take int= o the account the added COMMON-HEADER. I'll also add a clarifying text = stating that all the fragments indeed need the COMMON-HEADER (of 16 octets = length).

-- Tom
--
# Cisco =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0http://= www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--001a1134800e4c449d051dbd4da4-- From nobody Thu Aug 20 06:07:31 2015 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3411ACE20; Thu, 20 Aug 2015 06:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tplJeKpaNhe3; Thu, 20 Aug 2015 06:07:22 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A401ACE21; Thu, 20 Aug 2015 06:07:21 -0700 (PDT) Received: by lagz9 with SMTP id z9so22083081lag.3; Thu, 20 Aug 2015 06:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oice/8NB5547hz7G/2Zi7n+EbVAwURy35pJaf/G5vpw=; b=oHPfcH060YcLZ0VUXpq1OF+3K99CepDkxKR3M8Kck+J6oLq2tkcP46XDdj0y/fNZV2 18wB5DRZLoWWAMtftFfjr2xYu97axqgyLzjEFGFkgT5p+YsSHn/q+MuJQLA7SVrDkDm+ 0w4BCWl4kpp/tyF63BIO4UvRYsgSCqDCgSLS99NVLtvi0KGPD5pCMGSrAdjJvJPUKh0U JSTb8YNVR4zyHXtz9BD58Zn00Ka+yLHjART3rL3TOfpiOCrJfOLhwdnY+OH2NILQ3Zjj KLR/IVW38IYAX/rs7ChOc7zEh3JYjDmdYUX4Jyb2JsCzA5B3cbSQg67qD2S6BJJk7AqE UVuw== MIME-Version: 1.0 X-Received: by 10.152.26.163 with SMTP id m3mr2888320lag.86.1440076040004; Thu, 20 Aug 2015 06:07:20 -0700 (PDT) Received: by 10.25.85.67 with HTTP; Thu, 20 Aug 2015 06:07:19 -0700 (PDT) In-Reply-To: References: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> Date: Thu, 20 Aug 2015 15:07:19 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: drafts-lastcall@iana.org Content-Type: multipart/alternative; boundary=089e0158c73ed06c2a051dbdd474 Archived-At: Cc: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, "bfcpbis@ietf.org" , iesg@ietf.org, bfcpbis-chairs@ietf.org Subject: Re: [bfcpbis] [IANA #809493] Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:07:26 -0000 --089e0158c73ed06c2a051dbdd474 Content-Type: text/plain; charset=UTF-8 Answers inline below. On 2 March 2015 at 19:42, Pearl Liang via RT 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)' > > 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/ --089e0158c73ed06c2a051dbdd474 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.=C2=A0 Authors should re= view the comments and/or questions below.=C2=A0 Please report any inaccurac= ies 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:<= br>
IANA understands that, upon approval of this document there are four action= s which IANA must complete.

First, the document directs IANA to establish a Attribute subregistry of th= e The Binary Floor Control Protocol (BFCP) Parameters registry located at:<= br>
http://www.iana.org/assignments/bfcp-parameters/=

IANA observes that the initial values provided in the document being consid= ered are already in the existing Attribute subregistry.=C2=A0 Thus:

- IANA will simply change the reference for the subregistry and its registr= ations from RFC 4582 to [ RFC-to-be ].
- This draft revises the registration procedure from "Standards-Track = RFC" to "Specification
Required" as defined in RFC5226.=C2=A0 Please note that Specification = Required, when
used, also implies use of a Designated Expert.

Good.
=C2=A0

Questions: Is value 0 the first value of BFCP attributes?=C2=A0 And if so, = should value 0
be marked as Reserved in the registry?=C2=A0 =C2=A0Is there a maximum value= of this registry?
32-bit?=C2=A0 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.

=C2=A0
Second, the document directs IANA to establish a Primitive subregistry of t= he 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 consid= ered, with four exceptions, are already in the existing Primitive subregist= ry.=C2=A0 Thus:

- IANA will simply change the reference for the subregistry and its registr= ations from RFC 4582 to [ RFC-to-be ].
- This draft revises the registration procedure from "Standards-Track = RFC" to "Specification
Required" as defined in RFC5226.=C2=A0 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 ]

Goo= d.

=C2=A0
Questions: Is value 0 the first value of BFCP primitives?=C2=A0 And if so, = should value 0
be marked as Reserved in the registry?=C2=A0 =C2=A0Is there a maximum value= for this registry?
Or is this an unlimited resource registry?

<= div>The first value of BFCP primitives is 1 and an 8-bit field is used to r= epresent 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 consid= ered, are already in the existing Request Status subregistry. Thus:

- IANA will simply change the reference for the subregistry and its registr= ations from RFC 4582 to [ RFC-to-be ].
- This draft revises the registration procedure from "Standards-Track = RFC" to "Specification
Required" as defined in RFC5226.=C2=A0 Please note that Specification = Required, when
used, also implies use of a Designated Expert.

Good.

=C2= =A0
Questions: Is value 0 the first value of BFCP request status values?=C2=A0 = And if so, should
value 0 be marked as Reserved in the registry?=C2=A0 =C2=A0Is there a maxim= um value for this
registry? 8-bit?=C2=A0 Or is this an unlimited resource registry?

=C2=A0The first value of BFCP request status val= ues 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 consid= ered, with five exceptions, are already in the existing Error Code subregis= try.=C2=A0 Thus:

- IANA will simply change the reference for the subregistry and its registr= ations from RFC 4582 to [ RFC-to-be ].
- This draft revises the registration procedure from "Standards-Track = RFC" to "Specification
Required" as defined in RFC5226.=C2=A0 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 ]

Goo= d.


Questions: Is value 0 the first value of BFCP request status values?=C2=A0 = And if so, should
value 0 be marked as Reserved in the registry?=C2=A0 =C2=A0Is there a maxim= um value for this
registry?=C2=A0 32-bit?=C2=A0 Or is this an unlimited resource registry?

=C2=A0The first value of BFCP error = code values is 1 and an 8-bit field is used to represent the error code typ= e.

=C2=A0
Sounds good and should be the action needed when thi= s draft becomes an RFC!
=C2=A0
--= Tom


Thanks,

Pearl Liang
ICANN

(END IANA LAST CALL COMMENTS)


On Thu Feb 19 17:42:40 2015, ies= g-secretary@ietf.org wrote:
>
> The IESG has received a request from the Binary Floor Control Protocol=
> Bis=C2=A0 WG (bfcpbis) to consider the following document:
> - 'The Binary Floor Control Protocol (BFCP)'
>=C2=A0 =C2=A0<draft-ietf-bfcpbis-rfc4582bis-13.txt> as Proposed S= tandard
>
> The IESG plans to make a decision in the next few weeks, and solicits<= br> > final comments on this action. Please send substantive comments to the=
> ietf@ietf.org mailing lists by 20= 15-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
>
>
>=C2=A0 =C2=A0 Floor control is a means to manage joint or exclusive acc= ess to
>=C2=A0 =C2=A0 shared resources in a (multiparty) conferencing environme= nt.
>=C2=A0 =C2=A0 Thereby, floor control complements other functions -- suc= h as
>=C2=A0 =C2=A0 conference and media session setup, conference policy man= ipulation,
>=C2=A0 =C2=A0 and media control -- that are realized by other protocols= .
>
>=C2=A0 =C2=A0 This document specifies the Binary Floor Control Protocol= (BFCP).
>=C2=A0 =C2=A0 BFCP is used between floor participants and floor control= servers,
>=C2=A0 =C2=A0 and between floor chairs (i.e., moderators) and floor con= trol
>=C2=A0 =C2=A0 servers.
>
>=C2=A0 =C2=A0 This document obsoletes RFC 4582.=C2=A0 Changes from RFC = 4582 are
>=C2=A0 =C2=A0 summarized in Section 16.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/d= raft-ietf-bfcpbis-rfc4582bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.or= g/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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/=
## tomkrist@cis= co.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0http://folk.uio= .no/tomkri/
--089e0158c73ed06c2a051dbdd474-- From nobody Thu Aug 20 11:35:41 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF791A1A48; Thu, 20 Aug 2015 10:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35FTp2qHG2ie; Thu, 20 Aug 2015 10:36:47 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78121A1A20; Thu, 20 Aug 2015 10:36:47 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (8.13.8/8.13.8) with ESMTP id t7KHajIU027339; Thu, 20 Aug 2015 17:36:45 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 8799AC20155; Thu, 20 Aug 2015 17:36:45 +0000 (UTC) RT-Owner: Nobody From: "Amanda Baber via RT" In-Reply-To: References: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #840618 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 20 Aug 2015 17:36:45 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 20 Aug 2015 11:35:40 -0700 Cc: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis@ietf.org, 2mkristensen@gmail.com, bfcpbis-chairs@ietf.org Subject: [bfcpbis] [IANA #840618] Re: Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 17:36:50 -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 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 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)' > > > 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 > > From nobody Thu Aug 20 11:46:38 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D971AD0C9; Thu, 20 Aug 2015 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNPuD0KRcwB6; Thu, 20 Aug 2015 11:46:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A289C1AD0C8; Thu, 20 Aug 2015 11:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9965; q=dns/txt; s=iport; t=1440096392; x=1441305992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eA7YnxCpNXX/Y5H8t68hqATu1yoLxIDZ7hrFK3F6JD8=; b=MY+6jvBJyo3+hSXVyfJUIzEvv6t9qVeZ/c3RYoZ4uLS14nJNJt5GAJuj FqGpLRkYC9V8NOFY3uXsSZxx9h0vs8qB5Y2HZ3wBN8Y5mySuhRSkrhr7s PJZg/2H848yXQXc9Hs41jJzHZYR8RG/1Q33/wx6t3I/LBtKQocASMHx0t k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CQAgAfH9ZV/4oNJK1dgxtUaQa9UAEJgW0KhTFKAoE6OBQBAQEBAQEBfwuEIwEBAQMBAQEBNy4DAwsFCwIBCBgeBQshBgslAgQOBQmIEAMKCA3KQQ2FVwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLU4E9gRKCOweELAWVKQGFBIV9gW2BSkaDaI0LhzgmghskgT5xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,715,1432598400"; d="scan'208";a="22220624" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 20 Aug 2015 18:46:31 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7KIkVVs015250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2015 18:46:31 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 20 Aug 2015 13:46:30 -0500 Received: from xhc-rcd-x07.cisco.com (173.37.183.81) by xch-aln-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 20 Aug 2015 13:46:30 -0500 Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0248.002; Thu, 20 Aug 2015 13:46:30 -0500 From: "Charles Eckel (eckelcu)" To: "drafts-lastcall@iana.org" Thread-Topic: [IANA #840618] Re: [bfcpbis] Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard Thread-Index: AQHQ227NhFX0371kZUuh7P4WPKhOB54VGKWA Date: Thu, 20 Aug 2015 18:46:30 +0000 Message-ID: References: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.36.7.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <85B7F96719A86248915272ADB8F4A3A2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-bfcpbis-rfc4582bis.all@ietf.org" , "bfcpbis@ietf.org" , "2mkristensen@gmail.com" <2mkristensen@gmail.com>, "bfcpbis-chairs@ietf.org" Subject: Re: [bfcpbis] [IANA #840618] Re: Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 18:46:36 -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" 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. >>=20 >> On 2 March 2015 at 19:42, Pearl Liang via RT > lastcall@iana.org> >> wrote: >>=20 >> > (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. >> > >>=20 >> Good. >>=20 >>=20 >> 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? >> > >>=20 >> The first value of BFCP attributes is 1 and a 7-bit field is used to >> represent the attribute type. >>=20 >>=20 >>=20 >> > 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 ] >> > >>=20 >> Good. >>=20 >>=20 >>=20 >> > 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? >> > >>=20 >> The first value of BFCP primitives is 1 and an 8-bit field is used to >> represent the primitive type. >>=20 >>=20 >> 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. >> > >>=20 >> Good. >>=20 >>=20 >>=20 >> > 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? >> > >>=20 >> The first value of BFCP request status values is 1 and an 8-bit field >> is >> used to represent the request status type. >>=20 >>=20 >>=20 >> > 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 ] >> > >>=20 >> Good. >>=20 >>=20 >> 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? >> > >>=20 >> The first value of BFCP error code values is 1 and an 8-bit field is >> used >> to represent the error code type. >>=20 >>=20 >>=20 >> > 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. >> > >>=20 >> Sounds good and should be the action needed when this draft becomes an >> RFC! >>=20 >> -- Tom >>=20 >>=20 >> 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)' >> > > 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 >> > > > > From nobody Thu Aug 20 14:05:43 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810DA1B29EF for ; Thu, 20 Aug 2015 14:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovj-3A3cjoJL for ; Thu, 20 Aug 2015 14:05:39 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA7C1B29E9 for ; Thu, 20 Aug 2015 14:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12576; q=dns/txt; s=iport; t=1440104739; x=1441314339; h=from:to:cc:subject:date:message-id:mime-version; bh=wCsjkp2WgNLBSVR7T+7VTxfShc7+FapAjXfOMnedQtQ=; b=j8IB2SrRiR53abkmKPdqoap+N8ynZnwtCaG2ba3C1dJ++1B85y+7Xnyt ooSCDU47tog+ehk9ccOODbCxVBdPVfZp980IdDip+p110r6qbYPIsOrC9 4zpyxsNpDbk5cgmSg4Oy2HM/quc3GLHNGlyQFXHBrVtTg7A80fY9Nhsye w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B+AgDBQNZV/5FdJa1dgk5NVGkGvVABCYdygT44FAEBAQEBAQGBCoQjAQIELUwSAQgRAwECKDkUCQoEAQ0FiC7QQgEBAQEBAQEBAQEBAQEBAQEBAQEBGItThHkRhDMFlSkBjG6BSpBAiDEmg31xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,717,1432598400"; d="scan'208,217";a="180600642" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 20 Aug 2015 21:05:38 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7KL5cvW031585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2015 21:05:38 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 20 Aug 2015 16:05:37 -0500 Received: from xhc-aln-x04.cisco.com (173.36.12.78) by xch-rcd-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 20 Aug 2015 16:05:37 -0500 Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0248.002; Thu, 20 Aug 2015 16:05:37 -0500 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04 Thread-Index: AQHQ24v2XEqd0jP1zEWw4qlKCxlsgw== Date: Thu, 20 Aug 2015 21:05:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.37.102.27] Content-Type: multipart/alternative; boundary="_000_D1FB8E6755AD7eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "alissa@cooperw.in" Subject: Re: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 21:05:41 -0000 --_000_D1FB8E6755AD7eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Christer, Thanks for the review and comments. Draft authors, when can we expect responses to Christer=92s comments, and/o= r a corresponding update to the draft? Cheers, Charles From: bfcpbis > o= n behalf of Christer Holmberg > Date: Thursday, July 2, 2015 at 11:12 AM To: "bfcpbis@ietf.org" > Cc: "alissa@cooperw.in" > Subject: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04 Hi, Below is my review of draft-ietf-bfcpbis-bfcp-websocket-04. In general, things look good, and my comments should be mostly editorial. A= lso, my previous comments on the draft have been addressed. Thanks for that= ! Q1: There are a few abbreviations (TLS, HTTP etc) that are not expanded on = first occurrence. I didn=92t check whether they are considered well known a= bbreviations, but it would be good to double check. Q2: I think the last paragraph of section 1, talking about not preventing o= ther mechanisms, can be removed completely. (I think I previously had the same comment on the draft =96 or maybe it was= another WebSocket sub-protocol draft) Q3: Section one says =93since WebSocket is a reliable transport=94. Perhaps= =93provides a reliable transport=94 would be better? Q4: Section 5 says =93WebSocket [RFC6455] is a reliable protocol=94. I don= =92t know what =93reliable protocol=94 means, but I assume this text should= also talk about providing reliable transport. Q5: In section 6.1, there should be a reference for the =91setup=92 attribu= te. Also, when talking about SDP attributes, I=92d suggest to explicitly sa= y =93SDP setup attribute=94, or something similar. Q6: The introduction says that the draft updates rfc4582bis and rfc4583bis.= I think it would be good to have two explicit =93Updates to RFCXXXX=94 sec= tions to list exactly what those updates are. Q7: Just to check: are the new SDP m- line proto values aligned with the na= ming approach that has taken place in MMUSIC? Regards, Christer --_000_D1FB8E6755AD7eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Christer, 

Thanks for the review and comments.

Draft authors, when can we expect responses to Christer=92s comments, = and/or a corresponding update to the draft?

Cheers,
Charles

From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Ch= rister Holmberg <chris= ter.holmberg@ericsson.com>
Date: Thursday, July 2, 2015 at 11:= 12 AM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Cc: "alissa@cooperw.in" <alissa@cooperw.in>
Subject: [bfcpbis] Review of draft-= ietf-bfcpbis-bfcp-websocket-04

Hi,

 

Below is my review of draft-ietf-bf= cpbis-bfcp-websocket-04.

 

In general, things look good, and m= y comments should be mostly editorial. Also, my previous comments on the dr= aft have been addressed. Thanks for that!

 

Q1: There are a few abbreviations (= TLS, HTTP etc) that are not expanded on first occurrence. I didn=92t check = whether they are considered well known abbreviations, but it would be good to double check.

 

Q2: I think the last paragraph of s= ection 1, talking about not preventing other mechanisms, can be removed com= pletely.

 

(I think I previously had the same = comment on the draft =96 or maybe it was another WebSocket sub-protocol dra= ft)

 

Q3: Section one says =93since WebSo= cket is a reliable transport=94. Perhaps =93provides a reliable transport= =94 would be better?

 

Q4: Section 5 says =93WebSocket [RF= C6455] is a reliable protocol=94. I don=92t know what =93reliable protocol= =94 means, but I assume this text should also talk about providing reliable transport.

      = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;           

Q5: In section 6.1, there should be= a reference for the =91setup=92 attribute. Also, when talking about SDP at= tributes, I=92d suggest to explicitly say =93SDP setup attribute=94, or something similar.

 

Q6: The introduction says that the = draft updates rfc4582bis and rfc4583bis. I think it would be good to have t= wo explicit =93Updates to RFCXXXX=94 sections to list exactly what those updates are.

 

Q7: Just to check: are the new SDP = m- line proto values aligned with the naming approach that has taken place = in MMUSIC?

 

Regards,

 

Christer

 

 

 

 

 

 --_000_D1FB8E6755AD7eckelcuciscocom_-- From nobody Thu Aug 20 22:33:30 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604A41A8758 for ; Thu, 20 Aug 2015 22:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdPEvHZyZfAm for ; Thu, 20 Aug 2015 22:33:26 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BC31A8753 for ; Thu, 20 Aug 2015 22:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8113; q=dns/txt; s=iport; t=1440135206; x=1441344806; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CRhPqVVBaTzAscNeaJMFmrW5ppBy6j0PkELD6zf7ik4=; b=bem+V6T2Hi9Orh0geVDalYfynsqjCdeadIoH/Dodx3K3fjvpSWn5FErf eeG99jDOUC1X7QCLPl5SiSjykuVUyfANnkvKwNxoGffSsZpvmiTv03eBe 5xnXw15BMt/beSdX8GxbV9o+Pg7YVSe+qwcK6MmSdKLiontTiLyNtFcQi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B7AgA4t9ZV/4MNJK1dgxtUWg8GvVIBCYFtAQmFMUoCgTs4FAEBAQEBAQGBCoQjAQEBBAEBAWsLEAIBCBEDAQIoBycLFAkIAgQOBYguDc8jAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLU4R5DQQHgxiBFAWVKQGFBIdqgUqQQIRIg2kmg31xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,720,1432598400"; d="scan'208,217";a="180631969" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 21 Aug 2015 05:33:25 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7L5XOS5010814 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Aug 2015 05:33:24 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 21 Aug 2015 00:33:23 -0500 Received: from xhc-rcd-x07.cisco.com (173.37.183.81) by xch-rcd-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 21 Aug 2015 00:33:23 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.103]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0248.002; Fri, 21 Aug 2015 00:33:23 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Charles Eckel (eckelcu)" Thread-Topic: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04 Thread-Index: AQHQ24v2tJFpZs3eTEKDBmLDmBoP2p4WQpSA Date: Fri, 21 Aug 2015 05:33:22 +0000 Message-ID: <676DBA71-E49F-4D86-B82E-8263D70B6C35@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.16] Content-Type: multipart/alternative; boundary="_000_676DBA71E49F4D86B82E8263D70B6C35ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Ram Mohan R \(rmohanr\)" , "bfcpbis@ietf.org" , "alissa@cooperw.in" , Christer Holmberg Subject: Re: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 05:33:28 -0000 --_000_676DBA71E49F4D86B82E8263D70B6C35ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable @Charles - Ram and I are working on the updated version and hope to publish= it very soon. One additional request below. @Christer - It would be helpful to get your review of the complementary dra= ft you requested (draft-ram-bfcpbis-sdp-ws-uri-00). That way we can update both at the sa= me time. Let us know if this is something forthcoming. Thanks, Gonzalo On Aug 20, 2015, at 5:05 PM, Charles Eckel (eckelcu) > wrote: Christer, Thanks for the review and comments. Draft authors, when can we expect responses to Christer=92s comments, and/o= r a corresponding update to the draft? Cheers, Charles From: bfcpbis > o= n behalf of Christer Holmberg Date: Thursday, July 2, 2015 at 11:12 AM To: "bfcpbis@ietf.org" Cc: "alissa@cooperw.in" Subject: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04 Hi, Below is my review of draft-ietf-bfcpbis-bfcp-websocket-04. In general, things look good, and my comments should be mostly editorial. A= lso, my previous comments on the draft have been addressed. Thanks forthat! Q1: There are a few abbreviations (TLS, HTTP etc) that are not expanded on = first occurrence. I didn=92t check whether they are considered well knowndo= uble check. Q2: I think the last paragraph of section 1, talking about not preventing o= ther mechanisms, can be removed completely. (I think I previously had the same comment on the draft =96 or maybe it was= another WebSocket sub-protocol draft) Q3: Section one says =93since WebSocket is a reliable transport=94. Perhaps= =93provides a reliable transport=94 would be better? Q4: Section 5 says =93WebSocket [RFC6455] is a reliable protocol=94. I don= =92t know what =93reliable protocol=94 means, but I assume this text should= also talkabout providing reliable transport. Q5: In section 6.1, there should be a reference for the =91setup=92 attribu= te. Also, when talking about SDP attributes, I=92d suggest to explicitly sa= y=93SDP setup attribute=94, or something similar. Q6: The introduction says that the draft updates rfc4582bis and rfc4583bis.= I think it would be good to have two explicit =93Updates to RFCXXXX=94 sec= tionsto list exactly what those updates are. Q7: Just to check: are the new SDP m- line proto values aligned with the na= ming approach that has taken place in MMUSIC? Regards, Christer _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis --_000_676DBA71E49F4D86B82E8263D70B6C35ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable @Charles - Ram and I are working on the updated version and hope to publish= it very soon. One additional request below.

@Christer - It would be helpful to get your review of the c= omplementary draft you requested (draft-ram-bfcpbis-sdp-ws-uri-00). That way we can update both at the same time. Let us know if this is something forthcoming. 

Thanks,

Gonzalo


On Aug 20, 2015, at 5:05 PM, Charles E= ckel (eckelcu) <eckelcu@= cisco.com> wrote:

Christer, 

Thanks for the review and comments.

Draft authors, when can we expect responses to Christer=92s comments, and/o= r a corresponding update to the draft?

Cheers,
Charles

From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Christer Holmberg <chri= ster.holmberg@ericsson.com>
Date: Thursday, July 2, 2015 at 11:12 AM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Cc: "alissa@cooperw.in" <alissa@cooperw.in>
Subject: [bfcpbis] Review of draft-ietf-bfcpbis-bfcp-websocket-04

Hi,
 
Below is my review of draft-ietf-bfcpbis-bfcp-websocket-04.
 
In general, things look good, and my comments should be mostly editorial. A= lso, my previous comments on the draft have been addressed. Thanks forthat!=
 
Q1: There are a few abbreviations (TLS, HTTP etc) that are not expanded on = first occurrence. I didn=92t check whether they are considered well knowndo= uble check.
 
Q2: I think the last paragraph of section 1, talking about not preventing o= ther mechanisms, can be removed completely.
 
(I think I previously had the same comment on the draft =96 or maybe it was= another WebSocket sub-protocol draft)
 
Q3: Section one says =93since WebSocket is a reliable transport=94. Perhaps= =93provides a reliable transport=94 would be better?
 
Q4: Section 5 says =93WebSocket [RFC6455] is a reliable protocol=94. I don= =92t know what =93reliable protocol=94 means, but I assume this text should= also talkabout providing reliable transport.
                     = ;                     &nb= sp;                     &= nbsp;               
Q5: In section 6.1, there should be a reference for the =91setup=92 attribu= te. Also, when talking about SDP attributes, I=92d suggest to explicitly sa= y=93SDP setup attribute=94, or something similar.
 
Q6: The introduction says that the draft updates rfc4582bis and rfc4583bis.= I think it would be good to have two explicit =93Updates to RFCXXXX=94 sec= tionsto list exactly what those updates are.
 
Q7: Just to check: are the new SDP m- line proto values aligned with the na= ming approach that has taken place in MMUSIC?
 
Regards,
 
Christer
 
 
 
 
 
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis

--_000_676DBA71E49F4D86B82E8263D70B6C35ciscocom_-- From nobody Mon Aug 24 06:00:23 2015 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECD81B3464; Mon, 24 Aug 2015 06:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIRW1Ak4_oki; Mon, 24 Aug 2015 06:00:16 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCC11B3430; Mon, 24 Aug 2015 06:00:06 -0700 (PDT) Received: by lalv9 with SMTP id v9so76691145lal.0; Mon, 24 Aug 2015 06:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3VPs2ooIzQoFV3eqB1m08W3t3pXUwBaBJqHrQL+LmHU=; b=MfyF54ien1s2STzj/tMTyfupNKtedB9IIhU5ScdaKmJr6bjdNupQA3+Silirim0fYn De02jFdJIveBKMV/CvxX2fJa1aphuLYDOa6QZAYYtxOB5sq4+OSBz/RISCpO3rhFIkeT yHCrf8RUObDdVzg5U1WYvsHekUAo6UD+Xr4ddmnk6wjKzpjgiOUkzuuYdkEv2M4kOeRp CVIm1lQbE2xkFBdTSWaFfxxt6LXf8VA6cddI3ydCGFvhB1LsQA0xe9Uu8sESLawTwL47 vI2iOf0PKaan5fheiJ6Y4hqdjwwPno0bEYZryPiOixRI9gRb54l23R+EfzKOPAQZqC+d XW2w== MIME-Version: 1.0 X-Received: by 10.112.234.165 with SMTP id uf5mr19616960lbc.91.1440421204882; Mon, 24 Aug 2015 06:00:04 -0700 (PDT) Received: by 10.25.79.208 with HTTP; Mon, 24 Aug 2015 06:00:04 -0700 (PDT) In-Reply-To: References: <20150219174215.4401.59106.idtracker@ietfa.amsl.com> Date: Mon, 24 Aug 2015 15:00:04 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a11c3d2bc3e7c94051e0e327c Archived-At: Cc: "drafts-lastcall@iana.org" , "bfcpbis@ietf.org" , "draft-ietf-bfcpbis-rfc4582bis.all@ietf.org" , "bfcpbis-chairs@ietf.org" Subject: Re: [bfcpbis] [IANA #840618] Re: Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 13:00:21 -0000 --001a11c3d2bc3e7c94051e0e327c Content-Type: text/plain; charset=UTF-8 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) 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" > 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 >> 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)' > >> > > 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/ --001a11c3d2bc3e7c94051e0e327c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree. Noting the 0 value as reserved is probably the wa= y signal "stay away from using it" too.

-- Tom

On 20 August 2015 at 20:46, Charles Eckel (eckelcu) <eckelcu@cisco.= com> wrote:
My understandin= g 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.=C2=A0 Aut= hors should
>> > review
>> > the comments and/or questions below.=C2=A0 Please report any = inaccuracies
>> > and
>> > respond to any questions as soon as possible.
>> >
>> > IANA has some questions about the IANA actions requested in t= his
>> > draft.
>> >
>> > We received the following comments/questions from the IANA= 9;s
>> > reviewer:
>> >
>> > IANA understands that, upon approval of this document there a= re four
>> > actions which IANA must complete.
>> >
>> > First, the document directs IANA to establish a Attribute sub= registry
>> > of
>> > the The Binary Floor Control Protocol (BFCP) Parameters regis= try
>> > located at:
>> >
>> > http://www.iana.org/assignments/bfcp-p= arameters/
>> >
>> > IANA observes that the initial values provided in the documen= t being
>> > considered are already in the existing Attribute subregistry.= =C2=A0 Thus:
>> >
>> > - IANA will simply change the reference for the subregistry a= nd its
>> > registrations from RFC 4582 to [ RFC-to-be ].
>> > - This draft revises the registration procedure from "St= andards-Track
>> > RFC"
>> > to "Specification
>> > Required" as defined in RFC5226.=C2=A0 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?=C2=A0 An= d if so,
>> > should value 0
>> > be marked as Reserved in the registry?=C2=A0 =C2=A0Is there a= maximum value of
>> > this
>> > registry?
>> > 32-bit?=C2=A0 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 regis= try
>> > located at:
>> >
>> > http://www.iana.org/assignments/bfcp-p= arameters/
>> >
>> > IANA observes that the initial values provided in the documen= t being
>> > considered, with four exceptions, are already in the existing=
>> > Primitive
>> > subregistry.=C2=A0 Thus:
>> >
>> > - IANA will simply change the reference for the subregistry a= nd its
>> > registrations from RFC 4582 to [ RFC-to-be ].
>> > - This draft revises the registration procedure from "St= andards-Track
>> > RFC"
>> > to "Specification
>> > Required" as defined in RFC5226.=C2=A0 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?=C2= =A0 And if so,
>> > should value 0
>> > be marked as Reserved in the registry?=C2=A0 =C2=A0Is 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 re= gistry
>> > located
>> > at:
>> >
>> > http://www.iana.org/assignments/bfcp-p= arameters/
>> >
>> > IANA observes that the initial values provided in the documen= t being
>> > considered, are already in the existing Request Status subreg= istry.
>> > Thus:
>> >
>> > - IANA will simply change the reference for the subregistry a= nd its
>> > registrations from RFC 4582 to [ RFC-to-be ].
>> > - This draft revises the registration procedure from "St= andards-Track
>> > RFC"
>> > to "Specification
>> > Required" as defined in RFC5226.=C2=A0 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?=C2=A0 =C2=A0Is= there a maximum
>> > value
>> > for this
>> > registry? 8-bit?=C2=A0 Or is this an unlimited resource regis= try?
>> >
>>
>> The first value of BFCP request status values is 1 and an 8-bit fi= eld
>> 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 regis= try
>> > located at:
>> >
>> > http://www.iana.org/assignments/bfcp-p= arameters/
>> >
>> > IANA observes that the initial values provided in the documen= t being
>> > considered, with five exceptions, are already in the existing= Error
>> > Code
>> > subregistry.=C2=A0 Thus:
>> >
>> > - IANA will simply change the reference for the subregistry a= nd its
>> > registrations from RFC 4582 to [ RFC-to-be ].
>> > - This draft revises the registration procedure from "St= andards-Track
>> > RFC"
>> > to "Specification
>> > Required" as defined in RFC5226.=C2=A0 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 value= s?
>> And
>> > if so, should
>> > value 0 be marked as Reserved in the registry?=C2=A0 =C2=A0Is= there a maximum
>> > value
>> > for this
>> > registry?=C2=A0 32-bit?=C2=A0 Or is this an unlimited resourc= e 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 re= quired
>> > to be
>> > completed upon approval of this document.
>> >
>> > Note:=C2=A0 The actions requested in this document will not b= e completed
>> > until
>> > the document has been approved for publication as an RFC. Thi= s
>> > message is
>> > only to confirm what actions will be performed.
>> >
>>
>> Sounds good and should be the action needed when this draft become= s 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 Co= ntrol
>> > > Protocol
>> > > Bis=C2=A0 WG (bfcpbis) to consider the following documen= t:
>> > > - 'The Binary Floor Control Protocol (BFCP)'
>> > >=C2=A0 =C2=A0<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 c= omments to
>> > > the
>> > > ietf@ietf.org maili= ng 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 ac= cess to
>> > > shared resources in a (multiparty) conferencing environm= ent.
>> > > Thereby, floor control complements other functions -- su= ch as
>> > > conference and media session setup, conference policy ma= nipulation,
>> > > and media control -- that are realized by other protocol= s.
>> > >
>> > > This document specifies the Binary Floor Control Protoco= l (BFCP).
>> > > BFCP is used between floor participants and floor contro= l servers,
>> > > and between floor chairs (i.e., moderators) and floor co= ntrol
>> > > servers.
>> > >
>> > > This document obsoletes RFC 4582.=C2=A0 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/do= c/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/bfc= pbis
>> >
>
>
>




--
=
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepre= sence/
## to= mkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0htt= p://folk.uio.no/tomkri/
--001a11c3d2bc3e7c94051e0e327c--