[RTG-DIR] Rtgdir last call review of draft-ietf-roll-useofrplinfo-25

Min Ye via Datatracker <noreply@ietf.org> Wed, 17 April 2019 07:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4F9120161; Wed, 17 Apr 2019 00:09:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Min Ye via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: roll@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Min Ye <amy.yemin@huawei.com>
Message-ID: <155548498336.29300.5806386149863350116@ietfa.amsl.com>
Date: Wed, 17 Apr 2019 00:09:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/KLqYgEqWlg04zKTz9xaQ3Tb_5l4>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-roll-useofrplinfo-25
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 07:09:44 -0000

Reviewer: Henning Rogge
Review result: Has Issues


I was asked by the IETF to do a Routing-Directorate review of
draft-ietf-roll-useofrplinfo. Please note that I do NOT follow
the ROLL WG.

Overall I think the draft tries too hard to condense information
into one document. It often uses non-intuitive abbreviations (e.g.
"RPL-aware-Leaf" as "RaF" or "target" as "tgt") and I just don't
know if this is the common way to do it in ROLL or just an unlucky

A lot of tables are literally overloaded with information to the
point where the document generator splits apart words, making the
table unreadable (see table 4,6,7,8,11,21 among others).

Other table entries are just not easy to interpret. Table 7
(as an example) has the options "no, "must" and "yes" for a column
which raises the question what is the difference between "must"
and "yes".

I am not sure what advice to give for the draft, if this (as the
abstract states) is the analysis for the basis of header compression
design I am worried that the design decisions will be hard to understand.

Henning Rogge