[Gen-art] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

Brian Carpenter <brian.e.carpenter@gmail.com> Mon, 19 February 2018 23:22 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF106126CC4; Mon, 19 Feb 2018 15:22:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Carpenter <brian.e.carpenter@gmail.com>
To: gen-art@ietf.org
Cc: draft-ietf-6tisch-6top-protocol.all@ietf.org, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151908254474.29750.15541242231013194366@ietfa.amsl.com>
Date: Mon, 19 Feb 2018 15:22:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/nSvCz-YID5pI1RzOuOde_fDCbcQ>
Subject: [Gen-art] Genart telechat review of draft-ietf-6tisch-6top-protocol-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 19 Feb 2018 23:22:25 -0000

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-09

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-6tisch-6top-protocol-09.txt
Reviewer: Brian Carpenter
Review Date: 2018-02-20
IETF LC End Date: 2018-??-??
IESG Telechat date: 2018-03-06

Summary: Ready with issues
--------

Comment:
--------

This is a Last Call review despite the subject field. When will the Last
Call be started?

Major issues:
-------------

In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition
if A's timeout expires while B's Response is in flight. Can the 6top layer
prevent the L2 Ack being sent? (And similar race conditions seem to be
possible in the 3-step transaction.)

> 3.4.3.  Concurrent 6P Transactions
>
>  Only a single 6P Transaction between two neighbors, in a given
>  direction, can take place at the same time.  That is, a node MUST NOT
>  issue a new 6P Request to a given neighbor before having received the
>  6P Response for a previous request to that neighbor, except when the
>  previous 6P Transaction has timed out.  If a node receives a 6P
>  Request from a given neighbor before having sent the 6P Response to
>  the previous 6P Request from that neighbor, it MUST send back a 6P
>  Response with a return code of RC_RESET (as per Figure 36).  A node
>  receiving RC_RESET code MUST abort the transaction and consider it
>  never happened.

It isn't clear to me whether the RC_RESET aborts the first, the second,
or both transactions.

Minor issues:
-------------

> 1.  Introduction
...
>  6P
>  allows a node to communicate with a neighbor to add/delete TSCH cells
>  to one another.

This sentence is almost unintelligible because of the sequence to...to...to.
Does it mean this?:

  6P allows neighbours to add or delete TSCH cells in each other.


> 3.4.1.  Version Checking

This may be a pointless worry, but is there a DOS attack of some kind
by sending rubbish version numbers?