Paul, thank you for your review. I have entered a No Objection ballot for this document.
Lars > On Nov 18, 2022, at 16:55, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > [Resending to include the wg and last-call.] > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-opsawg-service-assurance-architecture-11 > Reviewer: Paul Kyzivat > Review Date: 2022-11-15 > IETF LC End Date: 2022-11-20 > IESG Telechat date: ? > > Summary: > > This draft is on the right track but has open issues, described in the review. > > Issues: 1 > Nits: 8 > > 1) ISSUE: Section 3.6: ambiguity > > As best I understand the text "Under Maintenance" is being used in two > different ways that can cause ambiguity: > > - "When a service or subservice is flagged as under maintenance, it must > report a generic "Under Maintenance" symptom, for propagation towards > subservices that depend on this specific subservice: any other symptom from > this service, or by one of its impacting dependencies must not be reported." > > - " In more complex cases, for instance with a primary and backup path ... > In such cases, the status of the service instance might include the "Under > Maintenance" as well as other symptoms (e.g. from the backup path)" > > In the latter case, if nothing is wrong with the backup path then there might > only be the "Under Maintenance" from the primary path, and it would be > indistinguishable from a case where there was no backup path. > > IIUC it is important that these cases be distinguishable. > > > 2) NIT: Section 3: missing word > > "Based on the service configuration provided by the service orchestrator, the > SAIN orchestrator decomposes the assurance graph. It then sends to the SAIN > agents the assurance graph along some other configuration options." > > s/along some other/along with some other/ > > > 3) NIT: Section 3.3.3: Improper DNS name in example > > "Assume that we want to assure a kubernetes cluster https://kubernetes.io."; > > Examples like this should only use DNS domains intended for examples, such as > kubernetes.example.org. > > > 4) NIT: Section 3.1.1: missing word > > "The status of a should depend on the status of c, d, e, f, g, and h" > > s/status of a should/status of a ???? should/ > > > 5) NIT: Section 3.6: confusing wording > > "Symptoms related to the device-specific subservices, such as the interfaces, > might be ignored as well as their state changes is probably the consequence > of the maintenance." > > Hard to parse. Does the following work? > > "Symptoms related to the device-specific subservices, such as the interfaces, > might also be ignored because their state changes are probably the > consequence of the maintenance." > > > 6) NIT: Section 3.6: punctuation > > Odd punctuation in: > > "... subservices that depend on this specific subservice: any other symptom > ..." > > I think this would be better as two sentences: > > "... subservices that depend on this specific subservice. Any other symptom > ..." > > > 7) NIT: Section 3.7: bad syntax > > Syntax problems with: > > "One of them is the domain of service management on network elements, with > also requires its own assurance." > > Does the following express the intent? > > "One of them is the domain of service management on network elements, that > also require their own assurance." > > > 8) NIT: Section 3.7: awkward language > > The following language is quite awkward: > > " Exactly like ... > , exactly like ... > , exactly like ... > . Exactly like ... . > > I suggest breaking this out as a list. > > > 9) NIT: Section 3.9: unusual language > > The following is IMO unusual phrasing: > > "The assurance graph will change along the time" > > I think the following would be a better phrasing: > > "The assurance graph will change over time" > > > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
