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

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 Mar 2013 06:32:40 +0100

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 30 Mar 2013 10:15:16 -0000

Hi all,

I think I see three things in Carsten's review.

1. Separation of glossary from new terms

I can see why this might be valuable, but I am not sure it is critical rather
than stylistic. That is, there are two types of term used in the ROLL work:
- terms that have a meaning specific to ROLL (terminology)
- terms that have a meaning in ROLL that is identical to their common meaning
(glossary)
In both cases, the words have a meaning in ROLL that needs to be documented.

2. Use of "more definitive" language for the explanation of new terms

I believe this may be a linguistic issue (or even cultural :-).
I, of course, reviewed the document and had no issue with "X is used to
describe..." To me, that is equivalent to "In the context of ROLL, X is...", or
the more simple "X is..." It is, perhaps, more chatty language than some would
use, but I think the meaning is clear: when you see "X" in a ROLL document you
know it means the totality of the paragraph.

Now, in the case that Carsten quotes for MP2P, I don't think the issue should be
with "used to describe" but with a transposition of "e.g." for "i.e.". Thus,
this is a specific problem with one paragraph, rather than with the general
text. And the author can sort this out.

3. Further trawling of related documents for terms that should be included

Thanks to Carsten for suggesting U-LLN as a term for inclusion. AFAICS, RFC 5548
is the only document using this term, and presents it as a documentation
abbreviation within the RFC rather than a generic term. So I don't think it
needs to be included.

As for "What about the other terms defined in RFCs 5548, 5673, 5826, 5867, 6206,
6550, 6551, 6552, 6719?" I think we can assume that the author checked those
documents and made a decision about which terms should be included and which
excluded. Also that the WG is well aware of the existence of those documents. So
rather than an open-ended "Please do more work" it would be helpful to identify
which terms are believed to be missing and in need of inclusion.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Carsten Bormann
> Sent: 30 March 2013 05:33
> To: IETF Apps Discuss; [email-masked]
> Cc: [email-masked] WG; The IESG
> Subject: AppsDir review of draft-ietf-roll-terminology-12.txt
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 Mar 2013 14:33:25 +0100

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