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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sat, 02 January 2016 09:20 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 404611B2BB3; Sat, 2 Jan 2016 01:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.915
X-Spam-Level: **
X-Spam-Status: No, score=2.915 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, 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 LZtYOLFuPXgO; Sat, 2 Jan 2016 01:20:45 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6F61B2BB4; Sat, 2 Jan 2016 01:20:44 -0800 (PST)
Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 97F4A2781D3; Sat, 2 Jan 2016 18:20:41 +0900 (JST)
Received: by mail-yk0-f174.google.com with SMTP id a85so132520325ykb.1; Sat, 02 Jan 2016 01:20:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.129.31.67 with SMTP id f64mr56315963ywf.94.1451726440256; Sat, 02 Jan 2016 01:20:40 -0800 (PST)
Received: by 10.129.147.5 with HTTP; Sat, 2 Jan 2016 01:20:40 -0800 (PST)
In-Reply-To: <567AC059.7080303@isode.com>
References: <567AC059.7080303@isode.com>
Date: Sat, 02 Jan 2016 01:20:40 -0800
X-Gmail-Original-Message-ID: <CAO249ycVpGjbnGiYUczs0um=En_Ctm3YCFhVmFCRXJUZ-N6u_Q@mail.gmail.com>
Message-ID: <CAO249ycVpGjbnGiYUczs0um=En_Ctm3YCFhVmFCRXJUZ-N6u_Q@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary="001a1141ed3cc861960528566614"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/9_7KtpJX6clBYHTovv4XYr27o1g>
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: Sat, 02 Jan 2016 09:20:47 -0000

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?


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

Thanks!
--
Yoshi