Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-sctp-failover-15: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 03 Feb 2016 05:41:42 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-sctp-failover-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 3 Feb 2016 13:31:31 -0800

Hi Stephan,
Thanks for the comments.

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/

Yes, this has been brought up several times.
After some discussions with folks include 4960 authors, we have chosen
this.
If necessary, we can revisit this point.

> ack, and that maps 1:1 with a destination address in the PF

This is SHOULD statement. So, if an implementation can utilize some info
outside of SCTP, it can override it.

Regards,
--
Yoshi