SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
draft-ietf-tsvwg-sctp-failover-16

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

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

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

Juergen Schoenwaelder  

performed the opsdir review

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