Re: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.txt

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

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA8921F87F5; Sat, 30 Mar 2013 06:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.176
X-Spam-Level:
X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 5NLmOctl9GAP; Sat, 30 Mar 2013 06:33:32 -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 DCE1C21F855A; Sat, 30 Mar 2013 06:33:29 -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 r2UDXQSI028334; Sat, 30 Mar 2013 14:33:26 +0100 (CET)
Received: from [192.168.217.135] (p548925A4.dip.t-dialin.net [84.137.37.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74EFC3812; Sat, 30 Mar 2013 14:33:26 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk>
Date: Sat, 30 Mar 2013 14:33:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4EB0392-CA57-44BA-B382-30E1EBDA93AE@tzi.org>
References: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk>
To: adrian@olddog.co.uk
X-Mailer: Apple Mail (2.1503)
Cc: roll@ietf.org, draft-ietf-roll-terminology.all@tools.ietf.org, 'IETF Apps Discuss' <apps-discuss@ietf.org>, 'The IESG' <iesg@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2013 13:33:33 -0000

Hi Adrian,

thanks for trying to read my somewhat terse statements, and I apologize for making them as easy to misunderstand as I did.

I didn't pay attention to the discussion that led up to this document.
I was trying to read it from scratch as a document that somebody from a different area would use to gain access to the terminology used in the ROLL work.

With my critique, I was less interested in the stylistic issues but in the definitional intent.

I think we can all agree that terms like "flash memory" or "field device" are useful in the vocabulary of someone trying understand ROLL documents.
There is no need to "define" these terms, as they already work in their industry-standard usage.
So that would be the glossary aspect of the document: gathering information about these terms that is focused on the ROLL context.  E.g., highlighting the potential constrainedness of field devices makes this glossary entry more immediately useful than a Wikipedia entry (which strangely doesn't exist) would be.

Re the coverage:  I used U-LLN as an example of a potentially missing term because draft-tripathi-roll-reactive-applicability-00.txt uses it as if the reader were expected to know it.
Fortunately, its first use there is close to a reference to 5548, so the definition was easy to find.
But. more generally speaking, if the intent is to list terms that are *not* defined in the RFCs, that would also be a useful way of scoping.

I was expecting more definitional intent on the terms that have been invented or appropriated for and by ROLL.  
But maybe that is a misunderstanding on my part of what this document is about (the WG charter did not help me in identifying its objective, and the introduction reads like there is defining intent).


So, in summary, if the WG intends this to be a loose collection of a number of background terms with a glossary-like intent, there is indeed only a bit more editorial work remaining, starting with clarifying that objective.  Maybe the alphabetic arrangement should have alerted me that this might really be the objective.

But then, coming from an applications area point of view, I'm still looking forward to a future ROLL terminology document.  Is "MP2P" a traffic pattern while "P2MP" isn't?  What is the relationship between RFC 4461 "P2MP LSP"s and what is called "P2MP" in RFC 6550?  What is the relationship between RFC 1112's "multicast" and what is called "multicast" in draft-ietf-roll-trickle-mcast-04.txt, which just completed WGLC?  What is the relationship between RFC 1122's "host"s and RFC 6550's "host"s?  What *is* an LLN?

Grüße, Carsten