Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB24DC14F61F; Thu, 10 Oct 2024 01:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckGMktSfVLTJ; Thu, 10 Oct 2024 01:24:50 -0700 (PDT) Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.238]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B3CC1519A7; Thu, 10 Oct 2024 01:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1728548690; x=1760084690; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=HN8YRTO2jaag8sW5GlDHLd4OLg0ozPf430zj3eoJ34M=; b=gj9as28H3DxtqlIn81u1ce1bhfsv/GyKk4DnPC0mcPPXRj3wQIUwkqve N/U+i2jQuVZYbQ7kMLuvxePq4Q9P/Nb22trxwEre7KA1M83aizDuAkc0i mJPsJjaQXj9/2hbBcedYDwBtBQf9vTy322b/KIBbjYMr4Jwyih4dKKaRe P4sCKd2lZivzHc3/9xoGr+5nj3XzC5a36nwZFH+UKOB5ohYPXdC2PYHaO OsHycEkR/7TTaCiJ5hd8+w+JsOO2RudcgMTaiAX2mICL4QfnBpmJ0Mp2W nkgsdI0f/aLDMuXOYWeaMYcSjvqc5S/YDsLFPpG3lYkIylLmw+iegkKfn Q==; Received: from unknown (HELO opfedv1rlp0b.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2024 10:24:47 +0200 Received: from unknown (HELO opzinddimail3.si.francetelecom.fr) ([x.x.x.x]) by opfedv1rlp0b.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2024 10:24:46 +0200 Received: from opzinddimail3.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id 2454C5202DF1; Thu, 10 Oct 2024 10:24:46 +0200 (CEST) Received: from opzinddimail3.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 703AE5202F47; Thu, 10 Oct 2024 10:24:30 +0200 (CEST) Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail3.si.francetelecom.fr (Postfix) with ESMTPS; Thu, 10 Oct 2024 10:24:30 +0200 (CEST) Received: from mail-northeuropeazlp17011019.outbound.protection.outlook.com (HELO DB3PR0202CU003.outbound.protection.outlook.com) ([40.93.64.19]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2024 10:24:30 +0200 Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by DU0PR02MB8644.eurprd02.prod.outlook.com (2603:10a6:10:3ef::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.20; Thu, 10 Oct 2024 08:24:27 +0000 Received: from DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1]) by DU2PR02MB10160.eurprd02.prod.outlook.com ([fe80::c9a1:d43c:e7c6:dce1%4]) with mapi id 15.20.8026.020; Thu, 10 Oct 2024 08:24:27 +0000 From: mohamed.boucadair@orange.com X-TM-AS-ERS: 10.218.35.128-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-DDEI-TLS-USAGE: Used Authentication-Results: smtp-out365.orange.com; dkim=none (message not signed) header.i=none; spf=Fail smtp.mailfrom=mohamed.boucadair@orange.com; spf=Pass smtp.helo=postmaster@DB3PR0202CU003.outbound.protection.outlook.com Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 40.93.64.19 as permitted sender) identity=mailfrom; client-ip=40.93.64.19; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="mohamed.boucadair@orange.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:spfa.orange.com include:spfb.orange.com include:spfc.orange.com include:spfd.orange.com include:spfe.orange.com include:spff.orange.com include:spf6a.orange.com include:spffed-ip.orange.com include:spffed-mm.orange.com -all" Received-SPF: Pass (smtp-in365b.orange.com: domain of postmaster@DB3PR0202CU003.outbound.protection.outlook.com designates 40.93.64.19 as permitted sender) identity=helo; client-ip=40.93.64.19; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@DB3PR0202CU003.outbound.protection.outlook.com"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all" IronPort-Data: A9a23:pI0xu6nncT2QkfaT5kWl8Fno5gyqIURdPkR7XQ2eYbSJt1+Wr1Gzt xIZUWnXbvyCN2SgLtwibt+w8BlV65SDx9UwGVQ/+yxgEC4T+ZvOCOrCIxarNUt+DCFioGGLT Sk6QoOdRCzhZiaE/n9BCpC48T8mk/jgqoPUUIbsIjp2SRJvVBAvgBdin/9RqoNziLBVOSvV0 T/Ji5OZYQbNNwJcaDpOt/vb8Us35ZwehRtD1rAATaES1LPhvylNZH4vDfnZB2f1RIBSAtm7S 47rpF1u1jqEl/uFIorNfofTKiXmcJaLVeS9oiM+t5yZv/R3jndaPpDXlhYrQRw/Zz2hx7idw TjW3HC6YV9B0qbkwIzxX/TEes1zFfUuxVPJHZSwmf2L40H9KXjg+e0tVU1nFNAz9bdQIUgbo JT0KBhVBvyCr86cm4qBErM03O8edJGweoQCpntn0DfVS+48RozOSLnL4tke2yosgsdJHrDVY M9xhThHMEyGMkYJZAtRUcNWcOSA3hETdxVdr1KcoKc7pWLU0Qd43LHsKvLSYNWMSsgTlUGdz o7D1zmkWkhCaYDCodaD2lGupPWfpQX5ZKVMH4SG2sBT0GKd4WNGXXX6UnPg+qPl1SZSQel3M UEP+iMihbk79EusCNL6WnWQsXeCsVsQXNFMFPchwACA1qSS5ByWbkAIVDdPdJknudM4ADony lqOk5byDjxivKCRRDeM/7Gb6zq2PQAUIHMMIygeQmMt5dT/pYY/phPCUtglF7S65uAZAhn1y jGO6S45nakTgNMR0L229ELDm2vz/sGQFldkoALKQmii8wV1Ipa/YJCl4kTa6vAGK5uFSl6Gv z4PnM32AP0y4Y+lpTShTN5XH72T/7XcPGz13HVgTr4B3mH4k5K8Rrx47DZ7LUZvF88Lfz71f UPe0T+9ArcDbRNGiocnMuqM59QW8ET2KTjyftH5Bueij7B0fQ6DuSdpf1KQ0n33l1AhmLM7I c7EKZ/1VS9LT6N60DCxWuERl6cxwTwzzn/SQpa9yAm71b2ZZzieTrJt3LqyggIRs/jsTOb9q ow32y62J/N3DbOWjs7/rNB7ELzyBSJnba0aUuQOHgJ5HiJoGXs6F9jayq47dopuksx9z7iSr i3sChAJkgSl1RUrzDlmjFgzOdsDur4v/BoG0dAEYwr3ixDPnK7zsvhDLMtvLdHLCsQ9kK8uE aJtlzq87gRnEW+dp2t1gWjVqY1pbhOwggySdyGieiBXQnKTb12hxzMQRSO2rHNmJnPv66MW+ uT8viuFG8Zrb1o5V67+Nqnwp25dSFBGxIqeqWOTf4EPEKgtmaA2QxHMYggfep1cc0yTlmrDj G57w34w/IHwnmP8y/GR7YjskmtjO7IW8pZyd4Ua0Vq3CcUe1kaJmrd6CLzQJxvgDDuvvqK/e e9S0vfwduUdm0pHuJZ9FLAtyr8i49zopPlRyQEM8LDjcQGwEr05SpWZ9ZAni0GP7ucxVciKt oan/cNTP7qEfsjiFTb94SI7O/+b26h8dib6sZwIHaki2BJKwQ== IronPort-HdrOrdr: A9a23:DOs14amWrcwYU4fFaAaIA91CHRvpDfObimdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcIi7SdK9qXO1z+8X3WBjB8bZYOCGghrkEGgG1+ffKlLbakrDH4JmtJ uINpIOcOEYbmIKwfoSgjPIderIqePvmM/HuQ6d9QYVcegAUdAD0+4NMHf+LqQAfngiOXNWLv qhz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYpoLSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzRfBky/JlagkEuDzYJriJaIfy+QzdZ9vfrGrCpe O84CvI+f4DrE85MFvF5ycFkDOQrArGo0WStmOwsD/GrcvlRDQ8EaN69P9km13imgUdVZhHod N2N271jesoMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1WwKr7KuZ0IMvW0vFQLA BVNrCU2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZLyLstD51fo+ jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR/2Mi6PJgTiJcikp XIV11V8WY0ZkL1EMWLmIZG9xjcKV/NKggFCvsuk6SRloeMNoYDaxfzOGzGu/HQ0MkiPg== X-Talos-CUID: 9a23:T6SsQ25794jX8OwN7NssxVY4Fvt/cXHn1DSJLx6RVE1mGZq1YArF X-Talos-MUID: =?us-ascii?q?9a23=3AWXaGTQ2WE5Re2VQ5/e51t36Q4zUjwKaMEhA1t5c?= =?us-ascii?q?6nJePDBJcBQ7NszqQTdpy?= X-IronPort-AV: E=Sophos;i="6.11,192,1725314400"; d="scan'208,217";a="55010545" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oE/ThxygD7rVUwPQnjU3sK6+bV9kyZelVbJx/jpfA4D++47Mf3BOUB07MyzP67imOfzjK9Hc6q8/ba9rLx9k2De+NXtLQmki5kVdFiJlmpojg1Mum1s0Mw3BqasZqbw+Xg1q2SLiheIUwff7MHRiqVnMl9gTVCo8LhlYWBpFxd6lAfpSo1QH3Fa8VDmBlhwfqW85hN8UWQSevto+6ntNGluvfn/Pr2uyBzG9TnLhRu4/2XaY2wrEoeHvpd4UGM0HDAQgDcmzWz5jTINRZ1WOw0Kl6MazW/zNh/2+zTET1L7SjG+Uzf44ks1krDtuKc624VVyPLZf4isnKAaI2RlSwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GFyTc25f6NKWew8zGmlb82oKlOChR3VP36Bgw3WRtNU=; b=bNMTU3AOIm96XvUAq47ALQHMPfAO04eoMtieXk/fSNLTeoLh3izhhW8w7kUtjeak53lue/FgdWFg767XVDHsrAOXND826cnp5/MtzKTcTFGEc7IUOP0xmweS0E1LRhjMRHQJJpGlS/Y+45B2y6EgsqiBJmXuhM4XSohOCGPE+DjlzH/wjSoEOkbRSwec2Q1QZWS1iKtDDu28GDsAWTQOsHKB+BSqpcZiWUZsTJfZim6G9M48GQSrBeBdIn6Xmwu8H1V6+u8f4geZRpLXs9MTJOfZehoFFYF8C7496z0rqZLqxR0DRloTb1wtNlNzzVKciedjMh9d4zhBaYCtr2qzGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none To: Reshad Rahman , "yang-doctors@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-netmod-schedule-yang-02 Thread-Index: AQHbGrqvN07bAbgF8Uq62EYCmxuPnbJ/pDGw Date: Thu, 10 Oct 2024 08:24:27 +0000 Message-ID: References: <172798390985.1205347.2461480523255358589@dt-datatracker-7bbd96684-zjf54> <907450088.9329002.1728422127919@mail.yahoo.com> <2040160631.63189.1728526650781@mail.yahoo.com> In-Reply-To: <2040160631.63189.1728526650781@mail.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=038fca14-6845-4780-99cd-19abb134864b;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2024-10-10T08:24:06Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=0;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU2PR02MB10160:EE_|DU0PR02MB8644:EE_ x-ms-office365-filtering-correlation-id: 801abbdd-7ac0-40e1-5bf3-08dce904f482 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?vO+1U36BdtbPzPMfJPBXfos8icV2GiabuVZLf61tHWAugr6dKeii5ySPKI?= =?iso-8859-1?Q?rPZo0MeIvR6ZqAkjpoMSQvdKHceNiv8C6tOnjS4w+eID/I1y67Fd6iyO4O?= =?iso-8859-1?Q?enC5HLCpdQuUbOcd/Mw8NfmZq5hUsEk9f8KcJDHsFX7nAEeovbeeT9lg2k?= =?iso-8859-1?Q?xKVqE5b88HvhSLiLbFCBm0Ju+E9BEPj339ytUoY4mH2VP3Adl7GHuyrN/j?= =?iso-8859-1?Q?/BW8xp2hXm5C7pqzpOadrt1WIzsQGeF1S18wYWTwilvPUW3RhrajnBdVUB?= =?iso-8859-1?Q?bup+rGzt+HHrw4ONpwzxQdK9nCgpXtXn8B+HyVfdwB/HDqLW7wHiIS4Tax?= =?iso-8859-1?Q?2n3FfR4SCtVPpdRxUK3PprIhQ43POsRrU18x+JzvZdr4Rm7tMFHphhlYv/?= =?iso-8859-1?Q?zZlKso9/RJ2CqqtoaQnhA46xPJv1yOZqTA2AlqJAAnCuCB32Z4p5VKJ94N?= =?iso-8859-1?Q?0dukeYDKaD3/R4B84auLLR4rCqz7B2HxLmkVsBD1/y3rKhYvE2mMWVo0em?= =?iso-8859-1?Q?fbOwARi36Ow+GOOAe0az+1okrp5CisYPWQ5j+kFpgKcYpAd3WlV6UUMq2m?= =?iso-8859-1?Q?i4dMk4PVQ4a3E+oUuXwgRpB9VNp81y3JRpf5D1PT6sTzpzzbq8cz8bxpY6?= =?iso-8859-1?Q?s0hJzvDYnTfY/bE5VoyL/UAnSZOWv/NRDkp9I5Ny/GdXtpEFL/bTYtZryH?= =?iso-8859-1?Q?9iUV8NMthGDoonewA95rszssn0Dh8wFFgwmun2BTiLAihvYH7akfsElNrh?= =?iso-8859-1?Q?UP5roZMk6vp7PR1o2e8vTgpIvQq/7yu9NJ3zwGx9aeOBThlyK0Jl2xwrQ8?= =?iso-8859-1?Q?CDb/oMluB6wGaY83KqoLTNmO513LjZVtFnYxP7Vgwl3iUxQ7RwbvMQ5sEa?= =?iso-8859-1?Q?F84nI7vquZ2vJzO0EisnlOqIZ3UzCcLqFDXi6GMZnZQxoEcuBBTjjgT42r?= =?iso-8859-1?Q?stkc3Z5cOXvREMn/UmUn4x/KCUEdyScracJncfFfClYEimuu/5JLUBcnWu?= =?iso-8859-1?Q?20jqPgJocr5duNDwlP74ip4TAOPPYSUsoLCu9NrmEH99jriloZBOYsTvMu?= =?iso-8859-1?Q?7TERlsh5Lh2DeNCIzr2K/lQD6JIpMYftbppStgrHx7+mUPBzu6tFckrsQl?= =?iso-8859-1?Q?wwaj1yMjvcKj1H8L548XDT8/A4C2DHOsPhIanw+dCWqKM3zHYrjccAG48h?= =?iso-8859-1?Q?mnlUGmJb+8fP1oscq5AaN/zPncfzF0KfeZwmQ+91DKvtwEGIxlGbMjVehX?= =?iso-8859-1?Q?xgGmbL1zPerhn8q9Y6o57JzCcnqsenRI+f44Idq+iUa2w5bAoTG4Ojhiop?= =?iso-8859-1?Q?qdAp4GACuLMMlDNsvvV6yvB+0NYH3NnPz2GDWwstf+pjIeU=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR02MB10160.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?E8r2J4hb7ULv+15iedx5RCXhByS9DtoFaOaLzTTVRJINKIFzSDEiVPN28g?= =?iso-8859-1?Q?8B9lmewtmIGGeFBCLQbeUQfycs3XZU91n3so+JY8xUCC3aax6bHjnKEjHs?= =?iso-8859-1?Q?sVGB7yehBt8/jdjdbKNBg1EiEta1B0Xt8ndmtOuHi5b7+CPvpbPblKH5gU?= =?iso-8859-1?Q?evilwYmhHX5Ec9mh5/x5Sb0liMG1JmhJcZJbb9r5bdw188u8u5qtSNUBoZ?= =?iso-8859-1?Q?HsMMZhDFtKqlJfEXN4dPQPl+fbSzAhrhNXwBj2GTtlqr1Myd8j2Rd8il7s?= =?iso-8859-1?Q?F9Og+2F34aHoJX1wFfRuFnRqMg9LjSovfMMn3T4LCy2yEHGoiYQO/qcRci?= =?iso-8859-1?Q?ya5CZUa+mGlHggEhQIt7h39epN8OM5tzMUE4nH716iNkZ417OHSWhQBMm0?= =?iso-8859-1?Q?FChG1Jfx8UVUOjFDWhPGhn7yJRtweBiVED9y2NYSQhVTwtVwK80SUw070F?= =?iso-8859-1?Q?Q0sOqDxpGDxVhqR5C/FfL/wijAd2izGaMvM85l1Kg9Uwrm6sXspkJIrCUq?= =?iso-8859-1?Q?NUYH6Q7Xfj2p/qBQNEOuY6XKjoFQw21ElWI9bfj7C2MQxFczvckdi1y737?= =?iso-8859-1?Q?RBApXjGBOshbhusKEDFHiBJonl0AMjO8QWvzZ1L8VKvfadVvz9VGTDevpJ?= =?iso-8859-1?Q?Vyuk2q5JeYW+d6hUropXFBd9Oe0xSAH3IoYaH9Bv2/BXNJRO9lrLKRzlg+?= =?iso-8859-1?Q?ozCFOFS179F+z6J+55CGHYI1Jc9gBp1AE1/qAraPoMr/hL9qU2V2XriJjE?= =?iso-8859-1?Q?1H5BoiiWLpfyl8QV8iAyQ0Z2JOfGus5hXEVu9hovh8Z3VYwM3MF5T6+v63?= =?iso-8859-1?Q?hksW3yy0xn7XwYN18YBq1WzpT19n1pUVw2mFnXQ5t1bn2/6B8sVoilJoS8?= =?iso-8859-1?Q?ke+9JclXwtOUUUMtniK/M2sTVd3+LJXklHkk/cjvm0ti7fdSwC7L2I+a14?= =?iso-8859-1?Q?57KIUwXkZ5UPz8VfUQHhau9GL9muod6Y5vlG1UAgOQYn9M6S8YF35cZqWn?= =?iso-8859-1?Q?8LR9OdBZbBrYKvq7Ma4fSbZSD5vRY8rJIYnwrFbh/5LPJoXesQj5QZFDr9?= =?iso-8859-1?Q?y3Z/GK5qsFelsTKq+q6CGSma+ZhvwJA4y9BV2lPUD5TNZh5r2GY+YlQVhJ?= =?iso-8859-1?Q?yga9FzmHwtcuPHwB1Z4IIC2uscyM+vgjhK7vK5XxDhFTHsGwR68xzON9Qv?= =?iso-8859-1?Q?JB3g1lr4Mcfqhm6SlfScA8LCexjt6x3H25i6MAqhczd+ritUXgaBYI5krW?= =?iso-8859-1?Q?gQApy3M/d5mLVi7f7YuAVmJe3dWKtdOq54L+kWPiNpfL7Ea/Jxs8JlalZG?= =?iso-8859-1?Q?VXLGsZzgcytaTK0hPympBJUxkwCXhxleeN2qVBFWBZIWQiYeUJlZu+QYWW?= =?iso-8859-1?Q?2HC4A3AX5X6j0CqCTQ4pnIXRLXXsVTg+OF2NupehO2hCG5XuSWtsdB9Nhh?= =?iso-8859-1?Q?gIF3ytCA7EWuvjMUT4qKg7FSy5ZRPIaQO6OJgAvrWQclZeHUH2O5PnyGCN?= =?iso-8859-1?Q?mPvIFWs1XBhVxpO0DiECDKCf5y35ucvcBqjbB/+ZuZOUPodcAGymi7sefC?= =?iso-8859-1?Q?uWhvdcNwTdPR4td3CVkNQw7/mzpgpefvyziuREPAjrRd+A7YnbohCT3JVN?= =?iso-8859-1?Q?h9ovWCRnjrtxqqzroWMnzGIXX44fGoAi2JPeFJYp7zcZfL4FkJf050HQ?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DU2PR02MB10160EADB6A860E795E94450B88782DU2PR02MB10160eu_" MIME-Version: 1.0 X-OriginatorOrg: orange.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10160.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 801abbdd-7ac0-40e1-5bf3-08dce904f482 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2024 08:24:27.0696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wEMhUtAHAzkcJzGnyTvaYWNB4xdlZfvgYgpip5KZztOceHntzYud6JwfZKpZah1UY8VpE644SKVo3ERI/P4ZWVIyDROO2pfr27f4jv+qgjU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR02MB8644 X-TM-AS-ERS: 10.218.35.128-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-TMASE-Version: DDEI-5.1-9.1.1004-28720.006 X-TMASE-Result: 10--48.516500-10.000000 X-TMASE-MatchedRID: tUqQe/AFyGgx8pFb/GzZiFskIo6bdVEJz5ZiODdbPIr7Tdr4xDxETXF4 cK3SCp+r9p5jyBfqMtCUdUEuMEOuOZ1U1lojafr/y2tHgDROzc/nIRwNOM8986cZdxCE7oUvS94 huuRD89QxONWxQSnHSwx6TQKWelWn/cdhqO7KmN86En2bnefhoJI8FdGBUEBtNZPNAljrRtBiUs NXJCrCSd351eV+3mgbrN4LKWBTbNQBGmsibWGTbcE5XPQnBzGXr0eoqAWVAMqb8L31DoAtbCvja imTF0F+tj5oWsFHk3u9akVy1RGiljBgCmbnj9JmC/ExpXrHizytYjW9XGZ0vDp3Ry2u39u7wEtW WP2MD4zAZETqpeNEgTyDV8RhnfzbDDzmS9l9fYpb0MaM9Tusz+QydRUvl3QTPdDpPwtPbAXu7KK AW/bb2u8EEeEKKEyuMVVfQoImUynX3j/lf1V8LExUJyPnqTyG7BS7GFkJ1jK65r4XXt+nOB2JNo pizplRCF+06wRezG1GmygMKaQXUtHu43wY4QfH8boZEVitthgOkJQR4QWbsOiGP450w+pP5cUDK o8lM0mkulA7P59GuofHWxXbOCmBL8+mpRda1YMbdKgBZxTjZS3l4HRVtXvclfP6pGc11De2Ys8l fSkw0kUGO9WlsMZabCY+PnJI5xELwUwfdPoXvtXLiEcLf+DIHnddRfSLChQKDSbGHxyHAIw1TMO kyb7hFZ9lWCzZG2EGYKq163LsnUWX0DfhVamwcV3n4J/0zUOX/EBF4QXd08vDQqEdbf1Ni4HCqJ Y4pUZ0lDZbaIhGuHf74i6NFWoHhhae/WD7MmlKHhaQPPG6/o5hyiW8kJaQBNVCIloTK1P9dU4/w VV+on41niV9KymzQ2B/dw3ziQ5RGaeOJTnMW2mRqNBHmBveuME6WhSqqOEeM08RhXSpsDPZmCLo EiI8d9uEkw9oNnudqpSxrbA5GePtMyKsnKRFkU6UkIr/V+1nME/Jsn/m+g== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: 2733f6d9-e00a-4d78-8a37-ac499ccbfc94-0-0-200-0 Message-ID-Hash: HPIY4566JFHBTGMCUSYP6ACGRVD5E2FG X-Message-ID-Hash: HPIY4566JFHBTGMCUSYP6ACGRVD5E2FG X-MailFrom: mohamed.boucadair@orange.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-netmod-schedule-yang.all@ietf.org" , "netmod@ietf.org" X-Mailman-Version: 3.3.9rc5 Precedence: list Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_Yangdoctors_early_review_of_draft-ietf-netmod-s?= =?utf-8?q?chedule-yang-02?= List-Id: NETMOD WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_DU2PR02MB10160EADB6A860E795E94450B88782DU2PR02MB10160eu_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Reshad, Great, thanks. The new version that implements the changes discussed in this thread is ava= ilable at: https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang= /03/. Cheers, Med De : Reshad Rahman Envoy=E9 : jeudi 10 octobre 2024 04:18 =C0 : yang-doctors@ietf.org; BOUCADAIR Mohamed INNOV/NET Cc : draft-ietf-netmod-schedule-yang.all@ietf.org; netmod@ietf.org Objet : Re: Yangdoctors early review of draft-ietf-netmod-schedule-yang-02 Hi Med, I looked at PRs #49 and #52, the changes look good to me. Regards, Reshad. On Wednesday, October 9, 2024 at 03:13:04 AM EDT, mohamed.boucadair@orange.= com > wrote: Hi Reshad, Thanks for the follow-up. We will release a new version with the changes SO= ON. Please see inline for more context. Cheers, Med Ps: removed ACKed items. De : Reshad Rahman > Envoy=E9 : mardi 8 octobre 2024 23:15 =C0 : yang-doctors@ietf.org; BOUCADAIR Mohame= d INNOV/NET > Cc : draft-ietf-netmod-schedule-yang.all@ietf.org; netmod@ietf.org Objet : Re: Yangdoctors early review of draft-ietf-netmod-schedule-yang-02 Hi Med, Thanks for the prompt response. Please see inline (where no explicit r= esponse, default is ack). On Friday, October 4, 2024 at 04:33:51 AM EDT, > wrote: Hi Reshad, Thank you for the review. The diff to track the changes made so far can be found here: https://author= -tools.ietf.org/api/iddiff?url_1=3Dhttps://netmod-wg.github.io/schedule-yan= g/draft-ietf-netmod-schedule-yang.txt&url_2=3Dhttps://netmod-wg.github.io/s= chedule-yang/reshad-review/draft-ietf-netmod-schedule-yang.txt Please see inline for more context. I let my co-authors further comment as appropriate. Cheers, Med > -----Message d'origine----- > De : Reshad Rahman via Datatracker > > Envoy=E9 : jeudi 3 octobre 2024 21:32 > =C0 : yang-doctors@ietf.org > Cc : draft-ietf-netmod-schedule-yang.all@ietf.org; netmod@ietf.org > Objet : Yangdoctors early review of draft-ietf-netmod-schedule- > yang-02 > > > Reviewer: Reshad Rahman > Review result: On the Right Track > > Hi all, > > - 3.1 mentions 2 features basic-recurrence and icalendar- > recurrence. Is it possible that one or the other recurrence > feature may be supported for some scheduled items but not for all. > e.g. both supported for disk backups but only basic-recurrence > supported for pings to a central controller. When implementing a > standard (e.g. IETF) YANG, a vendor can use deviations to work > around that. > Worth adding some text on this? I am also not sure whether it > makes sense to have those features. > [Med] The use of one or both in the same module is specific to the context = where the groupings are used. This is why we do say the following: Implementations may support a basic recurrence rule or an advanced one as needed, by declaring different features. Whether only one or both features are supported is implementation specific and depend on specific scheduling context. Please note that we provided an example where both are used. I did see the example and that is actually what triggered the question. The example for scheduled backups has this: container basic-recurrence-schedules { if-feature schedule:basic-recurrence-supported; description "Basic recurrence schedule specification, only applies when schedule:basic-recurrence-supported feaure is supported."; leaf schedule-id { type string; description "The schedule identifier for this recurrence rule."; } uses schedule:recurrence; } container icalendar-recurrence-schedules { if-feature schedule:icalendar-recurrence-supported; description "Basic recurrence schedule specification, only applies when schedule:icalendar-recurrence-supported feaure is supported."; leaf schedule-id { type string; description "The schedule identifier for this recurrence rule."; } uses schedule:icalendar-recurrence; } Let's say the device has another module for scheduled pings (based on examp= le above): container basic-recurrence-ping-schedules { if-feature schedule:basic-recurrence-supported; description "Basic recurrence schedule specification, only applies when schedule:basic-recurrence-supported feaure is supported."; leaf schedule-id { type string; description "The schedule identifier for this recurrence rule."; } uses schedule:recurrence; } container icalendar-recurrence-ping-schedules { if-feature schedule:icalendar-recurrence-supported; description "Basic recurrence schedule specification, only applies when schedule:icalendar-recurrence-supported feaure is supported."; leaf schedule-id { type string; description "The schedule identifier for this recurrence rule."; } uses schedule:icalendar-recurrence; } How would the device indicate e.g that it supports icalendar-recurrenc= e-schedules but not icalendar-recurrence-ping-schedules? [Med] If the base schedule features are not sufficient, and such control is= needed for a specific context, the device module can define dedicated feat= ures for that. Not via the feature since both use the same feature in the if-feature stat= ement. And the feature support doesn't depend on the context afaik, it is e= ither supported or not supported. So I think we'd need to define features f= or where the groupings are used and these features would depend on the feat= ures defined in this document? > - Section 3.2: one-shot is clear but the difference between period > and recurrence is not. > [Med] The period is similar to one-shot with the exception that it does not= disable itself once the scheduled action is terminated. Recurrence is more= a schedule that occurs many times (e.g., periodic). This subtlety, i.e. period v/s recurrence, still escapes me. If recurr= ence is periodic, then it sounds a lot like "period" :-) If it's clear for = everyone, maybe I need to look at the document again... But some text in 3.= 2 may help. [Med] recurrence is more generic than "periodic". Added some text to clarif= y this: https://github.com/netmod-wg/schedule-yang/pull/49/files > > - Section 3.3.1, what is the difference between validity and max- > allowed-end, not clear to me. [Med] These cover two distinct aspects of activating a schedule (start vs. = end). Can you please let me know what is not clear in the following text: The "validity" parameter specifies the date and time after which a schedule will be considered as invalid. It determines the latest time that a schedule can be executed by a system and takes precedence over similar attributes that are provided at the schedule instance itself. And The "max-allowed-end" parameter specifies the maximum allowed end time of the last occurrence. A requested schedule will be rejected if the end time of last occurrence is later than the configured "max- allowed-end" value. Thanks. What would help confirm my understanding, or not, is an example with b= oth in the appendix. Thanks. [Med] Noted: https://github.com/netmod-wg/schedule-yang/issues/50 > > - Section 3.3.3, should frequency be frequency-unit? Strictly > speaking, that's an interval-unit and not a frequency-unit? It > does seem odd to me to have frequency and interval in the same > grouping... And not a fan of identities such as "daily", > "minutely", "secondly": although those are English words I don't > think they mean what you're trying to convey here. But if you > rename frequency to interval-unit, you can use "day", "hour", > "minute", "second" etc for interval-type (renamed from frequency- > type). > [Med] We use frequency as we are relying upon RFC5545 for these matters. I have 2 problems with this: - RFC5545 is for iCalendar but the use of that definition of frequency has = leaked into use-cases not requiring iCalendar - Terminology section mentions iCalendar (RFC5545) but no mention of freque= ncy. Please add it there. I am not a fan of mixing interval and frequency. But I'll leave it to the W= G. [Med] Thanks. Added new terms: https://github.com/netmod-wg/schedule-yang/p= ull/52/files > - Section 3.3.X, many names have recurrence- as prefix e.g. > recurrence-first, recurrence-bound, recurrence-description. Best > practice is to remove the > recurrence- prefix and put all these nodes in a recurrence > container. You might to rework the groupings a bit but it should > be straightforward. [Med] We are aware about that guidance however we added "recurrence-" for s= ome of the items you mentioned in order to cover cases where, e.g., both pe= riod and recurrence are used within the same choice. Please see https://git= hub.com/netmod-wg/schedule-yang/pull/37 where we made that change. The fact that the recurrence- prefix is used for some leaf nodes to me= indicates that a recurrence container would be useful. [Med] Will need to think about this one further to see if a surrounding con= tainer makes things easily consumable for future modules, etc. > - recurrence-bound, I don't understand the use of the word "bound" > here, is it as in "boundary"? Maybe call it limit? > [Med] This is more about limit. FWIW, "bound" was used here as we leverage = RFC 5545 where we "grabbed" some naming. I took a look at RFC5545 and it's still not clear. The YANG descriptio= n here says "Modes to bound the recurrence rule.", still not clear to me. I= f not "recurrence-limit", what about "recurrence-end", "recurrence-max", ma= y be not ideal but IMO than recurrence-bound. [Med] Changed to =AB end =BB. _________________ ______________________________ __________________________= ____ ______________________________ _ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_DU2PR02MB10160EADB6A860E795E94450B88782DU2PR02MB10160eu_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Reshad,

 

