Subject: [tsvwg] [LB] Questions about draft-ietf-tsvwg-rfc4960-errata-08.txt

From: [email-masked]
Date: Fri, 11 Jan 2019 19:50:27 -0800 (PST)

Dear authors,

While editing draft-ietf-tsvwg-rfc4960-errata-08, we have the following questions.

Apologies for the long list of questions, but addressing these questions now should make the AUTH48 process for this document, as well as the overall process for the upcoming 4960bis document, go more smoothly.

Please reply so that your document will move forward in the publication process.

Thank you.

RFC Editor/lb

1) Section 1:  Does "the list" refer to the Transport Area
Working Group's tsvwg mailing list, or something else?  If yes, will
this be clear to readers even if not mentioned?

Original:
 Since
 this document is a historical record of the sequential changes that
 have been found necessary at various inter-op events and through
 discussion on the list, the last delta in the text is the one which
 should be applied.

2) Section 3.8.2:  We changed "COOKIE-ACK" in
"New text: (Section 5.1.6, Figure 4)" in this section to "COOKIE ACK"
(1) to match "COOKIE ACK" as used in "New text: (Section 5.1.6,
Figure 4)" in Section 3.9.2 and (2) per "Handle Duplicate COOKIE ACK"
in "New text: (Section 5.2.5)" in Section 3.9.2.  Please let us know
any objections.

Original (best viewed with a fixed-point font such as Courier; also,
  dashed lines are broken so that XML will not treat them as comments):
 - - - - -
 New text: (Section 5.1.6, Figure 4)
 - - - - -

 COOKIE ECHO [Cookie_Z] - - - \
 (Start T1-cookie timer)       \
 (Enter COOKIE-ECHOED state)    \- -> (build TCB enter ESTABLISHED
                                       state)
                                /- -  COOKIE-ACK
                               /
 (Cancel T1-cookie timer, <- -/
  Enter ESTABLISHED state)

Currently:
 - - - - -
 New text: (Section 5.1.6, Figure 4)
 - - - - -

 COOKIE ECHO [Cookie_Z] - - - \
 (Start T1-cookie timer)       \
 (Enter COOKIE-ECHOED state)    \- -> (build TCB, enter ESTABLISHED
                                       state)
                                /- -  COOKIE ACK
                               /
 (Cancel T1-cookie timer, <- -/
  enter ESTABLISHED state)

3) Sections 3.12.2 and 3.26.2, "New text: (Section 7.2.2)":
These sentences do not parse.  May we update as suggested?

Original:
 - - - - -
 New text: (Section 7.2.2)
 - - - - -

 o  When partial_bytes_acked is equal to or greater than cwnd and
    before the arrival of the SACK the sender had cwnd or more bytes
    of data outstanding (i.e., before arrival of the SACK, flightsize
    was greater than or equal to cwnd), partial_bytes_acked is reset
    to (partial_bytes_acked - cwnd).
...
 - - - - -
 New text: (Section 7.2.2)
 - - - - -
...
 o  When partial_bytes_acked is greater than cwnd and before the
    arrival of the SACK the sender had less than cwnd bytes of data
    outstanding (i.e., before arrival of the SACK, flightsize was less
    than cwnd), reset partial_bytes_acked to cwnd.

 o  When partial_bytes_acked is equal to or greater than cwnd and
    before the arrival of the SACK the sender had cwnd or more bytes
    of data outstanding (i.e., before arrival of the SACK, flightsize
    was greater than or equal to cwnd), partial_bytes_acked is reset
    to (partial_bytes_acked - cwnd).

Suggested:
 - - - - -
 New text: (Section 7.2.2)
 - - - - -

 o  (1) when partial_bytes_acked is equal to or greater than cwnd and
    (2) before the arrival of the SACK the sender had cwnd or more
    bytes of data outstanding (i.e., before the arrival of the SACK,
    flightsize was greater than or equal to cwnd), partial_bytes_acked
    is reset to (partial_bytes_acked - cwnd).  Next, cwnd is increased
    by 1*MTU.
...
 - - - - -
 New text: (Section 7.2.2)
 - - - - -
