Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014

"Becke, Martin" <martin.becke@uni-due.de> Tue, 25 November 2014 19:53 UTC

Return-Path: <martin.becke@uni-due.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B221A6FB4 for <tsvwg@ietfa.amsl.com>; Tue, 25 Nov 2014 11:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.96
X-Spam-Level:
X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQHm9QvFVZwz for <tsvwg@ietfa.amsl.com>; Tue, 25 Nov 2014 11:53:27 -0800 (PST)
Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9459E1A0367 for <tsvwg@ietf.org>; Tue, 25 Nov 2014 11:53:27 -0800 (PST)
Received: from HT01.win.uni-due.de ([132.252.185.215]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id sAPJrOPO013988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Nov 2014 20:53:24 +0100
Received: from ccr02.win.uni-due.de ([169.254.2.70]) by HT01.win.uni-due.de ([132.252.190.233]) with mapi id 14.03.0210.002; Tue, 25 Nov 2014 20:53:23 +0100
From: "Becke, Martin" <martin.becke@uni-due.de>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014
Thread-Index: AQHP84DRDtBde8o0EkqP4662Lb1M95xx687N
Date: Tue, 25 Nov 2014 19:53:22 +0000
Message-ID: <A33D17830EBE774E8AEFAED600DD54E20180066A0A@ccr02.win.uni-due.de>
References: <5d68d136cd87bde12faaf414b05167d3.squirrel@spey.erg.abdn.ac.uk>
In-Reply-To: <5d68d136cd87bde12faaf414b05167d3.squirrel@spey.erg.abdn.ac.uk>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [132.252.185.216]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16
Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/wgluaxmvk4xVKviiIr8bEbsQsRM
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 19:53:29 -0000

Hi all, 

I read the draft and I still think the algorithm described is functional and useful. I like the idea to introduce a potentially failed state (PF) to optimize the send process. 

I have only some questions/comments (No editorial comments, perhaps a native speaker can check the text, too):

- Perhaps the authors can give me a hint why it should be RECOMMENDED  to set the PFMR value to 0 when Quick Failover is used.  I would expect a value > 0 when it is used and 0 when it is not(!) used.   

- I think the term “multiple destinations” irritates.  Perhaps you can use “destination addresses” or “addresses” instead”.  FMPOV the use of the term “destination” in this draft is inaccurate.  In general the terms path, destination, destination address are very mixed for my feeling. Perhaps this can be rechecked.   

- “Heartbeats SHOULD be sent to PF destination(s) once per RTO. This means the sender MUST ignore HB.interval for PF destinations.”
 
This sounds strange to me. Why is SHOULD used here and what are the alternatives, when I MUST ignore HB.interval for PF destinations. I guess a rephrase of this two lines can help. 

- A link is missing in Section 5.1: [RFC6458] defines the constants SCTP_ADDR_AVAILABLE,….

Best 
________________________________________
Von: tsvwg [tsvwg-bounces@ietf.org]&quot; im Auftrag von &quot;gorry@erg.abdn.ac.uk [gorry@erg.abdn.ac.uk]
Gesendet: Mittwoch, 29. Oktober 2014 15:01
An: tsvwg@ietf.org
Cc: gorry@erg.abdn.ac.uk
Betreff: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014

TSVWG,

This is the start of a WGLC on "Quick Failover Algorithm in SCTP".
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-08

This WGLC will last until Wednesday, 19th November, 2014, this includes
the period of the coming IETF meeting.

A good note to the list is "I have read this version of the draft,
and I approve (or support) its progression to RFC". The chairs
request notes to the list showing support to get a sense of the WG.

Of course, you can ask for alternate text (where you supply the
actual replacement text, or convey the meaning sufficiently to the
authors) for anywhere in the document that you find unclear or troublesome.

James/Gorry/David
TSVWG chairs