Re: [auth48] AUTH48: RFC-to-be 9316 <draft-irtf-nmrg-ibn-intent-classification-08> for your review

[Olga Havel <[e-mail]>]

Hi,

I am forwarding to Chen, as there is some mismatch with email addresses.

Best Regards,
Olga


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday 20 September 2022 02:41
To: [e-mail]; Olga Havel <[e-mail]>; Adriana Olariu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9316 <draft-irtf-nmrg-ibn-intent-classification-08> for your review

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] FYI: The following references are not cited in the text and have been removed.  Please let us know any objections.

[RFC2119]
[RFC7575]
[RFC8328]
[RFC3198]
[RFC6020]
[RFC7285]
[I-D.du-anima-an-intent]
[I-D.ietf-supa-generic-policy-info-model]
[RFC8992]
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in
     the title) for use on https://www.rfc-editor.org/search. -->


3) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of
     RFC 5743 have been adhered to in this document.  -->


4)   <!--[rfced] May we update the Abstract with regard to the following
       definite and indefinite articles (a/the)?

Original:

   Intent is an abstract, high-level policy used to operate the network.
   Intent-based management system includes an interface for users to
   input requests and an engine to translate the intents into the
   network configuration and manage their life-cycle.

Perhaps:
   Intent is an abstract, high-level policy used to operate a network.
   An intent-based management system includes an interface for users to
   input requests and an engine to translate the intents into the
   network configuration and manage their life cycle.
-->


5) <!--[rfced] We note that "intent" is defined in more than one way in
     this document (in the Abstract, "Definitions", and "What is
     Intent" sections).

Original:
Intent is an abstract, high-level policy used to operate the network.

and

   Intent:  A set of operational goals (that a network should meet) and
      outcomes (that a network is supposed to deliver), defined in a
      declarative manner without specifying how to achieve or implement
      them.

and all of Section 4.1. (What is Intent)



Would it be helpful to the reader if these definitions were made more uniform?
-->


6) <!--[rfced] The use of "vision" seems a bit odd in this sentence.
     Could another word better convey the idea?

Original:
The vision of intent-based networks has attracted a lot of attention...

Perhaps:
The idea of intent-based networks has attracted a lot of attention...
-->


7)  <!-- [rfced] Section 1.1: we had the following questions regarding
      the first few paragraphs.

a) Might we update the first few paragraphs of the Introcution as follows?  This includes changes to reduce redundancy, improve readability, and make a few grammatical updates.  Please review carefully and let us know if this works for you.


Original:
1.1. Research activities

   Intent-based networking is an active research topic which spans
   across different areas that could benefit from an intent
   classification and taxonomy.

   One such area is intent expression and recognition ([Bezahaf21],
   [Bezahaf19]), NILE [Jacobs18]). The use of a common classification
   can provide consistency in the understanding of the various forms of
   intent expressions being proposed and investigated.

   Another area where this intent classification could contribute is the
   orchestration of cognitive autonomous RANs [Banerjee21] where intents
   are classified based on their content.

   The work carried in intent network verification [Tian19] where the
   authors are proposing new intent language is another candidate where
   intent classification could be used advantageously.

Perhaps:
1.1.  Research Activities

   Intent-based networking is an active research topic spanning across
   different areas that could benefit from an intent classification and
   taxonomy.  Some examples include:

   - intent expression and recognition ([Bezahaf21]
     [Bezhaf19] NILE [Jacobs18]).  The use of a common classification could
     provide consistency in the understanding of the various forms of
     intent expressions being proposed and investigated.

   - the orchestration of cognitive autonomous radio access networks (RANs)
     [Banerjee21] where intents are classified based on their content.

   - intent network verification [Tian19], where the authors are working to
     propose new intent language.


b) In the following sentence, may we remove "NILE" as it does not appear to be a reference and is mentioned in [Jacobs18]?  Or is there some other text missing to describe "NILE"?  Note that the updated text might appear differently based on your reply to the previous query.

Original:

   One such area is intent expression and recognition ([Bezahaf21],
   [Bezhaf19]), NILE [Jacobs18]).

Perhaps:

   One such area is intent expression and recognition ([Bezahaf21],
   [Bezhaf19], [Jacobs18]).
-->


8) <!--[rfced] Please review the updates to this text that we made in
     order to expand the abbreviation "IBN" on first use (to ensure we
     have correctly captured your intent with regard to the use of
     "based").

Original:

   ...for proposing self-generated Intent-based systems [Bezhaf19],
   for advancing IBN-based VNF placement solutions...
   
Edited:
   
   ...for proposing self-generated Intent-based systems [Bezhaf19],
   for advancing Internet-Based Network (IBN) Virtual Network Function
   (VNF) placement solutions...
-->


9) <!-- [rfced] In the following sentence, may we update the past tense
     "came up with" to "come up with"?

Original:
   The SDOs usually came up with their own way of specifying an intent,
   and with their own understanding of what an intent is.

Perhaps:
   The SDOs usually come up with their own way of specifying an intent
   with their own understanding of what an intent is.
-->


10)    <!--[rfced] Might "intended intent users" be tough to read?  Is
        there a word we could use instead of "intended" or a way to
        rephrase for the ease of the reader?

Original:
Besides that, each SDO defines a set of terms and level of abstraction, its intended intent users, and the applications and usage scenarios.

-->


11) <!-- [rfced] Should the last sentence following the bullet points in
     Section 1.2 be included in the bulleted list along with the other
     features proposed by SDOs?

Original:

      - It must be vendor agnostic in the sense that it abstracts the
      network capabilities, or the network infrastructure from the
      intent user, and it can be ported across different platforms.

      - It must provide an easy-to-use
      interface, which simplifies the intent users' interaction with the intent
      system through the usage of familiar terminology or concepts.

   It should be able to detect and resolve intent conflicts, which
   include, for example, static (compile-time) conflicts and dynamic
   (run-time) conflicts.

Perhaps:

      - It must be vendor agnostic in the sense that it abstracts the
      network capabilities, or the network infrastructure from the
      intent user, and it can be ported across different platforms.

      - It must provide an easy-to-use
      interface, which simplifies the interaction of intent users with
      the intent system through the usage of familiar terminology or concepts.

      - It should be able to detect and resolve intent conflicts,
      which include, for example, static (compile-time) conflicts and
      dynamic (run-time) conflicts.
-->


12) <!--[rfced] Please note that we have updated the expansion of O&M to
     match guidance we received on RFC 6291.  Please review and let us
     know any objections.

Original:
Operations & Maintenance

Current:
OAM & Maintenance
-->


13) <!-- [rfced] In the following category for Intent Users, should commas
     be placed to better separate the intent users?

Original:
   Network Operator Service Designers/App Developer Service Operators Customers/Subscribe rs

   Cloud Administrator Underlay Network Administrator Application Developers Customer/Ten ants

   Enterprise Administrator Application Developers End-Users

Perhaps:
   Network Operators, Service Designers / App Developers, Service Operators, Customers/Subscribers

   Cloud Administrators, Underlay Network Administrators, Application Developers, Customers/Tenants

   Enterprise Administrators, Application Developers, End-Users
-->


14) <!-- [rfced] In the following sentence, may we remove "rate" after
     1080p? It may be clear enough to readers without it.

Original:
   For carrier networks scenario, for example, if a customer/subscriber
   wants to watch high-definition video, then the intent is to convert the video
   image to 1080p rate.
-->


15) <!-- [rfced] In the following sentence, do operators want both more
     technical visibility and network visibility? If not, how might we
     clarify?

Original:
   Customers, application developers and end-users must not be required
   to set IP addresses, VLANs, subnets, ports, while operators may still want to
   have more technical and network visibility.

Perhaps:
   Customers, application developers, and end users must not be
   required to set IP addresses, VLANs, subnets, or ports, whereas
   operators may still want to have more technical network visibility.

Or perhaps:
   Customers, application developers, and end users must not be
   required to set IP addresses, VLANs, subnets, or ports, whereas
   operators may still want to have both more technical and network
   visibility.
-->


16) <!-- [rfced] Was it intended to use the first person "my" in the
     following bullet point?

Original:
   All stakeholders would benefit from the simpler interfaces, like:

      - Request gold VPN service between my sites A, B, and C

Perhaps:
   All stakeholders would benefit from simpler interfaces, such as:

      - Request gold VPN service between sites A, B, and C
-->


17) <!-- [rfced] We've updated APP to "Application-specific function" per
     its usage in past RFCs. Please let us know if this is incorrect.
-->	      


18) <!-- [rfced] In the following definition for "Partially automated
     network", the second sentence appears to be a fragment. How might
     we complete it?

