Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC

mohamed.boucadair@orange.com Thu, 01 October 2020 12:49 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30333A10E3; Thu, 1 Oct 2020 05:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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: 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 sxZZVqFzrOAU; Thu, 1 Oct 2020 05:49:31 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A077E3A10A9; Thu, 1 Oct 2020 05:49:25 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4C2Ccg75J9z4x66; Thu, 1 Oct 2020 14:49:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601556564; bh=5EYL8PgAYlNl8Z23eO4lWCevKykocvxDstMPokN+3ek=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ml7PiqqUSiVtnZiA7ldnd4DZ0gD5iNYtnbvxipgdC935YP97fOZaxJycXIlAnDkch ubnHqYwCC+HaXFF/JGL7waTPn+IV+ci3R66K9+B4r1HzpcIktETJDGikqV+cP/bVNw 2Lk5dAIc2o6pvF8IRPR9VEHPsJFTAyKE/tF6qFTPEiv/GePqH9+Lp6O4pLiP47O7sD bhEMeEiZ/DXi3j+0lNZJgckErsfEaCNe9capS3RtDlLL9Z2Go4BbSRdf0spbd3OCVn vTaEjGlh5ojapxSbZtfYSKve7SRyvLCvP2f9lY28UybS/9ug/iLfdyiWKaj3bZMFUk XQtHsfD6/2cCg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4C2Ccg5yvczDq7X; Thu, 1 Oct 2020 14:49:23 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: "draft-ietf-opsawg-model-automation-framework.all@ietf.org" <draft-ietf-opsawg-model-automation-framework.all@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC
Thread-Index: AQHWlppjz+XL5S1kWkyjSprd228cGqmCsWmg
Date: Thu, 1 Oct 2020 12:49:22 +0000
Message-ID: <7458_1601556563_5F75D053_7458_328_1_787AE7BB302AE849A7480A190F8B93303154B96C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160095255684.28293.2595806209469918634@ietfa.amsl.com> <0ae283b5-1675-9995-757f-d6e6ccbd6d54@gmail.com> <13759_1601358037_5F72C8D5_13759_498_1_787AE7BB302AE849A7480A190F8B933031549FD3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <de9bb4f6-5225-c820-8ddd-aaab73b6236d@gmail.com>
In-Reply-To: <de9bb4f6-5225-c820-8ddd-aaab73b6236d@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.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/UOOxAU77Xf_sOeVH9NE4uxAYgDQ>
Subject: Re: [OPSAWG] Last Call: <draft-ietf-opsawg-model-automation-framework-06.txt> (A Framework for Automating Service and Network Management with YANG) to Informational RFC
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 01 Oct 2020 12:49:33 -0000

Hi Brian,

An updated version to address your comments can be seen at: 

https://github.com/boucadair/draft-ietf-opsawg-model-automation-framework/blob/master/draft-ietf-opsawg-model-automation-framework-06.txt

You can track the changes at: https://tinyurl.com/ycpt62dh 

Please let me know if we need to say more. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Envoyé : mardi 29 septembre 2020 21:55
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>om>; last-
> call@ietf.org
> Cc : draft-ietf-opsawg-model-automation-framework.all@ietf.org;
> opsawg@ietf.org
> Objet : Re: Last Call: <draft-ietf-opsawg-model-automation-
> framework-06.txt> (A Framework for Automating Service and Network
> Management with YANG) to Informational RFC
> 
> Hi Med, see below...
> On 29-Sep-20 18:40, mohamed.boucadair@orange.com wrote:
> > Hi Brian,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> >> Envoyé : mardi 29 septembre 2020 00:25 À : last-call@ietf.org
> Cc :
> >> draft-ietf-opsawg-model-automation-framework.all@ietf.org;
> >> opsawg@ietf.org
> >> Objet : Re: Last Call: <draft-ietf-opsawg-model-automation-
> >> framework-06.txt> (A Framework for Automating Service and Network
> >> Management with YANG) to Informational RFC
> >>
> >> Hi,
> >>
> >> I have a question for clarification, and then a comment.
> >>
> >> First, consider these extracts:
> >>
> >>> 5.1.  L2VPN/L3VPN Service Delivery
> >>>
> >>>    In reference to Figure 5, the following steps are performed
> to
> >>>    deliver the L3VPN service within the network management
> >> automation
> >>>    architecture defined in this document:
> >>>
> >>>    1.  The Customer requests to create two sites (as per service
> >>>        creation operation in Section 4.2.1)...
> >> ...
> >>> 5.2.  VN Lifecycle Management
> >>>
> >>>    In reference to Figure 7, the following steps are performed
> to
> >>>    deliver the VN service within the network management
> automation
> >>>    architecture defined in this document:
> >>>
> >>>    1.  Customer requests (service exposure operation in Section
> >> 4.1.1)
> >>>        to create 'VN' based on Access point...
> >> ...
> >>>    3.  The Customer exchanges connectivity-matrix on abstract
> node
> >> and
> >>>        explicit path using TE topology model with the
> >> orchestrator...
> >>
> >> In those examples, how does the customer "request" or "exchange"
> >> data? I assume this is intended to happen by software, rather
> than by
> >> telefax.
> >
> > [Med] We hope this can be by software if we want to benefit from
> the automation in the full cycle but the approach still apply
> independently how a service request is captured.
> >
> > We don't zoom that much on that interface because the document is
> more on the provider's side.
> >
> >> So what protocol is involved, and which entity on the customer
> side
> >> is doing it?
> >
> > [Med] The component at the client side are generally represented
> as service ordering (see RFC 4176). That component may interact with
> the Order Handling at the provider side using a variety of means
> such as https://www.rfc-editor.org/authors/rfc8921.txt (Section 5)
> or by offering a management interface to the customer, etc.
> 
> Well, I'd rather see a standardised and generic solution to that
> problem, as noted in my reply to Adrian. But indeed, that is the
> requirement.
> 
> > Please let us know if you think that we need to add some text on
> this part.
> 
> I think it needs just a few words in section 3 or 4, even just to
> say that the mechanism is out of scope for this document.
> 
> >
> >>
> >>> 5.3.  Event-based Telemetry in the Device Self Management
> >>>
> >>>    In reference to Figure 8, the following steps are performed
> to
> >>>    monitor state changes of managed objects or resources in a
> >> network
> >>>    device and provide device self-management within the network
> >>>    management automation architecture defined in this document:
> >>>
> >>>    1.  To control which state a network device should be in or
> is
> >>>        allowed to be in at any given time, a set of conditions
> and
> >>>        actions are defined and correlated with network events
> >> (e.g.,
> >>>        allow the NETCONF server to send updates...
> >>
> >> Second, this is the first mention of NETCONF in the document, and
> the
> >> only other mention is in the Security Considerations. I suggest
> that
> >> there should be a short description of the role of NETCONF (and
> >> RESTCONF) earlier in the document, either in section 3 or more
> likely
> >> in section 4 (Functional Blocks and Interactions).
> >
> > [Med] Point taken. We will also clarify that in some cases the use
> of YANG does not require NETCONF/RESTCONF.
> 
> Thanks. (For example, draft-ietf-anima-grasp-distribution can serve
> for distributing YANG.)
> 
>     Brian
> >
> >>
> >> Regards
> >>    Brian Carpenter
> >
> >


_________________________________________________________________________________________________________________________

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.