SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
RFC 7829

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

Spencer Dawkins Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2016-02-02 for -15)
- 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.

(Benoit Claise) No Objection

Comment (2016-02-02 for -15)
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 ...

Alissa Cooper No Objection

(Stephen Farrell) No Objection

Comment (2016-02-03 for -15)

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.)

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2016-02-03 for -15)
Juergen Schoenwaelder  

performed the opsdir review

(Barry Leiba) No Objection

Comment (2016-02-03 for -15)
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

Terry Manderson No Objection

Alvaro Retana No Objection