Great, thanks.

 

The new version that implements t= he changes discussed in this thread is available at: https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/03/<= /a>.

 

Cheers,

Med

 

De : Reshad Rahman <reshad@yahoo.com&= gt;
Envoy=E9 : jeudi 10 octobre 2024 04:18
=C0 : yang-doctors@ietf.org; BOUCADAIR Mohamed INNOV/NET <mo= hamed.boucadair@orange.com>
Cc : draft-ietf-netmod-schedule-yang.all@ietf.org; netmod@ietf.= org
Objet : Re: Yangdoctors early review of draft-ietf-netmod-sched= ule-yang-02

 

Hi Med,

 

I looked at PRs #49 and #52, the changes look good to me.<= o:p>

 

Regards,

Reshad.

 

 

 

Hi Reshad,

 =

Thanks for the follow-up. We will release a new version with the chan= ges SOON.

 

Please see inline for more context.

 

Cheers,

Med

 

Ps: removed ACKed items.

 

De = : Reshad Rahman <reshad@yahoo.com>
Envoy=E9 : mardi 8 octobre 2024 23:15
=C0 : yang-doctors@iet= f.org; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc : draft-ietf-netmod-schedule-yang.all@ietf.org; netmod@ietf.org
Objet : Re: Yangdoctors early review of draft-ietf-netmod-sched= ule-yang-02

 =

 

