From: Jean Quilbeuf <[email protected]> Sent: 21 April 2022 12:58 To: Joe Clarke (jclarke); [email protected]; tom petch; Benoit Claise; [email protected] Subject: RE: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance-yang-02
Dear All, Thanks to Tom and Med for the comments. Here are answers to Med's comments that I am not sure of addressing properly: > > * I'm still not sure why this is restricted to "Intent-based Networking > Architecture" in the abstract. Reformulated: 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. > > * Move Section I to be positioned right after Section II Terminology is now section 1.1 part of the Introduction > > * not sure what is the rationale for having only one address per device, two > devices, why not a name is used to identify a device, etc. (Section 8.1). It > seems this about unicast connectivity, and not cover multicast. > > * Why only IS-IS is covered? I put IS-IS and IP connectivity as examples now, just to match the example from the architecture draft. I think defining the assurance subservices for other parts than device and interface should be done in other drafts. Here are the answers to Tom's comment that I am not sure to be addressing properly. > >> > >> This is the first module I can recall where the prefix is longer than > >> any of the identifiers that are prefixed. 'service-assurance- > >> interface:' does not make for an easy read IMHO. Changed the prefixes to sain- > >> - TLP ood Updated the date and "Simplified" -> "Revised" > >> - string with no indication of acceptable characters sometimes > >> attracts a DISCUSS Do you have a YANG type in mind? It's kind of hard to list the allowed of forbidden characters for any device name or any interface name. Maybe there are some obvious ones to forbid? <tp> No. SMI had a type but it was not carried across to YANG. A recent comment on readable text came from Francesca in the IESG review of I2NSF-nsf-facing... on 16feb22 (and it is not the only one:-) which led to language tags and the reference to RFC2277 in the current version of that I-D. I was surprised by the comment and have not got my mind around how widely that concept should be applied. Think Unicode and there are thousands of human-readable characters. My e-mail has decided to display the identifier of some senders in Chinese characters which may help a few billion people but not me:-( Tom Petch Note that according to sec. 9.4 in RFC 7950 "The string built-in type represents human-readable strings in YANG." Thanks again for the comments, please let me know any suggestion. Best regards, Jean > >> > >> Tom Petch > >> > >> > >> Regards, Benoit > >> > >> On 3/25/2022 11:48 AM, Jean Quilbeuf wrote: > >>> Hi Joe, > >>> Thanks for your comments. > >>> > >>> I updated the draft with some more details about the relation > >>> between > >> healt-score and health-score-weight. > >>> I left the counter so far, but changed it to 64 bits. > >>> > >>> Best, > >>> Jean > >>> > >>>> -----Original Message----- > >>>> From: Joe Clarke (jclarke) [mailto:[email protected]] > >>>> Sent: Thursday 24 March 2022 12:42 > >>>> To: Benoit Claise <[email protected]>; Jean > >>>> Quilbeuf <[email protected]>; [email protected] > >>>> Subject: Re: [OPSAWG] Comments on > >>>> draft-ietf-opsawg-service-assurance- > >>>> yang-02 > >>>> > >>>> On 3/24/22 08:21, Benoit Claise wrote: > >>>>> Hi Joe, > >>>>> > >>>>> On 3/24/2022 11:48 AM, Joe Clarke (jclarke) wrote: > >>>>>> On 3/9/22 11:13, Jean Quilbeuf wrote: > >>>>>>> Hi Joe, > >>>>>>> Thanks for your comments. > >>>>>>> > >>>>>>> > >>>>>>>> First, what is the purpose of assurance-graph-version? It's a > >>>>>>>> 32-bit > >>>> counter that can increment when something goes in and out of > >>>> maintenance (+2). I can easily see this wrapping fir services with > >>>> a lot of churn. What is the impact of that? Is this version > >>>> number required if we have a last modified timestamp? > >>>>>>> The purpose of assurance-graph-version is to enable a consumer > >>>>>>> of this > >>>> module to quickly check if they have the last version. It probably > >>>> makes sense to use a larger counter. I'll modify it. > >>>>>> How does it do that. If I get a version of 324523457273456, how > >>>>>> do I know that's the latest? > >>>>> MdT on-change. > >>>> Fair. But then, as a consumer, I know it's the latest because it's > >>>> the update I just got. And still, the date will be more useful... > >>>> > >>>> I know I'm being difficult and bike-sheddy. It doesn't really > >>>> bother me. Just trying to make sure there's true use for it. > >>>> > >>>> Joe > >>>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/opsawg > >>> . > >> _______________________________________________ > >> OPSAWG mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/opsawg > >> > >> _______________________________________________ > >> OPSAWG mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/opsawg > > > __________________________________________________________ > ____________ > > ___________________________________________________ > > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
