[tsvwg] Finishing: draft-ietf-tsvwg-sctp-failover

gorry@erg.abdn.ac.uk Thu, 11 June 2015 11:58 UTC

Message-ID: <22ef29b3a8ed578cdeead82532cd6796.squirrel@erg.abdn.ac.uk>
Date: Thu, 11 Jun 2015 12:57:23 +0100
From: gorry@erg.abdn.ac.uk
To: karen.nielsen@tieto.com
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/tsvwg/4NFf1T9CeOJG_nmxprDmMri_EiQ>
Cc: tsvwg@ietf.org
Subject: [tsvwg] Finishing: draft-ietf-tsvwg-sctp-failover
Precedence: list

Karen,

There is some editorial work needed to prepare
draft-ietf-tsvwg-sctp-failover for IESG review. The RFC 2119 usage
generally now looks good. Can I encourage you (Karen) as the document
editor to take the XML and provide the final edits needed to finish this.

I believe the WG was promised it would be sent to the IESG before IETF-93,
which means starting a WGLC in a week or two.

Best wishes,

Gorry & David
(tsvwg co-chairs)

---

As I recall the proposed next steps from the last IETF meeting were:

  All technical issues raised including standards language, are (believed
to have been) resolved. &#8232;
  BUT... some re-structuring would still be beneficial, given PS &#8232;
  Next step would be a -11 revision:
&#8232;  Implement the agreed technical resolutions&#8232;  Still
improve language and some restructuring

Extract from notes of meeting:

          Michael: If the heartbeat is not disabled by the user, then must
            send these faster. If not, then follow the user. If you make the
            text explicit, then OK.
          Michael: There is a change to the security model, it is not only
            faster, but with permanent failover, STCP moves the traffic away
            permanently from the first path if there is a traffic peak.
          Karen: The draft also proposes a mode with permanent switch over,
            we will document the changes and the security implications.
          Gorry: The security section was short, this should address that.
            The abstract should mention the API exists as a separate section.

          Karen: We received comments suggesting we remove the discussion of
            CC - since this document removes this.
          Gorry: I suggest you may leave the text marked "RFC Editor to
Remove",
            so the IETF and IESG knows that CC changes were discussed, and
            that there was consensus that this change was agreed.
          David Black: Please change the lower-case "should" to an "ought
to".

          Karen: We do not think this should update RFC 4960.
          Gorry: First, is implementation optional for a compliant SCTP
stack?
          Karen: Yes, optional
          Gorry: Are you updating the base mechanisms that you expect base
            implementer to read this?
          Randal Stewart: You would not want to update RFC 4960,
            because that would make existing implementations non compliant.
            I do not think this document should update RFC 4960.
          David: Is there a hidden "SHOULD" here?
            Is the text clear that this is based on one way to implement
            RFC4960, but this builds on one specific way to do this.
          Randal: There are reasons that an implementation does not want the
            dormant state specified in the base spec. This is an
            implementation choice needed for this specific spec.
          Chairs: We seem to have agreement this will not update RFC 4960.
&#8232;

[tsvwg] Finishing: draft-ietf-tsvwg-sctp-failover gorry
Re: [tsvwg] Finishing: draft-ietf-tsvwg-sctp-fail… Karen Elisabeth Egede Nielsen