...
 o  (1) when partial_bytes_acked is greater than cwnd and (2) before
    the arrival of the SACK the sender had less than cwnd bytes of
    data outstanding (i.e., before the arrival of the SACK, flightsize
    was less than cwnd), reset partial_bytes_acked to cwnd.

 o  (1) when partial_bytes_acked is equal to or greater than cwnd and
    (2) before the arrival of the SACK the sender had cwnd or more
    bytes of data outstanding (i.e., before the arrival of the SACK,
    flightsize was greater than or equal to cwnd), partial_bytes_acked
    is reset to (partial_bytes_acked - cwnd).  Next, cwnd is increased
    by 1*MTU.

4) Section 3.13.1, second "New text" in Section 3.13.2,
first paragraph of Section 3.13.3, and fourth "New text" in
Section 3.23.2:  Should "association overall error counter" be
"association overall error count," or perhaps "overall association
error count" per Section 13.2 of RFC 4960?

Original:
 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver
 of a HEARTBEAT ACK must reset the association overall error counter.
...
 the association overall error counter (as defined in Section 8.1).

etc.

5) Section 3.16.3:  Does "the same value as suggested in"
mean "the same value as the value suggested in," or something else?

Original:
 Use the same value as suggested in [RFC5681], Section 3.1, as an
 appropriate initial value.

6) Section 3.17.1:  To what does "are considered" refer in
this sentence?  If the suggested text is not correct, please clarify.

Original (the previous sentence is included for context):
 The Path Verification procedure of [RFC4960] prescribes that any
 address passed to the sender of the INIT by its upper layer is
 automatically CONFIRMED.  This, however, is unclear if only addresses
 in the request to initiate association establishment are considered
 or any addresses provided by the upper layer in any requests (e.g. in
 'Set Primary').

Suggested:
 This, however, is unclear if (1) only addresses
 in the request to initiate association establishment or (2) any
 addresses provided by the upper layer in any requests (e.g.,
 in 'Set Primary') are considered.

7) Section 3.21.2, "New text" for Section 10.1 G:
"stream sequence number - the Stream Sequence Number ..." reads oddly.
Should it be "stream sequence number - the sequence number ..."
or perhaps "Stream Sequence Number - the sequence number ..."?

Original:
 o  stream sequence number - the Stream Sequence Number assigned by
    the sending SCTP peer.

8) Section 3.23.2, "New text: (Section 8.2)":  Please
clarify the meaning of "bear any significant consequence to" in this
text.

Original:
 When the peer endpoint is multi-homed and the
 last chunk sent to it was a retransmission to an alternate address,
 there exists an ambiguity as to whether or not the acknowledgement
 could be credited to the address of the last chunk sent. However,
 this ambiguity does not seem to bear any significant consequence to
 SCTP behavior.

Possibly:
 However, this
 ambiguity does not seem to have significant consequences for SCTP
 behavior.

Or perhaps:
 However, this
 ambiguity does not seem to be of significant consequence to SCTP
 behavior.

9) Sections 3.24.2 and 3.32.2:  Although we realize that
the hyphens will probably not cause confusion for readers (and also
realize that additional comparable lists in the upcoming 4960bis
document would also need to be updated accordingly), would it be a
bit easier on readers' eyes to use colons (":") instead of hyphens in
the two "New text: (Section 15)" items for these lists, to avoid the
appearance of "minus" signs?

Original:
 - - - - -
 New text: (Section 15)
 - - - - -

 The following protocol parameters are RECOMMENDED:

    RTO.Initial - 1 second
    RTO.Min - 1 second
    RTO.Max - 60 seconds
    Max.Burst - 4
    RTO.Alpha - 1/8
 ...

Possibly:
 - - - - -
 New text: (Section 15)
 - - - - -

 The following protocol parameters are RECOMMENDED:

    RTO.Initial: 1 second
    RTO.Min: 1 second
    RTO.Max: 60 seconds
    Max.Burst: 4
    RTO.Alpha: 1/8 
 ...

10) Section 3.26.2:  We changed "one 1*MTU" to "1*MTU" in
this sentence.  Please let us know if this is incorrect.

Original:
 o  SCTP SHOULD increment cwnd by one 1*MTU once per RTT when
    the sender has cwnd or more bytes of data outstanding for
    the corresponding transport address.