Original:
   Level 1 - Partially automated network:
       Automated scripts are used to automate service provisioning, network
       deployment, and maintenance. Shallow perception of network status and
       decision making suggestions of machine.

-->


19) <!-- [rfced] May we update the definition for "Level 2 - Automated
     network:" to be a complete sentence to match other definitions in
     the list?

Original:
   Level 2 - Automated network:

    Automation of most service provisioning, network deployment, and
    maintenance of a comprehensive perception of network status and local
    machine decision making.

Perhaps:
   Level 2 - Automated network:

    Automated scripts are used to automate most service provisioning,
    network deployment, and maintenance of a comprehensive perception
    of network status and local machine decision-making.
-->


20) <!-- [rfced] May we update the definition for "Level 2" and "Level 3"
     to use complete sentences?

Original:
   Level 2 - Automated network:

      Automation of most service provisioning, network deployment, and
      maintenance of a comprehensive perception of network status and
      local machine decision making.  - simple intent on service
      provisioning

   Level 3 - Self-optimization network:

      Deep awareness of network status and automatic network control, meeting
      requirements of intent users of the network.

Perhaps:
   Level 2 - Automated network:

      This entails the automation of most service provisioning,
      network deployment, and maintenance of a comprehensive
      perception of network status and local machine decision-making.
      - simple intent on service provisioning

   Level 3 - Self-optimization network:

      This entails a deep awareness of network status and automatic
      network control, meeting requirements of intent users of the
      network.
-->


21) <!--[rfced] The use of "adapt to and adjust to meet people's
     intentions" is a bit difficult to parse.  We have updated as
     follows.  Please review and confirm that we have maintained your
     intended meaning.

Original:
In different network environments and network conditions, the network can automatically adapt to and adjust to meet people's intentions.

Current:
In different network environments and network conditions, the network can automatically adapt and adjust to meet people's intentions.
-->


22) <!--[rfced] Please review our edits to the following text to ensure we
     have maintained the intended meaning (i.e., confirm that "resource
     scope" is the name of the category).

Original:
For example, for the DC intent solution, a new category is identified, i.e. resource scope, and the classification table has been extended accordingly.
   
Current:
For example, for the DC intent solution, a new category "resource scope" is identified, and the classification table has been extended accordingly
-->


23) <!--[rfced] Might we update "use/add" in the following to clarify the
     relationship?

Original:
   8.  Identify any new categories and use/add the newly identified
   categories.
   
Perhaps:
   8.  Identify any new categories.  Use and add the newly identified
       categories. 

-->


24) <!--[rfced] We had the following questions regarding Figure 2:

a) In the text leading up to Figure 2, we see "intent solutions", "intent user types", "intent types", and "intent scope".  However, in the figure itself, we see simply "Solutions".  Should this be made "Intent Solutions"?  Or should "Intent User Types", "Intent Type", and "Intent Scope" be made "User Types", "Type", and "Scope" assuming that the "Intent" on the far left applies to all of them?

b) Should the "Intent Types" include the word "Intent"?  For example, "Customer Service" instead of "Customer Service Intent"?  Note that we do not see "Carrier Intent Solution" in the first box or "Connectivity Scope" etc.

c) Should "Solutions" and "Intent User Types" be made singular to match "Intent Type" and "Intent Scope" and others?


-->


25) <!-- [rfced] In the following sentence, was "apps of type video"
     intended? Would "video apps" or "video-type apps" work better?
       
Original:
   Example: Request reliable service during peak traffic periods for
   apps of type video.
-->


26) <!-- [rfced] In the following sentence, is "path P" being backed up,
     or is it itself a "backup path"?

Original (name is backup path P):
   Example: Request migration of all services in network N to backup path P.

Perhaps (in order to back path P up):
   Example: Request migration of all services in network N to back up path P.
-->


27) <!-- [rfced] In the following description, should SLA be in a
     sequential list with the other items?  (note: multiple instances).

Original:
   Service operator's customer orders, customer service / SLA.

Perhaps:
   Service operator's customer orders, customer service, or SLA.
-->


28) <!--[rfced] Please review the tense shift indicated by "A service
     chain intent expressed" to confirm that this action should not be
     simple present tense (as seen in the sentence before).


Original:
   In this PoC [POC-IBN], a slice intent expresses a request for a
   network slice with two types of components: a set of top layer
   virtual functions, and a set of virtual switches and/or routers of
   L2/L3 VNFs. A service chain intent expressed a request for a service
   operated through a chain of service components running in L4-L7
   virtual functions.
