[OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 20 October 2020 20:28 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsawg@ietf.org
Delivered-To: opsawg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFBE3A0967; Tue, 20 Oct 2020 13:28:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-opsawg-model-automation-framework@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, Adrian Farrel <adrian@olddog.co.uk>, adrian@olddog.co.uk
X-Test-IDTracker: no
X-IETF-IDTracker: 7.20.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160322572154.31611.14375690260604841111@ietfa.amsl.com>
Date: Tue, 20 Oct 2020 13:28:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/90O6eEvXA9oREjG2i-QhJscz_9g>
Subject: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-model-automation-framework-07: (with COMMENT)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 20:28:42 -0000

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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

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

** 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 of the YANG modules listed in this document are used
to exchange data between a NETCONF/RESTCONF clients and servers
[RFC6241][RFC8040].  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?

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

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

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

** Editorial Nits
Section 1.  Editorial.  s/Dynamically fed/Dynamically feed/

Section 3.1.  Typo. s/Connectivty/Connectivity/

Section 3.3. Typo. s/Fullfillment/Fulfillment/