Re: [Gen-art] Genart telechat review of draft-ietf-anima-autonomic-control-plane-16

Toerless Eckert <tte@cs.fau.de> Tue, 07 August 2018 23:26 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDE5130E87; Tue, 7 Aug 2018 16:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaaZuLNJS-bH; Tue, 7 Aug 2018 16:26:49 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1D212DD85; Tue, 7 Aug 2018 16:26:49 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DCC1758C507; Wed, 8 Aug 2018 01:26:44 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id CCC9C4E0C64; Wed, 8 Aug 2018 01:26:44 +0200 (CEST)
Date: Wed, 08 Aug 2018 01:26:44 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Elwyn Davies <elwynd@dial.pipex.com>
Cc: gen-art@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org
Message-ID: <20180807232644.5avcaxrnrt2phz3o@faui48e.informatik.uni-erlangen.de>
References: <153308194697.3384.1689302422182872423@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <153308194697.3384.1689302422182872423@ietfa.amsl.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ZL1XtJYcpdjLSVXYzviedz4Noms>
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-anima-autonomic-control-plane-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
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: Tue, 07 Aug 2018 23:26:52 -0000

Thanks a lot Elwyn


Changes for your review have been committed together with changes for Alissa's review
into just posted -17 rev of the doc. 

rfcdiff here: 

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-17.txt

I hope all the issues you raised ahve been resolved.

Point by point replies inline.

Cheers
    toerless

On Tue, Jul 31, 2018 at 05:05:47PM -0700, Elwyn Davies wrote:
> Reviewer: Elwyn Davies
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-anima-autonomic-control-plane-16
> Reviewer: Elwyn Davies
> Review Date: 2018-07-31
> IETF LC End Date: 2018-02-26
> IESG Telechat date: 2018-08-02
> 
> Summary:
> This document is ready but has a fair number of nits still to fix, particularly
> in the earlier part of the document.  There are also some language issues to
> address which the RFC Editor will deal with. My issues from the Last Call
> review have been addressed.
> 
> Major issues:
> None
> 
> Minor issues:
> None
> 
> Nits/editorial comments:
> General: There are three remaining examples of "intent" rather than "Intent".

ACK

> General: There are five instances of the construction -> "quoted text" () in
> s2. Need to remove -> and () in each case.  This may be down to tool problems -
> there is a comment in the revisions list.

