SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
RFC 7829
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
Alvaro Retana No Objection
(Martin Stiemerling; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
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 steering group member) No Objection
- 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 steering group member) No Objection
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 steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
Juergen Schoenwaelder performed the opsdir review
(Stephen Farrell; former steering group member) No Objection
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 steering group member) No Objection