Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Benoit Claise]

Dear all,

We have been receiving many comments during the live of these drafts. Lately, 
some good feedback from Tom.

I believe these drafts are ready.
Note: I am a little bit biased as co-author... Or maybe I spent so much time on 
these drafts that I am convinced.

Regards, Benoit


From:Tianran Zhou 
To:opsawg 
Date:2022-06-08 12:05:04
Subject:[OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Thomas.Graf]

Dear OPSAWG,

I have read the document and I think it is ready to progress. It is an 
important component of the Service Assurance for Intent-based Networking 
architecture.

Best wishes
Thomas

From: OPSAWG  On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 12:04 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs



smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[mohamed.boucadair]

Hi all,

Please find below my comments to this version.


  *   pdf: 
https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.doc

I think that some further work is needed.

Cheers,
Med

PS: I didn't review the appendices.

De : OPSAWG  De la part de Tianran Zhou
Envoyé : mercredi 8 juin 2022 12:04
À : opsawg@ietf.org
Objet : [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA]

Dear OPSAWG,

As companion of the SAIN architecture, I also support this document. The YANG 
module well captures the health of a service as graph.

Best regards,
Nacho.

From:Tianran Zhou 
To:opsawg 
Date:2022-06-08 12:05:04
Subject:[OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs

___ OPSAWG mailing list 
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg



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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Diego R. Lopez]

Hi,

I support moving ahead with the document.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lo...@telefonica.com
Mobile:  +34 682 051 091
--

On 22/06/2022, 15:19, "OPSAWG on behalf of IGNACIO DOMINGUEZ 
MARTINEZ-CASANUEVA" mailto:opsawg-boun...@ietf.org> on 
behalf of 
ignacio.dominguezmarti...@telefonica.com>
 wrote:

AVISO/WARNING: Este mail se ha originado fuera de la organización y no se pudo 
verificar al remitente / This mail was originated outside the organization and 
the sender could not be verified

Dear OPSAWG,

As companion of the SAIN architecture, I also support this document. The YANG 
module well captures the health of a service as graph.

Best regards,
Nacho.

From:Tianran Zhou 
To:opsawg 
Date:2022-06-08 12:05:04
Subject:[OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs

___ OPSAWG mailing list 
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg



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



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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Yangfan(Fan, IP Standards)]

Hi OPSAWG,

I support the progress of this document, and thanks.

Best,
Fan

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:04 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Wubo (lana)]

Hi all,

I have read this draft and I think this draft is ready to progress. This YANG 
model is an important part of SAIN architecture.

Thanks,
Bo

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:04 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all

I also support the progression of this document.

Best regards

Luis

De: OPSAWG  En nombre de Wubo (lana)
Enviado el: viernes, 24 de junio de 2022 12:53
Para: Tianran Zhou ; opsawg@ietf.org
Asunto: Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi all,

I have read this draft and I think this draft is ready to progress. This YANG 
model is an important part of SAIN architecture.

Thanks,
Bo

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:04 PM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs




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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Jean Quilbeuf]

Hi Med,
thanks again for your very thorough comments on the draft about the YANG 
modules for service assurance. The diff is here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-06

I think that I addressed most of your comments. The main one remaining is:

About maintenance-contact
MED: "Shouldn’t this be an URI?" "A pattern should then be provided to comply 
with this?"

Tried to add a pattern about adding monitor in front:
   pattern "(monitor:)?.*";
The I realized that it does not restrict anything. The description in English 
says what it should be while leaving things open.
We might want to restrict more and I am open to any suggestion.



Below are some answers to most important comments.


Section 3 (ietf-service-assurance) YANG model

About assurance-graph-version counter
MED: "Shouldn’t this version be configurable when a new one is installed?"

That counter should be automatically incremented each time any config node of 
the model is changed, should not be the responsibility of the client. Clarified 
in the text and the YANG model.


About parameters
MED: "I guess this is how you bind a service assurance to a service (or a 
service instance). If so, why isn’t this at the upper level? "

Clarified in the text that service instances are a particular type of 
subsrevice and the link between a service and its graph is obtained by 
following the dependencies from the subservice representing the service 
instance.

About the base identity for the susbservice types
MED: "Shouldn’t a list of such identities be defined here as well?"
and about the parameters
MED: "Why is this defined as a choice?"

Clarified in concepts before tree diagram that an augmentation is expected for 
each subservice type and that only the service instance type is defined in the 
base model. Clarified in the text after the tree that the parameters choice is 
the place where this augmentation takes place. Also made that choice mandatory 
so that a data instance without an entry in the parameter choice is invalid. 
(The drawback is that subservices that do not need any parameters, should they 
exist, will need to specify an augment with an empty container. At least it 
will be explicit that no parameters are needed.)


About type of the subservice in the model
MED: "Do you need a check to enforce that service instances are modeled as 
particular subservices ... ?"

I don’t think that we can check that. However, each model augmenting the base 
model by defining a new subservice type must also augment the "parameter" 
choice by specifying which parameters are mandatory for that type. In the case 
of service instances, the parameters are indeed mandatory.

About the symptoms start and end date.
MED: "Stop should be > that start."

Actually tried to encode that in a must constraint, but XPATH 1.0 does not have 
any date related function (FYI XPATH 3.0 does!) and I got a yanglint error 
trying to compare strings (luckily because I didn’t realize that 
yang:date-and-time is a string). So I just put that in the description of the 
leaf.

Thanks again for all your reviews.
Best,
Jean


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Tuesday 21 June 2022 09:02
To: Tianran Zhou ; opsawg@ietf.org
Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi all,

Please find below my comments to this version.


  *   pdf: 
https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.doc

I think that some further work is needed.

Cheers,
Med

PS: I didn’t review the appendices.

De : OPSAWG mailto:opsawg-boun...@ietf.org>> De la 
part de Tianran Zhou
Envoyé : mercredi 8 juin 2022 12:04
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline 

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Dhruv Dhody]

Hi WG,

I think this work is very useful. I have some comments (also see my review
of the architecture I-D).

Minor
- In the text of the I-D, we should explain that the symptoms are targeted
at humans and not machines.
- Architecture talks about circular dependencies and states that it is
likely to show up; shouldn't the YANG model add a notification saying
circular dependency detected?
- Security Considerations skips talking about readable leaves.
- For example-service-assurance-device-acme, wouldn't it make more sense to
augment the ietf-service-assurance-device instead of ietf-service-assurance?
- I am wondering what is the best practice for example YANG module -
copyright to IETF, organization, and contact to be IETF? It reads weird esp
for a vendor-specific model example in the appendix A!

Nits
- In the IANA section, the Registrant Contact is mentioned as NETCONF WG.

Thanks!
Dhruv

On Wed, Jun 8, 2022 at 3:34 PM Tianran Zhou  wrote:

> Hi WG,
>
>
>
> This mail we start a two weeks working group last call for
> draft-ietf-opsawg-service-assurance-yang-05.
>
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/
>
>
>
> Please send over your comments before June 22.
>
> Please also indicate if you think this document is ready to progress.
>
>
>
> Cheers,
>
> Tianran, on behalf of chairs
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[mohamed.boucadair]

Hi Jean,

Thank you for the update and the replies.

This version looks better. Please see below some pending comments on -06:


  *   I don’t think that the “id” MUST be globally unique”, but only within a 
domain/network.
  *   Can you please update the description of the “description”/”label” as 
suggested in my previous review. It seems that you retrieved an older version 
of the review files.
  *   You may want add some text to clarify how that version is useful/used.
  *   I do still see some value in allowing assurance-graph-version to be rw. 
This can be, for example, used to force aligning the version among several 
servers that manipulate the same assurance graph. Another usage would be to 
revert or force an assurance graph version. Some change in the structure may be 
needed to manipulate a list of graphs for the same service indexed by their 
version.
  *   A server may manipulate multiple services, and thus multiple service 
assurance graphs are maintained. How these various graphs are 
identified/demuxed?


Cheers,
Med

De : Jean Quilbeuf 
Envoyé : vendredi 24 juin 2022 20:56
À : BOUCADAIR Mohamed INNOV/NET ; Tianran Zhou 
; opsawg@ietf.org
Objet : RE: WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi Med,
thanks again for your very thorough comments on the draft about the YANG 
modules for service assurance. The diff is here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-06

I think that I addressed most of your comments. The main one remaining is:

About maintenance-contact
MED: "Shouldn’t this be an URI?" "A pattern should then be provided to comply 
with this?"

Tried to add a pattern about adding monitor in front:
   pattern "(monitor:)?.*";
The I realized that it does not restrict anything. The description in English 
says what it should be while leaving things open.
We might want to restrict more and I am open to any suggestion.



Below are some answers to most important comments.


Section 3 (ietf-service-assurance) YANG model

About assurance-graph-version counter
MED: "Shouldn’t this version be configurable when a new one is installed?"

That counter should be automatically incremented each time any config node of 
the model is changed, should not be the responsibility of the client. Clarified 
in the text and the YANG model.


About parameters
MED: "I guess this is how you bind a service assurance to a service (or a 
service instance). If so, why isn’t this at the upper level? "

Clarified in the text that service instances are a particular type of 
subsrevice and the link between a service and its graph is obtained by 
following the dependencies from the subservice representing the service 
instance.

About the base identity for the susbservice types
MED: "Shouldn’t a list of such identities be defined here as well?"
and about the parameters
MED: "Why is this defined as a choice?"

Clarified in concepts before tree diagram that an augmentation is expected for 
each subservice type and that only the service instance type is defined in the 
base model. Clarified in the text after the tree that the parameters choice is 
the place where this augmentation takes place. Also made that choice mandatory 
so that a data instance without an entry in the parameter choice is invalid. 
(The drawback is that subservices that do not need any parameters, should they 
exist, will need to specify an augment with an empty container. At least it 
will be explicit that no parameters are needed.)


About type of the subservice in the model
MED: "Do you need a check to enforce that service instances are modeled as 
particular subservices ... ?"

I don’t think that we can check that. However, each model augmenting the base 
model by defining a new subservice type must also augment the "parameter" 
choice by specifying which parameters are mandatory for that type. In the case 
of service instances, the parameters are indeed mandatory.

About the symptoms start and end date.
MED: "Stop should be > that start."

Actually tried to encode that in a must constraint, but XPATH 1.0 does not have 
any date related function (FYI XPATH 3.0 does!) and I got a yanglint error 
trying to compare strings (luckily because I didn’t realize that 
yang:date-and-time is a string). So I just put that in the description of the 
leaf.

Thanks again for all your reviews.
Best,
Jean


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Sent: Tuesday 21 June 2022 09:02
To: Tianran Zhou 
mailto:zhoutianran=40huawei....@dmarc.ietf.org>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi all,

Please find below my comments to this version.


  *   pdf: 
https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ie

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Benoit Claise]

ce where this augmentation 
takes place. Also made that choice mandatory so that a data instance 
without an entry in the parameter choice is invalid. (The drawback is 
that subservices that do not need any parameters, should they exist, 
will need to specify an augment with an empty container. At least it 
will be explicit that no parameters are needed.)


About type of the subservice in the model

MED: "Do you need a check to enforce that service instances are 
modeled as particular subservices ... ?"


I don’t think that we can check that. However, each model augmenting 
the base model by defining a new subservice type must also augment the 
"parameter" choice by specifying which parameters are mandatory for 
that type. In the case of service instances, the parameters are indeed 
mandatory.


About the symptoms start and end date.

MED: "Stop should be > that start."

Actually tried to encode that in a must constraint, but XPATH 1.0 does 
not have any date related function (FYI XPATH 3.0 does!) and I got a 
yanglint error trying to compare strings (luckily because I didn’t 
realize that yang:date-and-time is a string). So I just put that in 
the description of the leaf.


Thanks again for all your reviews.

Best,

Jean

*From:*OPSAWG [mailto:opsawg-boun...@ietf.org 
<mailto:opsawg-boun...@ietf.org>] *On Behalf Of 
*mohamed.boucad...@orange.com

*Sent:* Tuesday 21 June 2022 09:02
*To:* Tianran Zhou ; 
opsawg@ietf.org
*Subject:* Re: [OPSAWG] WGLC for 
draft-ietf-opsawg-service-assurance-yang-05


Hi all,

Please find below my comments to this version.

  * pdf:

https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.pdf
  * doc:

https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.doc

<https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.doc>

I think that some further work is needed.

Cheers,

Med

PS: I didn’t review the appendices.

*De :* OPSAWG  *De la part de* Tianran Zhou
*Envoyé :* mercredi 8 juin 2022 12:04
*À :* opsawg@ietf.org
*Objet :* [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.


https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.

Please also indicate if you think this document is ready to progress.

Cheers,

Tianran, on behalf of chairs

_
  
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.
  
This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Benoit Claise]

Hi Dhruv,

Thanks for reviewing the draft.
See inline.

On 6/26/2022 4:04 PM, Dhruv Dhody wrote:

Hi WG,

I think this work is very useful. I have some comments (also see my 
review of the architecture I-D).


Minor
- In the text of the I-D, we should explain that the symptoms are 
targeted at humans and not machines.
That might be the case now, but this is obviously not the end goal, as 
we want to solve closed loop automation.

So we propose not to mention it.
- Architecture talks about circular dependencies and states that it is 
likely to show up; shouldn't the YANG model add a notification saying 
circular dependency detected?
Next to the notification, the higher level question is: what's happening 
in case of circular dependencies configuration?
So instead of the notification, we might stress in the draft that 
circulation dependencies should be not be accepted by the 
implementation. Btw, that's something we can't impose from a YANG 
language point of view.



- Security Considerations skips talking about readable leaves.
Thanks. We're going to review this section according to 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines


- For example-service-assurance-device-acme, wouldn't it make more 
sense to augment the ietf-service-assurance-device instead of 
ietf-service-assurance?
Yes, we could. Actually, it depends whether the 
ietf-service-assurance-device is generic enough. As this is an example, 
we propose not to change that. We could add: "it's an implementation 
choice to either augment the identity from ietf-service-assurance or to 
augment the parameters from ietf-service-assurance-device"
- I am wondering what is the best practice for example YANG module - 
copyright to IETF, organization, and contact to be IETF? It reads 
weird esp for a vendor-specific model example in the appendix A!

https://www.rfc-editor.org/rfc/rfc8407.html#section-3.2.1 is not clear.
Good point. Let's remove the IETF references.


Nits
- In the IANA section, the Registrant Contact is mentioned as NETCONFWG.

Well spot.

Regards, Benoit

Thanks!
Dhruv

On Wed, Jun 8, 2022 at 3:34 PM Tianran Zhou 
 wrote:


Hi WG,

This mail we start a two weeks working group last call for
draft-ietf-opsawg-service-assurance-yang-05.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.

Please also indicate if you think this document is ready to progress.

Cheers,

Tianran, on behalf of chairs

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[Dhruv Dhody]

Hi Benoit,

On Tue, Jun 28, 2022 at 7:16 PM Benoit Claise 
wrote:

> Hi Dhruv,
>
> Thanks for reviewing the draft.
> See inline.
>
> On 6/26/2022 4:04 PM, Dhruv Dhody wrote:
>
> Hi WG,
>
> I think this work is very useful. I have some comments (also see my review
> of the architecture I-D).
>
> Minor
> - In the text of the I-D, we should explain that the symptoms are targeted
> at humans and not machines.
>
> That might be the case now, but this is obviously not the end goal, as we
> want to solve closed loop automation.
> So we propose not to mention it.
>

Dhruv: Ok. I wonder if "string" is the best way to model symptoms in that
case. I understand that having an identity for all possible symptoms would
be challenging. Perhaps a mix of some well-known symptoms plus the current
free-form! I will leave that for you to do the right thing as you are the
expert here :)

- Architecture talks about circular dependencies and states that it is
> likely to show up; shouldn't the YANG model add a notification saying
> circular dependency detected?
>
> Next to the notification, the higher level question is: what's happening
> in case of circular dependencies configuration?
> So instead of the notification, we might stress in the draft that
> circulation dependencies should be not be accepted by the implementation.
> Btw, that's something we can't impose from a YANG language point of view.
>
>
Dhruv: I am fine with that and the rest of your responses!

Thanks!
Dhruv

- Security Considerations skips talking about readable leaves.
>
> Thanks. We're going to review this section according to
> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
>
> - For example-service-assurance-device-acme, wouldn't it make more sense
> to augment the ietf-service-assurance-device instead of
> ietf-service-assurance?
>
> Yes, we could. Actually, it depends whether the ietf-service-assurance-device
> is generic enough. As this is an example, we propose not to change that. We
> could add: "it's an implementation choice to either augment the identity
> from ietf-service-assurance or to augment the parameters from
> ietf-service-assurance-device"
>
> - I am wondering what is the best practice for example YANG module -
> copyright to IETF, organization, and contact to be IETF? It reads weird esp
> for a vendor-specific model example in the appendix A!
>
> https://www.rfc-editor.org/rfc/rfc8407.html#section-3.2.1 is not clear.
> Good point. Let's remove the IETF references.
>
>
> Nits
> - In the IANA section, the Registrant Contact is mentioned as NETCONF WG.
>
> Well spot.
>
> Regards, Benoit
>
> Thanks!
> Dhruv
>
> On Wed, Jun 8, 2022 at 3:34 PM Tianran Zhou  40huawei@dmarc.ietf.org> wrote:
>
>> Hi WG,
>>
>>
>>
>> This mail we start a two weeks working group last call for
>> draft-ietf-opsawg-service-assurance-yang-05.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/
>>
>>
>>
>> Please send over your comments before June 22.
>>
>> Please also indicate if you think this document is ready to progress.
>>
>>
>>
>> Cheers,
>>
>> Tianran, on behalf of chairs
>>
>>
>> ___
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
>
> ___
> OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[mohamed.boucadair]

Hi Benoit,

Please see inline.

Cheers,
Med

De : Benoit Claise 
Envoyé : mardi 28 juin 2022 15:33
À : BOUCADAIR Mohamed INNOV/NET ; Jean Quilbeuf 
; Tianran Zhou 
; opsawg@ietf.org
Objet : Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi Med,

Thanks again.
See inline for some points
On 6/27/2022 10:44 AM, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:
Hi Jean,

Thank you for the update and the replies.

This version looks better. Please see below some pending comments on -06:


  *   I don’t think that the “id” MUST be globally unique”, but only within a 
domain/network.
I understand your logic. However, the YANG assurance graph between different 
domains can be connected... and we expect they will connected in the future 
(core, DC, etc..)
[Med] Yes, I had that in mind as well. I assumed that some coordination will be 
in place so that SAIN agents generate non-conflicting ids even within a single 
network. Local uniqueness may be ensured by a variety of means (concatenate an 
id generated by a SAIN agent and its identity, timestamping, etc.).


Therefore, it makes sense to have globally unique Ids
[Med] If this is justified, I’m afraid that a mechanism to ensure such a 
uniqueness + the behavior when a conflict is detected should be called out.


  *   Can you please update the description of the “description”/”label” as 
suggested in my previous review. It seems that you retrieved an older version 
of the review files.
  *   You may want add some text to clarify how that version is useful/used.
  *   I do still see some value in allowing assurance-graph-version to be rw. 
This can be, for example, used to force aligning the version among several 
servers that manipulate the same assurance graph. Another usage would be to 
revert or force an assurance graph version. Some change in the structure may be 
needed to manipulate a list of graphs for the same service indexed by their 
version.
I have to push back on this one.
We already have some issues regarding the source of truth in networking.
By adding the ability to configure the assurance-graph-version, we're going to 
add to the complexity. What does it mean in terms of intent?

[Med] What is authoritative is still the characterization in terms of 
subservices and dependencies. You may, for example, bump the version but the 
characterization is still the same so that all your controllers are in sync.

If you configure an old assurance graph version, does it mean that you want to 
network to go back to this old version?
[Med] Explicitly configuring an assurance graph can be a corrective action to a 
graph that was automatically generated. If we assume that explicitly configured 
graphs will take precedence, there are no implications on the service itself.

If you configure an new assurance graph version, does it mean that you know 
better than the SAIN architecture and that you impose it?
[Med] Yes. The SAIN orchestrator knowledge is (and will be) limited.


  *   A server may manipulate multiple services, and thus multiple service 
assurance graphs are maintained. How these various graphs are 
identified/demuxed?
Actually, a server maintains one graph, composed of all the service instances.
[Med] Yes, I got that. My comment is that don’t see how we can retrieve the 
assurance graph of a specific service type (e.g., EVPN or L3VPN) using the 
current structure. Thanks.

We explained this at the end of Section 3.1
By specifying service instances and their dependencies in terms of
subservices, one defines a global assurance graph. That assurance
graph is the result of merging all the individual assurance graphs
for the assured service instances. Each subservice instance is
expected to appear only one in the global assurance graph even if
several service instances depend on it. For example, an instance of
the device subservice is a dependency of every service instance that
rely on the corresponding device. The assurance graph of a specific
service instance is the subgraph obtained by traversing the global
assurance graph through the dependencies starting from the specific
service instance.
Thanks and Regards, Benoit



Cheers,
Med

De : Jean Quilbeuf <mailto:jean.quilb...@huawei.com>
Envoyé : vendredi 24 juin 2022 20:56
À : BOUCADAIR Mohamed INNOV/NET 
<mailto:mohamed.boucad...@orange.com>; Tianran 
Zhou 
<mailto:zhoutianran=40huawei@dmarc.ietf.org>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Objet : RE: WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi Med,
thanks again for your very thorough comments on the draft about the YANG 
modules for service assurance. The diff is here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-06

I think that I addressed most of your comments. The main one remaining is:

About maintenance-contact
MED: "Shouldn’t this be an URI?" "A pattern should then be provided to comply 
with this?"