Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
draft-ietf-tsvwg-sctp-prpolicies-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-04-08
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-03-25
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-03-05
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-02-12
|
07 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-02-11
|
07 | (System) | RFC Editor state changed to EDIT |
2015-02-11
|
07 | (System) | Announcement was received by RFC Editor |
2015-02-11
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2015-02-11
|
07 | (System) | IANA Action state changed to In Progress |
2015-02-11
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2015-02-11
|
07 | Amy Vezza | IESG has approved the document |
2015-02-11
|
07 | Amy Vezza | Closed "Approve" ballot |
2015-02-11
|
07 | Amy Vezza | Ballot approval text was generated |
2015-02-11
|
07 | Amy Vezza | Ballot writeup was changed |
2015-02-07
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-07
|
07 | Michael Tüxen | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-02-07
|
07 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-07.txt |
2015-02-05
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2015-02-05
|
06 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-02-05
|
06 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-02-05
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-02-04
|
06 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2015-02-04
|
06 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-02-03
|
06 | Kathleen Moriarty | [Ballot comment] Thank you for addressing the SecDir review questions. https://www.ietf.org/mail-archive/web/secdir/current/msg05262.html |
2015-02-03
|
06 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-03
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-02-03
|
06 | Benoît Claise | [Ballot comment] 1. Using the Priority Policy allows the sender of a user message to specify a priority. When storing a user message … [Ballot comment] 1. Using the Priority Policy allows the sender of a user message to specify a priority. When storing a user message in the send buffer while there is not enough available space, the SCTP stack at the sender side MAY abandon other user messages of the same SCTP association with a priority lower than the provided one. From the same SCTP association or the same stream within the SCTP association? Or is this implementation specific? 2. While reading through the draft, I was actually wondering how I could use those extensions in IPFIX. The first one is not applicable. Then I found in section 3.2: The Priority Policy can be used in the IPFIX protocol stack. See [RFC7011] for more information. This is a little lit light. I believe you should explain the use case you have in mind... because I don't believe this was an IPFIX requirement. |
2015-02-03
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-02-03
|
06 | Stephen Farrell | [Ballot comment] So I assume the ability to say "please re-tx this 2^32-1 times" is said to not introduce any new security consideration, because that … [Ballot comment] So I assume the ability to say "please re-tx this 2^32-1 times" is said to not introduce any new security consideration, because that is not sent over the wire. However, could there not be a DoS against a kernel from userland? And if that limit is set based on some WebRTC JS (is it? I don't know) then wouldn't that be a way to DoS a browser and possibly the other end of a WebRTC data channel too? So, perhaps noting the above would be good, as well as saying that implementations SHOULD or MUST have a limit that they enforce on the max number of re-tx's? (Apologies if that is there already and I missed it.) |
2015-02-03
|
06 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-02-03
|
06 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-02-02
|
06 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2015-02-02
|
06 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-01-29
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-01-28
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Tom Taylor |
2015-01-28
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Tom Taylor |
2015-01-26
|
06 | Barry Leiba | [Ballot comment] -- Section 3.1 -- The Limited Retransmissions Policy can be used with data channels in the WebRTC protocol stack. See [ … [Ballot comment] -- Section 3.1 -- The Limited Retransmissions Policy can be used with data channels in the WebRTC protocol stack. See [I-D.ietf-rtcweb-data-channel] for more information. I wonder whether implementors might misunderstand, and think this is meant to be restrictive. Please consider changing the wording (here and in 3.2) to something like this: NEW The Limited Retransmissions Policy was designed to be used with data channels in the WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), and can also be used in other appropriate situations. END ...or maybe... NEW The WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), is an example of where the Limited Retransmissions Policy might be used. END -- Section 3.2 -- When storing a user message in the send buffer while there is not enough available space, the SCTP stack at the sender side MAY abandon other user messages of the same SCTP association with a priority lower than the provided one. The algorithm for selecting the message being abandoned is implementation specific. A minor point: the first part is written as allowing multiple messages to be abandoned, and the last sentence is written in the singular. Should the second part say "message(s)" ? -- Section 4.2 -- The table shows the two policies that come out of RFC 6458 and the two that come from this document. Is it worth it to create a (FCFS?) registry for these names, to document them and provide references? |
2015-01-26
|
06 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2015-01-26
|
06 | Barry Leiba | [Ballot discuss] I have four things I'd like to discuss; three are up here, and one is down in the non-blocking comments. 1. Section 4 … [Ballot discuss] I have four things I'd like to discuss; three are up here, and one is down in the non-blocking comments. 1. Section 4 says this: Please note that this section is informational only. How are sections 4.2 thru 4.5 not normative? 2. The table in Section 4.2 shows the two policies that come out of RFC 6458 and the two that come from this document. Is this the time to create a registry for these? 3. In Section 6, you say that this adds no security considerations. Are there really no security considerations introduced by new conditions under which messages can be abandoned? And who determines the message priorities? Are there no security considerations involved in that determination? Is there no discussion at all that might be useful in determining reasonable values for Limited Retransmission Policy? |
2015-01-26
|
06 | Barry Leiba | [Ballot comment] -- Section 3.1 -- The Limited Retransmissions Policy can be used with data channels in the WebRTC protocol stack. See [ … [Ballot comment] -- Section 3.1 -- The Limited Retransmissions Policy can be used with data channels in the WebRTC protocol stack. See [I-D.ietf-rtcweb-data-channel] for more information. This isn't a DISCUSS, because I don't think I want to block the document on this, but I would like to discuss it: Is this meant to put restrictions on where the Limited Retransmissions Policy can be used? If so, it should be clearer about that. If not, what's the reason for this specific shout-out? The same question applies to this paragraph from Section 3.2: The Priority Policy can be used in the IPFIX protocol stack. See [RFC7011] for more information. -- Section 3.2 -- When storing a user message in the send buffer while there is not enough available space, the SCTP stack at the sender side MAY abandon other user messages of the same SCTP association with a priority lower than the provided one. The algorithm for selecting the message being abandoned is implementation specific. A minor point: the first part is written as allowing multiple messages to be abandoned, and the last sentence is written in the singular. Should the second part say "message(s)" ? |
2015-01-26
|
06 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2015-01-22
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-01-22
|
06 | Spencer Dawkins | Telechat date has been changed to 2015-02-05 from 2015-01-22 |
2015-01-22
|
06 | Spencer Dawkins | Placed on agenda for telechat - 2015-01-22 |
2015-01-22
|
06 | Spencer Dawkins | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-01-22
|
06 | Spencer Dawkins | Changed consensus to Yes from Unknown |
2015-01-22
|
06 | Spencer Dawkins | Ballot has been issued |
2015-01-22
|
06 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-01-22
|
06 | Spencer Dawkins | Created "Approve" ballot |
2015-01-22
|
06 | Spencer Dawkins | Ballot writeup was changed |
2014-12-11
|
06 | Michael Tüxen | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-12-11
|
06 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-06.txt |
2014-12-04
|
05 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. |
2014-12-01
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu. |
2014-12-01
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-11-14
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-11-14
|
05 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tsvwg-sctp-prpolicies-05, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-tsvwg-sctp-prpolicies-05, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2014-11-14
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2014-11-14
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2014-11-13
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2014-11-13
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2014-11-11
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2014-11-11
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2014-11-10
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-11-10
|
05 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Additional Policies for the Partial … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol) to Proposed Standard The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol' as Proposed Standard 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 2014-12-1. 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 defines two additional policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-11-10
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-11-10
|
05 | Spencer Dawkins | Last call was requested |
2014-11-10
|
05 | Spencer Dawkins | Ballot approval text was generated |
2014-11-10
|
05 | Spencer Dawkins | Ballot writeup was generated |
2014-11-10
|
05 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-11-10
|
05 | Spencer Dawkins | Last call announcement was changed |
2014-11-10
|
05 | Spencer Dawkins | Last call announcement was generated |
2014-11-09
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-11-09
|
05 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-05.txt |
2014-11-09
|
04 | Spencer Dawkins | A revised I-D may not be needed - I sent questions to the shepherd that may result in a revised I-D, but this is the … A revised I-D may not be needed - I sent questions to the shepherd that may result in a revised I-D, but this is the Substate that seemed to reflect that most clearly ... |
2014-11-09
|
04 | Spencer Dawkins | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2014-10-27
|
04 | Cindy Morgan | Intended Status changed to Proposed Standard |
2014-10-27
|
04 | Cindy Morgan | IESG process started in state Publication Requested |
2014-10-27
|
04 | (System) | Earlier history may be found in the Comment Log for /doc/draft-tuexen-tsvwg-sctp-prpolicies/ |
2014-10-27
|
04 | Cindy Morgan | Working group state set to Submitted to IESG for Publication |
2014-10-27
|
04 | Cindy Morgan | (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? … (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? PS (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: The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document defines two additional policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. Document Quality: The document is thought ready for publication. Note the socket API information is traditionally included as an informational section within SCTP specs. This API is thought to be completely implemented in FreeBSD, to be released in FreeBSD 10.1 Personnel: Who is the Document Shepherd? G Fairhurst (TSVWG Co-Chair) Who is the Responsible Area Director? Spencer Dawkins (TSV AD) (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. The document was reviewed against related documents and is thought ready to proceed. (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. No (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? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None are known (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? A WGLC was made in TSVWG, to end July 21st, 2014, with 5 comments. All were supportive of publishing a spec. on this topic. The update to the revised ID was discussed in TSVWG after the WGLC. (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None (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? Yes (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? OK (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). This document requires no actions from IANA (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-- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. |
2014-10-27
|
04 | Cindy Morgan | Changed document writeup |
2014-10-27
|
04 | Spencer Dawkins | Shepherding AD changed to Spencer Dawkins |
2014-09-28
|
04 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-04.txt |
2014-07-23
|
03 | Henrik Levkowetz | This document now replaces draft-tuexen-tsvwg-sctp-prpolicies instead of None |
2014-07-21
|
03 | Gorry Fairhurst | Document shepherd changed to Gorry Fairhurst |
2014-07-21
|
03 | Gorry Fairhurst | Document shepherd changed to David L. Black |
2014-05-29
|
03 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-03.txt |
2014-04-08
|
02 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-02.txt |
2014-01-22
|
01 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-01.txt |
2013-12-14
|
00 | Michael Tüxen | New version available: draft-ietf-tsvwg-sctp-prpolicies-00.txt |