[Gen-art] Genart last call review of draft-ietf-detnet-use-cases-18

Pete Resnick <resnick@episteme.net> Thu, 04 October 2018 18:02 UTC

Return-Path: <resnick@episteme.net>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0CF130E7E; Thu, 4 Oct 2018 11:02:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Pete Resnick <resnick@episteme.net>
To: <gen-art@ietf.org>
Cc: detnet@ietf.org, ietf@ietf.org, draft-ietf-detnet-use-cases.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.85.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153867614355.4541.14267222448061822810@ietfa.amsl.com>
Date: Thu, 04 Oct 2018 11:02:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vHl-bBETixLNmN3vrue_Dn1Gqv4>
Subject: [Gen-art] Genart last call review of draft-ietf-detnet-use-cases-18
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2018 18:02:24 -0000

Reviewer: Pete Resnick
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.

Document: draft-ietf-detnet-use-cases-18
Reviewer: Pete Resnick
Review Date: 2018-10-04
IETF LC End Date: 2018-10-03
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with Nits

This was a really cool document to read simply because of the breadth of the
industries involved. It clearly is going to need a good grammatical editing
pass by the RFC Editor, but none of the errors are the kind that make the text
hard to understand. All of my comments below are editorial in nature.

Major issues: None

Minor issues: None

Nits/editorial comments: For all of the below, the world does not end if you
don't fix them, but please consider:

----

Abstract: The first paragraph of intro seems like a better abstract. I don't
think the abstract needs as much detail as you've got in there.

----

The Intro says:

   For DetNet, use cases explicitly do not define requirements; The
   DetNet WG will consider the use cases, decide which elements are in
   scope for DetNet, and the results will be incorporated into future
   drafts.

Then why was 2.1.4 removed? It seems like it might be useful for historical
context.

----

In general, I don't like using "we" in consensus documents because it makes it
ambiguous whether the "we" is the "the author(s), "the detnet WG"", "the IETF",
or "this document". Additionally, using phrases like "we believe" or "we think"
are superfluous in most cases. Search for " we" and think about how to get rid
of such uses. A few examples:

2.2 I think you can simply just delete "we believe that". This document is
making a statement; no reason to hedge.

4.3 "In the future we expect". Changing to the passive voice solves the
problem: "It is expected that in the future"

5.3.2.1 "We would like to see DetNet define such a protocol". Detnet is the
author of this document, so "we" here seems really weird.

There are many other examples. Doing a search for " we " and seeing if you can
clean them up would be useful.

----

Throughout 3.1.1, 6.1.2, 7.3, 7.4: I presume "###us" is meant to be "###┬Ás". I
believe I-Ds are now allowed to have such characters.

----

In 3.3.2.3, there is no discussion about how this relates to NTP. I'm not sure
if that is necessary, but it seems odd for an IETF document.

----

I like that you have security considerations sprinkled throughout the document
instead of trying to combine them into one big section. However, some of the
sections are missing security considerations. For example, I think even I could
come up with some security considerations for the mining industry case. SECDIR
might have more to say, but I think it's worth adding these.

----

The FQDN idnit is because of Juergen Schmitt's email address, and it is fine.