[tsvwg] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12

Stefan Winter <stefan.winter@restena.lu> Wed, 16 August 2017 09:24 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F22132025; Wed, 16 Aug 2017 02:24:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stefan Winter <stefan.winter@restena.lu>
To: ops-dir@ietf.org
Cc: tsvwg@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-sctp-ndata.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150287547583.12471.9085655210334710687@ietfa.amsl.com>
Date: Wed, 16 Aug 2017 02:24:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Dyp8ha6KBZr-0p7zhlWnFeByBHc>
Subject: [tsvwg] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 09:24:36 -0000

Reviewer: Stefan Winter
Review result: Has Issues

One issue:

The chapter IANA considerations mentions four bits to be registered: E,B,U,I.
In the main body, only three of those are actually defined and used (End of
fragmented message, Beginning of fragmented message, Unordered/Ordered
message). Please add a definition of the I bit or remove the IANA registration
request for that bit.

And the rest are only musings not needing any action if the authors don't want
to action on them:

The introduction presents a good use case, quoting: "e.g., when the
transmission of an urgent
   message is blocked from transmission because the sender has started
   the transmission of another, possibly large, message".

The later queueing example in figure 1 has three SIDs being queued
simultanseously. It is not clear which of those "has already started" and which
are the important ones being delayed. For a better understanding of the reader,
it might be useful to revise the figure so that the head-of-line blocking
happens for SID 1 because transmission of  0 and 2 has already started (and
declare SID 1 to be the "important" message). The ASCII art would just have to
indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting
serialisation would then put all the SID 1 messages at the very end, when 0 and
2 have been completely submitted (right?).

In 2.2.3, is there any particular reason why the "protocol violation" error
cause is only a MAY? As it enables debugging on the remote end, a SHOULD seems
useful.