Re: [nmrg] Will's review for draft-clemm-nmrg-dist-intent-02, 1st part

["Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hi Will,

Thank you for the review of the draft.
As RG co-chair, I would encourage we have more reviews and comments – on the mailing list! – to move our work forward.

We had the chance to discuss on site at IETF 105 and I think most of the point you raise are now clarified. However a written answer is needed. I will provide my answer to your point in a separate email.

More generally, the draft is... well a draft and so some parts are still work in progress and not all parts are fitting well together (yet). We (authors) have plans to revise and complement our work in future versions and we will incorporate your comments.

Best regards, Laurent.

From: Liushucheng (Will Liu) <[e-mail]>
Sent: Saturday, July 20, 2019 03:59
To: [e-mail]
Cc: [e-mail]
Subject: Will's review for draft-clemm-nmrg-dist-intent-02, 1st part

Hi,

I took some time to read and learn -02 version, which updated a lot of content from -01. I have below comments and questions:

Section 4.2.3
>   Summarized differences:
…
>   o  Policy is a set of rules, typically modeled around a variation of
>      events/conditions/actions, used to express simple control loops
>      that can be rendered by devices themselves, without requiring
…
>   o  Intent is a higher-level declarative policy that operates at the
>      level of a network and services it provides, not individual
>      devices.  It is used to define outcomes and high-level operational


IMOH, these “summarized differences” may be still not clear enough as if we simplify these two sentences and put together, “policy is xxx rules, intent is xxx policy”. In SUPA we defined two types of policy, imperative policy(ECA) and declarative policy (Intent policy).

In this doc, if intent policy is one kind of policy, you may need to change the definition of policy. In addition, service may also be expressed in an “intent” way, like “service intent” at the end of this draft. If intent is going to be defined as a kind of policy, then shall we put “service intent” as a subset of policy?


>   One analogy to capture the difference between policy and intent
>   systems is that of Expert Systems and Learning Systems in the field
>   of Artificial Intelligence...

From the description I know authors wanted to use analogy to describe the relationship, however, may lead to even more confusing if we compare policy - expert system vs intent - learning system.


Section 5
>       Single Source of Truth (SSoT) and Single Version/View of Truth
>       (SVoT).

The paragraph of SSoT and SVoT was new, however, is this necessary principle as there was no related info in the two figures in section 6 and other parts of the doc.

>   2.  One touch but not one shot.  In an ideal intent-based system, the
>       user expresses its intents in one form or another and then the
>       system takes over all subsequent operations (one touch).  A zero-
>       touch approach could also be imagined in case where the intent-
>       based system has the capabilities or means to recognize
>       intentions in any form of data.  However, the zero- or one-touch
>       approach should not be mistaken the fact that reaching the state
>       of a well-formed and valid intent expression is not a one-shot
>       process.  On the contrary, the interfacing between the user and
>       the intent-based system could be designed as an interactive and
>       interactive process.  Depending on the level of abstraction, the


“One touch but not one shot”, I can guess the meaning. However, as a non-native speaker, I am not sure  as I searched in google there is no other article writing in this way. Is this term invented by this doc? ☺
As the concept of ‘zero-touch’ was not defined in this doc or referred to any existing publication, I am not sure why ‘recognize intentions in any form of data’ can support ‘Zero-touch’. And what is the difference between one-touch and zero-touch.


“an interactive and interactive process”, typo?

>   3. Autonomy and Oversight.  A desirable goal for an intent-based
>       system is to offer a high degree of flexibility and freedom on
…
>      to be added: description for feedback, reporting,
>       guarantee scope (check points, guard rails, dynamically
>       provisioned, context rich, regular operation vs. exception/
>       abnormal, information zoom in-out, and link to SVoT…

“to be added…”, I guess this part is editor note?


>   5.  Explainability.  Need expressive network capabilities,
>       requirements and constraints to be able to compose/decompose
>       intents, map user's expectation to system capabilities.
>       capability exposure.  not just automation of steps that need to
>       be taken, but of bridging the semantic gap between "intent" and
>       actionable levels of instructions Context: multi providers, need
>       discovery and semantic descriptions Explainability: why is a
>       network doing what it is doing

This paragraph seem to be difficult to read as some sentences (from third one) are not complete.

I have a couple of comments and questions to the two figures in section 6, and will try to provide in next email.


Regards,  / 致礼!
Will LIU   / 刘树成
----------------------------------------------------------------------------------------------
Shucheng LIU (Will, 刘树成), Ph.D.
Director of Standard Area
Huawei Technologies Co.,Ltd
[e-mail]<mailto:[e-mail]>
http://www.linkedin.com/in/shucheng
----------------------------------------------------------------------------------------------