[Teas] Intdir telechat review of draft-ietf-teas-ietf-network-slices-21

[Dirk Von Hugo via Datatracker <[e-mail]>]

Reviewer: Dirk Von Hugo
Review result: Ready with Nits

Hello,
I am an assigned INT directorate reviewer for
draft-ietf-teas-ietf-network-slices. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/> Based on my review, if I was
on the IESG I would ballot this document as NO OBJECTION.

I find the document helpful in defining and discussion terms related to IETF
network slicing and tend to agree with the genart review by Reese at
https://datatracker.ietf.org/doc/review-ietf-teas-ietf-network-slices-21-genart-lc-enghardt-2023-07-11/
to not repeat those comments here.

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.

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

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

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

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

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

p.23: issues of abstraction in a TE network => issues of abstraction in a
Traffic Engineering (TE) network
 This API communicates => This Interface can be seen as Application Programming
 Interface (API) communicating

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

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

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]

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

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

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

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

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

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

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

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

Thanks to all editors, authors, and contributorsto this document!

Best regards
Dirk