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

[Lynne Bartholomew <[e-mail]>]

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 <[e-mail]> wrote:
> 
>> On 25. Jan 2019, at 01:37, Lynne Bartholomew <[e-mail]> wrote:
>> 
>> 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:
>> 
>> 
>> Regarding our question 2) below and your reply:
>> 
>>> 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.
>> 
>> 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.
> No, this doesn't help. Just use a consistent name.
>> 
>> = = = = =
>> Regarding this item from our question 27) below and your reply:
>> 
>>>> 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."
>>> 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. 
> 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.
>> 
>> = = = = =
>> Regarding our question 29) below and your reply:
>> 
>>> 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,"
>> 
>> "bytes of each bit" appears in the "Old text" only.  It was already corrected in the "New text."
> My mistake. Sorry about the noise.
>> 
>> = = = = =
>> Please let us know which form is preferred for the following:
>> 
>>>> Error Cause / error cause
>>> OK.
> error cause
>>>> 
>>>> Error Cause indicating an Unresolvable Address /
>>>> "Unresolvable Address" error cause
>>> OK.
> "Unresolvable Address" error cause
> 
> Best regards
> Michael
>> 
>> 
>> Thanks again.
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Jan 20, 2019, at 12:45 PM, Michael Tuexen <[e-mail]> wrote:
>>> 
>>>> On 12. Jan 2019, at 04:50, [e-mail] wrote:
>>>> 
>>>> 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.
>>> Dear RFC Editor,
>>> 
>>> please find my answers in-line.
>>> 
>>> Best regards
>>> Michael
>>>> 
>>>> 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?
>>> Yes.
>>>> 
>>>> 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)
>>> 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.
>>>> 
>>>> 
>>>> 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.
>>> 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.
>>>> 
>>>> 
>>>> 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?
>>> 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.
>>>> 
>>>> 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?
>>> It means "the same value as the value suggested in,".
>>>> 
>>>> 
>>>> 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.
>>> OK.
>>>> 
>>>> 
>>>> 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.
>>> 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.
>>>> 
>>>> 
>>>> 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.
>>> OK, take the above.
>>>> 
>>>> 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 
>>>> ...
>>> OK.
>>>> 
>>>> 
>>>> 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.
>>> OK.
>>>> 
>>>> 
>>>> 11) Section 3.27.3:  Does "stored to the ssthresh value" mean
>>>> "also stored as ssthresh," "copied to ssthresh," or something else?
>>> Let us use "copied to ssthresh,".
>>>> 
>>>> 
>>>> 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.
>>> OK.
>>>> 
>>>> 
>>>> 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.
>>> OK.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>> Sure. Keeping it ordered makes sense.
>>>> 
>>>> 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".
>>> Correct. Good catch!
>>>> 
>>>> 
>>>> 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].
>>> Correct. Good catch, again!
>>>> 
>>>> 
>>>> 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.
>>> Please use "might limit interoperability," as suggested.
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> Suggested text is OK.
>>>> 
>>>> 
>>>> 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.
>>> Yes, breach is used in the same meaning as overbooking.
>>>> 
>>>> 
>>>> 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.
>>> OK.
>>>> 
>>>> 
>>>> 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.
>>> Please use "Host Name Address parameter". This is what is meant.
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> Please use your suggested text. It is the correct one.
>>>> 
>>>> 
>>>> 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/).
>>> Correct.
>>>> 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?
>>> This text was already used in RFC 4960. So I think there is no
>>> need to change it.
>>>> 
>>>> 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].
>>> I suggest to use "Port Number Registry" consistently?
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> You are correct. Thanks for catching this.
>>>> 
>>>> 
>>>> 25) Section 3.45.2:
>>>> 1. Should "sack immediately" be "SACK-IMMEDIATELY" per RFC 7053
>>>> 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. 
>>>> 2. Does "for sending buffer" mean "for the sending buffer,"
>>>> "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.
>>>> 
>>>> 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).
>>>> 
>>> OK.
>>>> 
>>>> 27) Section 3.46.2, "New text: (Appendix B)":
>>>> 1. Should "Note Definition for" be "Note: The definitions for"?
>>> Yes.
>>>> 2. Should "Mr. Williams direct calculation code" be "Mr. Williams's
>>>> direct calculation code"?
>>> I guess so.
>>>> 3. Should "TB_POLLY" be "TB_POLY"?  We found the updated URL for
>>> Yes.
>>>> 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."
>>> Please also update the link.
>>>> 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.
>>> Yes.
>>>> 
>>>> 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            */
>>>> /****************************************************************/
>>>> 
>>> Suggested text is OK.
>>>> 
>>>> 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"?
>>> Yes.
>>>> 2.  Should "open %s\n" be "open <%s>.\n"?
>>> Use "open <%s>.\n" for consistency.
>>>> 
>>>> 3.  Would you like "printf("Unable to close <%s>.", OUTPUT_FILE);"
>>>> to include the "\n" as do other similar types of printf calls?
>>> Yes.
>>>> 
>>>> 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);
>>> Your suggested text looks good.
>>>> 
>>>> 
>>>> 29) Section 3.46.2:  In the "New text," should "inplace" be
>>>> "in-place," and should "8-bit reversals" be "8-bit bit-reversals"?
>>> Yes.
>>>> 
>>>> Original:
>>>> ...
>>>> *  Note that a 32-bit bit-reversal is identical to four inplace
>>>> *  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,"
>>>> 
>>>> 
>>>> 30) Acknowledgements section:  Please confirm that "Morriss"
>>>> (and not "Morris") is correct.
>>> It is Morriss (double r, double s).
>>>> 
>>>> 
>>>> 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
>>>> ...
>>> OK.
>>>> 
>>>> 
>>>> 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)
>>> OK.
>>>> 
>>>> fast retransmit / Fast Retransmit (per RFC 4960)
>>> OK.
>>>> 
>>>> confirmed / Confirmed (titles) / CONFIRMED
>>> CONFIRMED is a state.
>>>> 
>>>> 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
>>> OK.
>>>> 
>>>> = = = = =
>>>> 
>>>> 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.)
>>> I double checked the spelling in "New text" and think it is as
>>> I expect it.
>>>> 
>>>> 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
>>> Use Verification Tag.
>>>> 
>>>> 
>>>> = = = = =
>>>> 
>>>> DATA transmission (1 instance in "New text" in this document,
>>>> and 1 instance in RFC 4960) / data transmission (3 instances in text)
>>>> 
>>> Use data transmission.
>>>> = = = = =
>>>> 
>>>> In some "New text" items:
>>>> 
>>>> Error Cause / error cause
>>> OK.
>>>> 
>>>> Error Cause indicating an Unresolvable Address /
>>>> "Unresolvable Address" error cause
>>> OK.
>>>> 
>>>> 
>>>> 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