Hi Paul, Thanks for your review. We tried to address your comments, see our answers inline. The diff is here: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-12 Best, Jean > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxxxxx] > Sent: Friday 18 November 2022 14:56 > To: draft-ietf-opsawg-service-assurance-architecture.all@xxxxxxxx > Cc: General Area Review Team <gen-art@xxxxxxxx>; opsawg@xxxxxxxx; last- > call@xxxxxxxx > Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-service- > assurance-architecture-11 [RESEND] > > [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. > Rewrote the paragraph, hopefully making it clear that these cases can be distinguished: In each example above, the subservice under maintenance is completely impacting the service instance, putting it under maintenance as well. There are use cases where the subservice under maintenance only partially impacts the service instance. For instance, consider a service instance supported by both a primary and backup path. If a subservice impacting the primary path is under maintenance, the service instance might still be functional but degraded. In that case, the status of the service instance might include "Primary path Under Maintenance", "No redundancy" as well as other symptoms from the backup path to explain the lower health score. In general, the computation of the service instance status from the subservices is done in the SAIN collector whose implementation is out of scope for this document. > > 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/ > Done > > 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. > Removed mention to kubernetes as suggested in Tsvart. > > 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/ Fixed => status of node 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." > Done > > 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 ..." Done > > 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." > Done > > 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. > Done > > 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" > > Done > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