Hi Med,

 =

Thanks for = the prompt response. Please see inline <RR> (where no explicit respon= se, default is ack).

 =

On Friday, Octo= ber 4, 2024 at 04:33:51 AM EDT, <mohamed.boucadair@orange.com> wrote:

 

 

Hi Reshad,

Thank you for the review.

The diff to track the changes made so far can be found here: https://author-tools.ietf.org/api/iddiff?url_1=3Dhttps://netmod-wg.github.i= o/schedule-yang/draft-ietf-netmod-schedule-yang.txt&url_2=3Dhttps://net= mod-wg.github.io/schedule-yang/reshad-review/draft-ietf-netmod-schedule-yan= g.txt

Please see inline for more context.

I let my co-authors further comment as appropriate.

Cheers,
Med

> -----Message d'origine-----
> De : Reshad Rahman via Datatracker <norepl= y@ietf.org>
> Envoy=E9 : jeudi 3 octobre 2024 21:32
> =C0 : yang-doctors@ietf.org
> Cc : draft-ietf-n= etmod-schedule-yang.all@ietf.org; netmod@ietf.org
> Objet : Yangdoctors early review of draft-ietf-netmod-schedule- > yang-02
>
>
> Reviewer: Reshad Rahman
> Review result: On the Right Track
>
> Hi all,
>

