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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 05 January 2016 05:10 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 75BBD1B2B5C; Mon, 4 Jan 2016 21:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.221
X-Spam-Level: *
X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_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 DdLPDG7tRbdZ; Mon, 4 Jan 2016 21:10:54 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21DA1B2B5A; Mon, 4 Jan 2016 21:10:54 -0800 (PST)
Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com [209.85.160.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4C3C8278161; Tue, 5 Jan 2016 14:10:52 +0900 (JST)
Received: by mail-yk0-f180.google.com with SMTP id v14so177695948ykd.3; Mon, 04 Jan 2016 21:10:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.13.205.199 with SMTP id p190mr75450515ywd.116.1451970650787; Mon, 04 Jan 2016 21:10:50 -0800 (PST)
Received: by 10.129.147.5 with HTTP; Mon, 4 Jan 2016 21:10:50 -0800 (PST)
In-Reply-To: <568A4DE9.6020302@isode.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>
Date: Mon, 4 Jan 2016 21:10:50 -0800
X-Gmail-Original-Message-ID: <CAO249ycoV-Hjy14gNap+7xNGA+fez4dT1rT4M31wR2CASawX=A@mail.gmail.com>
Message-ID: <CAO249ycoV-Hjy14gNap+7xNGA+fez4dT1rT4M31wR2CASawX=A@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary=001a114e5eb6dd58fe05288f42ad
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/WMsYz_u3YnuoghcXEpjUpkHYwHA>
Cc: draft-ietf-tsvwg-sctp-failover.all@ietf.org, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, 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 05:10:57 -0000

Hi Alexey,

On Mon, Jan 4, 2016 at 2:48 AM, Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

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

Thanks!

> 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).
>

I am not the best person to answer it. But, as far as I checked, RFC6525,
RFC7053 and RFC7496 don't define numeric values except chunk values which
will be on the wire.

Thanks,
--
Yoshi