[Roll] AppsDir review of draft-ietf-roll-terminology-12.txt

Carsten Bormann <cabo@tzi.org> Sat, 30 March 2013 05:32 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F0A21F8EF1; Fri, 29 Mar 2013 22:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.173
X-Spam-Level:
X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omVRNof6Mt+Z; Fri, 29 Mar 2013 22:32:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFBE21F8D84; Fri, 29 Mar 2013 22:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2U5WgjT012855; Sat, 30 Mar 2013 06:32:42 +0100 (CET)
Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3482378B; Sat, 30 Mar 2013 06:32:41 +0100 (CET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Carsten Bormann <cabo@tzi.org>
Date: Sat, 30 Mar 2013 06:32:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org>
To: IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-roll-terminology.all@tools.ietf.org
X-Mailer: Apple Mail (2.1503)
Cc: "roll@ietf.org WG" <roll@ietf.org>, The IESG <iesg@ietf.org>
Subject: [Roll] AppsDir review of draft-ietf-roll-terminology-12.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2013 05:32:50 -0000

I have been selected as the Applications Area Directorate (appsdir)
reviewer for this draft.  (For background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document
shepherd or AD before posting a new version of the draft.


Document: draft-ietf-roll-terminology-12.txt
Title: Terminology in Low power And Lossy Networks
Reviewer: Carsten Bormann
Review Date: March 30, 2013
IETF Last Call Date: March 16, 2013
IESG Telechat Date: not known


Summary: This document is NOT ready for publication.

After reading this draft, only one conclusion is possible:
Neither the author not the working group care about this document.

The document mixes up a glossary function (is it really intended to
define new ROLL terminology for "Flash Memory"?  "RAM"?  "ROM"?
"HVAC"?  "ISA"?  "HART"?) with much-needed actual definition of
specific terminology for the domain of the working group.

Where the latter is intended, there is often failure:

           MP2P: Multipoint-to-Point is used to describe a particular traffic
           pattern (e.g.  MP2P flows collecting information from many nodes
           flowing upstream towards a collecting sink or an LBR).

All we learn is that it is "used to describe" a traffic pattern and an
example for one.  Now what is the definition of the term?  Is it the
upstreamness that is characteristic of MP2P or is it the many-to-one
relation?  But maybe it isn't really to *one*?  This is the kind of
question that this document must answer, and it almost completely
fails.

For the glossary function, shouldn't be some coverage of the ROLL
documents?  E.g., RFC 5548 revolves around the term U-LLN.  Why isn't
that presumably useful term copied into the glossary part of this
document?  What about the other terms defined in RFCs 5548, 5673,
5826, 5867, 6206, 6550, 6551, 6552, 6719?

There is a quite useful start in this document, but it requires a
major cleanup and a lot more detail work before it becomes
publishable.

As a first step, the document needs structure, with a separation
between the glossary function and the defining intent.  For the
latter, some minimum amount of rigorous thinking needs to be applied.
Where terms are by definition wishy-washy, that is also fine, but
should be explicit.

I'd be happy to review a reworked document in more detail.

Grüße, Carsten