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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 22 Sep 2012 00:36:09 +0000

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: [email-masked]
> 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

---

From: Mary Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 16:13:59 -0500

I have reviewed the document and it looks pretty much ready.

I do have a couple of questions for clarification:
- Section 5.1 - Payload Length: states that "receiving server MAY send an
Error message"
but I would think that the client should know about the error. Is there a
specific reason this is a MAY versus a SHOULD or even a MUST? Why would the
error message matter if it's not required?

- Section 5.2 - "M" after Table 2 - I have a similar question about the 'M'
bit. RFC 4582 states that message is rejected if there is an unrecognized M
bit, whereas this document states that an error message MAY be sent.
Certainly, 4582 lacked appropriate normative language, but if the error
message is just a MAY, then why bother?

There are also a few nits that should be fixed/clarified before progressing.

Section 5.2.6 - Note under table 5:    "intended being used" -> "intended
to be used"

Section 6.1.: "e.g.,"  was changed to "e.g.".   The former is correct.

Section 9.1: You lost some indented paragraphs in this section - i.e., they
got shifted to align with the other paragraphs in that section.  I'm not
sure if that was intentional.

Section 16:
- New Primitives.  The text says five were added, but only 4 are listed and
that's all that's all that's defined per Figure 1.
- New error codes.  The text says that 3 are aded, but it looks there's
really 5 that have been added.
- Typo.  Referring to section 12.4.2 states that the change was from
SUPPORTED-PRIMITIVES
to SUPPORTED-PRIMITVIES but the latter is really the typo.

Regards,
Mary

On Fri, Sep 21, 2012 at 7:36 PM, Charles Eckel (eckelcu)
<[email-masked]>wrote:

> 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)
>
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 24 Sep 2012 22:18:09 +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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: Friday, September 21, 2012 5:36 PM
> To: [email-masked]
> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis
>

---

From: "Horvath, Ernst" <[email-masked]>
Date: Tue, 25 Sep 2012 10:28:37 +0000

Currently 6.3.2 "NAT Traversal" is a subsection of 6.3 "Large Message Considerations". Is this really the intention, or should NAT Traversal better be renumbered as section 6.4?

Regards,
Ernst

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: Samstag, 22. September 2012 02:36
> To: [email-masked]
> 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)
>