Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian Farrel <> Sun, 23 May 2021 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2402C3A1D1D for <>; Sun, 23 May 2021 08:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.051
X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=0.846, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OGHMefDrJd4j for <>; Sun, 23 May 2021 08:39:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D61BC3A1D19 for <>; Sun, 23 May 2021 08:39:16 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 14NFdCRA017279; Sun, 23 May 2021 16:39:12 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 97E0A4604A; Sun, 23 May 2021 16:39:12 +0100 (BST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 8263746043; Sun, 23 May 2021 16:39:12 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS; Sun, 23 May 2021 16:39:12 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 14NFdBmn019196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 23 May 2021 16:39:12 +0100
From: Adrian Farrel <>
To: 'Xufeng Liu' <>
Cc: 'TEAS WG' <>
References: <037401d740c5$70a9cc30$51fd6490$> <> <009401d74195$41fd70a0$c5f851e0$> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$> <> <> <> <> <>
In-Reply-To: <>
Date: Sun, 23 May 2021 16:39:11 +0100
Organization: Old Dog Consulting
Message-ID: <005501d74fe9$c77a1500$566e3f00$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01D74FF2.293F1940"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIxNfjF9qcx9VubDm1D4ubI8og6YwEz+LibAjUMGbABYFA3hgHvb8wpAemJjtIBZXPn4gI55yiCAf3KYIwAnIS6IqnGhrfg
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--17.699-10.0-31-10
X-imss-scan-details: No--17.699-10.0-31-10
X-TMASE-Result: 10--17.698500-10.000000
X-TMASE-MatchedRID: dL10VBB8yoeyoI+bK8UPQnFPUrVDm6jtC/ExpXrHizwhXy0Vy8CS1Ioq qJHJHX2WwkL7nAwIDMCA0c1O2233Kg3mZXbns8PV+ACG5oWJ7tLJbE9r9HBJT/z8/tFdCtAAhj5 3gjhYKkRwZgJThvxDHnBX//651JF2/Un+enHqUbVqZ6OipRp3eg5k1ea+clp65X8t/NkKVxkRYo RfqOC8+5n6uPXTHHYRkkqKCP21afZC/HHpIVNV9DiEPRj9j9rvz8/0zKksBYekXmvMFAHUOrwua nGfW+XuNtrqBJtuOX6I40w6RysGJoc7+Qb8+03pCLQsumV/5S+CFkqa43bHmwMuv289VbCIxUDT xL3vuSD4+veoc+y9mWZhpDhdH8fMLEu3XubSvQFitzfafzhYel3HHpZF/7mwxuio8Dr7zyQ/Sly sU74Qw1WeA27U+g5dIw6Kr6crgUxhTSvDZHacphz2MDiYujy5EsGpOXjV8vtMvtSjCgVE+vFBLq yzMQ6aziCmu04/U+hT0gFhwwXJ3VA37DzWkKjli+m1DDPm2yL/fHyH+MCF5dB/g+wgOV8M4J/B1 ev1TO27sLiGJ4XBUtAv/ud+Ea4aU6baA36eiawj80Za3RRg8G3Ui16l6RQ4z14cBq88EwghxK5f d9pWPPnG6jkqShMckisXOESdYT8=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 May 2021 15:39:20 -0000

Hi Xufeng,


>I agree with Loa, moving the definition of how the term "customer" is interpreted in the document to the Terms and Abbreviations section seems very reasonable.
I don't stick to "customer", but a discussion how about rephrasing "provider" with "producer" may also rise when I choose non-ietf-standard "consumer" term,

Related to this, should we rephrase " IETF Network Slice user" if there is any intention to leave?
5.2.  Expressing Connectivity Intents
The NSC northbound interface (NBI) can be used to communicate between IETF Network Slice users (or customers) and the NSC.
An IETF Network Slice user may be a network operator who, in turn, provides the IETF Network Slice to another IETF Network Slice user or customer.


> During the discussions on TE Topology Model, there was a similar discussion on

> such terminology. At that time, the pair "client/provider" was picked over 

> "consumer" and "customer". The term "client" has my vote here too.


I’m not sure we’re voting, but I have registered your preference.


If we get convincing reasons or an obvious consensus, we can change the words used. That, at least, will be an easy edit, and can be made at pretty much any time.