Skip to content
This repository was archived by the owner on Jun 9, 2022. It is now read-only.

Editorial suggestions from Benjamin Kaduk's IESG review #79

Open
kaduk wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Editorial suggestions from Benjamin Kaduk's IESG review #79

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 25 additions & 24 deletions draft-ietf-tsvwg-rfc4960-bis.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -146,7 +146,7 @@ as SYN attacks.</t></li>
for which all of these limitations of TCP are relevant.
While this application directly motivated the development of SCTP, other
applications might find SCTP a good match to their requirements.
One example for this are datachannels in the WebRTC infrastructure.</t>
One example of this is the use of data channels in the WebRTC infrastructure.</t>
</section>

<section>
Expand Down Expand Up @@ -217,7 +217,7 @@ addresses.</t>
</dd>
<dt>Bundling:</dt>
<dd>
<t>An optional multiplexing operation, whereby more than one user message can
<t>An optional multiplexing operation, whereby more than one user or control message can
be carried in the same SCTP packet.
Each user message occupies its own DATA chunk.</t>
</dd>
Expand All @@ -244,7 +244,7 @@ the Cumulative TSN Ack field of a SACK chunk.</t>
</dd>
<dt>Flightsize:</dt>
<dd>
<t>The amount of bytes of outstanding data to a particular destination transport
<t>The number of bytes of outstanding data to a particular destination transport
address at any given time.</t>
</dd>
<dt>Idle destination address:</dt>
Expand Down Expand Up @@ -272,7 +272,7 @@ messages sent within the stream on which the message was sent.</t>
</dd>
<dt>Outstanding data (or "data outstanding" or "data in flight"):</dt>
<dd>
<t>The total amount of the DATA chunks associated with outstanding TSNs.
<t>The total size of the DATA chunks associated with outstanding TSNs.
A retransmitted DATA chunk is counted once in outstanding data.
A DATA chunk that is classified as lost but that has not yet been
retransmitted is not in outstanding data.</t>
Expand Down Expand Up @@ -382,7 +382,7 @@ correlations if they are so desired.</t>
<dd>
<t>A 16-bit sequence number used internally by SCTP to ensure sequenced delivery
of the user messages within a given stream.
One Stream Sequence Number is attached to each user message.</t>
One Stream Sequence Number is attached to each (ordered) user message.</t>
</dd>
<dt>Tie-Tags:</dt>
<dd>
Expand Down Expand Up @@ -699,7 +699,7 @@ have been incorporated in this document:</t>
<li><t>Describe the packet size handling more precise by introducing PMTU,
PMDCS and AMDCS.</t></li>
<li><t>Add the definition of control chunk.</t></li>
<li><t>Improve the description of the handling of INIT chunks with invalid
<li><t>Improve the description of the handling of INIT and INIT ACK chunks with invalid
mandatory parameters.</t></li>
<li><t>Allow using L > 1 for Appropriate Byte Counting (ABC) during
slow start.</t></li>
Expand All @@ -708,7 +708,7 @@ have been incorporated in this document:</t>
<li><t>Improve the terminology to make clear that this specification does not
describe a full mesh architecture.</t></li>
<li><t>Improve the description of sequence number generation
(TSN and SSN).</t></li>
(TSN and Stream Sequence Number).</t></li>
<li><t>Improve the description of reneging.</t></li>
<li><t>Don't require the change of the cumulative TSN ACK anymore for increasing
the congestion window.
Expand Down Expand Up @@ -740,7 +740,7 @@ A chunk contains either control information or user data.</t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<t>INIT, INIT ACK and SHUTDOWN COMPLETE chunks MUST NOT be bundled
into one SCTP packet.
with any other chunks into an SCTP packet.
All other chunks MAY be bundled to form an SCTP packet that does not exceed
the PMTU.
See <xref target='sec_bundling'/> for more details on chunk bundling.</t>
Expand Down Expand Up @@ -899,7 +899,7 @@ Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length field will be
set to 4.
The Chunk Length field does not count any chunk padding.
However, it does include padding of any variable-length parameter except the
However, it does include any padding of variable-length parameters other than the
last parameter in the chunk.</t>
<t>Note: A robust implementation is expected to accept the chunk whether or not
the final padding has been included in the Chunk Length.</t>
Expand Down Expand Up @@ -1021,9 +1021,10 @@ parameters and has to report them according to
<xref target='sec_parameter_format'/>, it SHOULD bundle the ERROR chunk
containing the "Unrecognized Parameters" error cause with the chunk sent
in response (e.g., COOKIE ECHO).
If the receiver of the INIT ACK chunk cannot bundle the COOKIE ECHO chunk with
the ERROR chunk, the ERROR chunk MAY be sent separately but not before the
COOKIE ACK chunk has been received.</t>
If the receiver of the chunk with unrecognized parameters cannot bundle the
ERROR chunk with the chunk sent in response,
the ERROR chunk MAY be sent separately but not before the
chunk sent in response has been received.</t>
Copy link
Member