Currently:
 o  SCTP SHOULD increment cwnd by 1*MTU once per RTT when the sender
    has cwnd or more bytes of data outstanding for the corresponding
    transport address.

11) Section 3.27.3:  Does "stored to the ssthresh value" mean
"also stored as ssthresh," "copied to ssthresh," or something else?

Original:
 When the idle
 period is detected, the cwnd value is stored to the ssthresh value.

12) Section 3.29.1:  We had trouble following the last
sentence in this paragraph.  What causes many gaps?  If the suggested
text is not correct, please clarify.

Original:
 o  Initially it states that an endpoint should always transmit DATA
    chunks to the primary path.  Then it states that the rule for
    transmittal of reply chunks should also be followed if the
    endpoint is bundling DATA chunks together with the reply chunk
    which contradicts with the first statement to always transmit DATA
    chunks to the primary path.  Some implementations were having
    problems with it and sent DATA chunks bundled with reply chunks to
    a different destination address than the primary path that caused
    many gaps.

Suggested:
...
 Some
 implementations were having problems with it and sent DATA chunks
 bundled with reply chunks to a different destination address than
 the primary path, causing many gaps.

13) Section 3.30:  As it appears that "key terms" refers to
"data", "flightsize", and "data in flight," we updated the section
title and text accordingly.  If this is incorrect, please clarify
"outstanding data, flightsize and data in flight key terms."

Original:
3.30.  Outstanding Data, Flightsize and Data In Flight Key Terms

3.30.1.  Description of the Problem

   [RFC4960] uses outstanding data, flightsize and data in flight key
   terms in formulas and statements but their definitions are not
   provided in Section 1.3.

Currently:
3.30.  "Outstanding Data", "Flightsize", and "Data in Flight" Key Terms

3.30.1.  Description of the Problem

   [RFC4960] uses the key terms "outstanding data", "flightsize", and
   "data in flight" in formulas and statements, but Section 1.3
   ("Key Terms") of [RFC4960] does not provide their definitions.

14) Section 3.30.2, "New text: (Section 1.3)":  We see that
the definitions listed in Section 1.3 are in alphabetical order.
The "New text" will change that order.  Would the "Possibly" text
listed below be an acceptable alternative?

Original:
 - - - - -
 New text: (Section 1.3)
 - - - - -

 o  Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
    DATA chunk) that has been sent by the endpoint but for which it
    has not yet received an acknowledgement.

 o  Outstanding data (or Data outstanding or Data in flight): The
    total amount of the DATA chunks associated with outstanding TSNs.
    A retransmitted DATA chunk is counted once in outstanding data.
    A DATA chunk which is classified as lost but which has not been
    retransmitted yet is not in outstanding data.

 o  Flightsize: The amount of bytes of outstanding data to a
    particular destination transport address at any given time.

 o  Congestion window (cwnd): An SCTP variable that limits outstanding
    data, in number of bytes, a sender can send to a particular
    destination transport address before receiving an acknowledgement.

Possibly:
 - - - - -
 New text: (Section 1.3)
 - - - - -
 o  Congestion window (cwnd): An SCTP variable that limits outstanding
    data (see definition below), in number of bytes, that a sender can
    send to a particular destination transport address before
    receiving an acknowledgement.

 ...

 o  Flightsize: The amount of bytes of outstanding data (see
    definition below) to a particular destination transport address
    at any given time.

 ...

 o  Outstanding data (or "data outstanding" or "data in flight"): The
    total amount 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.

 o  Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
    DATA chunk) that has been sent by the endpoint but for which it
    has not yet received an acknowledgement.

15) Section 3.30.3:  We found these sentences confusing,
because the "New text" does not include the word "outstanding."
We updated these sentences as noted below.  If this is not correct,
please clarify "properly use the outstanding data term."

Original:
 Now Section 1.3, Key Terms, includes explanations of outstanding
 data, data in flight and flightsize key terms.  Section 6.1 is
 corrected to properly use the outstanding data term.

Currently:
 Section 1.3 is corrected to include explanations of the key terms
 "outstanding data", "data in flight", and "flightsize".  Section 6.1
 is corrected to now use "any DATA chunks" instead of "any outstanding
 DATA chunks".

16) Section 3.32.1:  RFC 1122 does not have a Section 4.3.2.1.
We changed the number to "4.2.3.1" per "RTO = 3 seconds" in
Section 4.2.3.1 of RFC 1122.  Please let us know any objections.

Original:
 [RFC4960] uses 3 seconds as the default value for RTO.Initial in
 accordance with Section 4.3.2.1 of [RFC1122].

Currently:
 [RFC4960] uses 3 seconds as the default value for RTO.Initial in
 accordance with Section 4.2.3.1 of [RFC1122].

17) Section 3.33.1:  Does "might only limit interoperability"
mean "might limit interoperability," or are some words missing?

Original:
 This restriction of the ordering is not necessary and might only
 limit interoperability.

18) Section 3.36.1:  We found this sentence difficult to
follow.  If the suggested text is not correct, please clarify
"unreachable described in the enumeration ..."

Original (the previous sentence is included for context):
 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
 messages.  The handling of ICMP messages indicating that the port
 number is unreachable described in the enumeration is not consistent
 with the description given in [RFC4960] after the enumeration.

Suggested:
 The handling of ICMP messages indicating that the port
 number is unreachable, as described in the enumerated procedures,
 is not consistent with the description given after the procedures.

19) Section 3.38.2:  We had trouble following this
sentence.  Does "breach" mean "overbooking" as used in
"New text: (Section 7.2.1)" a few lines later?

Original:
 The breach of cwnd MUST constitute one packet only.

20) Section 3.40.2:  We found this sentence difficult to
follow as written.  We updated it as noted below.  Please let us know
if this is incorrect (e.g., did something other than the CE bit
arrive from the network?).

Original:
 - - - - -
 New text: (Appendix A)
 - - - - -

 [RFC3168] updated by [RFC8311] details a specific bit for a receiver
 to send back in its TCP acknowledgements to notify the sender of the
 Congestion Experienced (CE) bit having arrived from the network.

Currently:
 - - - - -
 New text: (Appendix A)
 - - - - -

 [RFC3168] (updated by [RFC8311]) details a specific bit for a
 receiver to send back in its TCP acknowledgements to notify the
 sender of the Congestion Experienced (CE) bit that the CE bit has
 arrived from the network.

21) Section 3.41.2:  Although we see "(or Host Name
parameter)" at the end of Section 3.3.10.5 of RFC 4960, please
confirm that "Host Name parameter" should not be "Host Name Address
parameter" (as used in "New text: (Section 3.3.3)" earlier in this
section).

Original:
 - - - - -
 New text: (Section 5.1.2)
 - - - - -

 B) If there is a Host Name parameter present in the received INIT or
    INIT ACK chunk, the endpoint MUST immediately send an ABORT and
    MAY include an Error Cause indicating an Unresolvable Address to
    its peer.

22) Section 3.43.2, "New text: (Section 14.1)":  This is the
only "New text" item in this document that includes an "of [RFC4960]"
in it.  Unless this is a special case where the upcoming bis document
will need to refer specifically to RFC 4960, we suggest removing it.
Please advise.

Original:
 - - - - -
 New text: (Section 14.1)
 - - - - -

 b)  A detailed description of the structure of the chunk, which MUST
     conform to the basic structure defined in Section 3.2 of
     [RFC4960];

Suggested (assuming that this text is not some type of "special case"):
 b)  A detailed description of the structure of the chunk, which
     MUST conform to the basic structure defined in Section 3.2.

23) Sections 3.44.1, 3.44.2 ("New text"), and 4:  It appears
that "Port Numbers Registry," "Port Numbers registry," and
"port number registry" all refer to the "Service Name and Transport
Protocol Port Number Registry"
(https://www.iana.org/assignments/service-names-port-numbers/).
We would like to list the correct registry using consistent style.
Please let us know how the registry name(s) should be corrected.

Also, please confirm that "contact port numbers" is correct;
should the word "contact" perhaps be put in quotes?

Original:
 [RFC6335] updates [RFC4960] by updating Procedures for the Port
 Numbers Registry.
...
 - - - - -
 New text: (Section 14.5)
 - - - - -

 SCTP services can use contact port numbers to provide service to
 unknown callers, as in TCP and UDP.  IANA is therefore requested to
 open the existing Port Numbers registry for SCTP using the following
 rules, which we intend to mesh well with existing Port Numbers
 registration procedures.
...
 Section 3.44 of this document updates the port number registry for
 SCTP to be consistent with [RFC6335].

24) Section 3.45.2:  As it appeared to us that the sentence
"The following format MUST be used for the DATA chunk:" should also
be included in "New text: (Section 3.3.1)," we added it.  Also,
some text was missing in the "See [RFC7053]" sentence; we corrected
that as well.  Please let us know if anything is incorrect.

