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

"JP Vasseur (jvasseur)" <> Fri, 05 July 2013 07:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A748421F93E5; Fri, 5 Jul 2013 00:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gk2jg4WHt++8; Fri, 5 Jul 2013 00:00:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 070DB11E811D; Fri, 5 Jul 2013 00:00:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3267; q=dns/txt; s=iport; t=1373007649; x=1374217249; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BjHlmlcoQPa+9bgTDrJ5sHNuOJMif+ibRjQmIx1eES4=; b=NSGwoPNyjcMPEz4Uhs1CwgA9lHYht8pMmRVv7qJAmTwf6o82HWycGx/N iyVYPg8r9Zlit7boPB3uIZ0+/c4tio2KLFUaD8a34BljimWr1572Qg2Pr flYJDzz5YaKz4uC8EpPcgCsEgZBo6nFzINCOdc3ax0QOMm4OT8LmguMCF A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAMFu1lGtJV2c/2dsb2JhbABagwl7wDB/FnSCIwEBAQMBbAYEAwULAgEIDhQkMiUCBA4NE4duBrhujzgCMQeDBGkDiGugI4MRgig
X-IronPort-AV: E=Sophos;i="4.87,1000,1363132800"; d="scan'208";a="231185426"
Received: from ([]) by with ESMTP; 05 Jul 2013 07:00:48 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r6570mnO005208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 07:00:48 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 02:00:47 -0500
From: "JP Vasseur (jvasseur)" <>
To: Carsten Bormann <>
Thread-Topic: AppsDir review of draft-ietf-roll-terminology-12.txt
Thread-Index: AQHOeU1foqMjtDnPakqZRKa7TCB+UA==
Date: Fri, 05 Jul 2013 07:00:47 +0000
Message-ID: <>
References: <> <028a01ce2d2f$79d220d0$6d766270$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 07 Jul 2013 00:26:41 -0700
Cc: "<>" <>, "<>" <>, IETF Apps Discuss <>, The IESG <>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jul 2013 07:00:54 -0000

Hi Carsten,

Thanks, I will add a sentence at the beginning ... "The intent of this document is to provide a high level definition of terms 
used in various documents produced by Working Groups specifying solutions for the Internet of Things." This way the 
document will stay in the spirit of the objectives of that draft in ROLL.

Does that address your concern ?



On Mar 30, 2013, at 2:33 PM, Carsten Bormann wrote:

> 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