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 <jean.quilb...@huawei.com> Envoyé : vendredi 24 juin 2022 20:56 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org>; 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 <zhoutianran=40huawei....@dmarc.ietf.org<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-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 <opsawg-boun...@ietf.org<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 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