Original:
 - - - - -
 Old text: (Section 3.3.1)
 - - - - -

 The following format MUST be used for the DATA chunk:

      0                   1                   2                   3
...

 - - - - -
 New text: (Section 3.3.1)
 - - - - -

      0                   1                   2                   3
...

 I bit: 1 bit

    The (I)mmediate Bit MAY be set by the sender, whenever the sender of
    a DATA chunk can benefit from the corresponding SACK chunk being sent
    back without delay. See [RFC7053] for a discussion about

Currently:
 - - - - -
 New text: (Section 3.3.1)
 - - - - -

   The following format MUST be used for the DATA chunk:

        0                   1                   2                   3
...
 I bit: 1 bit

    The (I)mmediate bit MAY be set by the sender whenever the sender
    of a DATA chunk can benefit from the corresponding SACK chunk
    being sent back without delay.  See Section 4 of [RFC7053] for a
    discussion of the benefits.

25) Section 3.45.2:
1. Should "sack immediately" be "SACK-IMMEDIATELY" per RFC 7053
   or possibly "sack-immediately" per RFC 8303?
2. Does "for sending buffer" mean "for the sending buffer,"
   "for sending the buffer," or something else?

Original:
 - - - - -
 New text: (Section 10.1 E))
 - - - - -

 E) Send

  Format: SEND(association id, buffer address, byte count [,context]
          [,stream id] [,life time] [,destination transport address]
          [,unordered flag] [,no-bundle flag] [,payload protocol-id]
          [,sack immediately] )
  -> result
...
 - - - - -
 New text: (Append optional parameter in Subsection E of Section 10.1)
 - - - - -

 o  sack immediately - set the I bit on the last DATA chunk used for
    sending buffer.

26) Section 3.46.1:
1. We had trouble following these paragraphs.  If the suggested text
   is not correct, please clarify.
2. Even though Section 3.46.2 mentions Section 3.10, for ease of the
   reader we suggest adding a reminder, via a pointer to
   Section 3.10.2, that most of Appendix C of RFC 4960 will be moved
   to Appendix B of the bis document for RFC 4960.

Original:
 The code given for the CRC32c computations uses types like long which
 may have different length on different operating systems or
 processors.  Therefore, the code is changed to use specific types
 like uint32_t.

 While there, fix also some syntax errors and a comment.

Suggested (using different verb tenses, as this text is a problem
  description and not "solution" text):
 The code given for the CRC32c computations uses types such as "long",
 which may have different lengths on different operating systems or
 processors.  Therefore, the code needs to be changed, so that it uses
 specific types such as uint32_t.

 Some syntax errors and a comment also need to be fixed.

 We remind the reader that per Section 3.10.2 of this document most
 of Appendix C of RFC 4960 will be moved to Appendix B in the bis
 document (thus the "Old text: (Appendix C)" and "New text:
 (Appendix B)" items in this section).

27) Section 3.46.2, "New text: (Appendix B)":
1. Should "Note Definition for" be "Note: The definitions for"?
2. Should "Mr. Williams direct calculation code" be "Mr. Williams's
   direct calculation code"?
3. Should "TB_POLLY" be "TB_POLY"?  We found the updated URL for
   RFC 4960's "[WILLIAMS93]" listing (the URL in RFC 4960 is stale).
   <http://www.ross.net/crc/download/crc_v3.txt> says
   "TB_POLY is the "polynomial", which must be TB_WIDTH bytes wide."
4. Should "cm_xorort" be "cm_xorot" per
   <http://www.ross.net/crc/download/crc_v3.txt>?  We do not see
   "xorort" on the ross.net page.

If the suggested text is not correct, please clarify all of the above.

