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

Greg Mirsky <gregimirsky@gmail.com> Fri, 07 May 2021 19:55 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798A93A3049 for <teas@ietfa.amsl.com>; Fri, 7 May 2021 12:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JMwjM1lMyMY for <teas@ietfa.amsl.com>; Fri, 7 May 2021 12:55:30 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338903A3046 for <teas@ietf.org>; Fri, 7 May 2021 12:55:30 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id z9so14310867lfu.8 for <teas@ietf.org>; Fri, 07 May 2021 12:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4I6dzDQkBvj5QSnt+izJaeVIvuVxGXlKUfw1BjEx2CE=; b=Y3gRS6sp0QLG2YcML9pwZ6mfsOgOhNoTmAPAMn3uoKGV+KNH83sS47e1VffYNoyCo0 R2YS4cc3TRweYMxRzxDiK5sC75W+5k6NL/xd80JbjyC4ZIGREngUz3TpvneQMXkhC73u 8LtLWpcrXUsa1hNucqBlCiuxxHnQ10eZeXP9lSO9qsoM6hJFRiysRMkamiJllfp6zBm+ SX/j/szQFAeADQUK2NM6uA8fQRffIha1lrzC23xf7gdXI8EQZ3bcr0+HHnlu9cn4kUwC HBaFusQbB/hospovyajVcb9ttxNmrKMB1vVPfOk+fLIg6hyhnt1C0YyCgD/9z5E5Wwih 1z2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4I6dzDQkBvj5QSnt+izJaeVIvuVxGXlKUfw1BjEx2CE=; b=pCOhJHc0OxLuYO/3X8t7dMebfvp8c2y12z9mN9pq7ki4JuXzO0vssL8gHsXh0gGj+I YEwbg36awPEXMVXXEXLbVKUxFekmm9yaBWAe32X8WxGrRIpE29UceUI/6CV7QX24JKnY jGeq381AkkjidtZV2VBhTza4ZuXPLyTZqZmBp2naxzIqn+CUqmCFOrJWCscKtYSZdpVE Wtge1i7LuOrhmiB+osgF5WSr82j9zSqzBQKCzPw+NA/la22XqXGnwZxK7Lf2KqXM/suD VKzXWkOxtVgbi+bR57rUOi/y1QJvrCJfb+oSpRSU21/d//Bds2UYNAS3LV8pHhYPBPUk 3yWg==
X-Gm-Message-State: AOAM530MiQPQGl2Iw5DMfxZ4F8sVgNzJAi8vcAObc73Su6C6FeW2EuCD jVBtjA9Dj8rObFRyOzbgcwpYMmksdRuIG7MLxmM=
X-Google-Smtp-Source: ABdhPJwvjkSSMZ6bj+5d+7EzCqHWqj1KI0bN3cE43lEwvbrfxZB49BBBwECwes+JViQiKl6mV30uGtN5mAPcyjujUK4=
X-Received: by 2002:a19:df54:: with SMTP id q20mr7781425lfj.109.1620417326769; Fri, 07 May 2021 12:55:26 -0700 (PDT)
MIME-Version: 1.0
References: <037401d740c5$70a9cc30$51fd6490$@olddog.co.uk> <3ea262cf-e4c0-5ec0-9736-aedaf6d5d4d8@pi.nu> <009401d74195$41fd70a0$c5f851e0$@olddog.co.uk> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$@olddog.co.uk> <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu>
In-Reply-To: <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 7 May 2021 12:55:16 -0700
Message-ID: <CA+RyBmXoVT6z-tMEZdVoRVRzFp9gR5Ch2Ge_YQACJDUes6ja0w@mail.gmail.com>
To: Loa Andersson <loa@pi.nu>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Med Boucadair <mohamed.boucadair@orange.com>, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000266abb05c1c2cf2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/FMUoOMGDmMJ4pM668cfVTuiEX-g>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2021 19:55:35 -0000

Hi,
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. Perhaps the section can include two sub-sections -
Abbreviations/Acronyms and Terms/Terminology. I've noticed that there is
the forward reference in the section:
   The above terminology is defined in greater details in the remainder
   of this document.
It could be those other definitions of terms used in the specific context
in the document be collected in the new sub-section.

Regards,
Greg


On Thu, May 6, 2021 at 12:32 AM Loa Andersson <loa@pi.nu> wrote:

> Adrian,
>
> That is acceptable.
>
> As you said it is late in the document, and really not in a definitions
> section. I don't know if we can we place something in Section "2.  Terms
> and Abbreviations", but there seems to be only abbreviations.
>
> Your wholesale example:
>
> I think you forget about wholesale. What do you call the school that
> buys food at the shop to provide to the children? Do you call the school
> the customer, or do you refer to the cook who buys the food as the
> customer? The contract is with the school, negotiated by the cook,
> signed by the bursar.
>
> I think "the school! is the customer, which is OK in this context. The
> cook and the school kids could be viewed as consumers", one removed from
> the system.
>
> It strikes me that "Customer System" and "IETF Slice" are somewhat
> similar, the risk is that we talk about "customer" (even if we change
> it), and "slice" (even though if is really "IETF Slice)",
>
> Having said that, though it is not my task to call consensus, I think we
> have a enough support to use "customer".
>
> I rest my case.
>
> /Loa
>
>
> On 05/05/2021 13:05, Adrian Farrel wrote:
> > We currently have (in section 5.1, which may be a bit late in the
> document)
> >
> >     Customer:  A customer is the requester of an IETF Network Slice.
> >        Customers may request monitoring of SLOs.  A customer may manage
> >        the IETF Network Slice service directly by interfacing with the
> >        IETF NSC or indirectly through an orchestrator.
> >
> > We could add "A customer may be an entity such as an enterprise network
> or a
> > network operator, an individual working at such an entity, a private
> > individual contracting for a service, or an application or software
> > component."
> >
> > Cheers,
> > Adrian
> >
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > Sent: 05 May 2021 11:58
> > To: adrian@olddog.co.uk; 'Loa Andersson' <loa@pi.nu>nu>; teas@ietf.org
> > Subject: RE: [Teas] Moving forward with
> draft-ietf-teas-ietf-network-slices
> >
> > Hi all,
> >
> >> Anyone else got anything to say on the topic?
> >
> > I would simply use "customer" and make sure the definition is generic
> enough
> > to denote a role/entity.
> >
> > Thanks.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Teas [mailto:teas-bounces@ietf.org] De la part de Adrian Farrel
> >> Envoyé : mercredi 5 mai 2021 11:59
> >> À : 'Loa Andersson' <loa@pi.nu>nu>; teas@ietf.org
> >> Objet : Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-
> >> slices
> >>
> >> Hi Loa,
> >>
> >>> On customer vs. consumer Adrian says:
> >>>
> >>>>    c. "Consumer" vs "customer". I have made this consistent (we
> >> only need to
> >>>>         use one term). I selected "Customer" because that seemed
> >> best, but I
> >>>>         know some people prefer "consumer". Please discuss if you
> >> are not
> >>>>         happy.
> >>>
> >>> If the choice is between customer vs. consumer, I prefer customer.
> >>
> >> OK. So I made an improvement, but...
> >>
> >>> I don't know if it is too late to bring this up.
> >>
> >> It's never too late to bring things up.
> >>
> >>> But I really don't like either, normal language has a strong
> >>> indication that that that a customer is a person (a person that
> >> walks
> >>> inte to your
> >>> shop) and consumer is also a person /that eats what I bought at
> >> your shop).
> >>
> >> I think you forget about wholesale. What do you call the school that
> >> buys food at the shop to provide to the children? Do you call the
> >> school the customer, or do you refer to the cook who buys the food as
> >> the customer? The contract is with the school, negotiated by the
> >> cook, signed by the bursar.
> >>
> >>> IETF specifies "systems", including what goes into SW and HW, but
> >> we
> >>> don't specify normative rules for human behavior.
> >>>
> >>> I don't know if we can talk about Customer System?
> >>
> >> I'm afraid of this getting heavy for the reader. There are 73
> >> instances of "customer" in the document, and "customer system" may
> >> become tiresome to read.
> >>
> >> Anyone else got anything to say on the topic?
> >>
> >> Cheers,
> >> Adrian
> >>
> >> _______________________________________________
> >> Teas mailing list
> >> Teas@ietf.org
> >> https://www.ietf.org/mailman/listinfo/teas
> >
> >
> ____________________________________________________________________________
> > _____________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu
> > ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> > electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou
> > falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> > information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been
> > modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
>
> --
>
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>