> - 3.1 mentions 2 features basic-recurrence and icalendar-
> recurrence. Is it possible that one or the other r= ecurrence
> feature may be supported for some scheduled items but not for all.
> e.g. both supported for disk backups but only basic-recurrence
> supported for pings to a central controller. When implementing a
> standard (e.g. IETF) YANG, a vendor can use deviations to work
> around that.
> Worth adding some text on this? I am also not sure whether it
> makes sense to have those features.
>

[Med] The use of one or both in the same module is specific to the context = where the groupings are used. This is why we do say the following:

  Implementations may support a basic
  recurrence rule or an advanced one as needed, by declaring different=
  features.  Whether only one or both features are supported is   implementation specific and depend on specific scheduling context.
Please note that we provided an example where both are used.


<RR> I did see the example and that is actually what triggered the qu= estion.

 

The example= for scheduled backups has this:

    =
     container basic-recurrence-schedules {
    =
       if-feature schedule:basic-recurrence-s=
upported;
    =
       description
    =
         "Basic recurrence sch=
edule specification, only applies when=

    =
          schedule:basic-recur=
rence-supported feaure is supported.";
    =
       leaf schedule-id {
    =
         type string;
    =
         description
    =
           "The sche=
dule identifier for this recurrence rule.";
    =
       }=

    =
       uses schedule:recurrence;
    =
      }<=
