[netmod] Examples for groupings (was RE: Yangdoctors early review of draft-ietf-netmod-schedule-yang-02)
mohamed.boucadair@orange.com Wed, 09 October 2024 06:07 UTC
Return-Path: <mohamed.boucadair@orange.com>
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 6DE3BC151069; Tue, 8 Oct 2024 23:07:51 -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 XaG2PFud_wVG; Tue, 8 Oct 2024 23:07:47 -0700 (PDT)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.239]) (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 1DA34C151068; Tue, 8 Oct 2024 23:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1728454066; x=1759990066; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=VCf09oXHmIeP0jWE8msh2ih7dpa93JgRx3wDeD04ROM=; b=ZXLBh1y4mNbysmKSGCbBYzf6oOJPl209EYkEl96CdZsmTP/ypdH2+0lm OCE2UJNi+ZrDpE2v2o6VadoxBR6tSiwl+A5Yg2OuyQVnR36VIRxBRELHZ O4PrYg5EwG9sfIyyFgO8GKVNbdfSYNQXhzLOi7y58cKe9WkXXxkyuqq7J fZDOFChNrz2FVhcDcUs4ze30UuySt8RM7TluIFsqDP47whNw3vy/iyo0y 9aYBNMihuzcyBPbMGIV8f2yed+RBJUwtC3TVpIXn5BpohOmqFkAZzp0cW XA6ZF8Hljm9ozqcEvMdXnqqV+9cDpzrCUHh1F5TVB1N/Xc5voRI3Mfi54 g==;
Received: from unknown (HELO opfedv1rlp0h.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2024 08:07:44 +0200
Received: from unknown (HELO opzinddimail2.si.francetelecom.fr) ([x.x.x.x]) by opfedv1rlp0h.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2024 08:07:44 +0200
Received: from opzinddimail2.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with SMTP id 1A531D2C43BE; Wed, 9 Oct 2024 08:07:44 +0200 (CEST)
Received: from opzinddimail2.si.francetelecom.fr (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 26F5ED2C454B; Wed, 9 Oct 2024 08:06:13 +0200 (CEST)
Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail2.si.francetelecom.fr (Postfix) with ESMTPS; Wed, 9 Oct 2024 08:06:13 +0200 (CEST)
Received: from mail-vi1eur02lp2044.outbound.protection.outlook.com (HELO EUR02-VI1-obe.outbound.protection.outlook.com) ([104.47.11.44]) by smtp-out365.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2024 08:06:13 +0200
Received: from DU2PR02MB10160.eurprd02.prod.outlook.com (2603:10a6:10:49b::6) by AM7PR02MB6146.eurprd02.prod.outlook.com (2603:10a6:20b:1af::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.23; Wed, 9 Oct 2024 06:06:09 +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; Wed, 9 Oct 2024 06:06:09 +0000
From: mohamed.boucadair@orange.com
X-TM-AS-ERS: 10.106.160.162-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@EUR02-VI1-obe.outbound.protection.outlook.com
Received-SPF: Fail (smtp-in365b.orange.com: domain of mohamed.boucadair@orange.com does not designate 104.47.11.44 as permitted sender) identity=mailfrom; client-ip=104.47.11.44; 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@EUR02-VI1-obe.outbound.protection.outlook.com designates 104.47.11.44 as permitted sender) identity=helo; client-ip=104.47.11.44; receiver=smtp-in365b.orange.com; envelope-from="mohamed.boucadair@orange.com"; x-sender="postmaster@EUR02-VI1-obe.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:lPjoXqhgM0XKOgwChsUkCP7AX161fhcKZh0ujC45NGQN5FlHY01je htvUDiHMv6IZ2L3eY0gbIWw9BhVu8DQzt82GlFvpX8yFiIW8JqUDtmndUqhZCn6wu8v7a5EA 2fyTvGacajYm1eF/k/F3oDJ9CU6j+fRLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4 bsemOWBfgb8s9JIGjhMsf7a8Es+5K2aVA4w5TTSW9ga5TcyqFFFVPrzFYnpR1PkT49dGPKNR uqr5NlVKUuAon/Bovv8+lrKWhViroz6ZGBiuVIPM0SWuSWukwRpukoN2FjwXm8M49mBt4gZJ NygLvVcQy9xVkHHsLx1vxW1j0iSMIUekIIrL0RTvuSIz2abeSC18c9pL2InYI4Y/7lYBmFRo KlwxDAlNnhvhsqb/YjjEKxSp51mK8PmeoQCpntn0DfVS+48RozOSLnL4tke2yosgsdJHrDVY M9xhThHNUycJUEQfA5OTs5i9AurriGXnzlwrVWVrK867y7ZyxF62bTkMcD9fcaDQ8pY2E2fo woq+kykXkhGaIzDkVJp9FqVieTfxyz8WLssO/qg89gzhU+a4mMcXUh+uVyT+qLj1hHWt8hkA 1YZ4SonoYAj/UysSZ/2WBjQiG+NuBFZV91bD+og8ymMx7bapQGDCQAsQiRIZsBjtcIqS3ks2 0OMmN+sHjdvvbGITX/Y576SonW7PSw9LGIea2kDVwRty9/uvIQ0gjrOQ8ptVqmvgbXI9SrYx jmLqG0ghuwekNRTjaGjpwib33Sru4TDSRMz6kPPRGW54whlZYmjIYu19Vzc6vUGJ4GcJrWcg JQas9Oex70EVsi/riuuY/RQH7GsuNmCMCKJ1DaDAKId3ziq/neie6VZ7zd/OFplP644ldnBM B67VeR5tM47AZe6UZKbdb5dHOwD8cDd+TnNU/nVap9QY8F8aRXfpiV2PxbMgybqjVQmlrw5N dGDa8GwAH0GCKNhij2rW+Ma1rxtzSc7rY8yeXwZ50r2uVZ9TCfOIVvgDLdoRr1khE9jiFiIm +uzz+PQl31ivBTWO0E7C7I7I1EQNmQcDpvrscFRfePrClM5QjF9UqWKm+NwJdMNc0FpegHgr iDVtqhwmAuXuJE7AVvWNy4LhE7HAcgg8SlrZXxE0aiAhSR8PN33hEvgS3fHVeJ8rrA8pRKFZ /wEcN+HGfNBVnzM/C4FBaQRX6QzHClHcTmmZnL/CBBmJ8AIb1WQprfMIFGznAFQVXDfnZVl/ NWdOvbzGsdrq/JKV5qNN5pCDjqZ4RAgpQ6FdxKSeIYKKRyyq9MCxu6YpqZfHvzg4C7rnlOyv zt6yz9BzQURi+fZMeUlhJxoa6+ELtEmRA9kPjCe6ry7cy7H4mCk3IlMFv6SeizQX3/1/6PkY vhJy/b7M7sMm1MiX09UDeNw1axnjzfwj+Yy8+imNC2jg5eX5ndIJWOP28ZC8KZKw9e1fCOoD 1mX9IAy1aqhZKvYLbLJGDcYUw==
IronPort-HdrOrdr: A9a23:R4zxQq52gZY83Bk4PQPXwUOBI+orL9Y04lQ7vn2ZFiY5TiXIra qTdaogviMc0AxhIE3Jmbi7WJVoMkmsjqKdgLNhdYtKMzOW3FdAQLsN0WKm+UyYJ8SczJ8X6U 4DSdkYNDSYNzET4anHCUuDYrAdKbK8gcOVbJLlvhJQpHZRGsNdBmlCazqzIwlTfk1rFJA5HJ 2T6o5svDy7Y0kaacy9Gz0sQ/XDj8ejruOqXTc2QzocrCWehzKh77D3VzKC2A0Fbj9JybA+tU DYjg3C4Lm5uf3T8G6R64aT1eUYpDLS8KoDOCW+sLlUFtwqsHfqWG1VYczNgNnympDs1L9lqq iIn/5qBbUI15qYRBDJnfKq4Xir7N9m0Q6c9beV7EGT3fDRVXY0DdFMipledQac4008vMtk2K YOxG6BsYFLZCmw6xgVyuK4Ii2CrHDE1UYKgKoWlThSQIEeYLheocgW+15UCo4JGGb/5Jo8GO djAcnA7LIOGGnqJkzxry1q2pihT34zFhCJTgwLvdGUySFfmDR8w1EDzMISk38c/NY2SoVC5e 7DLqN0/Ys+OPM+fOZ4HqMMUMG3AmvCTVbFN3+TO03uEOUdN3fEu/fMkccIDSGRCe81JbcJ6e T8uQljxBAPkmrVeLyz4KE=
X-Talos-CUID: 9a23:uQ2YWG4mpvA8V2EGitss704/R8p+K0/ny1TzMhK7CWM2Z7qVVgrF
X-Talos-MUID: 9a23:WchTWQTJ6VvcuOq7RXTVizpybshv452QJwcVlLNfvtuNESN/bmI=
X-IronPort-AV: E=Sophos;i="6.11,189,1725314400"; d="scan'208,217";a="54144840"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ygmazkmNtOTLR17EhvWlXxauESMXTSSABxAlPSJjBh5QkDOBGqBDFaRK9Sg1MhTylwEIQeUlwl2+I2vVIg5JcL/Q+bTJw4RRQQJZmL1APPZcxDUIc7sehA4EV4yYz2r7gNVA3Yz2QxLDzl14fqX7hAEhmCKCUheDRPNVb4cQO8WpbRvdUB3L4e78RsJcdDPvFe+cgYGzJ0Pqpc1gk3iZJs15ZxzDHD6ptfO96B6jzBQiDq/Shz9M/5+eqXEgM7ryS3L6odx7eMbDNVXC4s7h/ukl/n8g0ECEl8iKyT0QDjhaibzi2ZcdC5+4Bbly/Apy0+jPvcDGIT9/GAItLAr/OA==
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=04A6cIalOTfgAhRFclZgrOjS17AxE7W2VbyyGdNigKY=; b=kfy9KhdodW2rDDlvFKWBriWfA0zJb/Mu/npA+SrpCWBO7sjkdMu1k4ZTl6oraaMpULIP1jP7yawnn3BJfmnp18d5LErmL7JCE7u6JBpfaJsnQXjjqZ4IsJb1R86AxzBhZDVT/pIVJV4/2QDqmMg49o7Avt4Y/QPZGjnK2r/fOfhf1tE7aw0DhAngU6C5+Mb44PFz2O7HpiyNDne+Q01lIPI4g4uiz13bngKvk+H2CtlhUPHNFZrOFkOF9oN0zAU/lqSmiPu3pe54LZ7bBnCkOun9WRunmjOSvksfgX4ZLL7xdDcAt4zDYvZb6ViO1pG8aKSjvemo9N21zOYwltucjw==
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 <reshad@yahoo.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: Examples for groupings (was RE: Yangdoctors early review of draft-ietf-netmod-schedule-yang-02)
Thread-Index: AdsaEVKRmQBmQ2V+SRGUJPb4ChEPgA==
Date: Wed, 09 Oct 2024 06:06:09 +0000
Message-ID: <DU2PR02MB1016085F01E29A03610535197887F2@DU2PR02MB10160.eurprd02.prod.outlook.com>
References: <172798390985.1205347.2461480523255358589@dt-datatracker-7bbd96684-zjf54> <DU2PR02MB10160FD115414264B311860C688722@DU2PR02MB10160.eurprd02.prod.outlook.com> <907450088.9329002.1728422127919@mail.yahoo.com>
In-Reply-To: <907450088.9329002.1728422127919@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=59e9cf59-9550-4cc5-8efb-0a9ab0dba288;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-09T05:56:50Z;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_|AM7PR02MB6146:EE_
x-ms-office365-filtering-correlation-id: 42162dbe-8477-45c9-5651-08dce828786c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700018;
x-microsoft-antispam-message-info: AD4deL0Gk9V7y8x73yq+prKzeVWwvjFZgDzjE51Jd9w/NjRJS3vYx7Wl5GKXptq03gOieu1wXRcRSieyUcrHr4rpCDDz1D3LPFaN6T4MJXeRJ6hV1JDzO9FAdKGPh+6Lgxxy0m2Yc1OTBg1AaZG5DLB8GVIiQsU3B1+2IzRxrd1TZ0LrZqT6XQwhaXy8qnby91kJirWLk1SY9eBCMIb3whX0xC6K9gyy+05uM0mKq+jtk9idblLEBv03LLEiN+uY1eZpsi66x9FyHhNdsTjuzU2Os6ANAwQxnqQAUAFfCQ5UWajXZFk2YIBPtxvqnBwH4hYs2PjgXz2AjwkV+7beaFRfkDR29/s646zBC6PkgwMAolChWsR121vxQHADeOLtMG8oGE6JM7JYUqWrGowiSXs6KplVJZpEwS7Gm/vszqhnCK3QAnTKLxtVrAX41EJL1UdrhqQ8y2hiRnPpht/1hHlntneFuB6WrHtio8l1AMJN+Q58YtBbayLfzvheVJR15kyrghCgWjr0fn+6GOt1IptlG11vwuq4eWdzd+F1lUxsK8bMxkCWuM2SIXHlXLN1LuAXY4BIPf2hkpmyehUZuKM3AkDnJyzDwT2w3NdujfT3efrUlvqVWGwdh9FovinRech2cgy9j0ylRFgq0UDn+jaNCDDNqKZsGgZXD+SBAzx/UeJdkBYrLWgDr4a5fnOdyRfGJF8n36z8JqmT2CRc/iseasnHKAP3s6e4aEiuOc23ptnxS44Gp3cO+wxwnjUacixY4VAsxTWfsfbRE8Owf+A8MiQmuQWq4xGBqbn4B1mXYs/zh72Q/+XYzJ++7GuwQeLr1yjFP3hDJengZQnFtmVcoD44HADPoBycy0igoO6Ht+3GiSBes50EuxliGOZhGrDBwKrbq/Impirb0t5oW2YbVhVgTd5X5PIH0Ya1A/JDskvw3Z4oh5spAYZFl73PJlisAVTGf/7bZ3Uzay/sRDanQdCxx5J28Mshb0PXQYESCFEIJIZYfIjNgnJbOijKkXkfJoYUL5jXmwgXKDBL+Tn54qcg/kPM6xpgefEu4AuQ03J7NtAVFStQqok5lbNPhSbVun0ZVNUbnm7xryq19IesGxjQeKE2pp5TAP8Yp6Gv0sI7sd8uADitOc49KhlAzRSycjGe+fFcqSw5noT/yU0DNXVDfSX+nlvYl2etN6Fng0WY6e//p2CKjRSWt5V781ERgjC9ZkNp3ksDUEbNZv6KfqYjg+4zSfv3gqWxaJR7aPD9LFp7vkxkazQpI3zwbvgo1ch7DMoxBOdcAviF2Q==
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)(366016)(376014)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: A73Mh2/mPfkPwbGsqV8UWVE/XWcMVJYgVQw7diUkTAF048EX4GfQOdw1aiyV1kBjn8mYonG6JrQIMD+2FhK0EUejkr6xQ/6uNO6CbMLFk2WiXuWlNi71WO1LpHizRxVBYAJlnissLlBcG8QIr3cwrSu1JV3lYIerS/2XZyRO/Qc0xEx0QGdCcdSOG9JjfjJ2z1W8Z0zy9xiv6vh1rUtUW9gJfWcEq1efYrJ1JVRWhflvqESFNyuuzIPUeLO5cl28FoavZd1CmLhy++xl6HGRqj2xRPp/y57UhO9tdvWkv/U/leyepo+xrzbBbpBPqOnc7qtHZAXcTFYDO0nMoxFue4CfXP2GWcHoBc/rfJMa2dzTeLm7pL07UmxMpz2W7CgO5ZoIRM9niVIONZg2DoDbr8JhnLYvGOFTjFkBr5E7iNZcb93SMwlymAC08nRaaietFZKMOlYdyq25Y4cXWIzZqYUhX8ELqV9ObVsgDBXkouEjfuq06ov72CLDpqdYI0OiQjpUNB1ROMCTSbaLalo4qtB4M7cskuMVe8izuQoW3o81utZ1dbyZM2rBWFf24oklfA5haIUd3+q+x9xDuxBKhFcabu06opxvL4VRErxdqIog6uHtn2WpTcJIq7BpiLg0m9vxYkGEo633jL09uQGPci2M7Udg0IlpW4H0b/yY/WmeBQMSQvm+28oQJ/4xs3cNIDkTUM2RRfGuIfDlcdPGrRuvv1rYaMfCz1LVGaK+oNtmcF6AEBawSJMLy5UMFQXGHY2qtJLF6EQLKF9uunOyONgcW+IZ701BOfuDTRii9XGmv9u8e0YNHTsjo085BjhVrmhv8fAJMivCQev0YLcL6N+WU/HgLf4xhLN8eMgSoO/MnfvxhWPaMhIgaS30mWUXsvg+Qq9rg4Ga0F/Y9FAFR5MCL92BG8+uP0GQGdHw7hqK1n4HJTmdi57c09z9KKprFwhmV03KUwcuzZYkpvi4VQWBD0pZNqAehk3fGNESeCf81I+M99cVrt3Y7naw4C2VVLzzPiNZH72K3AjKzeC4B1ZumLyJ3/MITmLehk3qaDi8uHfRAbNwZbZv3IteauTUbnr2W+dtsyxTD908uVS1qSxQtLPSe3pGxHPWWBYxD4oFeUMTsQWcdPotPhOQtRMHV7JA1FXpzmfNimc0Y2ohlfXV8TpvlH1kdTSj7SxYo2bRJnbNxq7Q3H8uDTT8r6VTi3GbTAO8xzu4RQohHeL/m7ysAGH9su/lzlmvWtgccAbOARSL3qdBnMfhq7B7HiWhzbRA4B+0D6jfRKZSZxwSjZOBEWVqsIX0bt4r7VT4MKmWs4xJMHOPu3bQbUm7Wv5FAgIOLY31byQzXPHQmpO6DMis0X3GKj467ve1mh4QuXclA7hsuWUsmn6s7dy5KDWxDd+WUholKZvjBA0+y1LAYNii3EWYzxN56XvJfVbr8A36U3hzu8CKvuUJhYnMp7lNKSafzBiaOh5ccKySNRqwSTuFl9iun1LwkdNuAMVp5Yre10n6v+pB1ACp9RwO49IhP6qpRHu9SOTMjKdwpCRSk6qlPg5WgmP7sIKNMkYbxsH0UeDTzuZYTLWb3eLZVVWT
Content-Type: multipart/alternative; boundary="_000_DU2PR02MB1016085F01E29A03610535197887F2DU2PR02MB10160eu_"
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: 42162dbe-8477-45c9-5651-08dce828786c
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2024 06:06:09.5965 (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: F3rEzVMt09xBqVj5so0UtzQZVSY3CQAN7Do6cBKynCR/G7/FF5W9eWXjI+wkooGhr15dbj7J2Gip9sQCfiAnJtNXBpq7Fd05y2kXMca1w90=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR02MB6146
X-TM-AS-ERS: 10.106.160.162-127.5.254.253
X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ==
X-TMASE-Version: DDEI-5.1-9.1.1004-28718.005
X-TMASE-Result: 10--45.147900-10.000000
X-TMASE-MatchedRID: tUqQe/AFyGgx8pFb/GzZiJGAt645FF0SlJBOf2Mfu5qsg78TAYp7icUg yK6VkMQRt3oHtbrI7QQ+D3J+ThgLRt+pUF0HsjxRSb0iodcjdvrTXj4xOnxHE87ZvzOqqgS38QH ZNahj3nwsjvWKImPjneSOZMGfgLFkOIQ9GP2P2u8ikU4xQFgb7jBvpOytqfK/gK6qCGa1Z9f59r irHyvjtWdknkELQxFlrWd6mzUt7wFvW5ELR8KA6rDeJMB5o2kw1L7t3plRainfMRHs1Hbti7K5C PyhsfLw5N88eFlUbyOo6c8tZT77+7i7edL7cQQOpPMmjQJmXyGNnAdfrf4ZXrSnJfu7KIKt16YO ozJj1NBs00ZABHv2qI+eiI05y0fpuW77/y896shy4VFP6muDhpnpTtCGSpGeaz+rBXOCRlzzviv t6h7lbHYRqP4gGEq0eDOKCQxQpCwiLmf+ghTG/6FiPo/lDWJLFXXsIV9lgAFkG4EtozBz35xWn6 dtA5GQ+5pnpESsyLAdwv8JHZzayiAWHOR37+AT9avse85ISVrIgofMgahPrSHOp88RcJy0x8o59 scni6xuAjj4f+4n7bBTVw0w1poQCKFDk1kJexIQdBDWZ8Nb7cUs8D7dqrW2RKLa632yXzQdzh1p XIOCCnmxErTrAdXhMc6bq2/AqmA4ZNXh8UPrIPG6GRFYrbYYDpCUEeEFm7DMruPn95vr5eBF8Ne M5rayicGme+3LESA0hImSnj/ka79A3Bl1/DcVCe1sPOFCidNJEjJjpEhCn9HNX8uxBymLIawtMs UJChUA9kG/R4Hl8gE4dbnyjMJaRaPXfvn+kepKHhaQPPG6/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: 1fa6f9ab-ae5e-44bf-840b-4643d6f7f3ba-0-0-200-0
Message-ID-Hash: CMVAGIKJ7IMZFTBCOM2YFUCLBCOGJQQ4
X-Message-ID-Hash: CMVAGIKJ7IMZFTBCOM2YFUCLBCOGJQQ4
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" <draft-ietf-netmod-schedule-yang.all@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [netmod] Examples for groupings (was RE: Yangdoctors early review of draft-ietf-netmod-schedule-yang-02)
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pRYsxmecXi3l5JPm41B0bnkQdlg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>
Hi Reshad, Thanks for the follow-up. However, with my 8407bis editor hat, I'm extracting this specific point: == > - The examples in appendix A are all based on the groupings. But > since the groupings will not be used in a stand-alone way, I think > the examples should illustrate a usage of the groupings. For > example, the examples could be based on the example YANG modules > in Appendix B. > [Med] We do have a note about the usage here: " Note that a "grouping" does not define any data nodes in the schema tree; the examples illustrated are thus for the ease of understanding." That's said, we will consider your suggestion further. Thanks. <RR> Ack. But these examples can't be validated (e.g using yanglint). == As I said, I'm OK to make the change. However, I also see a similar approach to the one we followed: e.g., draft-ietf-netconf-tcp-client-server/draft-ietf-netconf-udp-client-server/.. include a note: <!-- The outermost element below doesn't exist in the data model. --> <!-- It simulates if the "grouping" were a "container" instead. --> These examples can't be validated as well. Do we need to be consistent in how various I-Ds proceed here? Should we include a guidance in the bis? Cheers, Med De : Reshad Rahman <reshad@yahoo.com> Envoyé : mardi 8 octobre 2024 23:15 À : yang-doctors@ietf.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-schedule-yang-02 Hi Med, Thanks for the prompt response. Please see inline <RR> (where no explicit response, default is ack). On Friday, October 4, 2024 at 04:33:51 AM EDT, <mohamed.boucadair@orange.com<mailto: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=https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.txt&url_2=https://netmod-wg.github.io/schedule-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 <noreply@ietf.org<mailto:noreply@ietf.org>> > Envoyé : jeudi 3 octobre 2024 21:32 > À : yang-doctors@ietf.org<mailto:yang-doctors@ietf.org> > Cc : draft-ietf-netmod-schedule-yang.all@ietf.org<mailto:draft-ietf-netmod-schedule-yang.all@ietf.org>; netmod@ietf.org<mailto: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, > > This is an early YD review of -02. > > - My first impression of the document is that it seems > unnecessarily big, why all these groupings for something as simple > as a schedule :-) On further reading, I do now understand the > reason, all the knobs and belle-and-whistles... [Med] Great. The abstract and > section 3.1 do mention "basic, intermediate and advanced versions > of recurrence related groupings". But there is no further mention > of which ones are basic/intermediate/advanced. There is a basic- > recurrence feature defined but it is not clear whether that is > meant for only the basic groupings or ... Please consider in > section 3.3 whether each grouping should be tagged as > basic/intermediate/advanced and whether the features should be > defined accordingly. > [Med] Updated the wording to better focus on the modularity approach with groupings varying from basic to advanced (iclandar-like). Made this change in both the abstract and also the main text. > - 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. <RR> 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 example 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; } <RR> How would the device indicate e.g that it supports icalendar-recurrence-schedules but not icalendar-recurrence-ping-schedules? Not via the feature since both use the same feature in the if-feature statement. And the feature support doesn't depend on the context afaik, it is either supported or not supported. So I think we'd need to define features for where the groupings are used and these features would depend on the features defined in this document? > - Section 3.1: the feature names have the -supported suffix. This > is a personal preference, but I think the "supported" part is > implied for a feature and not needed in the feature names. > [Med] Works for me. This has also the advantage to shorten them. Thanks. > - 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 to look at the document again... But some text in 3.2 may help. > - Sections 3.3.X, I am not sure why all the other groupings are > listed. e.g. > 3.3.1 is about "generic-schedule-params", why list all the other > groupings in Figure 2? [Med] This is a zoom on the specific branch of the overall tree in Figure 1. That's a matter of editing taste to accompany reader in walking through the full tree. <RR> Ack. I'll leave that to the RFC Editor. > > - 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. <RR> What would help confirm my understanding, or not, is an example with both in the appendix. Thanks. > > - 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. <RR> 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 frequency. Please add it there. I am not a fan of mixing interval and frequency. But I'll leave it to the WG. > - Section 3.3.3 v/s 3.3.4, intuitively from "recurrence" to > "recurrence-utc" I expected the change to be just wrt use of UTC. > Consider renaming "recurrence" > to "recurrence-basic" since it is basic with just a description > and an interval/frequency. > [Med] Makes sense. Fixed. > - Wrt UTC, some nodes have "utc" as prefix and others as suffix. > Be consistent and my preference is for suffix e.g. start-time-utc > (instead of utc-start-time). [Med] ACK. > > - Section 3.3.X, be consistent in the names. e.g if UTC uses > start-time-utc, then 3.3.5 should use start-time (not date-time- > start). > [Med] ACK. > - 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 some of the items you mentioned in order to cover cases where, e.g., both period and recurrence are used within the same choice. Please see https://github.com/netmod-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 container would be useful. > > - Sections 3.3.4 and 3.3.5, not clear to me why UTC is deemed to > be for machine readability and with-time-zone for human > readability. [Med] You may refer to, e.g., https://mailarchive.ietf.org/arch/msg/netmod/qJtMJHg1qdgBgKNAKjOFe8z885c/ for systems to manipulate time zones, etc. > > - Section 3.3.4: what happens if duration > interval? I thought I > saw some text on this but can't find it. > [Med] The behavior will depend on the scheduled action. All what we say right now is to insist on the differences between these two notions: Note that the "interval" and "duration" cover two distinct properties of a schedule event. The interval specifies when a schedule will occur, combined with the frequency parameter; while the duration indicates how long an occurrence will last. > - 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. <RR> I took a look at RFC5545 and it's still not clear. The YANG description here says "Modes to bound the recurrence rule.", still not clear to me. If not "recurrence-limit", what about "recurrence-end", "recurrence-max", may be not ideal but IMO than recurrence-bound. > - discard-action does not mention how the warning/error message is > generated, is it a syslog? [Med] The exact mechanism to supply these is specific to the context/scheduled action. I'm afraid that mandating a specific mechanism here will limit the reusability of the groupings. How about using an alarm (RFC8632) as > another option? > [Med] alarm per 8632 is more a state than an action. No? Alarm (the general concept): An alarm signifies an undesirable state in a resource that requires corrective action. <RR> Ack. > - I don't see must-statement that period-end > period-start in the > YANG, although it is mentioned in the text. > [Med] We already considered that among authors but went with the normative language than a must statement because we don't see a simply what to express operations with date-and-time. If you have a suggestion here, we will be pleased to implement it. Thanks. <RR> Ack. > - The examples in appendix A are all based on the groupings. But > since the groupings will not be used in a stand-alone way, I think > the examples should illustrate a usage of the groupings. For > example, the examples could be based on the example YANG modules > in Appendix B. > [Med] We do have a note about the usage here: " Note that a "grouping" does not define any data nodes in the schema tree; the examples illustrated are thus for the ease of understanding." That's said, we will consider your suggestion further. Thanks. <RR> Ack. But these examples can't be validated (e.g using yanglint). Regards, Reshad. ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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.
- [netmod] Yangdoctors early review of draft-ietf-n… Reshad Rahman via Datatracker
- [netmod] Re: [yang-doctors] Yangdoctors early rev… Reshad Rahman
- [netmod] Re: Yangdoctors early review of draft-ie… mohamed.boucadair
- [netmod] Re: Yangdoctors early review of draft-ie… Reshad Rahman
- [netmod] Examples for groupings (was RE: Yangdoct… mohamed.boucadair
- [netmod] Re: Yangdoctors early review of draft-ie… mohamed.boucadair
- [netmod] Re: Examples for groupings (was RE: Yang… Reshad Rahman
- [netmod] Re: Examples for groupings (was RE: Yang… mohamed.boucadair
- [netmod] Re: Yangdoctors early review of draft-ie… Reshad Rahman
- [netmod] Re: Examples for groupings (was RE: Yang… Kent Watsen
- [netmod] Re: Yangdoctors early review of draft-ie… mohamed.boucadair