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

2018-08-07 Thread Toerless Eckert
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=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
> 
> .
> 
> 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:

[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.

> 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

  
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.
  

> 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 

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

2018-08-01 Thread Alissa Cooper
Elwyn, thanks for your reviews. Authors/editors, thanks for addressing Elwyn’s 
previous comments. I have pointed to his latest round in my ballot. I balloted 
DISCUSS based on one point in Section 6.10.4.

Alissa

> On Jul 31, 2018, at 8:05 PM, 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
> 
> .
> 
> 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".
> 
> 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.
> 
> S1, para 5: s/The ACP is designed to remains/The ACP is designed to remain/
> 
> 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./
> 
> s1, bullet point #1: s/supports directly/directly supports/
> 
> 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/
> 
> 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?
> 
> 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)
> 
> s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP domain
> certificate".
> 
> S2, "ACP Domain":  'of nodes with ->"ACP domain' . Remove "->" and ()?
> 
> s2. "ACP Loopback interface": Need to expand VRF on first use.
> 
> 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
> 
> s2, "Data-Plane": s/non-autonomic/by means other than autonomically/
> 
> s2, "GRASP": s/required/REQUIRED/
> 
> s2, "in-band (management)": fix up two instances of -> ... ().
> 
> s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the reference to
> s6.10.5 hasn't been translated.
> 
> s2, "(virtual) out-of-band network": fix up one instance of -> ... (); s/where
> historically/were historically/; In next to last sentence s/out of
> band/out-of-band/
> 
> s2, "ULA": s/are the first 48 bit/is the first 48 bits/
> 
> s2, "(ACP) Zone": s/protocols details/protocol's details/
> 
> s3.1: s/This way/In this way/; possibly s/other processes/single instamces of
> other processes/???
> 
> s3.2, last para: s/like/such as/  [like: Yuck!]
> 
> s3.3, para 1: s/managment/management/
> 
> s3.3, first bullet: s/out of Band/out-of-Band/
> 
> s4, ACP2: The phrase "(can block easily at edge)" needs additional 
> explanation.
> 
> s4, ACP4: s/generic.  Usable/generic,  that is it MUST/
> 
> s4, last para: Need to expand eACP.
> 
> s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/
> 
> s5, lata para: s/This way/In this way/
> 
> s6.1, para 4: Trailing colon s/b period.
> 
> s6.1.1, last para on page 20: s/":" are not/The character ":" is not/
> 
> s6.1.1, last but 2 para: s/information element it,/information
> element,/(probably)
> 
> s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; s/peers
> domain/peer's domain/
> 
> s6.1.3.1, last para: Expand ttl on first use.
> 
> s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain
> certificate/; s/nodes ACP/node's ACP/
> 
> s6.3, para 2: s/State Less/Stateless/
> 
> s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network with
> reasonably fast/
> 
> s6.12: s/hop by hop/hop-by-hop/

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

2018-07-31 Thread Elwyn Davies
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

.

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".

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.

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

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./

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

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/

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?

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)

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

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

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

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

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

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

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

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

s2, "(virtual) out-of-band network": fix up one instance of -> ... (); s/where
historically/were historically/; In next to last sentence s/out of
band/out-of-band/

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

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

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

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

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

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

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

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

s4, last para: Need to expand eACP.

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

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

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

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

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

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

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

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

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

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

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

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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art