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

[Gyan Mishra <[e-mail]>]

I agree with Loa and am not crazy about either customer or consumer as
either refers to a “human” endpoint and not a system endpoint made of
hardware or software like the term “CE”.

+1 for Customer over Consumer as a customer is human endpoint that has paid
for service SLA where  a consumer is  broader term like subscriber
describing for example all broadband subscriber community.

On Fri, May 7, 2021 at 3:55 PM Greg Mirsky <[e-mail]> wrote:

> 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 <[e-mail]> 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: [e-mail] <[e-mail]>
>> > Sent: 05 May 2021 11:58
>> > To: [e-mail]; 'Loa Andersson' <[e-mail]>; [e-mail]
>> > 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:[e-mail]] De la part de Adrian Farrel
>> >> Envoyé : mercredi 5 mai 2021 11:59
>> >> À : 'Loa Andersson' <[e-mail]>; [e-mail]
>> >> 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
>> >> [e-mail]
>> >> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/teas
>> >
>>
>> --
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Bronze Dragon Consulting             phone: [phone]
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*