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

["[e-mail]" <[e-mail]>]

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 ¨C please let us know if you need additional clarification.
 
Best Regards,
Chen



Àî  ³¿  Li Chen
ÖйúµçÐÅÕ½ÂÔÓë´´ÐÂÑо¿Ôº Õ½ÂÔÓë¹æ»®Ñо¿Ëù ÍøÂç¹æ»®ÖÐÐÄ
µç»°£º010-50902891/18910853955
ÓÊÏ䣺[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 Bezahaf, Mehdi
Sent: Friday, May 15, 2020 1:05 AM
To: [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 ¨C 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
ÖйúµçÐÅÕ½ÂÔÓë´´ÐÂÑо¿Ôº Õ½ÂÔÓë¹æ»®Ñо¿Ëù ÍøÂç¹æ»®ÖÐÐÄ
µç»°£º010-50902891/18910853955
ÓÊÏ䣺[e-mail]/[e-mail]
ֻΪ³É¹¦ÕÒ·½·¨£¬²»ÎªÊ§°ÜÕÒ½è¿Ú
==============================
Chen  Li
Network Evolution and Planning Center
Network Technology & Planning Department
Email£º[e-mail] /[e-mail]
Tel: [phone]
Mobile: [phone]