/o:p>
  
    =
     container icalendar-recurrence-schedules {<=
span style=3D"color:#26282A">
    =
       if-feature schedule:icalendar-recurren=
ce-supported;
    =
       description
    =
         "Basic recurrence sch=
edule specification, only applies when=

    =
          schedule:icalendar-r=
ecurrence-supported feaure is
    =
          supported.";
    =
       leaf schedule-id {
    =
         type string;
    =
         description
    =
           "The sche=
dule identifier for this recurrence rule.";
    =
       }=

  
    =
       uses schedule:icalendar-recurrence;
    =
     }<=
/span>

 

Let's say t= he device has another module for scheduled pings (based on example above):<= o:p>

    =
     container basic-recurrence-ping-schedules {=

    =
       if-feature schedule:basic-recurrence-s=
upported;
    =
       description
    =
         "Basic recurrence sch=
edule specification, only applies when=

    =
          schedule:basic-recur=
rence-supported feaure is supported.";
    =
       leaf schedule-id {
    =
         type string;
    =
         description
    =
           "The sche=
dule identifier for this recurrence rule.";
    =
       }=

    =
       uses schedule:recurrence;
    =
      }<=
/o:p>
  
    =
     container icalendar-recurrence-ping-schedules {
    =
       if-feature schedule:icalendar-recurren=
ce-supported;
    =
       description
    =
         "Basic recurrence sch=
edule specification, only applies when=

    =
          schedule:icalendar-r=
ecurrence-supported feaure is
    =
          supported.";
    =
       leaf schedule-id {
    =
         type string;
    =
         description
    =
           "The sche=
dule identifier for this recurrence rule.";
    =
       }=

  
    =
       uses schedule:icalendar-recurrence;
    =
     }<=
