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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 05 January 2016 11:13 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 900851B2AC7; Tue, 5 Jan 2016 03:13:30 -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 mk7SNFpJU0B7; Tue, 5 Jan 2016 03:13:28 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 92D091B2A6A; Tue, 5 Jan 2016 03:13:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1451992406; d=isode.com; s=selector; i=@isode.com; bh=350WOknNNpNYG5c8Vh/YFScp21HFwk8GH+TxD9DPq5A=; 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=fk0jyUmQTd0dMYiNqSHcKMsXEEOzBONWjJK+nFQ2+BNTFWfxkwp/BOcHaQiSvk+8JHHf2s +RfYfe1HU2WgKIO7uCNFQyo+aqnSG37eqbBkCCon6ewATbo4TJA9QZh+Ptm+qjXzGcq7x0 4fNLmEIPT/x7I23RKywIRZ4G4wdoQW4=;
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 <VoulVQAbMHTW@waldorf.isode.com>; Tue, 5 Jan 2016 11:13:26 +0000
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>, 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> <568A4DE9.6020302@isode.com> <990f9c74c8998c02a2dcd2eb605125c1@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <568BA548.102@isode.com>
Date: Tue, 5 Jan 2016 11:13:12 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <990f9c74c8998c02a2dcd2eb605125c1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------000704080606020709000108"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/sZbg-94nU7G6Sh7dm0X92DeNwNk>
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 11:13:30 -0000

Hi Karen,

On 05/01/2016 10:42, Karen Elisabeth Egede Nielsen wrote:
>
> HI,
>
> Please find some feedback below.
>
> BR, Karen
>
> *From:*Alexey Melnikov [mailto:alexey.melnikov@isode.com 
> <mailto:alexey.melnikov@isode.com>]
> *Sent:* 4. januar 2016 11:48
> *To:* Yoshifumi Nishida <nishida@sfc.wide.ad.jp 
> <mailto:nishida@sfc.wide.ad.jp>>
> *Cc:* General area reviewing team <gen-art@ietf.org 
> <mailto:gen-art@ietf.org>>; 
> draft-ietf-tsvwg-sctp-failover.all@ietf.org 
> <mailto:draft-ietf-tsvwg-sctp-failover.all@ietf.org>; The IESG 
> <iesg@ietf.org <mailto: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 <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.
>
> */[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./*
>
/*Agreed.*/
>
>
> *//*
>
>                 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”./*
>
Ok. I don't think this is right, but I will let go of this.

Best Regards,
Alexey