Re: [auth48] AUTH48: RFC-to-be 9417 <draft-ietf-opsawg-service-assurance-architecture-13> for your review

[Benoit Claise <[e-mail]>]

Thangham,

Do you want to change your contact information or it does not matter?

Regards, Benoit




From:Thangavelu Arumugam <[e-mail]>
To:Benoit Claise <[e-mail]>
Cc:Alanna Paloma <[e-mail]>;Diego R. Lopez <[e-mail]>;rfc-editor <[e-mail]>;Jean Quilbeuf <[e-mail]>;daniel.voyer <[e-mail]>;tarumuga <[e-mail]>;opsawg-ads <[e-mail]>;opsawg-chairs <[e-mail]>;mcr <[e-mail]>;rwilton <[e-mail]>;auth48archive <[e-mail]>
Date:2023-06-06 18:45:05
Subject:Re: AUTH48: RFC-to-be 9417 for your review

Approved,


Thanks,
Thangam





On Jun 6, 2023, at 8:08 AM, Benoit Claise <[e-mail]> wrote:

 Dear all,

IncludingThangam Arumugam's new email: [e-mail]<mailto:[e-mail]>

Regards, Benoit

On 6/2/2023 3:10 AM, Alanna Paloma wrote:

Hi Diego,

Your approval has been noted:
https://www.rfc-editor.org/auth48/rfc9417

Once we receive approvals from Dan and Thangam, we will move this document forward in the publication process.

Thank you,
RFC Editor/ap



On Jun 1, 2023, at 2:16 AM, Diego R. Lopez <[e-mail]><mailto:[e-mail]> wrote:

Hi Alanna,

You have my approval. Thanks!

Be Goode,

--
“Esta vez no fallaremos, Doctor Infierno”

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/dr2lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Mobile: [phone]
---------------------------------

On 31/5/23, 18:38, <[e-mail]><mailto:[e-mail]> wrote:

Hi Benoit,

Thank you for your reply. We have updated the files accordingly and noted your approval on the AUTH48 status page:
  https://www.rfc-editor.org/auth48/rfc9417

Once we receive approvals from Jean, Diego, Dan, and Thangam, we will move this document forward in the publication process.

The files have been posted here (please refresh):
  https://www.rfc-editor.org/authors/rfc9417.xml
  https://www.rfc-editor.org/authors/rfc9417.txt
  https://www.rfc-editor.org/authors/rfc9417.html
  https://www.rfc-editor.org/authors/rfc9417.pdf

The relevant diff files have been posted here:
  https://www.rfc-editor.org/authors/rfc9417-diff.html (comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9417-auth48diff.html (AUTH48 changes)
  https://www.rfc-editor.org/authors/rfc9417-lastdiff.html (htmlwdiff diff between last version and this)
  https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html (rfcdiff between last version and this)

Thank you,
RFC Editor/ap



On May 30, 2023, at 11:45 AM, Benoit Claise <[e-mail]><mailto:[e-mail]> wrote:

Hi,

On 5/26/2023 7:13 PM, Alanna Paloma wrote:


Hi Benoit,

Thank you for your replies. We have updated the files accordingly.

Regarding the use of “YANG module” and “YANG data model", we ask that you review all occurrences of “YANG model” in this document and let us know where updates are necessary. For example, in the following, “YANG modules” doesn’t seem right as RFC 7950 is titled “The YANG 1.1 Data Modeling Language”.


I followed your advice:
c) We have received guidance from the YANG Doctors
that "YANG module" and "YANG data model" are preferred.
Some occurrences may need an update, for example:


Original:
  This
   problem is compounded by a large, disparate set of data sources (MIB
   modules, YANG models [RFC7950], IPFIX information elements [RFC7011],
   syslog plain text [RFC5424], TACACS+ [RFC8907], RADIUS [RFC2865],
   etc.).


NEW:
  This
   problem is compounded by a large, disparate set of data sources (MIB
   modules, YANG data models [RFC7950], IPFIX information elements [RFC7011],
   syslog plain text [RFC5424], TACACS+ [RFC8907], RADIUS [RFC2865],
   etc.).