/span>
  
<RR> How would the device indicate e.g that it supports icale=
ndar-recurrence-schedules but not icalendar-recurrence-ping-schedules?
[M=
ed] If the base schedule features are not sufficient, and such control is n=
eeded for a specific context, the device module can define dedicated featur=
es for that. 
&n=
bsp; 

 Not via the feature sinc=
e both use the same feature in the if-feature statement. And the feature support doesn't depend on the context af=
aik, it is either supported or not supported. So I think we'd need to defin=
e features for where the groupings are used and these features would depend=
 on the features defined in this document?


> - Section 3.2: one-shot is clear but the difference between period
> and recurrence is not.
>

[Med] The period is similar to one-shot with the exception that it does not= disable itself once the scheduled action is terminated. Recurrence is more= a schedule that occurs many times (e.g., periodic).

 

<RR> This subtlety, i.e. period v/=
s recurrence, still escapes me. If recurrence is periodic, then it sounds a=
 lot like "period" :-) If it's clear for everyone, maybe I need t=
o look at the document again... But some text in 3.2 may help.

 

[Med] recurrence is more generic than “periodic”. Add= ed some text to clarify this: https://github.com/netmod-wg/schedule-yang/pull/49/files


>
> - Section 3.3.1, what is the differ= ence between validity and max-
> allowed-end, not clear to me.