@tuexen tuexen Dec 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your suggestion misses the point we want to make:

In the special case of unrecognized parameters in the INIT ACK chunk and the inability of bundling the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk can be sent separately, but only after the COOKIE ACK has been received. This avoids the case that if the packet containing the ERROR chunk arrives before the packet containing the COOKIE ECHO chunk arrives. If that would happen, the ERROR would result in destroying the association.

In other situations, there should not be a problem with arriving the packet with the ERROR chunk first. Therefore I think this change is not needed.

Copy link
Member

@tuexen tuexen Jan 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm marking this as resolved. If you don't agree, please unresolve this conversation.

Copy link
Author

@kaduk kaduk Jan 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was trying to be editorial consistency -- in the previous sentence we say "the chunk sent in response (e.g., COOKIE ECHO)". To me, that suggests that "the chunk sent in response" is the preferred identifier for that chunk, and "e.g., COOKIE ECHO" indicates that COOKIE ECHO is a typical type of chunk to be sent in response but that other types of chunk are possible. Your first response suggests that the COOKIE ECHO nature is quite important here, and points out that I had conflated COOKIE ECHO and COOKIE ACK in part of my suggested change. So, the COOKIE ACK text needs to stay as COOKIE ACK, I definitely agree. Additionally, if the only possible "chunk sent in response" is COOKIE ECHO, my proposal would be to s/e.g./i.e./ in the previous sentence and continue to use COOKIE ECHO (and COOKIE ACK) in this sentence. If other chunk types are possible, then my proposal would be to apply s/the/a/ in a few places (and continue to use COOKIE ECHO and COOKIE ACK), since the use of the definite article implies that there is always exactly one in the situation being described.

Copy link
Member

@tuexen tuexen Jan 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the receiver of any other chunk refers to any chunk different from the INIT chunk. In the context of this base specification, the INIT ACK chunk is the canonical example, but there are other chunks (mostly defined in extensions) this text applies to.

The text in the sentence you are improving proves a consideration for a special case, which has two prerequisites:

  1. The chunk containing unrecognized parameters is an INIT ACK chunk and
  2. the receiver of the INIT ACK chunk can not bundle the COOKIE ECHO with the ERROR chunk

Only if these two conditions are met, the sending of the ERROR needs to be delayed until the COOKIE ACK has been received.

How about using:

If the receiver of an INIT ACK chunk cannot bundle the COOKIE ECHO chunk with
the ERROR chunk, the ERROR chunk MAY be sent separately but not before the
COOKIE ACK chunk has been received.</t>

Does that address your issue?

