Subject: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06

From: Tommy Pauly via Datatracker <[email-masked]>
Date: Tue, 06 Oct 2020 09:17:22 -0700

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
[email-masked] 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.

---

From: <[email-masked]>
Date: Wed, 7 Oct 2020 06:09:09 +0000

Hi Tommy, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Tommy Pauly via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 6 octobre 2020 18:17
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-opsawg-model-
> [email-masked]
> Objet : Tsvart last call review of draft-ietf-opsawg-model-
> automation-framework-06
> 
> Reviewer: Tommy Pauly
> 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 [email-masked] 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
> draft-ietf-ippm-metric-registry, draft-ietf-ippm-initial-registry).

[Med] Happily. I made this change: 

OLD:

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:
> 
> 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

[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.