Stream Control Transmission Protocol: Errata and Issues in RFC 4960
draft-ietf-tsvwg-rfc4960-errata-08

[Ballot discuss]
Given that the majority of the IESG has now ballotted abstain, I think we should at least discuss this. I'm marking my ballot DISCUSS until we have a chance to discuss this on a telechat. After we've done that, if Spencer still believes we should advance the document, I will withdraw my DISCUSS.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
The reasons for my Abstain vs. No Objection are covered in the other Abstain positions' descriptions.

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?

[Ballot comment]
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.

[Ballot comment]
I agree with Adam and Spencer. This is just an incredibly user-hostile presentation of this information, in particular:

  Note that when reading this document one must use care to assure that
  a field or item is not updated further on within the document.  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.

This seems like good input to a -bis but should not be published as-is.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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...?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-tsvwg-rfc4960-errata-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In section 3.44 of the current document, the authors request updates and changes to the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

We understand that there are no changes to any existing registrations within the registry itself. However, upon approval of this document, we will work with the authors to reflect the changes suggested in section 3.44.2 of the current document into the textual introduction to the registry.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-04):

From: The IESG
To: IETF-Announce
CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-rfc4960-errata@ietf.org, tsvwg-chairs@ietf.org, Gorry Fairhurst , spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RFC 4960 Errata and Issues) to Informational RFC


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'RFC 4960 Errata and Issues'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-06-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document is a compilation of issues found since the publication
  of RFC4960 in September 2007 based on experience with implementing,
  testing, and using SCTP along with the suggested fixes.  This
  document provides deltas to RFC4960 and is organized in a time
  ordered way.  The issues are listed in the order they were brought
  up.  Because some text is changed several times the last delta in the
  text is the one which should be applied.  In addition to the delta a
  description of the problem and the details of the solution are also
  provided.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-errata/ballot/


No IPR declarations have been submitted directly on this I-D.

RFC 4960 Errata and Issues

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

INFORMATIONAL
- This doument proposes changes to update the base SCTP RFC. Publication will be followed by a standards-action document that implements these changes by the WG.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document is a compilation of issues found since the publication of the SCTP protocol specification as RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes.  It provides deltas to RFC4960 and is organized in a time ordered way.  The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one that should be applied. In addition to the delta a description of the problem and the details of the solution are also provided.

Working Group Summary

This document was adopted 22nd August 2016, as an Informational document to document the intended changes to the base spec. This follows the same process used to update RFC 2960 to RFC 4960 (where RFC 4460 documents the changes between the two spec). Publication of RFC 4460 had the advantage that base spec implementors updating RFC 2960, did not then have to derive the
chabges between  the two RFCs. This process also only required editorial work to complete publication of RFC 4960.  Since this plan had worked well, the implementers of SCTP requested the WG to proceed in the same way for the present work. The resulting document progressed with input from the WG and SCTP implementors was subject of a WGLC comments in Dec 2017. A revised ID was presented to TSVWG, and received support for publication.

Document Quality

There are existing implementations of the protocol,  people from implementor community commented and reviewed this ID. The document represents consensus of the TSV WG.

Personnel

Who is the Document Shepherd?

Gorry Fairhurst

Who is the Responsible Area Director?

Spencer Dawkins

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

During the lifetime of this ID, the document has been discussed by the WG and a bug tracker has been used to track the contributions.  8 people provided review comments or sent corrections during the WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

R. Stewart: Confirmed No known IPR
M. Tuexen: Confirmed No known IPR
M. Proshin: Confirmed No known IPR

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is strong consensus, and no opposition for this proposed update,
The WG has consensus to open edits of the base spec with a
view to progress SCTP to Full Standard.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None.

(13) Have all references within this document been identified as
either normative or informative?

Done

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

These are documented in section 3.44, and describe issues already raised with IANA.
IANA is requested to check the revised text is consistent with their registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None.

NOTES ON IMPLEMENTATIONS (draft-ietf-tsvwg-rfc4960-errata-05):

The following implementation status reports were received:
"The FreeBSD kernel implementation should already follow the new text given in the document." - Michael Tuexen, 6th March 2018.

"I have no comments on it myself. Have used this Errata some time ago
(we had rwnd/cwnd handling fixes on Linux stack because of the errata),
went over it again now, it LGTM and I don't think we (Linux stack) have
(major) discrepancies due to it." - Marcelo Ricardo Leitner November, 21st 2017.

"Ericsson SCTP implementations support the changes proposed in the draft and they are already deployed in real mobile networks." - Maxim Proshin, 7th March 2018.

RFC 4960 Errata and Issues

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

INFORMATIONAL
- This doument proposes changes to update the base SCTP RFC. Publication will be followed by a standards-action document that implements these changes by the WG.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document is a compilation of issues found since the publication of the SCTP protocol specification as RFC4960 in September 2007 based on experience with implementing, testing, and using SCTP along with the suggested fixes.  It provides deltas to RFC4960 and is organized in a time ordered way.  The issues are listed in the order they were brought up. Because some text is changed several times the last delta in the text is the one that should be applied. In addition to the delta a description of the problem and the details of the solution are also provided.


Working Group Summary

This document was adopted 22nd August 2016, and after input from the WG and SCTP implementors was subject of a WGLC comments in Dec 2017. A revised ID was presented to TSVWG.

Document Quality

There are existing implementations of the protocol,  people from implementor community commented and reviewed this ID. The document represents consensus of the TSV WG.

Personnel

Who is the Document Shepherd?

Gorry Fairhurst

Who is the Responsible Area Director?

Spencer Dawkins

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

During the lifetime of this ID, the document has been discussed by the WG and a bug tracker has been used to track the contributions.  8 people provided review comments or sent corrections during the WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

R. Stewart: Confirmed No known IPR
M. Tuexen: Confirmed No known IPR
M. Proshin: Confirmed No known IPR

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is strong consensus, and no opposition for this proposed update,
The WG has consensus to open edits of the base spec with a
view to progress SCTP to Full Standard.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None.

(13) Have all references within this document been identified as
either normative or informative?

Done

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

These are documented in section 3.44, and describe issues already raised with IANA.
IANA is requested to check the revised text is consistent with their registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None.

NOTES ON IMPLEMENTATIONS (draft-ietf-tsvwg-rfc4960-errata-05):

The following implementation status reports were received:
"The FreeBSD kernel implementation should already follow the new text given in the document." - Michael Tuexen, 6th March 2018.

"I have no comments on it myself. Have used this Errata some time ago
(we had rwnd/cwnd handling fixes on Linux stack because of the errata),
went over it again now, it LGTM and I don't think we (Linux stack) have
(major) discrepancies due to it." - Marcelo Ricardo Leitner November, 21st 2017.

"Ericsson SCTP implementations support the changes proposed in the draft and they are already deployed in real mobile networks." - Maxim Proshin, 7th March 2018.

Dear TSVWG WG,

As we discussed during the TSVWG session today, the draft "RFC 4960 Errata and Issues", is thought ready for publication and now ready for feedback. The latest version of the draft is available here:
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04

This email starts a 3 week WGLC to allow time for folks to provide feedback, to conclude on Fri 8th Dec 2017. Please send comments indicating the usefulness of the draft, noting issues, or simply asking for clariification to this list (or to the WG Dhairs).

Best Regards,

Gorry, David and Wes
(TSVWG co-Chairs)

The following people have agreed to also submit a review during the WGLC period:
Kacheong
Peter Lei
Irene Rungeler
Qiaobing Xie