SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
draft-ietf-tsvwg-sctp-failover-16
Yes
(Martin Stiemerling)
(Spencer Dawkins)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Terry Manderson)
Note: This ballot was opened for revision 15 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
(for -15)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -15)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -15)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2016-02-03 for -15)
Unknown
In addition to the 2119 issues that Ben has raised... In Section 3.2 bullet 1: The RECOMMENDED value of PFMR is 0, but other values MAY be used. "SHOULD do X, but MAY do Y" makes no sense. In this case, you can (should) just remove "but other values MAY be used". You might instead say *why* 0 is recommended at a 2119 level (implying that it has interoperability implications). In bullet 9, I found this to be oddly worded: A SCTP sender MAY clear the error counter and move a destination address back to active state if it has other information, than the acknowledgment, that uniquely determines which destination, among multiple destination addresses, the chunk reached. Perhaps this?: NEW A SCTP sender MAY clear the error counter and move a destination address back to active state if it has information other than the acknowledgment that uniquely determines which destination, among multiple destination addresses, the chunk reached. END
Ben Campbell Former IESG member
No Objection
No Objection
(2016-02-02 for -15)
Unknown
- 3.2: Since PMR is allowed to be greater than zero, there is the potential to have a non-zero error count but not yet have entered the potentially failed state. Did I miss guidance on when the error count might be reset under those conditions? (I found guidance for when in the potentially failed state.) -3.2, 4: The paragraph says the sender MUST follow the following rules, but both of those rules just say SHOULD. I'm not sure what that means. - 3.2, 7: "sender SHOULD clear the error counter" Why not MUST? - 4, 3rd paragraph: "handling SHOULD NOT be coupled" Why not MUST? - 6: The recommended value for PFMR is redundant with an earlier section. Editorial: - There are a number of places where paragraphs are put into long numbered lists for no apparent reason. Could those not just be normal paragraphs? As it is, I keep getting section numbers and paragraph numbers confused. - 3.2, 3.ii:"...the sender thus by [RFC4960], section 6.4.1, should attempt..." The wording is confusion. I think you mean something to the effect of "According to [RFC4960] section 6.4.1, when the sender retransmits data that has timed out, it should attempt..." - 3.2, 4, last paragraph: The current wording can be interpreted ambiguously. I think you mean the following: OLD The sender MUST NOT change the state and the error counter of any destination address regardless of whether it has been chosen for transmission or not. NEW The sender MUST NOT change the state and the error counter of any destination address simply because it has been chosen for transmission. END - 6: RECOMMENDATIONS should not be capitalized. -7: The section says it's informational. Does that include child sections? I found at least one 2119 MAY at te end of 7.2.
Benoît Claise Former IESG member
No Objection
No Objection
(2016-02-02 for -15)
Unknown
As discussed by Jürgen Schönwäder (part of this OPS DIR review) and the authors. Jürgen: Since the I-D introduces the new state Potentially Failed, does this imply that an update of the SCTP-MIB [RFC3873] (sctpAssocState) is needed as well? Are there additional MIB objects to report, e.g., spt_pathpfthld and spt_pathcpthld? I see some additional SCTP related docs in TSVWG and perhaps after they have been completed an update of the SCTP-MIB would make sense to consider. Yoshifumi Nishida: I think it makes senses to update MIB. We'll check with implementors and other experts. Thanks for pointing it out. Ideally, you should add a sentence or two expressing that RFC3873 should be updated to support this functionality with a few objects that ...
Brian Haberman Former IESG member
No Objection
No Objection
(for -15)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -15)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-02-03 for -15)
Unknown
Juergen Schoenwaelder performed the opsdir review
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-02-03 for -15)
Unknown
Thanks for a clearly written specification. - Should this formally UPDATE 4960? I don't care but some might:-) If you want new SCTP implementations to include this then adding the UPDATES may make sense. - 3.2, step 9: Just wondering: is this still true even if the implementation knows that the ack was received from a destination address that is currently in the PF state? (Say if all destination addresses are on different interfaces, and I can see on which interface I rx'd the ack, and that maps 1:1 with a destination address in the PF state.)
Terry Manderson Former IESG member
No Objection
No Objection
(for -15)
Unknown