Hi Éric, Thank you for the comments.
Please see inline. I let my co-authors further comment as appropriate. Cheers, Med > -----Message d'origine----- > De : Éric Vyncke via Datatracker <nore...@ietf.org> > Envoyé : mardi 18 octobre 2022 08:03 > À : The IESG <i...@ietf.org> > Cc : draft-ietf-opsawg-yang-vpn-service...@ietf.org; opsawg- > cha...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk; > adr...@olddog.co.uk > Objet : Éric Vyncke's No Objection on draft-ietf-opsawg-yang-vpn- > service-pm-13: (with COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-opsawg-yang-vpn-service-pm-13: No Objection > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > positions/ > for more information about how to handle DISCUSS and COMMENT > positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn- > service-pm/ > > > > ------------------------------------------------------------------ > ---- > COMMENT: > ------------------------------------------------------------------ > ---- > > > # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-yang-vpn- > service-pm-13 > CC @evyncke > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies > would be > appreciated even if only for my own education), and some nits. > > Special thanks to Adrian Farrel for the shepherd's detailed write- > up including > the WG consensus *and* the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS > > ### Relationship with other OPSAWG documents > > Just curious: it this work somehow related to > draft-ietf-opsawg-service-assurance-architecture ? I.e., should > this document > add some reference to the service assurance I-Ds ? [Med] Both drafts refer to RFC8969 which provides the overall framework. The assurance draft defines an architecture that can consume the data exposed by means of I-D.ietf-opsawg-yang-vpn-service-pm. I-D.ietf-opsawg-yang-vpn-service-pm does not assume nor preclude that SAIN is in place. If I have to make a change, I would make it in draft-ietf-opsawg-service-assurance-architecture, e.g., OLD: Service orchestrators use Network service YANG modules that will infer network-wide configuration and, therefore the invocation of the appropriate device modules (Section 3 of [RFC8969]). Knowing that a configuration is applied doesn't imply that the service is up and running as expected. For instance, the service might be degraded because of a failure in the network, the experience quality is distorted, or a service function may be reachable at the IP level but does not provide its intended function. Thus, the network operator must monitor the service operational data at the same time as the configuration (Section 3.3 of [RFC8969]). To feed that task, the industry has been standardizing on telemetry to push network element performance information. NEW: Service orchestrators use Network service YANG modules that will infer network-wide configuration and, therefore the invocation of the appropriate device modules (Section 3 of [RFC8969]). Knowing that a configuration is applied doesn't imply that the service is up and running as expected. For instance, the service might be degraded because of a failure in the network, the experience quality is distorted, or a service function may be reachable at the IP level but does not provide its intended function. Thus, the network operator must monitor the service operational data at the same time as the configuration (Section 3.3 of [RFC8969]). To feed that task, the industry has been standardizing on telemetry to push network element performance information (e.g., [I-D.ietf-opsawg-yang-vpn-service-pm]). > > ### Section 2.1 > > As 'PE' is defined, I was also expecting to see 'CE' (notably used > in section > 4.1) and 'P' (notably used in section 4.3). > [Med] OK > ### Section 3 > > Suggest to explain why in `Models are key for automating network > management > operations.`. [Med] RFC8969 provides a detailed discussion about this. I suggest to make this change: OLD: Models are key for automating network management operations. According to [RFC8969], together with service and network models, performance measurement telemetry models are needed to monitor network performance to meet specific service requirements (typically captured in an SLA). NEW: Models are key for automating network management operations (Section 3 of [RFC8969]). Particularly, together with service and network models, performance measurement telemetry models are needed to monitor network performance to meet specific service requirements (typically captured in an SLA). > > ### Section 4 > > Unsure about the value of figure 2, but feel free to keep it (this > is a matter > of taste). [Med] This can be removed, IMO. > > ### Section 4.3 > > Just curious about why `mac-num-limit` is used rather than > `maximum-mac-entries` for consistency with the previous entries? [Med] Good catch. I suggest we go for "limit-number" to be consistent with this part from RFC8407: "Child nodes within a container or list SHOULD NOT replicate the parent identifier" > > ### Section 4.4 > > Would it be useful to split `inbound-non-unicast` into broadcast > and multicast ? > [Med] This was raised also by Rob during his review (https://mailarchive.ietf.org/arch/msg/opsawg/bGqJ7V2EvVzJv7H-Xi2Y-jIOsKw/). Please search for "bum". > ## NITS [Med] Thanks for catching those. Will be fixed. Thanks. > > ### Space after ':' > > It would nicer if there was a space character after several ':'. > > ### Section 4.4 > > s/updatd/updated/ > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You > can use the > [`ietf-comments` tool][ICT] to automatically convert this review > into > individual GitHub issues. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > > _________________________________________________________________________________________________________________________ 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
