From: "Paul E. Jones" <paulej@packetizer.com>
To: draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, bfcpbis-chairs@ietf.org,
 bfcpbis@ietf.org, IESG <iesg@ietf.org>,
 "Tom Kristensen" <tomkrist@cisco.com>, gen-art@ietf.org
Date: Tue, 22 Sep 2015 20:49:36 +0000
Message-Id: <em2240cd8c-30a7-454b-9e88-40b7f39ab393@sydney>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------=_MB37DD9864-0D96-4966-9A61-1FF24B3E135A"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/jiBBlYvXiOAsGOGBMYVNXGxHdlA>
Cc: Alissa Cooper <alissa@cooperw.in>
Subject: [Gen-art] Comments on draft-ietf-bfcpbis-rfc4582bis-14
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>


--------=_MB37DD9864-0D96-4966-9A61-1FF24B3E135A
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Folks,

Alissa asked me to review the current text, provide input, and help=20
address some of the current DISCUSS points.

Here are some suggested improvements:

Editorial:
In Section 4.1, it says "Subsequent FloorStatus messages consist of=20
server-initiated transactions, and therefore their Transaction ID is 0."=
=20
  This is true since the transport in these examples is reliable.  While=
=20
perhaps minor, I think it might be worth explicitly stating that be=20
appending "given the example uses a reliable transport", otherwise the=20
reader may miss that there is a difference in behavior when=20
communicating over unreliable transports.In 5.3.7, it says "the=20
following is the format of the FloorRequest message".  That should be=20
"FloorQuery message"In 6.2.3, the equation:
  (message size - COMMON-HEADER size / MTU size - COMMON-HEADER size)
for better readability should say:
  ((message size - COMMON-HEADER size) / (MTU size - COMMON-HEADER=20
size))In 10.2.2, it reads "A message from the floor control server is=20
considered a response to the FloorRelease message if the message from=20
the floor control server has the same Conference ID, Transaction ID, and=
=20
User ID as the FloorRequest message."  I believe "FloorRequest" should=20
be "FloorRelease".A similar copy/paste error as above was noted in=20
12.1.2.I think it would be beneficial in Appendix A to explicitly show=20
what the "R" value is.  It is possible for a floor participant and a=20
floor control server to each initiate a transaction at the same time=20
with Transaction ID =3D=3D 124, for example.  The "R" bit is what helps =
to=20
differentiate transactions and their responses, and I think that would=20
be helpful here.
Technical:
Section 10.1.1 says the "User ID will be used by the floor control=20
server to authenticate and authorize the request."  TLS/DTLS is used for=
=20
authentication/authorization presently.  Further, the draft more than=20
once that other mechanisms might be developed in the future.  Merely=20
looking at this field in a message, though, is not sufficient to=20
authenticate or authorize a request.  This existed in the original RFC,=20
but I propose we strike the sentence.
Paul

--------=_MB37DD9864-0D96-4966-9A61-1FF24B3E135A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE id=3DeMClientCss>
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;=
 padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin=
g-top: 0px; }
.plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh=
t: normal; font-style: normal; white-space: pre-wrap; }
a img { border: 0px; }body {font-family: Calibri;font-size: 11pt;}
.plain pre, .plain tt {font-family: Calibri;font-size: 11pt;}</STYLE>
</HEAD>
<BODY>
<DIV>Folks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Alissa asked me to review the current text, provide input, and help=
 address some of the current DISCUSS points.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Here are some suggested improvements:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Editorial:</DIV>
<UL>
<LI>In Section 4.1, it says "Subsequent FloorStatus messages consist of =
server-initiated transactions, and therefore their Transaction ID is 0."&nb=
sp; This is true since the transport in&nbsp;these examples is reliable.&nb=
sp;&nbsp;While perhaps minor, I think it might be worth explicitly stating=
 that be&nbsp;appending "given the example uses a&nbsp;reliable transport",=
 otherwise the reader may miss that there is a difference in behavior&nbsp;=
when communicating over&nbsp;unreliable transports.</LI>
<LI>In 5.3.7, it says "the following is the format of the FloorRequest mess=
age".&nbsp; That should be "FloorQuery message"</LI>
<LI>In 6.2.3, the equation:<BR>&nbsp;(message size - COMMON-HEADER size =
/ MTU size - COMMON-HEADER size)<BR>for better readability should say:<BR>&=
nbsp;((message size - COMMON-HEADER size) / (MTU size - COMMON-HEADER size)=
)</LI>
<LI>In 10.2.2, it reads "A message from the floor control server is conside=
red a response to the <STRONG>FloorRelease </STRONG>message if the message=
 from the floor control server has the same Conference ID, Transaction ID,=
 and User ID as the <STRONG>FloorRequest</STRONG> message."&nbsp; I believe=
 "FloorRequest" should be "FloorRelease".</LI>
<LI>A similar&nbsp;copy/paste error as above&nbsp;was noted in 12.1.2.</LI>
<LI>I think it would be beneficial in Appendix A to explicitly show what=
 the "R" value is.&nbsp; It is possible for a floor participant and a floor=
 control server to each initiate a transaction at the same time with Transa=
ction ID =3D=3D 124, for example.&nbsp; The "R" bit is what helps to differ=
entiate transactions and their responses, and I think that would be helpful=
 here.</LI></UL>
<DIV>Technical:</DIV>
<UL>
<LI>Section 10.1.1 says the "User ID will be used by the floor control serv=
er to authenticate and authorize the request."&nbsp; TLS/DTLS is used for=
 authentication/authorization presently.&nbsp; Further, the draft more than=
 once that other mechanisms might be developed in the future.&nbsp;&nbsp;Me=
rely looking at this field in a message, though,&nbsp;is not sufficient =
to authenticate or authorize a request.&nbsp; This existed in the original=
 RFC, but I propose we strike the sentence.</LI></UL>
<DIV>Paul</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>
--------=_MB37DD9864-0D96-4966-9A61-1FF24B3E135A--