[Med] These cover two distinct aspects of activating a = schedule (start vs. end). Can you please let me know what is not clear in t= he following text:

  The "validity" parameter specifies the= date and time after which a
  schedule will be considered as invalid.  It= determines the latest
  time that a schedule can be executed by a system= and takes precedence
  over similar attributes that are provided at the= schedule instance
  itself.

And

  The "max-allowed-end" parameter specif= ies the maximum allowed end
  time of the last occurrence.  A requested s= chedule will be rejected
  if the end time of last occurrence is later than= the configured "max-
  allowed-end" value.=

Thanks.

<RR> What would help confirm my un=
derstanding, or not, is an example with both in the appendix. Thanks.
[M=
ed] Noted: https://github.com/netmod-wg/schedule-yang/issues/50=

 

>
> - Section 3.3.3, should frequency be frequency-uni= t? Strictly
> speaking, that's an interval-unit and not a freque= ncy-unit? It
> does seem odd to me to have frequency and interval= in the same
> grouping... And not a fan of identities such as &q= uot;daily",
> "minutely", "secondly": althou= gh those are English words I don't
> think they mean what you're trying to convey here.= But if you
> rename frequency to interval-unit, you can use &qu= ot;day", "hour",
> "minute", "second" etc for int= erval-type (renamed from frequency-
> type).
>

