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? It seems to me the date is as useful as that number. I still don't _know_ I have the latest version, but I can be more confident if I have one from a couple of seconds ago, it's recent. > > >> Second, is it intended that health-score-weight of all symptoms' health >> score weights for a given subservice add to 100? If so, that is not clearly >> stated. I guess I'm wondering what this might look like in practice if I >> have a degraded subservice with health 50 and two symptoms of weight 10 and >> 20 respectively. Obviously, I would look at weight 20 first, but I might >> then wonder if something unseen is also affecting my subservice. > For now, the relation between symptoms weights (health-score-weight) and > health score is that a health score that is not optimal must be explained by > at least one symptom with a weight greater than 0. > It's also stated that the weight of the symptom is the impact incurred on the > health score when the symptom is present, without précising what "incurred" > means. > > To state think more clearly, we could define the health score as a function > of the symptom weights, for instance health-score = max(0, 100 - > sum(symptoms/health-score-weight)), but I am not sure that such a function is > generic enough to be part of the draft. Understood. Though this might make could implementor considerations as potential ways to do this. > > The advantage of the current version is that we state that there is a > relationship between the symptoms weights and the subservice health score, > but we don't enforce the exact relation. We can also sort the symptoms by > weight to know the most impacting one. > > What do you think about adding the example above and stating that the > relationship between the symptoms weights and the final health score is left > to the implementation of the agent? Would that make things clearer? Yes. Offering some insight into how to best implement and then make use of this would be much appreciated. Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
