From: Jean Quilbeuf <jean.quilb...@huawei.com> Sent: 22 April 2022 14:14
> -----Original Message----- > From: tom petch [mailto:ie...@btconnect.com] > Sent: Thursday 21 April 2022 17:04 > To: Jean Quilbeuf <jean.quilb...@huawei.com>; Joe Clarke (jclarke) > <jclarke=40cisco....@dmarc.ietf.org>; mohamed.boucad...@orange.com; > Benoit Claise <benoit.cla...@huawei.com>; opsawg@ietf.org > Subject: Re: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance- > yang-02 > > > <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 Thanks for the precision. I am wondering whether to add a grouping such as grouping natural-language-text { description "Represents text written in natural language. According to RFC 2277, such strings MUST be accompanied with a language-tag specifying the language of the text"; leaf language-tag { type string; mandatory true; description "Tag representing the language of the text. The tag format is described in RFC 5646."; } leaf text { type string; mandatory true; description "The actual text, must be written in the language specified in language tag."; } } According to YANG catalog there are less than 10 nodes who refer to RFC 5646, so it does not seem like a common practice. So I think I would leave the strings as they are now. Any suggestions? Also, it seems like a generic problem that should be solved in the WG that takes care of YANG. <tp> That would be the NETMOD WG where the subject comes up but does not get worked on:-( I agree that language tags are not common practice so I would be inclined not to include them but it may be that our current IESG will take a firmer line, in which case you are fore-warned. Sometimes a protocol I-D, nothing to do with YANG, will reference Unicode as to what can appear but as I said before, there is an awful lot of Unicode and it is hard to know where to draw the line Tom Petch Best, Jean > > 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:jcla...@cisco.com] > > >>>> Sent: Thursday 24 March 2022 12:42 > > >>>> To: Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org>; > > >>>> Jean Quilbeuf <jean.quilb...@huawei.com>; opsawg@ietf.org > > >>>> 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 > > >>> 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 > > > > > > __________________________________________________________ > > ____________ > > > ___________________________________________________ > > > > > > 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
