Tsvart last call review of draft-ietf-dmm-ondemand-mobility-15

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 08 January 2019 16:59 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB0F130F20; Tue, 8 Jan 2019 08:59:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: <tsv-art@ietf.org>
Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org, ietf@ietf.org, dmm@ietf.org
Subject: Tsvart last call review of draft-ietf-dmm-ondemand-mobility-15
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154696674971.25571.1339944415060306908@ietfa.amsl.com>
Date: Tue, 08 Jan 2019 08:59:09 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lnE4Mv5omRyeYApFPHxcgwqmOGs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 16:59:16 -0000

Reviewer: Magnus Westerlund
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

First of all I do become a bit uncertain about the intentions of this document.
As an informational document I think discussing an possible optimization and
how it can be solved is all okay. What I fail to see the point and a likely a
source of confusion is the draft socket API changes which may be considered as
solutions. However, an detailed solution to the problem space requires one to
actually dig into some of the areas the document explicitly calls outside of
its intentions. Thus, I wished the document was a bit clearer on its purpose of
only sketching an idea and be firmer of not actually offering a ready solution
that can be implemented. Thus, I think there are risks with having something
that appears to define a socket API extension. If the intention is to actually
define socket API extensions then I think there are much more that needs to be
defined and solved.

Secondly, I think the proponents of this work should have a long and serious
discussion if the ongoing work in the TAPS WG can actually provide an better
way forward for the API as well as provide an improvement to the TAPS
architecture. Because if an application specifies its needs for session
continuity then an TAPS implementation could fulfill this either using a
combination of TCP with Session lasting IP address or with Non-persistent IP
address and transport protocols that has built in session mobility or
continuity features such as MPTCP or QUIC.