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

["Paul E. Jones" <[e-mail]>]

Spencer,

Following up on this email (and building a growing to-do list)....

------ Original Message ------
From: "Spencer Dawkins" <[e-mail]>
To: "The IESG" <[e-mail]>
Cc: [e-mail]; 
[e-mail]; [e-mail]; 
[e-mail]
Sent: 3/4/2015 11:38:26 PM
Subject: [bfcpbis] Spencer Dawkins' Discuss on 
draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS)

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

I did not see a reply, either, so I just sent one.  Several good points 
in there, as you might see in my response.


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

Agree, this would help to have that term.


>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?
You understanding of "ver" is correct.  The error-handling text is there 
just for completeness. In theory, there should never be a ver==1 over 
UDP or ver==2 over TCP.

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

If a version 3 device sends messages over TCP, then the v1/v2 servers 
will reject it.  That would have to be dealt with at that time, such as 
falling back to v1 mode if the server is v1.


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

He had a lot of good points.  I replied to each one, so I'll not repeat 
that here (as you suggest).


>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?
All of the above are in a reply to Gorry (and I CC'd you).

Paul


>