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

["Bezahaf, Mehdi" <[e-mail]>]

Dear Chen,

First of all, I want to thank the authors for their detailed reply to my comments (sorry if I sounded harsh, it is not my purpose) and support the adoption of the current draft.

Please find below more questions/remarks for the next round ☺

All the best,

Mehdi

•         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!

The manual errors (and downtime cause by them) & cost (OPEX)/time needed to configure new services / network as a result of complex imperative Network APIs is one of the core problems identified by Service Providers. Also, it will not be possible for humans to manually make decisions in the future networks and comprehend the impact of any manual changes on the existing users, applications and services.

I completely agree with you that misconfiguration by the human being is one of the core problems. It might be true that in the future, humans will not be able to manually configure the whole network. But the title of the section is ``current problems``, and I think the word ``problems`` is maybe too strong for how the section is written. Most of the App developers or network engineers currently interact with the network manually due to the lack of automation. This is why I think that a title like Intent`s benefits or possible improvements fit better this section`s text.


•         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!

This is the core picture that we added to explain the methodology for intent classification, based on previous draft comments. We can try in the next version to improve the description and the appearance of the diagram, but we believe the problem is in the txt version. We previously shared a ppt document with the picture, we will send the latest ppt slides to you as well.

I think it will be a good idea to describe (in the text) the steps of the classification process and define if there is an order in the actions.

I am sorry to ask this question but are we talking about classifying an existing intent (it is already implemented) or an intent that we want to implement, so we look to its classification to have a better idea of how to implement it?

The Intent classification methodology takes as an input the solution knowledge, which is described as the knowledge about solution requirements, targeted use cases, available technologies and networks, actors, and the intent requirements. I think the solution knowledge needs to be better introduced and how do we obtain it. It is even confusing to have as an input, for example, the actors (described in Section 4.2 as the intent user type) and later on in your classification process identify intent user types (R2-U2)!! Definitively, section 5.1 needs clarification.

Solution requirements, lifecycle requirements and intent requirements are not clearly defined. Intent requirements and solution requirements are used as an input to the classification methodology but how can they be expressed/obtained..

Tables in 5.3.2, 5.4.2, 5.5.2 need to be filled right?


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


From: [e-mail] <[e-mail]>
Sent: Wednesday, May 27, 2020 2:48 AM
To: Bezahaf, Mehdi <[e-mail]>; nmrg <[e-mail]>
Cc: draft-li-nmrg-intent-classification <[e-mail]>
Subject: [External] RE:[nmrg] [NMRG] review of draft-li-nmrg-intent-classification-03.txt


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

Thank you very much for your comments. 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]<mailto:[e-mail]/[e-mail]>
只为成功找方法，不为失败找借口
==============================
Chen  Li
Network Evolution and Planning Center
Network Technology & Planning Department
Email：[e-mail]<mailto:[e-mail]> /[e-mail]<mailto:/[e-mail]>
Tel: [phone]
Mobile: [phone]

From: nmrg [mailto:[e-mail]] On Behalf Of Bezahaf, Mehdi
Sent: Friday, May 15, 2020 1:05 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [nmrg] [NMRG] review of draft-li-nmrg-intent-classification-03.txt

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

Added to the list of updates for the next version. We will update it in all places to lifecycle.

•         Add NBI, API, VNF, PNF, AI and GBP to the acronym section

Added to the list of updates for the next version. We will add NBI, API, VNF, PNF, AI, GBP and any other missing acronym 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.

Added to the list of updates for the next version. We will link the sentence to the one just before.

•         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

Added to the list of updates for the next version. We were referring here to what solutions does the Intent Engine support – Carrier Network Solutions, DC Network Solutions, Enterprise Network Solution.
They could be further split and new solutions could be added, through the methodology presented in section 5.1 that can be used for extensions. We will reiterate in the next section that these are the example solutions, and that methodology could be used to extend. It is mentioned later, but may be mentioned here as well for clarity purposes.

•         Does the table cover all the possibilities or just some examples (if it is the case, it needs to be clear in the text)?

Added to the list of updates for the next version. The table covers the starting point for the intent classification. The methodology section 5.1 describes how we can extend for future scenarios. We will update with clarification.

•         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
Could you please refer to what part in Section 3.2 you do not agree with? We do say that we would have different intent types and different use cases for each user. The user requirements and use cases would be the starting point to define what intent types are needed. I am not sure that use case would solely determine intent.
We believe your statement is covered in table 5.3.1, for example. In that table, the scenario is carrier network, and a user can be Customer, and indeed we have different intent types.

•         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!
Are there not potentially multiple use cases that can refer to the same intent? For example, the use case 1 can be activating network intent on the network, and use case 2 can be accessing the report for the network intent. Some would consider the action as being intent (activate, view), while others would consider an entity to be intent (network service?). Therefore , we have different categories there that corresponds to both. So, in your case, you will identify only those intent types you consider part of your scope.

•         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!

The manual errors (and downtime cause by them) & cost (OPEX)/time needed to configure new services / network as a result of complex imperative Network APIs is one of the core problems identified by Service Providers. Also, it will not be possible for humans to manually make decisions in the future networks and comprehend the impact of any manual changes on the existing users, applications and services.

•         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!

This is the core picture that we added to explain the methodology for intent classification, based on previous draft comments. We can try in the next version to improve the description and the appearance of the diagram, but we believe the problem is in the txt version. We previously shared a ppt document with the picture, we will send the latest ppt slides to you as well.

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


 Added to the list of updates for the next version. We are talking about user types and not users.
In 4.2 we do mention that network operators are a type of management personnel.
We will update to make this explicit and consistent everywhere , by updating or moving 4.2 to 3.2.

•         Section 5.3.1
•         In the first table, the authors duplicated some entries twice (probably by mistake).

Added to the list of updates for the next version. Thanks for the comments, it seems that the last version of formatting somehow ended up with duplicated rows.

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

Added to the list of updates for the next version. Thanks for this, we would add strategy intent into the intent types in section 3.4 as well.

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

Added to the list of updates for the next version. Our main meaning  in section 6 is : AI could be an aid to the intent classification method, through a large number of interactions between the user(humen) and the system(the first loop), extract the key feature values of the intent to help the intent classification . In the next update, we will focus on improving this description.





Best Regards,
Mehdi


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

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