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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 8 Oct 2012 18:09:12 +0000

(as an individual)

Hi Horvath,

Sorry for the delay in responding. I agree that NAT traversal should not be a subsection of Large message considerations; however, I think it would be better to relocate it to section 6.2.3 as a part of Section 6.2 "Unreliable Transport".

     6.2.  Unreliable Transport . . . . . . . . . . . . . . . . . . . 
       6.2.1.  Congestion Control . . . . . . . . . . . . . . . . . . 
       6.2.2.  ICMP Error Handling  . . . . . . . . . . . . . . . . . 
       6.2.3.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . 
     6.3.  Large Message Considerations . . . . . . . . . . . . . . . 
       6.3.1.  Fragmentation Handling . . . . . . . . . . . . . . . . 

Cheers,
Charles

> -----Original Message-----
> From: Horvath, Ernst [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2012 3:29 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: WGLC for draft-ietf-bfcpbis-rfc4582bis
> 
> 
> 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
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> > Sent: Samstag, 22. September 2012 02:36
> > To: [email-masked]
> > 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: [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
> > _______________________________________________
> > bfcpbis mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/bfcpbis
> >

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 10 Oct 2012 10:52:33 +0200

Actually, my proposal would be to move both the subsections under 6.2 
"Unreliable Transport", since the "NAT Traversal" and "Large 
Message..."/"Fragmentation Handling" is written in the UDP/BFCP context.

I also propose to collapse the section "Large Message..." and its 
subsection "Fragmentation Handling" into one, since the main thing here 
is to describe the fragmentation handling solution.

OK?

-- Tom

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 10 Oct 2012 11:03:54 +0200

On 09/25/2012 12:18 AM, Charles Eckel (eckelcu) wrote:

Reply comments inline.

> (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 agree. Good catch as well, since the section 4 text is unchanged from 
RFC 4582 - and amusingly enough fits with the semantics of UDP/BFCP!
> 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
>    
OK.
> 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.
>    
OK for 2) and 3). Easier to read and understand.
> 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.
>    
Fine, but I'll add "... or message segment" to the previous sentence, so 
that it reads:
  "Each BFCP UDP datagram MUST contain exactly
    one BFCP message or message segment"
> 5) Section 6.2,
> r/Entities MUST only have at most one/Entities MUST have at most one
>    
Agree, better language!
> 6) Section 6.2.1
> r/attempt, this is identical/attempt. This is identical
OK.

I'll change the upcoming rfc4582bis version accordingly if no objections 
or further comments on these issues are received.

-- Tom

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 10 Oct 2012 11:16:30 +0200

On 09/24/2012 11:13 PM, Mary Barnes wrote:
> 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?

I don't remember why MAY was chosen here, but after having a look at 
this again I see that SHOULD is used for sending an Error message twice 
in the original RFC 4582. So, we should (!) change to SHOULD.  OK?

> - 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?

Yeah, why bother ;-)
We'll change to SHOULD. However, it wouldn't harm using MUST for sending 
these error messages - apart from that SHOULD is used in RFC 4582 and 
that is my main reason for suggesting using SHOULD here.

> 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"

OK

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

OK

> 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.

What do you mean? Same white space indentation as in RFC 4582, isn't it?

> 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.

Fine, good catches - will change.

I'll change accordingly ASAP in the new version if no objections are 
provided!

-- Tom

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 10 Oct 2012 15:22:21 +0000

Works for me. I originally thought we might also address BFCP messages that  exceeded the 16 bit payload length field, and I structured the section accordingly. We decided to not tackle that, but the section structure remained anyway. I like your proposal.
As part of the reorganization, it may be worthwhile to change the text for what is  currently section 6.3 from:

   Large messages become a concern when using BFCP if the overall size
   of a single BFCP message exceeds that representable within the 16-bit
   Payload Length field of the COMMON-HEADER.  When using UDP, there is
   the added concern that a single BFCP message can be fragmented at the
   IP layer if its overall size exceeds the MTU threshold of the
   network.

To 

   The size of a BFCP message is limited by the 16-bit Payload Length field of the 
   COMMON-HEADER.  When using UDP, a single BFCP message may be fragmented 
   at the IP layer if its overall size exceeds the MTU threshold of the network.

After this, the information in what is currently section 6.3.1 can clearly be targeted at UDP only.

Cheers,
Charles

> From: Tom Kristensen (tomkrist)
> Sent: Wednesday, October 10, 2012 1:53 AM
> To: Charles Eckel (eckelcu)
> Cc: Horvath, Ernst; [email-masked]
> > Sorry for the delay in responding. I agree that NAT traversal should not be
> a subsection of Large message considerations; however, I think it would be
> better to relocate it to section 6.2.3 as a part of Section 6.2 "Unreliable
> Transport".
> >

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 10 Oct 2012 17:13:44 +0000

That all works for me.

Thanks,
Charles

> Sent: Wednesday, October 10, 2012 2:04 AM
> Cc: [email-masked]
> > 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:
> >
> > 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:
> >
> > I suggest replacing the section 4 text with the following introductory level
> text, that currently exists in section 8 .
> >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 24 Oct 2012 13:32:30 +0300

Hi Tom,

> in the original RFC 4582. So, we should (!) change to SHOULD.  OK?

yes, the sending of error responses should appear at the SHOULD level.

Thanks,

Gonzalo

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 24 Oct 2012 13:30:04 +0200

> yes, the sending of error responses should appear at the SHOULD level.

Good, this is fixed in the -06 version.

-- Tom