Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06 Wed, 07 October 2020 06:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6B303A1556; Tue, 6 Oct 2020 23:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j00Ss8WLkK4l; Tue, 6 Oct 2020 23:09:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B07913A1128; Tue, 6 Oct 2020 23:09:11 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4C5kS61HkJz20CF; Wed, 7 Oct 2020 08:09:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1602050950; bh=tK35uhiD0DM6KcjDtmuDBKF+vjtpvG3tJ6I3YZlqXaQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=GcXL/54x3oeFSn1cvezTvOMvlKodFrv2NlRKtkmp+Ti1qUZj3BCD0GDmO63GsLS28 cIQcWitysHaDZA1y57By6O1WnIattVKzlFbMNuYWXCRN8nFnbYX8ACgVI+yogEdcyV skBz9Ena/AZ5DV62TN7W/tY/khr3kyWMR6eDqlXpMVeomx0F6DLK//nEfR5jjA6k7I Q9yTDykAaMWi+vOp2vE66+Mr2jBvLzoFN+MGiRc1Rnf5W+hmi+zmntgbLTcfci+gGI a2SwWs3sNj4SfJbu6pL2YCjKvdFals7OuInAGbYGsl9Hu2bJqdUw7WilhjDQLi+jAt 8eRKgtNfiauIg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4C5kS571jczDq7p; Wed, 7 Oct 2020 08:09:09 +0200 (CEST)
From: <>
To: Tommy Pauly <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06
Thread-Index: AQHWm/wtBsnkS2MHkUuoHb7HV/3vbamLn84w
Date: Wed, 7 Oct 2020 06:09:09 +0000
Message-ID: <29937_1602050950_5F7D5B86_29937_206_1_787AE7BB302AE849A7480A190F8B93303154E239@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OPSAWG] Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Oct 2020 06:09:14 -0000

Hi Tommy, 

Thank you for the review. 

Please see inline. 


> -----Message d'origine-----
> De : Tommy Pauly via Datatracker []
> Envoyé : mardi 6 octobre 2020 18:17
> À :
> Cc :;; draft-ietf-opsawg-model-
> 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 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
> (
> metrics.xhtml,
> draft-ietf-ippm-metric-registry, draft-ietf-ippm-initial-registry).

[Med] Happily. I made this change: 

   o  the traffic performance guarantees (One-Way Delay (OWD) [RFC7679],
      One-Way Loss [RFC7680], ...),

   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

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