Re: [OPSAWG] AD review for draft-ietf-opsawg-model-automation-framework-04

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 24 September 2020 12:41 UTC

Return-Path: <rwilton@cisco.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 CD2593A0A29; Thu, 24 Sep 2020 05:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=RSeM9BQH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uDDhj6qa
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 VKDnQg4pxUdq; Thu, 24 Sep 2020 05:41:34 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02043A09DB; Thu, 24 Sep 2020 05:41:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15857; q=dns/txt; s=iport; t=1600951293; x=1602160893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kkh9xDHqdpsle1MxUNNAqETju1af1C1ztljYOKlUBtA=; b=RSeM9BQH622oVNLo4uBg/D93/OZbJkDQmmqGFwgLU7p12f+5W3bW5hIi 12o6N7kckEIupWfm/LfRjybwvB8NgBCVGlApbcDsyllEqtkhU/0+wYKGN a2nOPOgD+JW6zTrshe3DhcSWi2XtaYzN5G9fqXruNPeEm42GW2MTGzhf7 E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AxuxXKRcZD4itXyoZaA+9D2h0lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9fc8ftChOeQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFrIq3u94HgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXBQCHk2xf/5FdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUlEHcFkvLAqHeAONeph2gUKBEQNVCwEBAQ0BASMKAgQ?= =?us-ascii?q?BAYRLAoIsAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFawcBAQEBAxIVGQEBKgY?= =?us-ascii?q?EAwELBAIBCBEBAwEBFhIHMhQDBggBAQQBDQUIGhMHgmuCSwMuAQMLqyQCgTm?= =?us-ascii?q?IYXSBATODAQEBBYFHQYM1GIEgcAMGgTiCcoo8G4FBP4ERQ4JNPoJcAQECAQE?= =?us-ascii?q?VfxIBEgEJGj2DC4Itj3kKDwokAYIziH+aP4EJCoJniHuRfIMMiXuODIV6kwS?= =?us-ascii?q?Bd4htlR8CBAIEBQIOAQEFgWsjZ3BwFTuCaVAXAg2OHwwXg06FFIVCdDcCBgE?= =?us-ascii?q?JAQEDCXyMWi2BBgGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.77,297,1596499200"; d="scan'208";a="547613602"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2020 12:41:32 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 08OCfWGQ024157 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2020 12:41:32 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Sep 2020 07:41:31 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Sep 2020 07:41:31 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 24 Sep 2020 08:41:30 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a1qsAB19rfRQEO0R1VHNM5frq8Cs8LorVHa2Z9vKg83yxsFwMJEckkWFZJUJJFBAYVY4QLBPc/yU48whW5PUgcnr3eK0NOPWRwZ3wjba6ltDIHlCzt+y//g/AVm8T4LUvxW4nStT7+NMWOZxH0fNXH06oteq2gIPNZPHm2y/vk7xX1y38NMUrxoKYVTGfexcqt8ubeds07uDtBkQBZcfx9J9yDz3t49nh05n1WnYmMkOhNBguLO4x9RclmjKyN4HwFSAA3vfLvJEMMYr6rubB35Hf/Y+aaNbQQc1tW1an5+UX3lIeFNqJwIEMSuZ5P7ei8sLPHKGyF/zH/7NJZGAow==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2EtVxchDVW3c28Tm74y3Yv6AXqX2nsANMcsuk9AIuuM=; b=kn/CFgAfT4ZNjbX9ypg+VmyYGasDps6WIkHHSEBeNFXM+Bftq57wfUiNcOu7HbU20B7CM5I67E52WrsSs8zQihk0jLxbn4PPPykNfR2ZJ96LcIF9BvIqDdTyjSM0zq6It9IhQGZHPJJFbxgaOX92FP+PSQ3IAj1Ccf7z2sQGBYd737uF+aNu+bLZUA2fONloiBh6hMZlEekcrE0lPIvuvHc6abRjzNs6t2jkD/JYE28FQkpeRPUaXxzjStsyDcghy7OAxAB2yQcApwokHrSCvL1yerEJrCsdeGbURyuXrpv5Pmm1XHI8aafrGArcOZj01K8610Kzr7OSXBZlmzGEyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2EtVxchDVW3c28Tm74y3Yv6AXqX2nsANMcsuk9AIuuM=; b=uDDhj6qazUhFIstIb5m0D/1L2ic+XDHoHa1D9liF4JYOykF7vbTGQjOkM+O+coqxQpw4S2EJ/wGo1CdH3dZ9fA1gYs+H11stebovKBvfrrzUC+nDI3Yss6BEFelBNZTkKP2catsZk12jMxRAxDZ4sFdS7JmcggjejxH77K8rv1w=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4448.namprd11.prod.outlook.com (2603:10b6:208:193::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Thu, 24 Sep 2020 12:41:29 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3391.026; Thu, 24 Sep 2020 12:41:29 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, opsawg <opsawg@ietf.org>
CC: "draft-ietf-opsawg-model-automation-framework.all@ietf.org" <draft-ietf-opsawg-model-automation-framework.all@ietf.org>
Thread-Topic: AD review for draft-ietf-opsawg-model-automation-framework-04
Thread-Index: AdaC3a2C6z2FO6K2SPCz/hmx2OWKrwCAISCAAD80x0ACARNooACDwGwQAKBiZXA=
Date: Thu, 24 Sep 2020 12:41:29 +0000
Message-ID: <MN2PR11MB4366A90815899FE5216D06F4B5390@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <MN2PR11MB4366A6F49DE8D6EFD8C5B969B52D0@MN2PR11MB4366.namprd11.prod.outlook.com> <4002_1599489295_5F56450F_4002_85_3_787AE7BB302AE849A7480A190F8B93303153BD35@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15872_1599568053_5F5778B5_15872_268_1_787AE7BB302AE849A7480A190F8B93303153C57E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MN2PR11MB436670F5FD876E5507E63D4BB53F0@MN2PR11MB4366.namprd11.prod.outlook.com> <15524_1600675933_5F68605D_15524_61_13_787AE7BB302AE849A7480A190F8B933031543376@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <15524_1600675933_5F68605D_15524_61_13_787AE7BB302AE849A7480A190F8B933031543376@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d4eab1a6-5ebb-493b-dd0e-08d8608728d7
x-ms-traffictypediagnostic: MN2PR11MB4448:
x-microsoft-antispam-prvs: <MN2PR11MB4448A076B5296580B04D1CCDB5390@MN2PR11MB4448.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uJ6xTXMSO1x4oS5a8lGv9W4rl8EUQaQN+7pELMQJHxV5YfGi2J8c/wfzk+CTovgroyfzGW8+A/B7ir8Xp9sRDcTpjgYQgfUEYYKSBreDM/4HGe5L5JMnKD4pxWxu6L9GIcf76zmcdjfNVqIKygmMGNcGUenrZ2uV1nnT6mbivM296YKjJRaOJ+BFmLC3PM7SFjODgAZrR7uivN7FA2miU6kqItWd8B1kJUp4utz4bUAKxFZ39acQa0vml7nEt4ZoPGNqavsTbCrLDdpdo5qZT69mmgtcgF4NslbuhTrt+EIH9D05ts5a2eeA1ZmCazf5lguJonzz5Vjl/2awXdYnJQMSwXGjgEwgYE+Qzsjwtg9NyzkjOg4xEtxF6pYi7gjvsE6s/tJqQIMLBmea92ZH9uFUkvy9L+s7fFkc+i8HmriBZEqIbZ++Fv3yLzaMtTie82QVTw+Y4766/yWTwDCbQQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(376002)(396003)(346002)(110136005)(83380400001)(66946007)(186003)(71200400001)(316002)(76116006)(53546011)(6506007)(26005)(5660300002)(9686003)(4326008)(33656002)(966005)(30864003)(7696005)(2906002)(8936002)(66556008)(66446008)(66476007)(52536014)(478600001)(86362001)(64756008)(55016002)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: mWmZxKJDGjKz/IAtS89PDNiR+GOQ3LDPWms3VhsfbnEM2t+ecdNwyoOrUDhh/MAX/jXtVr5YqdsSuIbBYE/QI5d4m7nqudVh/wBcc5PYl7xjsA/3pgKkIMr6FlC/JmcNcMtESBgEHU0275AOLQzVgSpZCTZVC7BeIEAJv2wO5zIx51T3HsXg2MWSo/s7dCiFEtnB8QfPxcR6MAdorbDw03dxS5i52kumBAq9MG5J/B6ojrmrsHiGWNQa4IYaxuUlZ5BZ9gAJpGTpoi6rvSBKWH6AYeLuyKVxAYSMjg85vrj96fNK9+x/h+aNshPmMHG1HydKrw3571ktdX0TaODL6YtDtip5g+mQuLxR8PHjKJkblfqH/03sgXkjYHALFgsyTy9wc5nOU9NdLY4oEO2slSXHpmKVXDev1L0XR3K5uZRagRtORfx822ot0qvIhcJVRZhkf3jtL0GROvny+wXFJixUgllID0w1DK1G8hYYHF+YWwvgXSyGdGMBYXkv1h+OFwUFzG9gN+U0bVw41HSqBmG9YJFbAXCYTAG0spErQYlX3tCDqy5pwd4d9DNyPvZU9qZlKVgivz7Uej+lcAf6TUQAe7lvKNa8Q3mydGKC09ATUe7elhFIow9x6xY+hTXfKs5BFloGJqTbnem3JS1GMg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d4eab1a6-5ebb-493b-dd0e-08d8608728d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2020 12:41:29.1564 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bEYFuDS5OMMvTd65lx6XgiKGbL4pHKICzbQwimKLwhsjb5yAd8AOqIpdiIz12mku1BuQ68M3c+HIl6FEZzLuxw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4448
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ayoRQPFWf6BX7kDCr-G-ntS8rlE>
Subject: Re: [OPSAWG] AD review for draft-ietf-opsawg-model-automation-framework-04
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, 24 Sep 2020 12:41:37 -0000

