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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 04 January 2016 10:48 UTC

Return-Path: <alexey.melnikov@isode.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 4FF761A8785; Mon, 4 Jan 2016 02:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 K5eS-tAgFEY8; Mon, 4 Jan 2016 02:48:13 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 74FC61A8784; Mon, 4 Jan 2016 02:48:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1451904492; d=isode.com; s=selector; i=@isode.com; bh=caZwzacAGwsqgfLIqCFT7ytevEYPMAmXcyQogXtFpys=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TGc9JUckFjUOm17Wa8C1hf6AU20n6fQ4ARgJGkd3gMeJ8GuuLRdjMfVdLSFQrjY+9zrl38 q2XUJtQdmq1cZTMPlUZsct1DGpWB6PeDaVVKpLGrWdtPc//uGdPWXn7Wxy7wvAPCBlgiIv RhT/ZTqvWOqc7OrwEXp8KYN60kWrhG4=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VopN6wAbMG5Q@waldorf.isode.com>; Mon, 4 Jan 2016 10:48:12 +0000
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
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>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <568A4DE9.6020302@isode.com>
Date: Mon, 4 Jan 2016 10:48:09 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <CAO249yf3Zz1oY9tB0D4cOQi+7doYJEjmye=xohLBWOD5QVi9MA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------080103010406070800070800"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/hlNIN_AKVbbUyK5hCQcHm3NcGdQ>
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: Mon, 04 Jan 2016 10:48:16 -0000

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 <mailto:alexey.melnikov@isode.com>> wrote:
>
>     Hi Yoshi,
>
>     On 2 Jan 2016, at 09:20, Yoshifumi Nishida <nishida@sfc.wide.ad.jp
>     <mailto: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 <mailto: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.
>
>>         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).