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