[bfcpbis] Spencer Dawkins' Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS)

["Spencer Dawkins" <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-bfcpbis-rfc4582bis-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

For the moment, I'm balloting a process Discuss, because I'm not seeing a
response to Gorry Fairhurst's TSV-DIR review sent on March 2, at
https://www.ietf.org/mail-archive/web/ietf/current/msg92156.html. Did I
miss it?

During my review, I did not see a definition of "transaction failure
window". I can guess what that means, but would love to know for sure.

I'm understanding that in RFC 4582, the version number (1) was a version
number, but in this draft, version 1 means "reliable transport" and
version 2 means "unreliable transport". Is that right? If so, how does an
RFC 4582 TCP-only floor control server receive a message with a version
field set to 2, which would have been sent over UDP?

I'm also wondering whether overloading the version number field as a
transport reliability indicator would cause a problem in the future. If
you end up with a mandatory extension that applies to both reliable and
unreliable transport, does that mean you'd use two version numbers
(possibly 2 for reliable and 3 for unreliable)?

Within Gorry's review, these are the points I thought were
Discuss-worthy. It's probably best for you to reply to these in his
e-mail, rather than try to juggle two sets of overlapping comments. I'm
just pointing out what I think matters most. On the others, please do the
right thing.

-

Gorry asked in Section 5:

What is the security model when TLS/DTLS is not used? - has the protocol
protection from off-path attacks, and how is this provided?

I'm especially interested in this question when unreliable transport is
used without DTLS. This is probably related to the question about
randomizing Conference ID later in Gorry's review.

- 

Payload Length:
- What happens when using a datagram format if the datagram length (e.g.
UDP-Length) is less or more than the value specified within the BFCP?

-

Fragment Length:
- What happens if the datagram length (e.g. UDP-Length) is less or more
than the value specified within the BFCP?