<t>Any time a COOKIE ECHO chunk is sent in a packet, it MUST be the first
chunk.</t>
</section>
Expand Down Expand Up @@ -1242,7 +1243,7 @@ to the INIT chunk.</t>
<t>The Chunk Flags field in INIT chunks is reserved, and all bits in it SHOULD
be set to 0 by the sender and ignored by the receiver.
The sequence of parameters within an INIT chunk can be processed in any
order.</t>
order (but must appear within the chunk in the order indicated above).</t>
<dl newline="true">
<dt>Initiate Tag: 32 bits (unsigned integer)</dt>
<dd>
Expand Down Expand Up @@ -1275,8 +1276,8 @@ however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks.</t>
to create in this association.
The value of 0 MUST NOT be used.</t>
<t>A receiver of an INIT chunk with the OS value set to 0 MUST discard the
packet, SHOULD send a packet in response containing an ABORT chunk and using
the Initiate Tag as the Verification Tag, and MUST NOT change the state of any
packet, SHOULD send a packet in response containing an ABORT chunk with the
T bit set, and MUST NOT change the state of any
existing association.</t>
</dd>
<dt>Number of Inbound Streams (MIS): 16 bits (unsigned integer)</dt>
Expand All @@ -1288,8 +1289,8 @@ The value 0 MUST NOT be used.</t>
two endpoints will use the min(requested, offered).
See <xref target='sec_handle_stream_parameters'/> for details.</t>
<t>A receiver of an INIT chunk with the MIS value set to 0 MUST discard the
packet, SHOULD send a packet in response containing an ABORT chunk and using
the Initiate Tag as the Verification Tag, and MUST NOT change the state of any
packet, SHOULD send a packet in response containing an ABORT chunk with the
T bit set, and MUST NOT change the state of any
existing association.</t>
</dd>
<dt>Initial TSN (I-TSN): 32 bits (unsigned integer)</dt>
Expand Down Expand Up @@ -1377,8 +1378,8 @@ Address Translation (NAT).</t>

<section>
<name>Cookie Preservative (9)</name>
<t>The sender of the INIT chunk SHOULD use this parameter to suggest to the
receiver of the INIT chunk for a longer life-span of the State Cookie.</t>
<t>The sender of the INIT chunk uses this parameter to suggest to the
receiver of the INIT chunk a longer life-span for the State Cookie.</t>
<artwork align='center'>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Expand Down Expand Up @@ -1904,7 +1905,7 @@ chunk (see <xref target='sec_heartbeat_ack_chunk'/>).
Note also that the HEARTBEAT chunk is both for reachability checking and for
path verification (see <xref target='sec_path_verifiation'/>).
When a HEARTBEAT chunk is being used for path verification purposes, it MUST
hold a random nonce of length 64-bit or longer (<xref target='RFC4086'/>
include a random nonce of length 64-bit or longer (<xref target='RFC4086'/>
provides some information on randomness guidelines).</t>
</dd>
</dl>
Expand Down Expand Up @@ -3110,8 +3111,8 @@ respond with an INIT ACK chunk using the same parameters it sent in its
original INIT chunk (including its Initiate Tag, unchanged), provided
that no NEW address has been added to the forming association.
If the INIT chunk indicates that a new address has been added to the
association, then the entire INIT chunk MUST be discarded, and SHOULD NOT do any
changes to the existing association.
association, then the entire INIT chunk MUST be discarded, and SHOULD NOT
change the state of any existing association.
An ABORT chunk SHOULD be sent in response that MAY include the error
'Restart of an association with new addresses'.
The error SHOULD list the addresses that were added to the restarting
Expand Down Expand Up @@ -4433,7 +4434,7 @@ transmission.</t></li>
the destination addresses it can send to (not each source-destination pair but
for each destination).
The parameters SHOULD decay if the address is not used for a long enough time
period. <xref target='RFC5681'/> specifies this long enough time as a
period. <xref target='RFC5681'/> specifies this "long enough time" as a
retransmission timeout.</t></li>
<li><t>For each of the destination addresses, an endpoint does slow start upon
the first transmission to that address.</t></li>
Expand Down Expand Up @@ -6480,7 +6481,7 @@ clear this flag.</t>
<dt>last-time:</dt>
<dd>
<t>The time to which this destination was last sent.
This can be to determine if the sending of a HEARTBEAT chunk is needed.</t>
This can be used to determine if the sending of a HEARTBEAT chunk is needed.</t>
</dd>
</dl>
</section>
Expand Down