Re: [Gen-art] Genart last call review of draft-ietf-opsawg-model-automation-framework-06

mohamed.boucadair@orange.com Mon, 12 October 2020 06:41 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D183A12B9; Sun, 11 Oct 2020 23:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkaAE1whWQwv; Sun, 11 Oct 2020 23:41:03 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E85F3A12B8; Sun, 11 Oct 2020 23:41:03 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4C8pwY1fFSzBs5j; Mon, 12 Oct 2020 08:41:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1602484861; bh=GuY2WIRvte2H2tNL6qX4tVGyY8sHhNFqeie32CKgmYg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ViWDHXNY10rtdl+ey7sbQb3QSqFNJgx8hVRkw6nOrpGBalgEvKMOA8zFtzBUxq8OB WmtJCFHLrPvzrJW0Q3dCtvW9r+jEhEoVN4Tn6nJw4I7DU4W75KiuvnCANw3byMdhxH XSEDV+41RrAqph5t1NRKaJJttggUacn9bbd3WChp5bHNiw8dUmhJTjdtNRAlRoEAxH vq23+bIvp7TxWQ/Bs6yow5VJCTwiTnE2VfffSGDj13jn+DfkWDf4gqCO8x7sYjz2xy YI/eOhChRgfckQ0qrF0qMd6ZGnzwEB7stX9Z6FuNwt5WdC5+aMOgGcuFDFP3qwjtv0 M1N7dUCCkUjhA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4C8pwY0K8NzCqlt; Mon, 12 Oct 2020 08:41:01 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Ines Robles <mariainesrobles@googlemail.com>
CC: "gen-art@ietf.org" <gen-art@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "draft-ietf-opsawg-model-automation-framework.all@ietf.org" <draft-ietf-opsawg-model-automation-framework.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-opsawg-model-automation-framework-06
Thread-Index: AQHWn7W8BU1ymoTN/Eyt0ftfhXiBiqmTgwLw
Date: Mon, 12 Oct 2020 06:40:59 +0000
Message-ID: <8879_1602484861_5F83FA7D_8879_41_1_787AE7BB302AE849A7480A190F8B93303155C7E6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160219726151.7069.6476351560272708886@ietfa.amsl.com> <16977_1602230670_5F80198E_16977_251_3_787AE7BB302AE849A7480A190F8B93303155BAC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAP+sJUejn4D-O6mJoVb32ijJJWLpgjbBMzpwCwTwS3S+Wb_viw@mail.gmail.com>
In-Reply-To: <CAP+sJUejn4D-O6mJoVb32ijJJWLpgjbBMzpwCwTwS3S+Wb_viw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303155C7E6OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/HWdgutfnMbHzNtqpCVrSXARWnpg>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-opsawg-model-automation-framework-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2020 06:41:08 -0000

Hi Ines,

Thank you. A new version that takes into account all reviews, including yours can be seen at:


URL:            https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework

Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07

Please see also inline.

Cheers,
Med

De : Ines Robles [mailto:mariainesrobles@googlemail.com]
Envoyé : dimanche 11 octobre 2020 12:03
À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
Cc : gen-art@ietf.org; opsawg@ietf.org; draft-ietf-opsawg-model-automation-framework.all@ietf.org; last-call@ietf.org
Objet : Re: Genart last call review of draft-ietf-opsawg-model-automation-framework-06

Hi Med,

Thank you very much for addressing my comments. Please find my answers below.



> d- Figure 3: The box Device includes Device Modeling. Should be
> added in Device as another box for "Resource Orchestration"? (As
> e.g. Service has Service
> Orchestration)
>

[Med] Resource orchestration/allocation is more on the network level. The network model definition says the following:

      It can be used by a network operator to allocate resources (e.g.,
      tunnel resource, topology resource) for the service or schedule
      resources to meet the service requirements defined in a Service
      Model.

Of course some of this may be distributed, but I don't think that we need to overload the document with this.

<ines> Ok,  it is fine for me, my question was more related to device resources e.g. sensors/actuators as device resources </ines>

[Med] Thank you for the clarification. This is a sub-component of the overall “Device Modelling”. Please refer to “A.4.2.  Device Management”. We don’t want to overload figure 3 with many internal components.


> e.3- In the explanation of the Functional Blocks and Interactions
> section, why the following blocks are not defined/explained in the
> subsections?: *Service Assurance *Specific Service
> Creation/Modification *Specific Service Optimization *Specific
> Service Assurance

[Med] We don’t repeat "Specific-*" as we do say the following:

   The end-to-end service lifecycle management is technology-independent
   service management and spans across multiple network domains and/or
   multiple layers while technology specific service lifecycle
   management is technology domain specific or layer specific service
   lifecycle management.

We also include in the description of the journey among layers. For example, the service creation section says:

   If the request is accepted, the service orchestrator/management
   system maps such service request to its view.  This view can be
   described as a technology specific Network Model or a set of
   technology specific Device Models and this mapping may include a
   choice of which networks and technologies to use depending on which
   service features have been requested.

That is basically about "Specific Service Creation".

Will double check, though.
  <ines> Ok,  thank you. But what about the service Assurance? </ines>
[Med] A new sub-section was added.



_________________________________________________________________________________________________________________________

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.