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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 13:28:41 -0700

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/

---

From: <[email-masked]>
Date: Wed, 21 Oct 2020 06:10:02 +0000

Hi Roman, 

Thank you for the comments. Most of them are addressed in https://tinyurl.com/auto-iesg-review.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 20 octobre 2020 22:29
> À : The IESG <[email-masked]>
> Cc : [email-masked]; opsawg-
> [email-masked]; [email-masked]; Adrian Farrel
> <[email-masked]>; [email-masked]
> Objet : Roman Danyliw's No Objection on draft-ietf-opsawg-model-
> automation-framework-07: (with COMMENT)
> 
> 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.)
> 
> 
> 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.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 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.