Original:
 - - - - -
 New text: (Appendix B)
 - - - - -

 <CODE BEGINS>
 /*************************************************************/
 /* Note Definition for Ross Williams table generator would   */
 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE        */
 /* For Mr. Williams direct calculation code use the settings */
 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF,      */
 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000        */
 /*************************************************************/

Suggested:
 - - - - -
 New text: (Appendix B)
 - - - - -

 <CODE BEGINS>
 /****************************************************************/
 /* Note: The definitions for Ross Williams's table generator    */
 /* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE.      */
 /* For Mr. Williams's direct calculation code, use the settings */
 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF,         */
 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000            */
 /****************************************************************/

28) Section 3.46.2, "New text: (Appendix B)":
1.  RFC 4960 and this document lean heavily toward "CRC32" rather
    than "CRC-32."  Would you like to change these two instances of
    "CRC-32" to "CRC32"?
2.  Should "open %s\n" be "open <%s>.\n"?
3.  Would you like "printf("Unable to close <%s>.", OUTPUT_FILE);"
    to include the "\n" as do other similar types of printf calls?

May we update as suggested below?

Original:
 - - - - -
 New text: (Appendix B)
 - - - - -

 /* Example of table build routine */
...
 printf("\nGenerating CRC-32c table file <%s>\n",
...
 printf ("Unable to open %s\n", OUTPUT_FILE);
...
 if (fclose (tf) != 0)
   printf("Unable to close <%s>.", OUTPUT_FILE);
 else
   printf("\nThe CRC-32c table has been written to <%s>.\n",
     OUTPUT_FILE);

Suggested:
 - - - - -
 New text: (Appendix B)
 - - - - -

 /* Example of table build routine */
...
 printf("\nGenerating CRC32c table file <%s>.\n",
...
 printf ("Unable to open <%s>.\n", OUTPUT_FILE);
...
 if (fclose(tf) != 0)
   printf("Unable to close <%s>.\n", OUTPUT_FILE);
 else
   printf("\nThe CRC32c table has been written to <%s>.\n",
     OUTPUT_FILE);

29) Section 3.46.2:  In the "New text," should "inplace" be
"in-place," and should "8-bit reversals" be "8-bit bit-reversals"?

Original:
...
 *  Note that a 32-bit bit-reversal is identical to four inplace
 *  8-bit reversals followed by an end-for-end byteswap.

30) Acknowledgements section:  Please confirm that "Morriss"
(and not "Morris") is correct.

Original (the spacing in Karen E. E. Nielsen's name has been fixed):
...
 Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff
 Morriss, Karen E.  E.  Nielsen, Tom Petch, Kacheong Poon, Julien
...

31) Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 CWND (titles of Sections 3.26, 3.31, and 3.38) /
   cwnd (>80 instances in section titles and running text)

 fast retransmit / Fast Retransmit (per RFC 4960)

 confirmed / Confirmed (titles) / CONFIRMED

