Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT) Wed, 21 October 2020 06:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A96B3A107C; Tue, 20 Oct 2020 23:10:06 -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 lD9pBxBlAXk6; Tue, 20 Oct 2020 23:10:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B6CA3A107B; Tue, 20 Oct 2020 23:10:04 -0700 (PDT)
Received: from (unknown [xx.xx.xx.71]) by (ESMTP service) with ESMTP id 4CGKpf5FyYz61YT; Wed, 21 Oct 2020 08:10:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1603260602; bh=hoWwFHnz6ilgjHoFJ+hq521lMlxLxN6KLTp4eS73xoI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Ay4dqfmNzY1uGhXYAUbOI+5D7zTp/2MenAnhiih3PLb7yklnEU5A8OJSfkPDQItSD r6WnBQuQcT4WEwBj7CVVR8A3CqJRararwMpq2WKemNbL28OAIOozjGctPIKTaTZ4ZD cj1chmPMsTRvqQJDMzdBv8hjD60NPnwbkJifT8mUrMvbHMH4h3j33DjJNXAjwq7gfe d/zY4m4pWR4HMLY1vuN17BNFbC6h/zpv25WpJIdxUqZhgI/orCk5wmcl5iUMBoQ9ce o0Jl8i29n6s4W+Y9XttbHC6yAPMRbxQFggKotcD5J55b2cam8H3+aDdG8+s8ZLw3tn ah6TfBxAX/m4w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by (ESMTP service) with ESMTP id 4CGKpf4QprzFpXs; Wed, 21 Oct 2020 08:10:02 +0200 (CEST)
From: <>
To: Roman Danyliw <>, The IESG <>
CC: "" <>, "" <>, "" <>, Adrian Farrel <>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
Thread-Index: AQHWpx+bRqv60pM3uk+t1lz3bQadPqmhhHfg
Date: Wed, 21 Oct 2020 06:10:02 +0000
Message-ID: <29041_1603260602_5F8FD0BA_29041_129_1_787AE7BB302AE849A7480A190F8B93303156415A@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] Roman Danyliw's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
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, 21 Oct 2020 06:10:07 -0000

Hi Roman, 

Thank you for the comments. Most of them are addressed in

Please see inline. 


> -----Message d'origine-----
> De : Roman Danyliw via Datatracker []
> Envoyé : mardi 20 octobre 2020 22:29
> À : The IESG <>
> Cc :; opsawg-
>;; Adrian Farrel
> <>uk>;
> Objet : Roman Danyliw's No Objection on draft-ietf-opsawg-model-
> automation-framework-07: (with COMMENT)
> Roman Danyliw has entered the following ballot position for
> draft-ietf-opsawg-model-automation-framework-07: 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
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> framework/
> --------------------------------------------------------------------
> --
> --------------------------------------------------------------------
> --
> Thank you for responding to the SECDIR Review (and thank you to
> Christian Huitema for providing the review)
> Focusing primarily on Section 3 and 4 (and ignoring the examples in
> Section 5), I didn’t find much guidance on using YANG as was
> suggested by the introductory materials.

[Med] All the components in Sections 3/4 are about manipulating YANG modules and functionalities. We tried to avoid overloading the description with examples as this may distract the reader. We extracted these details into "A.  Layered YANG Modules Examples Overview" appendix. Would you prefer if that appendix is moved into the core document?
> ** Section 3.1.  Figure 2 notes “full guarantees class” and “delay
> guarantees class” which seems to speak to a particular class of
> traffic, but I didn’t follow what these were.

[Med] Fair. Added this NEW:

   In reference to Figure 2, "Full traffic performance guarantees class"
   refers to a service class where all traffic performance metrics
   included in the service model (OWD, loss, delay variation) are
   guaranteed, while "Delay traffic performance guarantees class" refers
   to a service class where only OWD is guaranteed.

> ** Section 6.  Per “ The YANG modules cited in this document define
> schema for data that are designed to be accessed via network
> management protocols such as NETCONF [RFC6241] or RESTCONF
> [RFC8040]”, this seems to conflict with Section 1 which reminds us
> that “any

[Med] The original text is "Many" not "any".

 of the YANG modules listed in this document are used to
> exchange data between a NETCONF/RESTCONF clients and servers
> [RFC6241][RFC8040].

[Med] Good catch. Fixed with this change

s/The YANG modules/Many of the YANG modules

  Nevertheless, YANG is transport independent
> data modeling language.  It can thus be used independently of
> NETCONF/RESTOCNF.”  To be clear, the behavior described in the
> latter is not part of this architecture?

[Med] This is typically the case of the service exposure where other protocols can be used in that interface. The use of YANG in such case is covered, but not the communication protocols themselves.    

> ** Section 6.  The following architectural assumptions seem to
> conflict:
> -- Section 3.1, “All these elements (i.e., Orchestrator(s),
> Controller(s),
> device(s)) are under the responsibility of the same operator.
> -- Section 6.1. “A provider may rely on services offered by other
> providers to build composite services.”

[Med] It isn't. The communication between a network and a peer one occurs at the service layer. That is, there is no direct communication between a local service controller and a network controller of in a peer network. This is explained in this text: 

   A composite service offered by a network operator may rely on
   services from other operators.  In such case, the network operator
   acts as a customer to request services from other networks.  The
   operators providing these services will then follow the layering
   depicted in Figure 3.  The mapping between a composite service and a
   third-party service is maintained at the orchestration level.

> Is the assumption that “under the responsibility of” to include
> contractual arrangement with the service provider?

[Med] No. 

> ** Section 6.  Per “In order to prevent leaking sensitive
> information, special care should be considered when translating
> between the various layers in Section 4 or when aggregating data
> retrieved from various sources.”, agreed.
> However, as Section 6.1. suggests that services from other providers
> may also be used, this caution should extend to be both in the layer
> and inter and intra layers.

[Med] The case of services from other providers is covered by this text: 

"The network operator must enforce means to protect privacy-related information included in customer-facing models."

> ** Editorial Nits

[Med] Thanks. Fixed. 

> Section 1.  Editorial.  s/Dynamically fed/Dynamically feed/
> Section 3.1.  Typo. s/Connectivty/Connectivity/
> Section 3.3. Typo. s/Fullfillment/Fulfillment/


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.