Stream Control Transmission Protocol: Errata and Issues in RFC 4960
RFC 8540

Note: This ballot was opened for revision 06 and is now closed.

(Spencer Dawkins) Yes

Deborah Brungard No Objection

Mirja K├╝hlewind No Objection

Comment (2018-07-02 for -06)
No email
send info
1) sec 3.27.2:
" o  When the endpoint does not transmit data on a given transport
      address, the cwnd of the transport address SHOULD be adjusted to
      max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the
      ssthresh of the transport address SHOULD be adjusted to the cwnd."
This part is still unclear to me. What does adjust "per RTO mean"? I guess it is sufficient to adjust it once after the first RTO without data, no?
Also I assume ssthresh is set after the cwnd adjustment?

2) sec 3.28.2
"An SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data. When the window opens
   up, an SCTP receiver SHOULD send additional SACK chunks to update
   the window even if no new data is received. The receiver MUST avoid
   sending large bursts of window updates."
This is also not super well specified now. What is a large burst? 
I would rather like to see something like "The receiver MUST not send more then one window update per RTT."

3) 3.31.
Would it make sense to then use a different variable, e.g. cwnd_temp or max_send_limit, and not cwnd...?

4) Text changes in sec 3.35.2. are kind of unclear. I assume the new text should be added at the end of the old text sections...?

Martin Vigoureux No Objection

Comment (2018-07-03 for -06)
No email
send info
Hello,

Thank you for writing down this Document. I see the value of documenting fixes to known issues so I support this initiative but I somehow also share Alexey's view.
I'm not sure an RFC is the best means to achieve that goal. A living wiki page would have been more suitable in my opinion. 
I'm not an expert in that field, but what if a new issue is uncovered in the future? That would render this Document incomplete. Will a new draft be published that Updates this Document?

I am a bit more concerned by the relationship between this document and the Erratas for 4960, and by the possible "discrepancy" its publication, with all things staying as they are, would introduce.
4 Erratas for 4960 are in Reported state, yet 3 of these 4 are addressed in this Document.
Also, one of these 3 has a resolution which differs from the proposed Errata text.
Finally, only this errata is referenced by its ID in the Document.
Spencer the first two points might be more in your hands than in the authors' but I wonder if something should be done about it as part of publishing this Document.
More details below:

3.47.  Clarification of Gap Ack Blocks in SACK Chunks
The Errata for this is https://www.rfc-editor.org/errata/eid5202
The text change proposed by the draft is different than the one proposed by the Errata. Note that I am not arguing which one is better.

3.24.  SACK.Delay Not Listed as a Protocol Parameter
The Errata for this is https://www.rfc-editor.org/errata/eid4656

3.9.  Miscellaneous Typos
The Errata for this is https://www.rfc-editor.org/errata/eid5003

The not discussed Reported errata is https://www.rfc-editor.org/errata/eid4876

(Ben Campbell) Abstain

Comment (2018-07-02 for -06)
No email
send info
I agree with Alexey that I don't see the value of publishing this, and am concerned it might even be slightly harmful.  The approach seems unfriendly to implementers, who would get much more benefit from an "RFC4960bis" draft.  At best it seems like an intermediate step in the creation of such a bis draft. (I note similar concerns from the Gen-ART and OPSDIR reviewers)

I don't expect the decision to publish this in it's current form to change, so I am balloting "abstain" and getting out of the way.

Alissa Cooper Abstain

Comment (2018-07-05 for -06)
No email
send info
I agree with the Gen-ART reviewer and the other ADs who have abstained on this document. I see why the WG wants this documented, but it doesn't appear to need to be documented in an RFC.

Benjamin Kaduk Abstain

Comment (2018-07-04 for -06)
No email
send info
The reasons for my Abstain vs. No Objection are covered in the other Abstain positions' descriptions.
In particular, the "user-unfriendliness" aspect; e.g., in my notes, I was going to suggest switching the
example CRC code to using fixed-width types, and had to wait until basically the end of the document
to see that this was already done.

I did take some notes while reviewing the document, though:

Section 3.14.2 (new text)

 When its peer is multi-homed, an endpoint SHOULD send fast
 retransmissions to the same destination transport address where the
 original data was sent to. If the primary path has been changed and the
 original data was sent there before the fast retransmit, the
 implementation MAY send it to the new primary path.

What is "there"?

Section 3.35.2

There seem to be two instances of "Old Text" for the same outline of text;
presumably the second one is supposed to be "New Text".

Section 3.36.2

The ICMP3 change goes both from "MAY ignore" to "SHOULD ignore" and from
"code does not indicate" to "code indicates", which is qualitatively a
large change.  There are 13 code values that are not mentioned in either
old or new text, and the supporting problem/solution descriptions don't do
very much to explain the change for these 13 codes.

Section 3.40.2

Is ECN really still a "proposed extension to IP", or a realized extension?

Suresh Krishnan Abstain

Comment (2018-07-05 for -06)
No email
send info
I agree with my abstaining co-ADs that this document is better kept as a living document and 4960bis is the one that should be published.

(Terry Manderson) Abstain

Comment (2018-07-04 for -06)
No email
send info
I appreciate and recognise the WG's desire to highlight the number of issues that need to be correctioned in RFC 4960. I urge the WG to select an alternative way to keep track of these concerns in leading toward a -bis. Archiving the enumerated list doesn't to me seem like an ideal way forward. Adam has provided a URL of previous advice that the WG should consider.

I am, therefore, abstaining.

Alexey Melnikov (was No Objection) Abstain

Comment (2018-07-05 for -06)
No email
send info
I am not convinced in the value of publishing this document (as opposed to just doing -bis).

(Eric Rescorla) (was Discuss, Abstain) Abstain

Comment (2018-11-01)
Now that we have had a discussion, I am re-balloting Abstain. In my opinion, this document should not be published as an RFC.

Alvaro Retana Abstain

Comment (2018-07-04 for -06)
No email
send info
As others have commented, while this intermediate document is of value to implementors, and a similar process has worked well before (rfc2960 -> rfc4460 -> rfc4960), I believe the work is not required to be published as an RFC.  Nonetheless, I won't stand in the way of its publication and I am then also ABSTAINing.

Adam Roach Abstain

Comment (2018-07-03 for -06)
No email
send info
I agree with Ben (and, transitively, the OPSDIR an GENART reviewers). From my
reading, this document -- while immensely valuable to the working group for
creation of an RFC 4960 bis document -- has little archival value. The following
standing guidance from the IESG would seem to be applicable:

https://www.ietf.org/blog/support-documents-ietf-working-groups/

Like Ben, I'm abstaining on this document. I would ask the working group to
consider not publishing it in this form, and waiting until a complete bis
version of the document can be produced.

Ignas Bagdonas No Record

Comment (2018-07-05 for -06)
No email
send info
The history behind the decisions made and errata of 4960 are certainly of value, but it does not justify to be published as an RFC.