DEFERRED, added instruction to text:

    <t>[RFC Editor: WG/IETF/IESG review of the terms below asked for references
       betwen these terms when they refer to each other. The only option in RFC/XML
       i found to point to a hanging text acronym definition that also displays
       the actual term is  the format="title" version, which leads to references
       like '->"ACP domain certificate" ()'. I found no reasonable way to eliminate
       the trailing '()' generated by this type of cross references. Can you
       please take care of removing these artefacts during editing (after conversion
       to nroff ?). Also created ticket to ask for xml2rfc enhancement to avoid this
       in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.</t>

> S1, para 5: s/The ACP is designed to remains/The ACP is designed to remain/

ACK

> s1, para 5: s/The details how this achieved are defined in Section 6./The
> details of how this achieved are described in Section 6./

ACK (also added "is" after "this".

> s1, bullet point #1: s/supports directly/directly supports/

ACK

> s1, bullet point #3: s/network/(Data-Plane) network/
> S1, last para: s/Defined Networking (SDN) (see [RFC7426]), style
> automation/Defined Networking- (SDN-)style (see [RFC7426]) automation/

ACK

> S1.1, para 2: Operational Technology is a term that is not very well-known - a
> reference would help.  Unfortunately it seems that the text of ISA99 that
> defines the term is not freely available. Suggestions of a freely available
> alternative?

Added xref to terminology section, added term to terminology section,
 used Wikipedia URL and first line description from it

  <t hangText="Operational Technology (OT):" anchor="ot">
    <xref target="https://en.wikipedia.org/wiki/Operational_Technology"/>:
    "The hardware and software dedicated to detecting or causing changes
    in physical processes through direct monitoring and/or control of physical
    devices such as valves, pumps, etc". OT networks are today in most cases
    well separated from Informationn Technology (IT) networks.
  </t>

> s1.1, para 3: Although RPL is in the glossary in s2, this instance occurs
> before s2 is announced, so it would be worth adding RPL (Routing Protocol for
> Low-power and Lossy Networks - RFC6550)

ACK

> s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP domain
> certificate".

See above. I specifically added "->" because thats whats typically done
in other terminologies when there is a reference to another term.

> S2, "ACP Domain":  'of nodes with ->"ACP domain' . Remove "->" and ()?

Likewise.

I have tried to find some better examples of cross-references between
words in a terminology section of an RFC, but couldn't find any.

Aka: lets RFC editor figure it out and/or Hendrik via tooling and trac case.

> s2. "ACP Loopback interface": Need to expand VRF on first use.

ACK

> s2, "ACP secure channel": As wrtten this equates a security association with a
> secure channel.  Suggest: NEW: ACP secure channel: A sequence of links
> established hop-by-hop between adjacent ACP nodes with a security association
> established for each link using the ACP secure channel protocol and the ACP
> Domain Certificate.  The channel is used to carry traffic of the ACP VRF
> separated from Data-Plane traffic in-band over the same links as the
> Data-Plane. ENDS

Ok, got the point that the channel is not just an association but the
actual data channel, but your suggestion was binding the term to a
sequence of links, which i think is wrong too.

Replaced now with:

<t hangText="ACP secure channel:">A cryptographically authenticated and encrypted data connection 
 established between (normally) adjacent ACP nodes to carry traffic of the ACP VRF secure and
 isolated from Data-Plane traffic in-band over the same link/path as the Data-Plane.
</t>

> s2, "Data-Plane": s/non-autonomic/by means other than autonomically/

ACK

> s2, "GRASP": s/required/REQUIRED/

I have refrained from considering the terminology section to be normative so
far because i don't think i have ever seen this being done in other RFCs,
so i am only using those uppercase words in the normative sections.

Let me know if you disagree.

> s2, "in-band (management)": fix up two instances of -> ... ().

see above.

> s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the reference to
> s6.10.5 hasn't been translated.

ACK

> s2, "(virtual) out-of-band network": fix up one instance of -> ... ();

see above

> s/where historically/were historically/; In next to last sentence s/out of
> band/out-of-band/

ACK

> s2, "ULA": s/are the first 48 bit/is the first 48 bits/

changed to "are the first 48 bits"

> s2, "(ACP) Zone": s/protocols details/protocol's details/

ACK

> s3.1: s/This way/In this way/; possibly s/other processes/single instamces of
> other processes/???

ACK

> s3.2, last para: s/like/such as/  [like: Yuck!]

ACK
*yikes* several of these sneaked into the text, tried to eliminate all of them..

> s3.3, para 1: s/managment/management/

ACK

> s3.3, first bullet: s/out of Band/out-of-Band/

Actually now using consistently out-of-band

> s4, ACP2: The phrase "(can block easily at edge)" needs additional explanation.

Changed to "infrastructure security (filtering based on known address space)".

> s4, ACP4: s/generic.  Usable/generic,  that is it MUST/

ACK.

> s4, last para: Need to expand eACP.

s/Th eACP/The ACP/ ;-)

> s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/

Text changed due to Alissas discuss.

> s5, lata para: s/This way/In this way/

ACK

> s6.1, para 4: Trailing colon s/b period.

ACK

> s6.1.1, last para on page 20: s/":" are not/The character ":" is not/

ACK

> s6.1.1, last but 2 para: s/information element it,/information
> element,/(probably)

ACK

> s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; s/peers
> domain/peer's domain/

ACK

> s6.1.3.1, last para: Expand ttl on first use.

ACK

> s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain
> certificate/; s/nodes ACP/node's ACP/

ACK

> s6.3, para 2: s/State Less/Stateless/

Actually StateLess as its used to expand SLAAC

> s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network with
> reasonably fast/

ACK

> s6.12: s/hop by hop/hop-by-hop/

ACK

> s8.2.1, bullets 2 and 3: s/vrf/VRF/

ACK


Many thanks again!