Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 24 September 2012 22:18 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B898421F85B1 for <bfcpbis@ietfa.amsl.com>; Mon, 24 Sep 2012 15:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPD+GYMWuN9W for <bfcpbis@ietfa.amsl.com>; Mon, 24 Sep 2012 15:18:11 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 00D4821F858F for <bfcpbis@ietf.org>; Mon, 24 Sep 2012 15:18:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5188; q=dns/txt; s=iport; t=1348525091; x=1349734691; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ES5upjWLQkk7G6BBCdEYUbYSGbGQDJpC9UuzwJyL3kE=; b=Gd8inxs8C7ZOXg50XJeclVjAXOqiLPfIWoH9Kc8rwGHOmYFNnDnAvq8X C/CHHrZzM6xtmjlluIt2NykFWrhFFgX5M5+ktDayLx/MJVp286otKotcw sPIrF0CwL4VqNtlSsgbGN3xxZwPYXn0HJV8t7JB4XAbwwKXlpXzUXBf/c g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADvbYFCtJXHA/2dsb2JhbABFvluBCIIgAQEBBAEBAQ8BCh0tBxcEAgEIEQQBAQsLCQkHJwsUCQgBAQQTCBqHYgELmFygIosbgxZTgXlgA5Z6jSWBaYJaDYIX
X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="124871302"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 24 Sep 2012 22:18:10 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8OMIATb003249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <bfcpbis@ietf.org>; Mon, 24 Sep 2012 22:18:10 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.66]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Mon, 24 Sep 2012 17:18:09 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: WGLC for draft-ietf-bfcpbis-rfc4582bis
Thread-Index: Ac2NAeUBlWZWMlJIRpyXKbtffhLaTQLV4YwwAJIvu8A=
Date: Mon, 24 Sep 2012 22:18:09 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C088280A8B97@xmb-aln-x08.cisco.com>
References: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280A5951@xmb-aln-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.68.122.22]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19206.004
x-tm-as-result: No--59.255600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2012 22:18:12 -0000

(as an individual)

I have reviewed the draft and I think that overall it is in very good shape. The only comment I would consider major is one dealing with section 4's description of server-initiated transactions:

Section 4 reads as follows:

   There are two types of transaction in BFCP: client-initiated
   transactions and server-initiated transactions.  Client-initiated
   transactions consist of a message from a client to the floor control
   server and a response from the floor control server to the client.
   Correspondingly, server-initiated transactions consist of a message
   from the floor control server to a client and the associated
   acknowledgement message from the client to the floor control server.
   Both messages can be related because they carry the same Transaction
   ID value in their common headers.

This is accurate when using UDP as the transport, but does not account for the case of using TCP as the transport. A more detailed and accurate description is provided in Section 8, which reads as follows:

   In BFCP, there are two types of transactions: client-initiated
   transactions and server-initiated transactions (notifications).
   Client-initiated transactions consist of a request from a client to a
   floor control server and a response from the floor control server to
   the client.  The request carries a Transaction ID in its common
   header, which the floor control server copies into the response.
   Clients use Transaction ID values to match responses with previously
   issued requests.

   Server-initiated transactions consist of a single message from a
   floor control server to a client.  Since they do not trigger any
   response, their Transaction ID is set to 0 when used over reliable
   transports, but must be non-zero and unique in the context of
   outstanding transactions over unreliable transports.

I suggest replacing the section 4 text with the following introductory level text, that currently exists in section 8 .

   In BFCP, there are two types of transactions: client-initiated
   transactions and server-initiated transactions (notifications).

The rest of the details currently in section 4 can  replaced with a reference to section 8.

I also have the following minor  comments.

1) Section 5.2.6, note after table 5
r/is intended being used/is intended to be used

2) Section 5.3.14 current reads as follows:

   Floor participants and chairs acknowledge the receipt of a subsequent
   FloorRequestStatus message from the floor control server when
   communicating over unreliable transport.

I suggest the following rewording:

   When communicating over unreliable transport, floor participants and chairs 
   acknowledge the receipt of a subsequent FloorRequestStatus message from 
   the floor control server by sending an FloorRequestStatusAck.

3) Similar change for section 5.3.15.

4) Section 6.2, currently contains the following fragment:
   
   Only allowing exactly one BFCP message or message segment per UDP
   datagram.  

This is covered previously in the paragraph, so this fragment can be removed.

5) Section 6.2,
r/Entities MUST only have at most one/Entities MUST have at most one

6) Section 6.2.1
r/attempt, this is identical/attempt. This is identical

Cheers,
Charles


> -----Original Message-----
> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: Friday, September 21, 2012 5:36 PM
> To: bfcpbis@ietf.org
> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis
> 
> Just a gentle reminder that we are into the last week for comments. Please
> review the draft and submit your comments by the Sept 28th, 2012 deadline
> (not 2011 as erroneously typed previously)
> 
> Thanks,
> Charles (as co-chair)
> 
> > -----Original Message-----
> > From: Charles Eckel (eckelcu)
> > Sent: Friday, September 07, 2012 7:06 AM
> > To: bfcpbis@ietf.org
> > Subject: WGLC for draft-ietf-bfcpbis-rfc4582bis
> >
> > (As WG co-chair)
> >
> > This is to announce a working group last call for draft-ietf-bfcpbis-
> > rfc4582bis, "The Binary Floor Control Protocol (BFCP)".
> > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/
> >
> > This is intended as a Standards Track RFC, obsoleting RFC 4582.
> > Please respond to the list by September 28th 2011 (i.e. 3 weeks) with any
> > comments.
> >
> > It is helpful to attempt to categorize your comment (e.g. technical issue vs.
> > editorial), and also  to provide any replacement text you feel is necessary.
> > If you review the document and have no comments, please tell the chairs
> > that you have reviewed it. This is always useful information in assessing
> the
> > degree of WG review and consensus behind the document.
> > Note, another WGLC for draft-ietf-bfcpbis-rfc4583bis will be run in
> parallel.
> >
> > Cheers,
> > Charles
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis