From: Jean Quilbeuf <jean.quilb...@huawei.com> Sent: 29 April 2022 17:19
Dear Tom, Thank you very much for your comments. Here is the updated version: URL: https://www.ietf.org/archive/id/draft-ietf-opsawg-service-assurance-yang-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-yang Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-05 The main changes were to remove the guidelines section and move the example modules to the informative section. I also fixed some issues such as the prefixes in IANA section and some minor text edits. <tp> Looks good. You probably know that going forward there needs to be just the one Revision statement in each module so at some stage all the others must come out. I have some thoughts on the YANG but would like to see a YANG Doctor review first so as not to contradict them:-) I note the absence of a definition of 'service' which I find problematic.. That probably ought to be in -architecture but I see no sign thereof. Service for me is part of a Service Level Agreement but your usage seems different. Tom Petch Thanks again, Jean > -----Original Message----- > From: tom petch [mailto:ie...@btconnect.com] > Sent: Friday 29 April 2022 12:07 > To: Jean Quilbeuf <jean.quilb...@huawei.com>; opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance- > yang-04.txt > > From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Jean Quilbeuf > <jean.quilbeuf=40huawei....@dmarc.ietf.org> > Sent: 25 April 2022 18:37 > > Dear All, > This new version of the draft addresses the comments from Tom Petch and > Mohamed Boucadair. Thanks again for their reviews. > > <tp> > mmmmm I see a structural problem that I think will confuse users. > > IANA Considerations (where I start) registers three YANG module which is > not fine; the prefix definitions are a nonsense. When I turn to the body of > the I-D, which by default is Normative, I find six YANG modules only three of > which are in IANA Considerations and so exist. I think that this will > confuse. > > What I see (all?) other authors do is put examples in Appendices which by > convention are Informative. Often the explanatory text is there too since it > too is mostly or all Informative. I think that at least the three example > modules should be in Appendices A. B. C. - I would put them before the > sample protocols. Some text likely belongs in the Normative part of the > document but only what is Normative, what someone creating an extension > SHOULD or MAY or MUST do when creating an extension; details of what to > do with a specific extension e.g. OSPF belong in the Appendix IMO. > > Section 8 should not exist. The IETF has rules about names of IETF and non- > IETF work and they should not be here. Rather this I-D should reference > those rules, if it needs to; many YANG modules expect vendors to augment > them and I cannot recall any other I-D including such guidance. Vendors > need to know what they are doing > > I note in passing > > The second YANG module, ietf-service-assurance-device, extends > > The third YANG module, ietf-service-assurance-device, is another > > Like I said, may cause confusion. > > Tom Petch > > Best, > Jean > > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of internet- > > dra...@ietf.org > > Sent: Monday 25 April 2022 18:32 > > To: i-d-annou...@ietf.org > > Cc: opsawg@ietf.org > > Subject: [OPSAWG] I-D Action: > > draft-ietf-opsawg-service-assurance-yang- > > 04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Operations and Management Area > > Working Group WG of the IETF. > > > > Title : YANG Modules for Service Assurance > > Authors : Benoit Claise > > Jean Quilbeuf > > Paolo Lucente > > Paolo Fasano > > Thangam Arumugam > > Filename : draft-ietf-opsawg-service-assurance-yang-04.txt > > Pages : 45 > > Date : 2022-04-25 > > > > Abstract: > > This document specifies YANG modules representing assurance graphs. > > These graphs represent the assurance of a given service by > > decomposing it into atomic assurance elements called subservices. A > > companion RFC, Service Assurance for Intent-based Networking > > Architecture, presents an architecture for implementing the assurance > > of such services. > > > > The YANG data models in this document conforms to the Network > > Management Datastore Architecture (NMDA) defined in RFC 8342. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-y > > ang/ > > > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assura > > nce-yang-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance- > > yang-04 > > > > > > Internet-Drafts are also available by rsync at > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > 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
