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

[Thangavelu Arumugam <[e-mail]>]

Hi Benoit,

Sorry for the delay.

I am yet to get the response from legal team.

I will go with consultant and private email address: [e-mail]

Thanks,

Thangavelu 

On Jun 26, 2023, at 10:07 AM, Benoit Claise <[e-mail]> wrote:

 Hi Thangham,


We are waiting for you for both:
-  https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417
- https://www.rfc-editor.org/auth48/rfc9418" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9418

I understand that you changed company and that you wanted to check with your company legal department. Engaging lawyers take weeks... we know it ... so engaging them was probably not the best way out of it.
AUTH48 stems from 48 hours. We passed this by a long time: first RFC editor email on 2023/05/23)

There are 3 ways out of that.
1. you keep the Cisco affiliation and Cisco email address (after all, this RFC was entirely done under Cisco)
2. you keep the Cisco affiliation and your private email address
3. you mentioned "consultant" and your private email address.

Please let us know.
It's time to get those documents published

Regards, Benoit

On 6/21/2023 6:41 PM, Alanna Paloma wrote:

Hi Dan and Thangavelu,

Dan - Thank you for your reply. Your approval has been noted on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417

Thangavelu - We will await word regarding how you would like your address/affiliation to be updated prior to moving this document forward in the publication process.

Best regards,
RFC Editor/ap

On Jun 21, 2023, at 8:08 AM, Voyer, Daniel <[e-mail]> wrote:

Approved !

Sorry for the delay !

Thanks 
Dan

On 2023-06-19, 6:39 PM, "Alanna Paloma" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Dan,


This is a friendly reminder that we await your review and approval prior to moving this document forward in the publication process.


The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.xml https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.xml>
https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.txt https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.txt>
https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.html https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.html>
https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.pdf https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-diff.html https://www.rfc-editor.org/authors/rfc9417-diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-diff.html> (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-auth48diff.html https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-auth48diff.html> (AUTH48 changes) 
https://www.rfc-editor.org/authors/rfc9417-lastdiff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-lastdiff.html https://www.rfc-editor.org/authors/rfc9417-lastdiff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html> (rfcdiff between last version and this)


The AUTH48 status page can be seen here:
https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417 https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow"><https://www.rfc-editor.org/auth48/rfc9417>


Thank you,
RFC Editor/ap

On Jun 6, 2023, at 12:47 PM, Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:

Hi Thangam,

If you change Tangam's email, don't you want to update the affiliation accordingly?

As we updated your email, please let us know how you would like your affiliation/address to be updated.

Thank you,
RFC Editor/ap

Regards, Benoit 




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

Hi Thangam,

Your approval has been noted on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417 https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow"><https://www.rfc-editor.org/auth48/rfc9417>

We have updated you email address in this document and in RFC-to-be 9418.

The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.xml https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.xml>
https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.txt https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.txt>
https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.html https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.html>
https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.pdf https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-diff.html https://www.rfc-editor.org/authors/rfc9417-diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-diff.html> (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-auth48diff.html https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-auth48diff.html> (AUTH48 changes) 
https://www.rfc-editor.org/authors/rfc9417-lastdiff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-lastdiff.html https://www.rfc-editor.org/authors/rfc9417-lastdiff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html> (rfcdiff between last version and this)

Thank you,
RFC Editor/ap

On Jun 6, 2023, at 10:06 AM, Thangavelu Arumugam <[e-mail] <mailto:[e-mail]>> wrote:

Can you please change?

On Jun 6, 2023, at 9:54 AM, Benoit Claise <[e-mail] <mailto:[e-mail]>> wrote:


Thangham,

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

Regards, Benoit




From:Thangavelu Arumugam <[e-mail] <mailto:[e-mail]>>
To:Benoit Claise <[e-mail] <mailto:[e-mail]>>
Cc:Alanna Paloma <[e-mail] <mailto:[e-mail]>>;Diego R. Lopez <[e-mail] <mailto:[e-mail]>>;rfc-editor <[e-mail] <mailto:[e-mail]>>;Jean Quilbeuf <[e-mail] <mailto:[e-mail]>>;daniel.voyer <[e-mail] <mailto:[e-mail]>>;tarumuga <[e-mail] <mailto:[e-mail]>>;opsawg-ads <[e-mail] <mailto:[e-mail]>>;opsawg-chairs <[e-mail] <mailto:[e-mail]>>;mcr <[e-mail] <mailto:[e-mail]>>;rwilton <[e-mail] <mailto:[e-mail]>>;auth48archive <[e-mail] <mailto:[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] <mailto:[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" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417 https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow"><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/" rel="nofollow">https://www.linkedin.com/dr2lopez/ https://www.linkedin.com/dr2lopez/" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417 https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.xml https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.xml>


https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.txt https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.txt>


https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.html https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.html>


https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.pdf https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-diff.html https://www.rfc-editor.org/authors/rfc9417-diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-diff.html>
(comprehensive diff)

https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-auth48diff.html https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-auth48diff.html>
(AUTH48 changes) 

https://www.rfc-editor.org/authors/rfc9417-lastdiff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-lastdiff.html https://www.rfc-editor.org/authors/rfc9417-lastdiff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html https://www.rfc-editor.org/authors/rfc9417-lastrfcdiff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.xml https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.xml>


https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.txt https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.txt>


https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.html https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.html>


https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.pdf https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-diff.html https://www.rfc-editor.org/authors/rfc9417-diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-diff.html>
(comprehensive diff)

https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-auth48diff.html https://www.rfc-editor.org/authors/rfc9417-auth48diff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417 https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow"><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:[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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-alt-diff.html https://www.rfc-editor.org/authors/rfc9417-alt-diff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/search https://www.rfc-editor.org/search" rel="nofollow"><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" rel="nofollow"><https://www.rfc-editor.org/styleguide/part2/#inclusive_language> https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;" rel="nofollow"><https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>

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/" rel="nofollow">https://www.rfc-editor.org/faq/ https://www.rfc-editor.org/faq/" rel="nofollow"><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/" rel="nofollow">https://trustee.ietf.org/license-info/ https://trustee.ietf.org/license-info/" rel="nofollow"><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" rel="nofollow"><https://authors.ietf.org/rfcxml-vocabulary> https://authors.ietf.org/rfcxml-vocabulary&gt;" rel="nofollow"><https://authors.ietf.org/rfcxml-vocabulary&gt;>
.

* 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" rel="nofollow">https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc" rel="nofollow"><https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>

* The archive itself:

https://mailarchive.ietf.org/arch/browse/auth48archive/" rel="nofollow">https://mailarchive.ietf.org/arch/browse/auth48archive/ https://mailarchive.ietf.org/arch/browse/auth48archive/" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.xml https://www.rfc-editor.org/authors/rfc9417.xml" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.xml>


https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.html https://www.rfc-editor.org/authors/rfc9417.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.html>


https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.pdf https://www.rfc-editor.org/authors/rfc9417.pdf" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.pdf>


https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.txt https://www.rfc-editor.org/authors/rfc9417.txt" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417.txt>


Diff file of the text:

https://www.rfc-editor.org/authors/rfc9417-diff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-diff.html https://www.rfc-editor.org/authors/rfc9417-diff.html" rel="nofollow"><https://www.rfc-editor.org/authors/rfc9417-diff.html>


https://www.rfc-editor.org/authors/rfc9417-rfcdiff.html" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-rfcdiff.html https://www.rfc-editor.org/authors/rfc9417-rfcdiff.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417-xmldiff1.html https://www.rfc-editor.org/authors/rfc9417-xmldiff1.html" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.original.v2v3.xml https://www.rfc-editor.org/authors/rfc9417.original.v2v3.xml" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/authors/rfc9417.form.xml https://www.rfc-editor.org/authors/rfc9417.form.xml" rel="nofollow"><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" rel="nofollow">https://www.rfc-editor.org/auth48/rfc9417 https://www.rfc-editor.org/auth48/rfc9417" rel="nofollow"><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.

------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints