Re: [Gen-art] Gen-art LC review of draft-ietf-tsvwg-sctp-failover-14

Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Tue, 05 January 2016 10:42 UTC

Return-Path: <karen.nielsen@tieto.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE691B2AA7 for <gen-art@ietfa.amsl.com>; Tue, 5 Jan 2016 02:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Kx5l8eK6bNoO for <gen-art@ietfa.amsl.com>; Tue, 5 Jan 2016 02:42:34 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2651B2AA2 for <gen-art@ietf.org>; Tue, 5 Jan 2016 02:42:34 -0800 (PST)
Received: by mail-ig0-x234.google.com with SMTP id ph11so11648445igc.1 for <gen-art@ietf.org>; Tue, 05 Jan 2016 02:42:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=G05bln50IXYLKSuKIiNg0/JCxE5SjtOPC41mF4CKXHI=; b=z/Q4MH1AvuIbWJNpDjeiJ2eNqa6k77HYErxdPQgF2d8UdZyofyZrNWDsQiezDf48mX sISHq1p7OZeoLJx9xU/flx2vDicSfgfuyd/teJF+MO4oxmXVoHDjgkHaFK+CHfRSb3Uu TcqSbiiPU/9WFOMy0hxOBtTftIiYXT19ZSlR0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=G05bln50IXYLKSuKIiNg0/JCxE5SjtOPC41mF4CKXHI=; b=SAQKycF8v0s/uUDdb9jbeQxEhuG7UhLZTvl6kXwrRfZnsX0J9rvBubsCAwzP0j5RUE avAhjJ6voo6o2/yABoVXQXpdlHQmxqKCWDymlLrSWO8vrJIqp28PfoctpGjE/ZoD6oQr n+/x2A42zZABgu6XPeAUOj3qs1FdPZ1rAO7Ueg4Tls1nqjLBjK6OEuMqmaYCXSxIOmdp 0VXn8G+gDc+yrEB9y3eg4tL2nj4eqLzUw7Fg4hPySW/DQKyBa+/rfE1ng40wUnQPxxFK 4gbvb0oxhLr30MOYQ/krvnzCfS9Er06bYdv/Sd8pkK9ulRBRVDeSiDtIgGfQDYZ13MmL AFtw==
X-Gm-Message-State: ALoCoQmG8+vvxqYRio9/m1Thlq9gx1rTrbqbnBFINyJE6fJyPtV9l9JkmV9rFmQ90FfgGo+k6hSLHccv6OBeIQfyqWM+VHTDDe7NMxm8VVimRkgarT6gTRaaIHdxobFWYt8StnmUsHSOB3fV0rBH8xK6CYbm6rHwCA==
X-Received: by 10.50.114.3 with SMTP id jc3mr3212727igb.2.1451990553561; Tue, 05 Jan 2016 02:42:33 -0800 (PST)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <567AC059.7080303@isode.com> <CAO249ycVpGjbnGiYUczs0um=En_Ctm3YCFhVmFCRXJUZ-N6u_Q@mail.gmail.com> <F6D7A8DA-E2CD-41C8-B852-7C69EDF68298@isode.com> <CAO249yf3Zz1oY9tB0D4cOQi+7doYJEjmye=xohLBWOD5QVi9MA@mail.gmail.com> <568A4DE9.6020302@isode.com>
In-Reply-To: <568A4DE9.6020302@isode.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQI92kmk2Oyp3PZhhWyNNbVd2nPLgQJgc2FfAfJS8qwBWymUSwFpFYv2ndqy2fA=
Date: Tue, 5 Jan 2016 11:42:31 +0100
Message-ID: <990f9c74c8998c02a2dcd2eb605125c1@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Content-Type: multipart/alternative; boundary=089e0153844829a7fb052893e519
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/1ljnNsySIeLtO2xvlFw7iN08sNg>
Cc: draft-ietf-tsvwg-sctp-failover.all@ietf.org, General area reviewing team <gen-art@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-tsvwg-sctp-failover-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 10:42:37 -0000