-->


29) <!-- [rfced] We had the following questions regarding Table 4 (Intent
     Classification for Data Center Network Solutions):
	

a) While we've made the figure in Section 6.3.3 a table, it does not quite fit the maximum allowable width. Is there any way we can shorten the table to make it fit?  Would we be able to shorten the columns C1
- C4 under "Network Scope"?  Note: Similar instance in Section 6.4.3.

Original:
   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   | Intent  | Intent  | Intent    | NF  | Network         | ABS |L-C  |
   | User    | Type    | Scope     |Scope| Scope           |     |     |
   |         |         ++++++++++++++++++++++++++++++++++++++++++++++++
   |         |         |C1|C2|C3|C4|C1|C2|C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|

Perhaps:
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   | Intent  | Intent  | Intent    | NF  | Network   | ABS |L-C  |
   | User    | Type    | Scope     |Scope| Scope     |     |     |
   |         |         +++++++++++++++++++++++++++++++++++++++++++
   |         |         |C1|C2|C3|C4|C1|C2|C1-C4|C5|C6|C1|C2|C1|C2|

b) Also note that the text output of the table in Section 6.3.3 does not span out the headers (e.g., Intent Scope, NF Scope, etc.) in the way that HTML output does.


-->


30) <!-- [rfced] In the following sentence, was "connnectivity
     communication" intended or "community and communication"?

Original:
   Configuration of VMs, DB Servers, app servers, and connectivity,
   communication between VMs.

Perhaps:
   Configuration of VMs, DB Servers, app servers, and connectivity
   communication between VMs.
-->


31) <!-- [rfced] In the following example, does the API also request
     configuration of DB servers?

Original:
   Example: API to request configuration of VMs, or DB Servers.

Perhaps:
   Example: API to request configuration of VMs or DB Servers.
-->


32)    <!--[rfced] We have made this update for parallel structure.
        Please let us know any objections.  (Two sentences only to
        show relationship - no change suggested for the second line.)

Original:
   1.  The intent solution is for the data center.
and
   1. The intent solution for both intents is carrier network.


Edited (only a change to the first line):
   1.  The intent solution is data center.
and
   1. The intent solution for both intents is carrier network.
-->


33) <!--[rfced] Is it known that "more details of these security intents"
     will be described in a future document(s)?  Perhaps "will",
     "might", or "could" would be more appropriate here?

Original:
   More details of these security intents would be described in future
   documents that specify architecture, functionality, user...

Perhaps:
   More details of these security intents will be described in future
   documents that specify architecture, functionality, user...

-->


34) <!-- [rfced] Would you like the references to be alphabetized or left in their current order?
-->


35) <!-- [rfced] FYI: For reference [ONF], we've updated the target site
     to the non-parsing
     <https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-rep
orts/TR-523_Intent_Definition_Principles.pdf>
     to
     <https://opennetworking.wpengine.com/wp-content/uploads/2014/10/TR-523_Intent_Defini
tion_Principles.pdf>
     and have updated the title to "Intent NBI - Definition and
     Principles".  Please let us know if this is not correct.
-->


36) <!--[rfced] Please note that we have updated to point to RFC-to-be
     9315 (I-D.irtf-nmrg-ibn-concepts-definitions) assuming that it
     will be published prior to this document (see
     http://www.rfc-editor.org/auth48/rfc9315).

If this is not the case, we can revert the reference to point to the I-D or hold this document to be published simultaneously.  Please advise.-->


37) <!-- [rfced] Terminology: we had the following questions related to
     terminology throughout the document.


a) We have lowercased "autonomous networks" throughout - please let us know if anything needs to be done to make "autonomous network" and "autonomous driving network" uniform.



-->


38) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. -->


Thank you.

RFC Editor/re/mf

*****IMPORTANT*****

Updated 2022/09/19

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9316.xml
   https://www.rfc-editor.org/authors/rfc9316.html
   https://www.rfc-editor.org/authors/rfc9316.pdf
   https://www.rfc-editor.org/authors/rfc9316.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9316-diff.html
   https://www.rfc-editor.org/authors/rfc9316-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9316-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9316

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9316 (draft-irtf-nmrg-ibn-intent-classification-08)

Title            : Intent Classification
Author(s)        : C. Li, O. Havel, A. Olariu, P. Martinez-Julia, J. Nobre, D. Lopez
WG Chair(s)      : 
Area Director(s) :