Re: [Teas] [Last-Call] Intdir telechat review of draft-ietf-teas-ietf-network-slices-21

[Adrian Farrel <[e-mail]>]

Hey Dirk,

Many thanks for this careful review and apologies for the delay in replying
(I am currently away from home at a small networking conference).

Tl;dr  Nearly completely "Yes"

Individual response in line.

Cheers,
Adrian

> The following are other (minor) issues I found with this document that
SHOULD
> be corrected before publication:
>
> Since on p.3 scope is limited to network technologies described and
> standardized by the IETF, I would omit on p.4 mentioning 'optical' and
mayde
> replace by L3VPN or other IETF network technology.

We talked about this on a separate thread, and I am not going to omit
'optical'. But I will add some words to clarify that we are talking about an
IETF-specified data plane and/or management/control plane.

> The following are very minor issues (typos, misspelling, minor text
> improvements) with the document:
>
> p.3: (e.g. eMBB => (e.g., eMBB
> a customer to describe their => customers to describe their

Ack

> p.5: resources (e.g. =>resources (e.g.,
> of data, control and =>  of data, control, and
> level of control of, e.g., to customize => level of control to, e.g.,
customize
> [?] OR: level of control of means, e.g., to customize

Ack

> p.6: maybe a physical => may be a physical

Ack

> p.15: Maximum Permissible Packet Loss Rate:  The ratio => Maximum
Permissible
> Packet Loss Ratio:  The ratio

Nice! And found another of these.

> p.16:  (e.g. diversity, =>  (e.g., diversity,

Ack

> p.23: issues of abstraction in a TE network => issues of abstraction in a
> Traffic Engineering (TE) network

Ow, wow! Yes.

> This API communicates => This Interface can be seen as Application
Programming
> Interface (API) communicating

API is starred at https://www.rfc-editor.org/materials/abbrev.expansion.txt
and I suspect more than a few readers will be familiar with the term.

> p.25: provisioning, operating and => provisioning, operating, and

Ack

> p.34: underpin a IETF Network => underpin an IETF Network

Oops.

> p.35: instantiate such an IETF Network Service Slice. => instantiate such
an
> IETF Network Slice. [expression of 'IETF Network Service Slice' is not
defined
> nor used anywhere else in the document]

Yeah, could catch. "IETF Network Slice Service"

> p.37: IETF Network Slices Service => IETF Network Slice Services

Ack

> p.38: be mitigated by reduding the access => be mitigated by reducing the
> possibility of access [?]

I think this one stands.

> p.39: importance that the system use the privacy protection mechanism =>
> importance that the system uses the
> privacy protection mechanism

A grumpy Ack here.

> p.47: In many case, => In many cases,

Ack

> p.49: is no different to => is not different to OR: does not differ from

More grumpy conversion to common usage ;-)

> p.51: End-to- End Connectivity => End-to-End Connectivity

Ack

> p.52: with Inter- connected Networks => with Inter-connected Networks OR:
with
> Interconnected Networks [consistent use within the document]

Ack

> Also consistent use of US or UK English spelling - e.g. characterise vs.
> characterize should be achieved IMO.

Global change 
"enterprise" --> "enterprize" and "otherwise" --> "otherwize"
Back out global change, and do the work properly.