HI,



Please find some feedback below.



BR, Karen



*From:* Alexey Melnikov [mailto:alexey.melnikov@isode.com]
*Sent:* 4. januar 2016 11:48
*To:* Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
*Cc:* General area reviewing team <gen-art@ietf.org>rg>;
draft-ietf-tsvwg-sctp-failover.all@ietf.org; The IESG <iesg@ietf.org>
*Subject:* Re: Gen-art LC review of draft-ietf-tsvwg-sctp-failover-14



Hi Yoshi,

On 02/01/2016 23:03, Yoshifumi Nishida wrote:

Hi Alexey,



On Sat, Jan 2, 2016 at 6:49 AM, Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

Hi Yoshi,


On 2 Jan 2016, at 09:20, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:

Hi Alexey,



Thanks for the comments.



On Wed, Dec 23, 2015 at 7:40 AM, Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-tsvwg-sctp-failover-14
Reviewer: Alexey Melnikov
Review Date: 2015-12-23
IETF LC End Date: 2015-12-23
IESG Telechat date: (if known) N/A

Summary: Ready with a couple of minor points that need to be clarified.

Major issues:
None

Minor issues:

In Section 5

   However as [RFC4960] switchback behavior is
   suboptimal in certain situations, especially in scenarios where a
   number of equally good paths are available, an SCTP implementation
   MAY support also, as alternative behavior, the Primary Path
   Switchover mode of operation and MAY enable it based on users’
   requests.

Did you really mean "users" (human beings) and not "applications"
(programs) here? I.e., is this something that needs to be exposed in APIs
or User Interfaces.



Yes, It basically meant if people prefer (which means they understand its
advantage and disadvantage), this feature can be activated.

APIs or UIs can be implemented for this, but I'm not very sure if we need..
Could you elaborate your concern here?



Your text sounds like a requirement on UIs (and not on APIs), I think you
meant a requirement on APIs (with no requirement on UIs, which might expose
this option anyway. I personally think that exposing this option to anybody
by application developers or system administrators is going to be a
mistake). So I think you should change "users'" to "applications'". I am
sorry if this sounds like nitpicking, but I think this is an important
difference.



Ok. I see your point. What we have presumed here is something like sysctl
command which only administrators can run.

This is because it might be difficult for endusers to know whether equally
good paths a available or not.

So, an example of the usage is administrators activate this feature after
some discussions with their users or customers.

If we say "enable it based on users' (e.g. system administrators)
decisions", do you think it will be clearer?

Yes.

*[Karen Elisabeth Egede Nielsen] Hmm…. **We have defined a run-time API for
this by purpose. Further in some signaling node implementations in
deployment this API has been exposed all the way up to the UI/O&M
 interface towards Users (human system administrators/operators) as
configurable on a per association level. I do however agree with changing
the text either simple replacing “users” with “applications” or by the
clarification on system administrators as there is no requirement for such
to be controlled by the users on all applications/all systems.*

In Section 7.1: should new constants be defined with specific numeric
values, in order to improve interoperability?



In my understanding, RFC6458 doesn't define specific numeric values. I
prefer to follow the convention of RFC6458 unless there are strong reasons.



How is ABI interoperability (binary interface interoperability between
different implementations, for example if they are implemented as shared
libraries) achieved with SCTP options?



The peer state value is exchanged only between an SCTP stack and its
applications. It won't be exchanged between SCTP stacks.

(SCTP stacks estimate their peers' state from packet loss and other info.)

I think that's why RFC6458 didn't have to define numeric values.


Is this common for SCTP extensions? For other APIs I am familiar with
applications are frequently linked against shared libraries, so
standardizing numeric values is beneficial (even if they are never sent
across the wire).

*[Karen Elisabeth Egede Nielsen] Yes this is common for all constants in
the SCTP API, RFC6458. Extensions as well as “base constants”.*