Hi Tommy, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Tommy Pauly via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : mardi 6 octobre 2020 18:17 > À : tsv-art@xxxxxxxx > Cc : last-call@xxxxxxxx; opsawg@xxxxxxxx; draft-ietf-opsawg-model- > automation-framework.all@xxxxxxxx > Objet : Tsvart last call review of draft-ietf-opsawg-model- > automation-framework-06 > > Reviewer: Tommy Pauly > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review > team's ongoing effort to review key IETF documents. These comments > were written primarily for the transport area directors, but are > copied to the document's authors and WG to allow them to address any > issues raised and also to the IETF discussion list for information. > > When done at the time of IETF Last Call, the authors should consider > this review as part of the last-call comments they receive. Please > always CC tsv-art@xxxxxxxx if you reply to or forward this review. > > This document describes an architecture for using YANG models in > with automated networks and services. The details of delivery (such > as over L2 or L3 VPNs) is not discussed in detail, and transport- > specific details of that delivery seem out of scope for this > document. The primary intersection of this work with the Transport > Area is the integration with IPPM specifications and YANG modules. > > Section 3.1 references several IPPM specifications (One-Way > Delay/Loss metrics, and Link Capacity). It may be good to reference > the new IPPM registries for metrics, which are currently in AUTH48 > (https://www.iana.org/assignments/performance-metrics/performance- > metrics.xhtml, > draft-ietf-ippm-metric-registry, draft-ietf-ippm-initial-registry). [Med] Happily. I made this change: OLD: o the traffic performance guarantees (One-Way Delay (OWD) [RFC7679], One-Way Loss [RFC7680], ...), NEW: o the traffic performance guarantees expressed using metrics such as One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]. A summary of performance metrics maintained by IANA can be found in [IPPM]. > Also as a nit, the link for “I-D.ietf-ippm-capacity-metric-method” > doesn’t seem to be a live hyperlink. > > I am also a bit unclear about the way that these metrics are > referenced. The relevant text is: > > For example, the service level > can be used to characterise the network service(s) to be ensured > between service nodes (ingress/egress) such as: > … > o the traffic performance guarantees (One-Way Delay (OWD) > [RFC7679], > One-Way Loss [RFC7680], ...), > o link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method], > > This is the first place that “service level” is used as a term. > Should this be “Service Model” as is used earlier in the paragraph? [Med] I agree this is confusing as "service level" is not yet introduced (see Figure 4, for example). I made this change: s/the service level/Service Models > It also seems a bit problematic to reference these link metrics as > “guarantees”; these metrics are used to represent empirical > measurements, but cannot guarantee behavior of a link. Could we > replace “guarantees” and “ensures” with other words, such as > “expected”/“expectations”? [Med] We use "guarantees" as this is frozen in a service level agreement where penalties may also be defined to cover cases where perceived/delivered is not matching what is guaranteed (and thus expected :-)). Guaranteed values can be: max OWD, min OWL, etc. We need to reflect that commitment is "hard" and not only "loose". > > I also agree with Christian’s secdir review comments, particularly > with the number of referenced documents and dependencies. > [Med] Please note that there is no normative dependency on drafts. _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