Hi Med,

Thanks for the final updates.  I've requested IETF LC on -06.

Regards,
Rob


> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: 21 September 2020 09:12
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; opsawg <opsawg@ietf.org>
> Cc: draft-ietf-opsawg-model-automation-framework.all@ietf.org
> Subject: RE: AD review for draft-ietf-opsawg-model-automation-framework-04
> 
> Hi Bob,
> 
> Thank you for double checking.
> 
> I confirm that your initial AD review message I received was truncated
> (see attached).
> 
> Will update the draft to take into account the missing part.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
> > Envoyé : vendredi 18 septembre 2020 19:21
> > À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>om>; opsawg
> > <opsawg@ietf.org>
> > Cc : draft-ietf-opsawg-model-automation-framework.all@ietf.org
> > Objet : RE: AD review for draft-ietf-opsawg-model-automation-
> > framework-04
> >
> > Hi Med,
> >
> > The changes that you have made look good.  But I had some comments
> > at the end of my review email that it doesn't look like you have
> > responded to, or actioned.  Hence, I'm wondering if my review email
> > might have been truncated, or the end of it missed (from "Also, I
> > ...") onwards (copied below).
> >
> >
> > A.3.1.1.  Schema Mount
> >
> >    That capability does not cover design time.
> >
> > This sentence is unclear on its own.  Perhaps either expand it or
> > remove it.
> >
> > Also, I wouldn't regard schema mount as necessarily being specific
> > to device models, and could be used for network and service YANG
> > models as well.  Although there may not be a good place to put it.
> >
> > 14.
> > A.3.2.  Device Models: Samples
> >
> > As above, having a section for interfaces/interface management would
> > be useful.  I also think think it would be good to have a section
> > for device management (e.g. system, nacm)
> >
> > I would potentially reorder the list of modules:
> >    - Move Core Routing up, near the top of the list (above BGP)
> >    - L2VPN (next to) but before EVPN
> >    - Perhaps move BGP down, and having routing policy next to it
> > might be helpful
> >    - NAT and Stateless Address Sharing could perhaps move down.
> >
> >
> > Editorial nits to check:
> >
> > 1. Network Operator -> network operator?
> > 2. Perhaps "it can accommodate modules" -> "it can also accommodate
> > modules"?
> > 3. "follow top-down approach" -> "follow a top-down approach"
> > 4. "validated during the implementation time" -> "validated during
> > implementation"
> > 5. For Diagram A2, possibly could have just used the full names and
> > not requried the legend.
> > 6. "[RFC8345] with TE topologies specifics." -> "[RFC8345] with TE
> > topology related content."
> > 7. "Network Topology Models" -> Network Topologies Model"?
> > 8. "TE Topology Models" => "TE Topology Model"?
> > 9. "Layer 3 Topology Models:" -> "Layer 3 Topology Model:"
> > 10. "Layer 3 topologies specifics" -> "Layer 3 topology specifics"
> > 11. "Layer 2 Topology Models:" -> "Layer 2 Topology Model:"
> > 12. "Layer 2 topologies specifics" -> "Layer 2 topology specifics"
> > 13. Figure 4: "Config Validate" -> "Config Validation", and realign
> > "Monitoring"
> >
> > Please can you check?
> >
> > Regards,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > > Sent: 08 September 2020 13:28
> > > To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; opsawg
> > <opsawg@ietf.org>
> > > Cc: draft-ietf-opsawg-model-automation-framework.all@ietf.org
> > > Subject: RE: AD review for
> > > draft-ietf-opsawg-model-automation-framework-04
> > >
> > > Rob,
> > >
> > > FWIW, an updated version with changes to address your review is
> > > available
> > > online:
> > >
> > > URL:            https://www.ietf.org/id/draft-ietf-opsawg-model-
> > > automation-framework-05.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-05
> > > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-
> > opsawg-model-
> > > automation-framework-05
> > >
> > > Please let us know if any of your comments is still pending. Thank
> > you.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : mohamed.boucadair@orange.com
> > > > [mailto:mohamed.boucadair@orange.com]
> > > > Envoyé : lundi 7 septembre 2020 16:35 À : Rob Wilton (rwilton)
> > > > <rwilton@cisco.com>om>; opsawg <opsawg@ietf.org> Cc :
> > > > draft-ietf-opsawg-model-automation-framework.all@ietf.org
> > > > Objet : RE: AD review for draft-ietf-opsawg-model-automation-
> > > > framework-04
> > > >
> > > > Hi Rob,
> > > >
> > > > Thank you for the detailed review.
> > > >
> > > > Please see inline.
> > > >
> > > > I let my co-authors further comment.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Rob Wilton (rwilton) [mailto:rwilton@cisco.com] Envoyé :
> > > > vendredi
> > > > > 4 septembre 2020 19:22 À : opsawg <opsawg@ietf.org>rg>;
> > > > > draft-ietf-opsawg-model-automation-
> > > > > framework.all@ietf.org
> > > > > Objet : AD review for
> > > > > draft-ietf-opsawg-model-automation-framework-
> > > > 04
> > > > >
> > > > > Apologies for the lengthy delay in performing the AD review.
> > > > >
> > > > > I found that this document to be well written so I would like
> > to
> > > > thank
> > > > > the authors, WG, and doc shepherd for that.  My more
> > significant
> > > > > comments relate to questions on the scope of this
> > architecture.
> > > > >
> > > > >
> > > > > More significant comments:
> > > > >
> > > > > 1. By "Data Model" does this document mean "YANG data model"?
> > And
> > > > if
> > > > > so, does it take this meaning all through this document, or
> > only
> > > > some
> > > > > of the time?
> > > > >
> > > >
> > > > [Med] "Data Model" is used as a generic term as per
> > rfc3444#section-4.
> > > > We are using "YANG data models" or "YANG module" when we wanted
> > to
> > > > be more specific about the DM flavour.
> > > >
> > > > I double checked the text to make sure this is consistently used
> > > > along the document. Updated some occurrences in the text where
> > the
> > > > use of "YANG data model" is more accurate.
> > > >
> > > > > 2. Generically, service data models are not necessarily
> > written in
> > > > > YANG (e.g., I think that MEF are defining them using OpenAPI).
> > > > > So, related to (1), is this architecture intended to be tied
> > to
> > > > > only service models defined in YANG, or be more broadly
> > applicable?
> > > >
> > > > [Med] We don't require the service models to be YANG-modelled
> > (see
> > > > for instance the example depicted in Figure 2). That's said, the
> > use
> > > > of YANG in all levels would ease mapping operations.
> > > >
> > > > >
> > > > > 3. This architecture seems to quite strictly represent 3
> > layers
> > > > > (service, network, device).  Does it envisage that these
> > layers
> > > > > may themselves be deconstructed?  E.g. a customer service can
> > be
> > > > > constructed from underlying services
> > > >
> > > > [Med] Yes, that's not excluded. The architecture can be
> > "recursive"
> > > > (Such as rfc8597#section-3.1.3).
> > > >
> > > >  (e.g., as discussed in section
> > > > > 3.1, but more as an East-West relationship).  Similarly,
> > device
> > > > models
> > > > > could also be deconstructed, e.g., if the dataplane is
> > decoupled
> > > > from
> > > > > the control plane, or if a device itself acts as a controller
> > > > managing
> > > > > other devices.
> > > >
> > > > [Med] The document does not make assumptions on the organic
> > > > structure or where the functions are provided. Having a
> > controller
> > > > co-located with other YANG-controlled functions is not excluded.
> > > >
> > > > >
> > > > > 4. My minimal understanding of the MEF LSO architecture was
> > that
> > > > they
> > > > > put quite a lot of emphasis on East-West models, probably at
> > the
> > > > > service layer. Is this effectively the same as what is
> > described
> > > > > in Figure 1 in section 3.1?
> > > >
> > > > [Med] Inter-domain interactions between two services or two
> > adjacent
> > > > networks are not shown in Figure 1. This figure focuses mainly
> > on
> > > > the interface between a service and an underlying network.
> > > >
> > > >   Does the potential existence of these East-
> > > > > West APIs need to be described in any more detail?
> > > > >
> > > >
> > > > [Med] A network can act as a "customer" and request services
> > from
> > > > other networks. The peer network will then follow the levels
> > > > depicted in the architecture. This is for example hinted in this
> > > > text for
> > > > example:
> > > >
> > > >    o  allow customers (or Network Operators) to dynamically
> > adjust the
> > > >       network resources based on service requirements as
> > described in
> > > >       Service Models (e.g., Figure 2) and the current network
> > > >       performance information described in the telemetry
> > modules.
> > > >
> > > > We can add some more text if needed.
> > > >
> > > > Section 4.3 discusses how multi-domain mapping can be handled at
> > the
> > > > server level. This assumes that the interaction is not between
> > the
> > > > domains themselves but driven by the service layer.
> > > >
> > > > >
> > > > > Minor comments/clarifications:
> > > > >
> > > > > Section 3.1: Data Models: Layering and Representation
> > > > >
> > > > > 5. Network Models are mainly network resource-facing modules;
> > they
> > > > >    describe various aspects of a network infrastructure,
> > including
> > > > >    devices and their subsystems, and relevant protocols
> > operating
> > > > > at the
> > > > >    link and network layers across multiple devices (e.g.,
> > network
> > > > >    topology and traffic-engineering tunnel modules).
> > > > >
> > > > > Would it be fair to say that Network Models might be protocol
> > > > > specific, or might be generalized?  If so, is that worth
> > mentioning?
> > > > >
> > > >
> > > > [Med] Network models may include some protocol-specific
> > parameters.
> > > > I'm neutral whether this needs to be mentioned in the text.
> > > >
> > > > >
> > > > > 6. Re: DOTS & RFC 8783, I'm not sure how well the YANG model
> > > > > defined in that drafts fits into the category of Service YANG
> > model.
> > > > >
> > > >
> > > > [Med] RFC8783 defines the filtering service requested by a
> > > > client/customers; how this request triggers the selection of the
> > > > devices that need to be configured, the exact set of ACLs, and
> > the
> > > > enforcing of the ACLs in these devices is managed by other
> > layers
> > > > (RFC8519). From that perspective, we do think that the module in
> > RFC
> > > > 8783 satisfies the following from RFC8309:
> > > >
> > > >    "Details
> > > >    included in the service model include a description of the
> > > > service as
> > > >    experienced by the customer, but not features of how that
> > service
> > > > is
> > > >    delivered or realized by the service provider. "
> > > >
> > > > > 7. Pipe vs hose vs funnel.  Are these terms, or do they need
> > to
> > > > > be, defined somewhere?  In particular it is not obvious to me
> > what
> > > > > the distinction is between pipe vs hose.
> > > >
> > > > [Med] "pipe" means that only point-to-point communications are
> > > > allowed while "hose" means that communications from one to N is
> > allowed.
> > > >
> > > > We can text to explain this.
> > > >
> > > > >
> > > > >
> > > > > In Appendix A:
> > > > > 8. Would it be useful to discuss or reference YANG Catalog (as
> > a
> > > > > source of querying YANG models), the public YANG github
> > > > > repository,
> > > > or
> > > > > YANG module tags as a method of organizing YANG models?
> > > > >
> > > >
> > > > [Med] Good point. Will consider adding some text.
> > > >
> > > > > 9.
> > > > >    o  Tunnel identities to ease manipulating extensions to
> > specific
> > > > >       tunnels [RFC8675].
> > > > >
> > > > > I found this sentence slightly unclear.  Perhaps it could be
> > > > reworded?
> > > > >
> > > >
> > > > [Med] Fair point. Updated to :
> > > >
> > > > " o  Tunnel identities: [RFC8675] defines a collection of YANG
> > > > identities used
> > > >      as interface types for tunnel interfaces."
> > > >
> > > > > 10.
> > > > >    o  Generic Policy Model:
> > > > >
> > > > >    The Simplified Use of Policy Abstractions (SUPA) policy-
> > based ...
> > > > >
> > > > > It does not like this draft is going anywhere, and I'm not
> > > > > convinced that it is really helpful to reference it here.  Or,
> > if
> > > > > it must be referenced, it should be caveated accordingly.
> > > > >
> > > >
> > > > [Med] Fair enough. I tend to agree with you.
> > > >
> > > > > 11.
> > > > > A.3.  Device Models: Samples
> > > > >
> > > > > I think that it would be helpful if this diagram, and the list
> > in
> > > > > section A3.2, had references to the interface YANG module.
> > > > >
> > > >
> > > > [Med] Point taken.
> > > >
> > > > > 12.
> > > > > A.3.1.  Model Composition
> > > > >
> > > > >    o  Device Model
> > > > >
> > > > >    [I-D.ietf-rtgwg-device-model] presents ...
> > > > >
> > > > > Again, I'm not sure that this is a helpful reference, given
> > that
> > > > > the approach defined in this draft did not gain traction, and
> > > > > instead, a more loosely coupled structure was preferred.
> > E.g., I
> > > > > see that tags (and arguably schema mount) solve this
> > > > > organizational problem in a more flexible way.
> > > > >
> > > >
> > > > [Med] Fair point.
> > > >
> > > > > 13.
> > > > > A.3.1.1.  Schema Mount
> > > > >
> > > > >    That capability does not cover design time.
> > > > >
> > > > > This sentence is unclear on its own.  Perhaps either expand it
> > or
> > > > > remove it
> > > >
> > > > [Med] OK.
> > >
> > >
> 
> __________________________________________________________________________
> _______________________________________________
> 
> 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.