[Med] We use frequency as we are relying upon RFC5545 f= or these matters.

<RR> I have 2 problems with this:<=
/span>
- RFC5545 is for iCalendar but the use of that definition of freque=
ncy has leaked into use-cases not requiring iCalendar
- Terminology section mentions iCalendar (RFC5545) but no mention o=
f frequency. Please add it there.=

  
I am not a fan of mixing interval and frequency. But I'll leave it =
to the WG.
[M=
ed] Thanks. Added new terms: https://github.com/netmod-wg/sched=
ule-yang/pull/52/files 
  

> - Section 3.3.X, many names have recurr= ence- as prefix e.g.
> recurrence-first, recurrence-bound,= recurrence-description. Best
> practice is to remove the<= br> > recurrence- prefix and put all these nodes in a re= currence
> container. You might to rework the groupings a bit= but it should
> be straightforward.

[Med] We are aware about that guidance however we added= "recurrence-" for some of the items you mentioned in order to co= ver cases where, e.g., both period and recurrence are used within the same choice. Please see https://github.com/net= mod-wg/schedule-yang/pull/37 where we made that change.

<RR> The fact that the recurrence-=
 prefix is used for some leaf nodes to me indicates that a recurrence conta=
iner would be useful.
  
[M=
ed] Will need to think about this one further to see if a surrounding conta=
iner makes things easily consumable for future modules, etc.=


>=
 - recurrence-bound, I don't understand the use of the word "bound&quo=
t;
> here, is it as in "boundary"? Maybe call it limit?
> 

[Med] This is more about limit. FWIW, "bound" was=
 used here as we leverage RFC 5545 where we "grabbed" some naming=
.
<RR> I took a look at RFC5545=
 and it's still not clear. The YANG description here says "Modes to bo=
und the recurrence rule.", still not clear to me. If not "recurre=
nce-limit", what about "recurrence-end", "recurrence-ma=
x", may be not ideal but IMO than recurrence-bound.
  
[M=
ed] Changed to =AB end =BB.
_________________ ______________________=
________ ______________________________ ______________________________ _
Ce message et ses pieces jointes peuvent=
 contenir des informations confidentielles ou privilegiees et ne doivent do=
nc
pas etre diffuses, exploites ou copies s=
ans autorisation. Si vous avez recu ce message par erreur, veuillez le sign=
aler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion,
Orange decline toute responsabilite si c=
e message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may con=
tain 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.
____________________________________________________________=
________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_DU2PR02MB10160EADB6A860E795E94450B88782DU2PR02MB10160eu_--