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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

HI Gorry,

Yes,

Things have been complicated here...

I have started working on the update.
We should aim to have a document version out next week for the wg.

BR, Karen

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Thursday, June 11, 2015 1:57 PM
>To: [e-mail]
>Cc: [e-mail]
>Subject: Finishing: draft-ietf-tsvwg-sctp-failover
>
>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. 
 •  BUT... some re-structuring would still be
>beneficial, given PS 
 •  Next step would be a -11 revision:
>
 – Implement the agreed technical resolutions
 – 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.
>

>