Re: [nmrg] [External] [NMRG] review of draft-li-nmrg-intent-classification-03.txt

["El Khatib, Yehia (elkhatib)" <[e-mail]>]

Hi all,

This version of the draft is better than the last. I think it brings more clarity about the different ways intents could be used, which also helps to define who the users of intents are. Some suggestions:

- Like Mehdi mentioned, the bit in §3.1 about “Intent is very often just a synonym for policy” comes off as being confirmative of that stance, although the draft argues otherwise. And the rest of the paragraph repeats the same 2 points again. Perhaps just better wording here would help. Suggested alternative:

   An intent is mistaken by many to be just a synonym for policy.
   While it is easier for those familiar with different standards to
   understand what service, CFS, RFS, resource, policy continuum, ECA
   policy, declarative policy, abstract policy or intent policy is, it
   may be more difficult for the wider audience. Furthermore, those
   familiar with policies understand the difference between a business,
   intent, declarative, imperative and ECA policy.

- There is a number of examples spread throughout the draft, but none of them go into any detail so would leave some readers a little lost. I think the draft would benefit from having at least one case study explained in a little more detail. I’ve used some examples in my papers, e.g. : section III in
https://yelkhatib.github.io/papers/elkhatib2017idn.pdf

An alternative would be to just expand a little more whenever each of these examples is thrown in, such as “Request high priority queueing for traffic of class A”. The expansion would be a couple of sentences on how this would be manifested in an operational sense without being tech-specific.

- The draft mentioned that an intent-driven network (IDN) “should be able to detect and resolve intent conflicts”, but not how or whose responsibility this would be. This is probably beyond the scope of this draft, but it’s not ideal to leave that requirement there and never comment on its feasibility or responsibility. Even a brief comment would be better than nothing at all.

- I assume that the intent scopes in §4.3 are expandable and are context-specific?


Best,
Yehia


--
Dr. Yehia Elkhatib
Distributed Systems Group Lead  &  Director of PhD Admissions
School of Computing & Communications
Lancaster University, LA1 4WA, UK
y.elkhatib /then add/ lancaster.ac.uk
https://yelkhatib.github.io


From: nmrg <[e-mail]> on behalf of "Bezahaf, Mehdi" <[e-mail]>
Date: Thursday, 14 May 2020 at 9:46 pm
To: "[e-mail]" <[e-mail]>
Subject: [External] [nmrg] [NMRG] review of draft-li-nmrg-intent-classification-03.txt


This email originated outside the University. Check before clicking links or attachments.
Dear all,

I hope this email finds you all safe and sound. Please find below my review of the last version of Draft-li-nmrg-intent-classification-03.txt.


     *   Lifecycle or life-cycle, keep it consistent
     *   Add NBI, API, VNF, PNF, AI and GBP to the acronym section
     *   In section 3.1

        *   The authors mentioned that "Intent is very often just a synonym for policy". I am sure that the authors meant that for the wider audience confusing intent and policy. Probably need to link this sentence with the one just before it.

     *   Section 3.2

        *   It is a bit confusing because the authors are talking about intent solutions and they present as an example carrier networks, DC networks, and Enterprise networks, which for me are more as situations, scenarios or contexts than a solution
        *   Does the table cover all the possibilities or just some examples (if it is the case, it needs to be clear in the text)?
        *   I don't agree. I guess if we pick the scenario (carrier networks for example) and a user (network operator), you will probably have different intent types depending on the use-case. What I mean is that just the user and the context does not describe or define the intent type
        *   Section 3.1 and 3.2 are related. If you can pick the actor, the context, and the use case, you can have a clear definition of your intent!

     *   Section 3.3

        *   The title of this section is "current problems and requirements".. I wouldn't say 'problems' as it is defined in this section but more as possible improvement or intent benefits! I guess there are still some technical people that they want/need to use APIs/CLI to fix/access/interact with the system on specific issues!


     *   Section 5.1

        *   The figure in this section is a bit confusing! Does the classification process follow this order (R1-U1, R2-U2,…..)? I think this picture can be deleted!

     *   Section 5.2

        *   In section 4.2, three different intent user types were defined (customers, App dev, and Management). However, in section 5.2, the authors mentioned other intent user types such as Network or service operator, Enterprise administrator, cloud administrator, underlay network administrator. There is a difference between intent user and intent user type..

     *   Section 5.3.1

        *   In the first table, the authors duplicated some entries twice (probably by mistake).
        *   In section 3.4, the authors define a list of intent types that should be supported but in section 5.3.1, 5.4.1, and 5.5.1 new intent types are defined such as "strategy intent".

     *   Section 6

        *   I don't see the point of having this section (at least as it is) in this document. What I mean, is that I cannot see how AI will impact the classification!
        *   I don't agree with the authors when they support that intent determined by AI-based will have a format closer to machine language structures than natural language structures to avoid misconception. One way to do it is to have multiple exchanges between the user (human) and the system (the first loop) to be sure about the user request and that the AI-based agent gets the user's intention.


Best Regards,
Mehdi


Mehdi Bezahaf, PhD
Senior Research Associate
D31, InfoLab21
School of Computing & Communications
Lancaster University
[phone]