In another example, we see the following. However, Section 6 is titled “Subservice Augmentation: ietf-service-assurance-interface YANG Module”.


This is fine.


Original:
   This can be partially achieved by correctly setting permissions of
   each node in the YANG model as described in Section 6 of
   [RFC9418].


New:
   This can be partially achieved by correctly setting permissions of
   each node in the YANG data model as described in Section 6 of
   [RFC9418].


Note that it is not always clear to us whether “model” vs. “module” is correct and/or if all instances of “YANG model” should be updated to “YANG data model”. Please review each instance and let us know if updates are needed.


OLD:
In order to avoid this data
   model mapping, the industry converged on model-driven telemetry to
   stream the service operational data, reusing the YANG models used for

NEW:
In order to avoid this data
   model mapping, the industry converged on model-driven telemetry to
   stream the service operational data, reusing the YANG data models used for

OLD:
   In order to make agents, orchestrators, and collectors from different
   vendors interoperable, their interface is defined as a YANG model in
   a companion document [RFC9418].  In Figure 1, the communications that
   are normalized by this YANG model are tagged with a "Y".  The use of
   this YANG
model module
 is further explained in Section 3.5.

NEW:
   In order to make agents, orchestrators, and collectors from different
   vendors interoperable, their interface is defined as a YANG moddule in
   a companion document [RFC9418].  In Figure 1, the communications that
   are normalized by this YANG module are tagged with a "Y".  The use of
   this YANG
model module
 is further explained in Section 3.5.

OLD:
 The set of dependency types presented here is not exhaustive.  More
   specific dependency types can be defined by extending the YANG model.

NEW:
 The set of dependency types presented here is not exhaustive.  More
   specific dependency types can be defined by extending the YANG module.

OLD:
This also implies that, while waiting for all the
   metrics to be available via standard YANG modules, SAIN agents might
   have to retrieve metric values via nonstandard YANG models,

NEW:
This also implies that, while waiting for all the
   metrics to be available via standard YANG modules, SAIN agents might
   have to retrieve metric values via nonstandard YANG data models,



The files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc9417.xml
 https://www.rfc-editor.org/authors/rfc9417.txt
 https://www.rfc-editor.org/authors/rfc9417.html
 https://www.rfc-editor.org/authors/rfc9417.pdf

The relevant diff files have been posted here:
 https://www.rfc-editor.org/authors/rfc9417-diff.html (comprehensive diff)
 https://www.rfc-editor.org/authors/rfc9417-auth48diff.html (AUTH48 changes)

Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.

We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.


Everything is fine.

Thanks, B.


For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9417

Thank you,
RFC Editor/ap



On May 24, 2023, at 3:18 AM, Benoit Claise <benoit.claise=[e-mail]><mailto:benoit.claise=[e-mail]> wrote:

Dear RFC editors,

On 5/24/2023 11:09 AM, [e-mail]<mailto:[e-mail]> wrote:


Authors,

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

Also, please note that this diff file will allow you to more easily view changes in the Introduction and Terminology sections.  Apologies, as we forgot to include this in the initial AUTH48 message:
   https://www.rfc-editor.org/authors/rfc9417-alt-diff.html


All is fine thanks.


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


NA



2) <!-- [rfced] May we update this document to say "an architecture that
assures" rather than "aims to assure"?  Otherwise, perhaps "an architecture
that provides some assurance that service instances are..."?

Original:
   This document describes an architecture that aims at assuring that
   service instances are running as expected.
-->


an architecture
that provides some assurance that service instances are..."

The above works better, thanks.


3) <!--[rfced] FYI, we have moved the Terminology section to appear after
the Introduction.
-->


Ok.



4) <!-- [rfced] "feed" reads a bit awkwardly.  Would "fuel" work here
instead?

Original:
   To feed that task, the industry has been standardizing
   on telemetry to push network element performance information (e.g.,
   [I-D.ietf-opsawg-yang-vpn-service-pm]).
-->


Fuel is better.



5) <!-- [rfced] As this document is being published as an RFC, should
"propose" be removed?  That is, should it read "this document defines an
architecture implementing ..."?


Yes.


Original:
   In this document, we propose an architecture implementing Service
   Assurance for Intent-Based Networking (SAIN).
-->


6) <!--[rfced] Should the terms listed in the Terminology section be
listed in alphabetical order?
-->


IIRC, there is some logic behind the order, for the reader
Ex: health status after subservice.


7) <!-- [rfced] We have updated the expansion for L2VPN to be "layer 2
virtual private network" (i.e., s/level/layer).  Please let us know if any
updates are needed.

Original:
   As an example of a service, let us consider a point-to-point level 2
   virtual private network (L2VPN).
-->


OK


8) <!-- [rfced] What is being forwarded to the orchestrator?  Is it the
information that a switchover has occurred?  Also, is it the orchestrator
that reconfigures the agents?  Please consider whether the suggested text
correctly conveys the intended meaning.

Original:
   The
   collector also detects changes in the assurance graph structures, for
   instance when a switchover from primary to backup path occurs, and
   forwards to the orchestrator, which reconfigures the agents.

Perhaps:
   The
   collector also detects changes in the assurance graph structures (e.g., an
   occurrence of a switchover from primary to backup path) and
   forwards the information to the orchestrator, which reconfigures the agents.
-->


Good proposal



9) <!--[rfced] We note that RFC 8641 does not include mention of
"telemetry".  Please review and let us know if/how the text/citation
should be updated.

Original:
   *  Stream (via telemetry [RFC8641]) operational and config metric
      values when possible, else continuously poll.
-->


  *  Stream (via telemetry such as YANG-PUSH [RFC8641]) operational and config metric
     values when possible, else continuously poll.




10) <!--[rfced] For clarity, may we change "as" to "since" here? This
would make it clear the intended meaning is a result rather than "at the
same time".

Original:
  However, the dependencies between the link and the
  interfaces are lost as they were causing the circular dependency.

Perhaps:
  However, the dependencies between the link and the
  interfaces are lost since they were causing the circular dependency.
-->


Fine.



11) <!-- [rfced]  We find the use of "configuration" and
"configuring"/"configure" in the same sentence a bit confusing.  Please
consider whether updates are needed?  Will the suggested text change the
intended meaning?

Original:
   The SAIN orchestrator must be able to analyze configuration pushed to
   various devices for configuring a service instance and produce the
   assurance graph for that service instance.

   To schematize what a SAIN orchestrator does, assume that the
   configuration for a service instance touches two devices and
   configure on each device a virtual tunnel interface. ...

Perhaps:
   The SAIN orchestrator must be able to analyze the configuration pushed to
   various devices of a service instance and produce the
   assurance graph for that service instance.

   To schematize what a SAIN orchestrator does, assume that
   a service instance touches two devices and
   configures a virtual tunnel interface on each device.
-->


Yes, this is better


12) <!-- [rfced] Is it possible to detect a non-functional tunnel?


Yes, it's configured but no traffic is forwarded.


Does
detection that a tunnel exists imply that it is functional?


No, see above.


Original:
   *  Capturing the intent would start by detecting that the service
      instance is actually a tunnel between the two devices, and stating
      that this tunnel must be functional.

Perhaps:
   *  Capturing the intent would entail detecting that the service
      instance is actually a tunnel between the two devices and indicating
      that the tunnel must remain functional.
-->


Proposal

  *  Capturing the intent would start by detecting that the service
     instance is actually a tunnel between the two devices, and stating
     that this tunnel must be operational.




13) <!-- [rfced] This text reads awkwardly in that it first says the
organization is out of scope but then lists goals.  Please consider
whether the suggested text is correct.

Original:
   The organization of such a process is out-of-scope for this
   document and should aim to:

   *  Ensure that existing subservices are reused as much as possible.

   *  Avoid circular dependencies.

Perhaps:
   The organization of such a process is out of scope for this
   document.  Future documentation should aim to:

   *  Ensure that existing subservices are reused as much as possible.

   *  Avoid circular dependencies.
-->


Proposal:

  The organization of such a process (Ensure that existing subservices are reused as much as possible
  and avoid circular dependencies) is out-of-scope for this
  document.

Does it work better?




14) <!--[rfced] In the sentence below, does "identify the object" describe
"the parameters" or "a minimal set"?

Original:
   Then, the parameters
   must be chosen as a minimal set that completely identify the object
   (see examples from the previous paragraph).

Perhaps (describes "a minimal set"):
   Then, the parameters
   must be chosen as a minimal set that completely identifies the object
   (see examples from the previous paragraph).
-->


Your proposal is better.



15) <!-- [rfced] We are having some difficulty understanding "expressed
differently" in the sentence below. Please review and let us know how this
sentence should be updated.


expressed differently = in other words


Original:
   In order to keep subservices independent of metric collection method,
   or, expressed differently, to support multiple combinations of
   platforms, OSes, and even vendors, the architecture introduces the
   concept of "metric engine".

Perhaps A:
   In order to keep subservices independent of metric collection method,
   and support multiple combinations of
   platforms, OSes, and even vendors, the architecture introduces the
   concept of "metric engine".

Perhaps B:
   In order to keep subservices independent of metric collection method
   (or, expressed differently, to support multiple combinations of
   platforms, OSes, and even vendors), the architecture introduces the
   concept of "metric engine".
-->


Proposal B is better



16) <!--[rfced] Ordering the IANA section before the Security Considerations
section is strongly recommended in the RFC Style Guide (see RFC 7322,
Section 4). Given this, we updated the document accordingly.  Please let us know any objections.
-->


Then we will strongly follow the recommendations :-)



17) <!--[rfced] Terminology questions

a) FYI, we have capitalized instances of "engineer A" and "engineer B"
to be "Engineer A" and "Engineer B" to be consistent. Please let us know
of any objections.


No objection.


b) We note that "health score" and "health-score" are both used in this
document. Should these instances be made consistent?


Fine to change "health-score" to health score. There is only one occurence.


c) We have received guidance from the YANG Doctors
that "YANG module" and "YANG data model" are preferred.
Some occurrences may need an update, for example:

Original:
   The use of this YANG model is further
   explained in Section 3.5.

Where Section 3.5 is "Open Interfaces with YANG Modules.”

Please review and specify any needed updates.
-->


This is fine.


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

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.


Thank you very much for the improvements.

Regards, Benoit


-->


Thank you.

RFC Editor




On May 23, 2023, at 7:58 PM, [e-mail]<mailto:[e-mail]> wrote:

*****IMPORTANT*****

Updated 2023/05/23

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><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]<mailto:[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]<mailto:[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]<mailto:[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/rfc9417.xml
   https://www.rfc-editor.org/authors/rfc9417.html
   https://www.rfc-editor.org/authors/rfc9417.pdf
   https://www.rfc-editor.org/authors/rfc9417.txt

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

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

The following files are provided to facilitate creation of your own
diff files of the XML.

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9417.original.v2v3.xml

XMLv3 file that is a best effort to capture v3-related format updates
only:
   https://www.rfc-editor.org/authors/rfc9417.form.xml


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

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

Please let us know if you have any questions.

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9417 (draft-ietf-opsawg-service-assurance-architecture-13)

Title            : Service Assurance for Intent-based Networking Architecture
Author(s)        : B. Claise, J. Quilbeuf, D. Lopez, D. Voyer, T. Arumugam
WG Chair(s)      : Henk Birkholz, Joe Clarke, Tianran Zhou
Area Director(s) : Warren Kumari, Robert Wilton




Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [e-mail]<mailto:[e-mail]>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [e-mail]<mailto:[e-mail]>. You may consult additional information on the processing of your data in our Privacy Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a [e-mail]<mailto:[e-mail]>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade.