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

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

Thanks for addressing the comments.

/y



From: <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Wednesday, 27 May 2020 at 02:51
To: Yehia Elkhatib <[e-mail]>, nmrg <[e-mail]>
Cc: draft-li-nmrg-intent-classification <[e-mail]>
Subject: Re: FW: [nmrg] [External] [NMRG] review of draft-li-nmrg-intent-classification-03.txt

Dear Yehia,

Thank you very much for your comments. Thanks for your opinion that this version of the draft is much better and brings more clarity. Please see the replies below. We propose to address in the next version of the document those comments with reply “Added to the list of updates for the next version”. For others, we added some clarification – please let us know if you need additional clarification.

Best Regards,
Chen

________________________________
李  晨  Li Chen
中国电信战略与创新研究院 战略与规划研究所 网络规划中心
电话：[phone]
邮箱：[e-mail]/[e-mail]
只为成功找方法，不为失败找借口
==============================
Chen  Li
Network Evolution and Planning Center
Network Technology & Planning Department
Email：[e-mail] /[e-mail]
Tel: [phone]
Mobile: [phone]

From: nmrg [mailto:[e-mail]] On Behalf Of El Khatib, Yehia (elkhatib)
Sent: Friday 15 May 2020 13:43
To: [e-mail]
Subject: Re: [nmrg] [External] [NMRG] review of draft-li-nmrg-intent-classification-03.txt

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.

Added to the list of updates for the next version –
Thank you for your suggestion on improving the wording. We will update in the next version to further clarify that for the wider audience intents are sometimes confused with policies.

- 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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyelkhatib.github.io%2Fpapers%2Felkhatib2017idn.pdf&data=02%7C01%7Cy.elkhatib%40lancaster.ac.uk%7Cb7dcbe0813b145735fd708d801e087b4%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637261411162193391&sdata=f9%2BTetWnPIexyrbaMHNWP885vo7%2F%2B%2BudgTAvfKfhsRw%3D&reserved=0>

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.

Added to the list of updates for the next version –
The examples presented in tables 5.3.1, 5.4.1 and 5.5.1 have been added based on the previous draft comments received. The purpose of these intents is to provide actual examples of intent from the perspective of a user for different solutions, intent user types, and intent types. We agreed that the Use Cases, Intent Formal Definition (DSL) the operational aspects (such as how these intents are decomposed) behind these intents are outside of the scope of this draft and would be addressed by other drafts (Use Cases, Intent DSL, Intent Architecture). But your suggestion to add some expansions is welcome and we will add some clarification in the next draft version.
Thanks for sharing the link, it is excellent reference and should be used when the RG start working on use cases and formal definition and architecture.

- 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.

Added to the list of updates for the next version -
We agreed that addressing in detail intent conflict resolution is outside the scope of this draft.
We will update this sentence in the next version of the draft, to explain that a new intent issued by an intent user, can be in conflict with the already existing intents, and that once the system identifies such a conflict, an option is to report back to the user to refine its intent.

- I assume that the intent scopes in §4.3 are expandable and are context-specific?
Yes, the intent scopes are expendable through the methodology presented in section 5.1.


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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyelkhatib.github.io%2F&data=02%7C01%7Cy.elkhatib%40lancaster.ac.uk%7Cb7dcbe0813b145735fd708d801e087b4%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637261411162203383&sdata=QWiHXl4Ds1%2BLo7Y24jUkLgJw0l%2Fd4WSWKMtwoARBt90%3D&reserved=0>


From: nmrg <[e-mail]<mailto:[e-mail]>> on behalf of "Bezahaf, Mehdi" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 14 May 2020 at 9:46 pm
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]