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

["Adrian Farrel" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Carsten Bormann
> Sent: 30 March 2013 05:33
> To: IETF Apps Discuss; [e-mail]
> Cc: [e-mail] WG; The IESG
> Subject: AppsDir review of draft-ietf-roll-terminology-12.txt
> 
> 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