[OPSAWG] Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06
Tommy Pauly via Datatracker <firstname.lastname@example.org> Tue, 06 October 2020 16:17 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3677B3A1495; Tue, 6 Oct 2020 09:17:22 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Tommy Pauly via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Tommy Pauly <email@example.com>
Date: Tue, 06 Oct 2020 09:17:22 -0700
Subject: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2020 16:17:22 -0000
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 firstname.lastname@example.org 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). 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? 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”? I also agree with Christian’s secdir review comments, particularly with the number of referenced documents and dependencies.
- [OPSAWG] Tsvart last call review of draft-ietf-op… Tommy Pauly via Datatracker
- Re: [OPSAWG] Tsvart last call review of draft-iet… mohamed.boucadair