[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: https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. ** 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 layers. ** Editorial Nits Section 1. Editorial. s/Dynamically fed/Dynamically feed/ Section 3.1. Typo. s/Connectivty/Connectivity/ Section 3.3. Typo. s/Fullfillment/Fulfillment/
- [OPSAWG] Roman Danyliw's No Objection on draft-ie… Roman Danyliw via Datatracker
- Re: [OPSAWG] Roman Danyliw's No Objection on draf… mohamed.boucadair