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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Wed, 26 November 2014 08:27 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.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 F26051A6F5A for <tsvwg@ietfa.amsl.com>; Wed, 26 Nov 2014 00:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.961
X-Spam-Level:
X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6, SPF_HELO_PASS=-0.001, 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 vDVFF2qYtkNM for <tsvwg@ietfa.amsl.com>; Wed, 26 Nov 2014 00:27:57 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4D91A6F57 for <tsvwg@ietf.org>; Wed, 26 Nov 2014 00:27:57 -0800 (PST)
Received: from [192.168.1.200] (p548190F0.dip0.t-ipconnect.de [84.129.144.240]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 44E911C1622BA; Wed, 26 Nov 2014 09:27:55 +0100 (CET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <A33D17830EBE774E8AEFAED600DD54E20180066A0A@ccr02.win.uni-due.de>
Date: Wed, 26 Nov 2014 09:27:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3275B07E-DFD6-412E-97D5-7E71740DDBBC@lurchi.franken.de>
References: <5d68d136cd87bde12faaf414b05167d3.squirrel@spey.erg.abdn.ac.uk> <A33D17830EBE774E8AEFAED600DD54E20180066A0A@ccr02.win.uni-due.de>
To: Martin Becke <martin.becke@uni-due.de>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tsvwg/pEZYhu8nCrqPwgx63B2JCOfJDOo
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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: Wed, 26 Nov 2014 08:27:59 -0000

On 25 Nov 2014, at 20:53, Becke, Martin <martin.becke@uni-due.de> wrote:

> 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.   
Because it is not a flag controlling the usage of Quick Failover, but a threshold. See second item
in the enumeration in Section 4.2.

Best regards
Michael
> 
> - 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
> 
> 
>