b) In descriptive text in this document, the following terms are used
inconsistently.  Please let us know which form is preferred.

 Congestion Avoidance / congestion avoidance *
   (for example, "congestion avoidance phase" (Sections 3.12.1,
    3.12.3, and 3.26.3),
    "Congestion Avoidance phase" (Section 3.26.1),
    "during congestion avoidance" (Section 3.26.2),
    "in Congestion Avoidance" (Section 3.27.1)

* Suggested:  "congestion avoidance" per consistent usage in RFC 4960

= = = = =

 In some "New text" items:

   stream sequence number / Stream Sequence Number (in running text)
     (RFC 4960 uses "stream sequence number" in three "Format:" items
      only.)

   Verification Tag / verification tag  (RFC 4960 has two instances of
     "verification tag" and approx. 69 instances of "Verification Tag"
     in text.)

   "New text" in Section 3.25.2:
   a zero Verification Tag ... a non-zero verification tag

= = = = =

 DATA transmission (1 instance in "New text" in this document,
   and 1 instance in RFC 4960) / data transmission (3 instances in text)

= = = = =

In some "New text" items:

 Error Cause / error cause

 Error Cause indicating an Unresolvable Address /
   "Unresolvable Address" error cause

Title                  : RFC 4960 Errata and Issues
Author(s)              : R. Stewart,  M. Tuexen, 
                         M. Proshin
Working Group Chair(s) : David L. Black, Gorry Fairhurst, Wesley Eddy
Area Director(s)       : Spencer Dawkins, Mirja Kühlewind

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 20 Jan 2019 21:45:09 +0100

> On 12. Jan 2019, at 04:50, [email-masked] wrote:
> 
> Dear authors,
> 
Dear RFC Editor,

please find my answers in-line.

Best regards
Michael
> this be clear to readers even if not mentioned?
Yes.
> (Cancel T1-cookie timer, <- -/
The change from COOKIE-ACK to COOKIE ACK is exactly the change we
make in Section 3.9.2.

I would prefer to keep changes separate.
>    is reset to (partial_bytes_acked - cwnd).  Next, cwnd is increased
I'm not sure why the original text doesn't parse, but if you think
the use of an inline enumeration makes is clearer, I'm OK with it.
> error count" per Section 13.2 of RFC 4960?
We mean the "overall association error count" from Section 13.2.

However checking RFC 4960, the following is used in the text two times:
association overall error count.

So I would suggest to stay consistent with the text and use
"association overall error count" instead of
"association overall error counter" here.
> mean "the same value as the value suggested in," or something else?
It means "the same value as the value suggested in,".
> in 'Set Primary') are considered.
OK.
> o  stream sequence number - the Stream Sequence Number assigned by
I'm referring the "Stream Sequence Number" as defined in Section 1.3
of RFC 4960. That is why exactly that term is used using capital letters.

The variable of the call is not using capital letters, since they are
not used in in the function call. So I suggest to keep it as it is.
> ambiguity does not seem to have significant consequences for SCTP
OK, take the above.
> The following protocol parameters are RECOMMENDED:
OK.
>    has cwnd or more bytes of data outstanding for the corresponding
OK.
> "also stored as ssthresh," "copied to ssthresh," or something else?
Let us use "copied to ssthresh,".
> the primary path, causing many gaps.
OK.
>   ("Key Terms") of [RFC4960] does not provide their definitions.
OK.
>    has not yet received an acknowledgement.
Sure. Keeping it ordered makes sense.
> is corrected to now use "any DATA chunks" instead of "any outstanding
Correct. Good catch!
> accordance with Section 4.2.3.1 of [RFC1122].
Correct. Good catch, again!
> This restriction of the ordering is not necessary and might only
Please use "might limit interoperability," as suggested.
> is not consistent with the description given after the procedures.
Suggested text is OK.
> The breach of cwnd MUST constitute one packet only.
Yes, breach is used in the same meaning as overbooking.
> arrived from the network.
OK.
>    MAY include an Error Cause indicating an Unresolvable Address to
Please use "Host Name Address parameter". This is what is meant.
>     MUST conform to the basic structure defined in Section 3.2.
Please use your suggested text. It is the correct one.
> (https://www.iana.org/assignments/service-names-port-numbers/).
Correct.
> should the word "contact" perhaps be put in quotes?
This text was already used in RFC 4960. So I think there is no
need to change it.
> SCTP to be consistent with [RFC6335].
I suggest to use "Port Number Registry" consistently?
>    discussion of the benefits.
You are correct. Thanks for catching this.
>   or possibly "sack-immediately" per RFC 8303?
It should not be "SACK-IMMEDIATELY". It could be changed to
"sack-immediately flag" to be consistent with RFC 8303.
Please change it two times: in the SEND() parameter list and
in the explanation below. 
>   "for sending the buffer," or something else?
Change it to:

o  sack immediately - set the I bit on the last DATA chunk used for
   user message to be transmitted.
> (Appendix B)" items in this section).
OK.
> 1. Should "Note Definition for" be "Note: The definitions for"?
Yes.
>   direct calculation code"?
I guess so.
> 3. Should "TB_POLLY" be "TB_POLY"?  We found the updated URL for
Yes.
>   "TB_POLY is the "polynomial", which must be TB_WIDTH bytes wide."
Please also update the link.
>   "xorort" on the ross.net page.
Yes.
> If the suggested text is not correct, please clarify all of the above.
Suggested text is OK.
>    than "CRC-32."  Would you like to change these two instances of
Yes.
> 2.  Should "open %s\n" be "open <%s>.\n"?
Use "open <%s>.\n" for consistency.
>    to include the "\n" as do other similar types of printf calls?
Yes.
>   printf("\nThe CRC32c table has been written to <%s>.\n",
Your suggested text looks good.
> "in-place," and should "8-bit reversals" be "8-bit bit-reversals"?
Yes.
> *  8-bit reversals followed by an end-for-end byteswap.
I just realized that in the next sentence:

"In other words, the bytes of each bit are in the right order,"

needs to be changed to

"In other words, the bits of each byte are in the right order,"
> (and not "Morris") is correct.
It is Morriss (double r, double s).
> Morriss, Karen E.  E.  Nielsen, Tom Petch, Kacheong Poon, Julien
OK.
>   cwnd (>80 instances in section titles and running text)
OK.
> fast retransmit / Fast Retransmit (per RFC 4960)
OK.
> confirmed / Confirmed (titles) / CONFIRMED
CONFIRMED is a state.
> * Suggested:  "congestion avoidance" per consistent usage in RFC 4960
OK.
>     (RFC 4960 uses "stream sequence number" in three "Format:" items
I double checked the spelling in "New text" and think it is as
I expect it.
>   a zero Verification Tag ... a non-zero verification tag
Use Verification Tag.
>   and 1 instance in RFC 4960) / data transmission (3 instances in text)
Use data transmission.
> Error Cause / error cause
OK.
>   "Unresolvable Address" error cause
OK.

---

From: Lynne Bartholomew <[email-masked]>
Date: Thu, 24 Jan 2019 16:37:41 -0800

Dear Michael,

Thank you for the email, and apologies for the delayed reply.  We have updated this document per your notes below.

We have a few follow-up items for you:

> I would prefer to keep changes separate.

Apologies; we reverted the change.

= = = = =
Regarding our question 25) below and your reply ("sack-immediately flag" to be consistent with RFC 8303"):  Would you like to cite RFC 8303 here?

Possibly:
   o  sack-immediately flag (RFC 8303) - set the I bit on the last DATA chunk used
      for the user message to be transmitted.

= = = = =

> Please also update the link.

Please note that we cannot update the URL in RFC 4960.  We only mentioned the newer URL as a way to let you know how we found "TB_POLY."  Apologies if we were unclear. 

= = = = =

> "In other words, the bits of each byte are in the right order,"

"bytes of each bit" appears in the "Old text" only.  It was already corrected in the "New text."

= = = = =

>>  "Unresolvable Address" error cause

Thanks again.

RFC Editor/lb

> On Jan 20, 2019, at 12:45 PM, Michael Tuexen <[email-masked]> wrote:
>

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 25 Jan 2019 09:56:22 +0100

> On 25. Jan 2019, at 01:37, Lynne Bartholomew <[email-masked]> wrote:
> 
> Dear Michael,
> 
No, this doesn't help. Just use a consistent name.
> Please note that we cannot update the URL in RFC 4960.  We only mentioned the newer URL as a way to let you know how we found "TB_POLY."  Apologies if we were unclear. 
That is OK. I'm aware that you can not change RFC 4960. I was referring to adding a OLD TEXT/NEW TEXT entry
which updates the reference.

But we need to do similar things for other references when working on RFC 4960bis, so leave it as it is and
we'll update the reference in the RFC 4960bis document.
> "bytes of each bit" appears in the "Old text" only.  It was already corrected in the "New text."
My mistake. Sorry about the noise.
>>> Error Cause / error cause
error cause

Best regards
Michael

---

From: Lynne Bartholomew <[email-masked]>
Date: Mon, 28 Jan 2019 11:11:35 -0800

Dear Michael,

Per your first note below, we did not add a citation for RFC 8303 to the "sack-immediately flag" definition; thank you.

We also changed the instances of 'Error Cause indicating an Unresolvable Address' to '"Unresolvable Address" error cause' per your other note below.

You and your coauthors will have the opportunity to review the edited document during the AUTH48 state.

Thank you very much for your help!

RFC Editor/lb

> On Jan 25, 2019, at 12:56 AM, Michael Tuexen <[email-masked]> wrote:
>