From nobody Wed Mar 3 03:07:36 2021 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 336C63A0D1E for ; Wed, 3 Mar 2021 03:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=gFcwaiKA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RsilEip2 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 XHzqBXqIFLEZ for ; Wed, 3 Mar 2021 03:07:32 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5763A0D08 for ; Wed, 3 Mar 2021 03:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5529; q=dns/txt; s=iport; t=1614769651; x=1615979251; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=hPIT/EYWAOAA+2Y4hV+X2nFL3esZNfUm8vCav5zUl8w=; b=gFcwaiKAbF7nRBhT6TyDUXe4cp8kCpsPAt9nWk17O6+t08z0ji3npGQm eMRZMyCnDzwHOjIm2Dl69mXId+8gLtiTtiKale0/ibBfoXjwy/04KHVv9 cF1XjcFefPf/3D5huj/BfE574aPAh6OT9dZOgpNRQoGbuGAeAmpcfvESB Q=; X-IPAS-Result: =?us-ascii?q?A0A5AgBxbD9gmIcNJK1ZCYEJgU+BU1F9WjYxCgGHfgOFO?= =?us-ascii?q?YhWmSSBLhSBEQNUCwEBAQ0BASgKAgQBAYETAYM5AoF6AiU0CQ4CAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2AQyHBQYBATgRAT5CJgEEG4JoAYJVA?= =?us-ascii?q?y8BAwuiQwKKJXSBNIMEAQEGhSoYghIDBoE4gnaGWYQaHIFJQoERQ4Ipg0gCg?= =?us-ascii?q?TQSHINIgiuBTwpxAQE8Ki8kIAIkIIEXFSAKOJtMjCWQOYEUCoJ8iT+TA4M3i?= =?us-ascii?q?k+TB4JJjwOFUoIJiTSSAoReAgQCBAUCDgEBBoFUOCyBLXAVO4JpUBcCDY44g?= =?us-ascii?q?1aKWXM4AgYKAQEDCXyKCAGBDgEB?= IronPort-PHdr: =?us-ascii?q?9a23=3APcR4CBAEob7mO1f35Ry+UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,219,1610409600"; d="scan'208";a="695656832" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 11:07:30 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 123B7Ubd010767 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 3 Mar 2021 11:07:30 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 3 Mar 2021 05:07:30 -0600 Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 3 Mar 2021 05:07:29 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 3 Mar 2021 05:07:29 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RHy2x+KLuqcT0Ba53DUX9WDdZ5aCYWjB4sqwqa7yvHEsOZkyj5IjQx0hVH9LqlObdzgxgzeW8v6QNqrdjyX9J0LhOhcpQYW80N7yu0JUWoRNooWBPnmjdOCdE0x4k+cIWvr0+jIY6z0YTuO7Kz+F9k14LpiNf+pZw51SvQosbUuVucP7dJ15MYH/yzedTIWPw51uTu8FVDD6XkE8dMg1837ghMBlUn2SlOKFcJGtcwtYvUmoXI/yUyZBa6QNwxcVM2kbHKic4qNK+mv7nGOSa1m+hRO+rFCB7vCRX51T/O1LSSElj3I0k3DjplW2tU3MNEoo7dqIxdV5jH96TnFetg== 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=ESCK1bJXgzYep56wiuZzOetlZpCxINEdliarv0PJrvw=; b=ksy/HyN/fRZM3N4JbtWWMuRbNw92hFd3OgUoVIV72G+3Kv3lTYh3QcdHLC/WnEIPNAD6K9VxdFT+joLHhAaQdAZPxTmduM9kjcWODAAsMYqnjrG86QCmkbhddbZysttM+BCPSB4JRylu2z7pgrWbazMmkYlhr9b1DQcIK8Dwri70058vR82hERz9u/st9jloFF+DS0Ygf6azSH4ghGrcQR3pck8RpJN4yyWSjDJMRydsEp0qO73OTrcB44T0N80jJBwUcMPvRrUPjihUeVCOEWTHTV+rBNPHlzeEfSKg0+J4Pz/n60HFkeShSl/6lB9a8gZE4haRHFKnrj/tD697cg== 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=ESCK1bJXgzYep56wiuZzOetlZpCxINEdliarv0PJrvw=; b=RsilEip2pflpRfoRyTgo9aHTolzjgzEJSIabPwQp3bry7YCjW4FW49QEfOVy8MRoUIIj2cDpYpzZtouIYtJSlCtw2Xg4c2/TVnx2xfr0oBCB9eoq7W5RBmaxpAGrPebBl8L7UXsEA9rmnefbqCk5Td6ZOWXLbWJw5YviOViuPpo= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3252.namprd11.prod.outlook.com (2603:10b6:208:6e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.28; Wed, 3 Mar 2021 11:07:28 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3890.028; Wed, 3 Mar 2021 11:07:28 +0000 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" Thread-Topic: Proposed IANA text for YANG Module Versioning and Semver Drafts Thread-Index: AdcQG/9VJO5KypwRTzuE8gHDegltpg== Date: Wed, 3 Mar 2021 11:07:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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: 384cb8e1-5dce-4522-f224-08d8de3488d3 x-ms-traffictypediagnostic: BL0PR11MB3252: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PeGmZpJ2FVkkkslZ99diPbTbnOirl5rdTvbyi0c9fceZYEGa5jhXaLNbKeg9dRpaxsj1JrO2QJ+ntGq8I5IWGW9b40khFBpGsV48JY0f4BeHwvZOAcVuNihkRW/QuE9PARvzremCCTHXT4qc+CfdkLhu1BOHx2RUmtz4BYUZCH+1QejxOBeiNayNDThf6XtrLlZm3tGtCe0/aHPs2s4j64QicJEempato9+3LqQ1rerNmRxPG+9tEdQTRBtT/VuHomxpoi0tmJ3vlQtauMoseTah+kcY+t2zqYiQhaXDVo16KiNNfAD2U3a3x9/MRjHodcFxvOR4UQPcPoteb2T6pjCcH1gsIF5kv44HEe7bpDiuL3K8C4XGJKj+liZw+z9ppngFJnEqDBFPTYVAdet+t4657ET1m8GswxWMpUd+H6fQFnZbjdTn35qfOXtkm6JR1pPziTAsUJw2ArrwX9Q/Ht8ilsCsYbQ8urDmf6zM5s2Ai2fTXqkX6HzY/ljPg6TfLu7fe9JGFsrsifk+D5NZzhlY1B/roarpEBLYPsiti6RUOhq8dIGvfbXSexCl6ii8lxJbwS1bDNZlr2bdj5+VkE02bxctKZugdKj2L5g/5qs= 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)(396003)(136003)(39860400002)(346002)(376002)(64756008)(66446008)(66556008)(66476007)(86362001)(76116006)(66946007)(6506007)(4001150100001)(316002)(5660300002)(26005)(33656002)(8676002)(8936002)(2906002)(52536014)(7696005)(478600001)(186003)(966005)(9686003)(55016002)(83380400001)(71200400001)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?itx2/ZPkiyzF93+jzzFy5fHzdipqgYXadhV1WLdfJYoeQlX74NljvaMsycPU?= =?us-ascii?Q?agQKDDtkhw63ziRbqbFqoVVwIdn1LTBiw0wb6kbXMFXvj+Qtc9dKYKljCy7m?= =?us-ascii?Q?qmcB8KvpO+9MZ/epuYR4tNwI757xXtYHZxgmn4UF1SOp2zPqMD+jqxu7XkOD?= =?us-ascii?Q?f6ibEV635RrXbVl3kMOkJu5z7iMrnqWOqc8Oj2EZWdCGW6xcdoIR72DgicR6?= =?us-ascii?Q?yspWbYFeo8SSGLgQAgUjdFR/PK7Yh48szvpya863NVI+JCjaTHU1GIyL382E?= =?us-ascii?Q?gPxa3fa2eIBZCStjDZFigcslb8zXXhZGwRCwNysFJhPISVuKmWM9nTKWvPZP?= =?us-ascii?Q?uvVSfOrOmfhLzCEtpTnytTgDNc07nPIEC8yQEfEoO1scUSHiptQmkvgSVRWL?= =?us-ascii?Q?U0yumMS8iicIXOMiCquXsXHdcuPdE1AYjQYVehTwOmsDV12iJpkCYLIhptoM?= =?us-ascii?Q?8yMSJaWAeuwfUuiYLNUaqMQMNWbTnUV8D2x8DbCv68LpRM0QxFgAciiUNeRp?= =?us-ascii?Q?aGA3QuTVOP64xdMSwApwybETlnG0fAjaB4/KXBDp8YPMYVG6I/kfq3bnCAii?= =?us-ascii?Q?KS7vE/9sUJUchq8zmM94yjNZNg+eitdUtyAkQ3KiOVr/UfKVWISh8v0N2RWL?= =?us-ascii?Q?Ek384ZyMRTP/p5wng1n8hztjvDpbm1ZVKCb6Ss/9izCv6UGe157KuonNBrZL?= =?us-ascii?Q?mfsMPjR9VS/SyRRrf6QZAJZffs8ICVi4t0EWsr2BGSU76gIrLSAIYAsYegpN?= =?us-ascii?Q?ZHz7M+dXziZvFEMZ4hHPrvhc4nRHCzJF+AlhjhFI+LKvovs7Yv7CfzT72D0k?= =?us-ascii?Q?I9vTUP2fGG99UEHONPfoMho0P5JSpl70JjTLjJa76QYl12xQwvM3lQdu7Zpx?= =?us-ascii?Q?JAbImaAftOFfJXMIb8mBKo7LAle1ZtckGPW2QabsWgidnTGrDH2X+Rk2rKUD?= =?us-ascii?Q?W2MvvDqwPNMVKbeXuJ3iW6UbADBHt0Fx4dB31t332iXN90Uybjqddeax99iV?= =?us-ascii?Q?SgSHPgrvPH2bPfTefMYTEsYeVsHKS0A0A3jOyT5svrXdp3lXFBFUchR7Kw/E?= =?us-ascii?Q?w0xlCc/IJieD1yY10gTYSg3KhB/HpQdCJaFocHbYuJF4wT40Uzm8pIoqCXWH?= =?us-ascii?Q?FbvF9OQMOowtrt8N5Acx7gWvRFq1hTnWttTHmXdz0w1W8H2D7OLxwuKod5Z2?= =?us-ascii?Q?+KcHzNWXMKyDv3f8dM0dlcQlyjW2L9/jhqbj6nLG1v9ChTtTkbvBNk7l9rmB?= =?us-ascii?Q?Pz7U92ktdRVArnBqggbZhiVCm4GFYsiK7iWTjPg4jnU+QLlyhuz0gbvSIHwe?= =?us-ascii?Q?/reVKwFQ9nMpBdc6ag+khPZN?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" 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: 384cb8e1-5dce-4522-f224-08d8de3488d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 11:07:28.6813 (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: f5DncZBrsiMkbAlSkhX/dKGMuKeCOoRHRVx2ivPBr/KB0/iYy1P0PuvL4wIdY+iX8BV7GJwRqqlMubtARwvj0g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3252 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 11:07:34 -0000 Hi, // As an individual contributor We discussed proposed IANA text at the last NETMOD interim on the YANG vers= ioning work. Tracked by issue https://github.com/netmod-wg/yang-ver-dt/iss= ues/59 I had the action of updating the text based on comments received in the int= erim meeting and then sending that text to the list. The proposed text is below (that is in the current published versions of bo= th drafts). If the WG has no objections to this text, then the planned nex= t step is to ask IANA for an early review of this text. IANA section in draft-ietf-netmod-yang-module-versioning-02: 11.2. Guidance for versioning in IANA maintained YANG modules Note for IANA (to be removed by the RFC editor): Please check that the registries and IANA YANG modules are referenced in the appropriate way. IANA is responsible for maintaining and versioning YANG modules that are derived from other IANA registries. For example, "iana-if- type.yang" [IfTypeYang] is derived from the "Interface Types (ifType) IANA registry" [IfTypesReg], and "iana-routing-types.yang" [RoutingTypesYang] is derived from the "Address Family Numbers" [AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI) Parameters" [SAFIReg] IANA registries. Normally, updates to the registries cause any derived YANG modules to be updated in a backwards-compatible way, but there are some cases where the registry updates can cause non-backward-compatible updates to the derived YANG module. An example of such an update is the 2020-12-31 revision of iana-routing-types.yang [RoutingTypesDecRevision], where the enum name for two SAFI values was changed. In all cases, IANA MUST follow the versioning guidance specified in Section 3.1, and MUST include a "rev:nbc-changes" substatement to the latest revision statement whenever an IANA maintained module is updated in a non-backwards-compatible way, as described in Section 3.2. Note: For published IANA maintained YANG modules that contain non- backwards-compatible changes between revisions, a new revision should be published with the "rev:nbc-changes" substatement retrospectively added to any revisions containing non-backwards-compatible changes. Non normative examples of updates to enumeration types in IANA maintained modules that would be classified as non-backwards- compatible changes are: Changing the status of an enumeration typedef to obsolete, changing the status of an enum entry to obsolete, removing an enum entry, changing the identifier of an enum entry, or changing the described meaning of an enum entry. Non normative examples of updates to enumeration types in IANA maintained modules that would be classified as backwards-compatible changes are: Adding a new enum entry to the end of the enumeration, changing the status or an enum entry to deprecated, or improving the description of an enumeration that does not change its defined meaning. Non normative examples of updates to identity types in IANA maintained modules that would be classified as non-backwards- compatible changes are: Changing the status of an identity to obsolete, removing an identity, renaming an identity, or changing the described meaning of an identity. Non normative examples of updates to identity types in IANA maintained modules that would be classified as backwards-compatible changes are: Adding a new identity, changing the status or an identity to deprecated, or improving the description of an identity that does not change its defined meaning. IANA section for draft-ietf-netmod-yang-semver-02 9.2. Guidance for YANG Semver in IANA maintained YANG modules Note for IANA (to be removed by the RFC editor): Please check that the registries and IANA YANG modules are referenced in the appropriate way. IANA is responsible for maintaining and versioning some YANG modules, e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang [RoutingTypesYang] . In addition to following the rules specified in the IANA Considerations section of [I-D.ietf-netmod-yang-module-versioning] , IANA maintained YANG modules MUST also include a YANG Semver revision label for all new revisions, as defined in Section 3 . The YANG Semver version associated with the new revision MUST follow the rules defined in Section 3.3 . Note: For IANA maintained YANG modules that have already been published, revision labels MUST be retrospectively applied to all existing revisions when the next new revision is created, starting at version "1.0.0" for the initial published revision, and then incrementing according to the YANG Semver version rules specified in Section 3.3 . Most changes to IANA maintained YANG modules are expected to be backwards-compatible changes and classified as MINOR version changes. The PATCH version may be incremented instead when only editorial changes are made, and the MAJOR version would be incremented if non- backwards-compatible major changes are made. Given that IANA maintained YANG modules are versioned with a linear history, it is anticipated that it should not be necessary to use the "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT" version element. Comments welcome. Thanks, Rob From nobody Wed Mar 3 04:19:15 2021 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 B170F3A0F09 for ; Wed, 3 Mar 2021 04:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 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_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 uDNg7zMrqGYs for ; Wed, 3 Mar 2021 04:19:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F773A0F0A for ; Wed, 3 Mar 2021 04:19:09 -0800 (PST) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id BEE8E1409EF; Wed, 3 Mar 2021 13:19:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1614773946; bh=g5JVu+pciqLq0gz0fQWvr6vEXpZfjUA93XYZwloN1vg=; h=From:To:Date; b=dqSdiMdn2zv5Ej32u0B+kGsdts7G1rBChtAo1Zp970piIW/XoEqOYc4/gYgKEuKF5 02PWhGTWfYF60t+BRNeycsfzvNBnaMgexKWgzX5VsHSarSoZAjNsZEUwQ0K95wVzK7 MctH5OAT6Vj+RQcQmPwU0BPy3eEVU9ieTq0KNGAA= From: Ladislav Lhotka To: "Rob Wilton (rwilton)" , "netmod@ietf.org" In-Reply-To: References: Mail-Followup-To: "Rob Wilton (rwilton)" , "netmod@ietf.org" Date: Wed, 03 Mar 2021 13:19:06 +0100 Message-ID: <87sg5cxwed.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 12:19:14 -0000 Hi Rob, I don't know whether this has been discussed, but one issue that might need to be addressed is the difference between IANA and YANG in the definitions of "obsolete" and "deprecated" - the details are here (slide 5): https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa-yang-types-for-dns-classes-and-resource-record-types-00 The best solution would be to unify the definitions. If this is not possible (in a short term), then it is IMO necessary to mark an entry that is made obsolete or deprecated in an IANA registry as "obsolete" in the YANG module. Lada "Rob Wilton \(rwilton\)" writes: > Hi, > > // As an individual contributor > > We discussed proposed IANA text at the last NETMOD interim on the YANG versioning work. Tracked by issue https://github.com/netmod-wg/yang-ver-dt/issues/59 > > I had the action of updating the text based on comments received in the interim meeting and then sending that text to the list. > > The proposed text is below (that is in the current published versions of both drafts). If the WG has no objections to this text, then the planned next step is to ask IANA for an early review of this text. > > > IANA section in draft-ietf-netmod-yang-module-versioning-02: > > 11.2. Guidance for versioning in IANA maintained YANG modules > > Note for IANA (to be removed by the RFC editor): Please check that > the registries and IANA YANG modules are referenced in the > appropriate way. > > IANA is responsible for maintaining and versioning YANG modules that > are derived from other IANA registries. For example, "iana-if- > type.yang" [IfTypeYang] is derived from the "Interface Types (ifType) > IANA registry" [IfTypesReg], and "iana-routing-types.yang" > [RoutingTypesYang] is derived from the "Address Family Numbers" > [AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI) > Parameters" [SAFIReg] IANA registries. > > Normally, updates to the registries cause any derived YANG modules to > be updated in a backwards-compatible way, but there are some cases > where the registry updates can cause non-backward-compatible updates > to the derived YANG module. An example of such an update is the > 2020-12-31 revision of iana-routing-types.yang > > [RoutingTypesDecRevision], where the enum name for two SAFI values > was changed. > > In all cases, IANA MUST follow the versioning guidance specified in > Section 3.1, and MUST include a "rev:nbc-changes" substatement to the > latest revision statement whenever an IANA maintained module is > updated in a non-backwards-compatible way, as described in > Section 3.2. > > Note: For published IANA maintained YANG modules that contain non- > backwards-compatible changes between revisions, a new revision should > be published with the "rev:nbc-changes" substatement retrospectively > added to any revisions containing non-backwards-compatible changes. > > Non normative examples of updates to enumeration types in IANA > maintained modules that would be classified as non-backwards- > compatible changes are: Changing the status of an enumeration typedef > to obsolete, changing the status of an enum entry to obsolete, > removing an enum entry, changing the identifier of an enum entry, or > changing the described meaning of an enum entry. > > Non normative examples of updates to enumeration types in IANA > maintained modules that would be classified as backwards-compatible > changes are: Adding a new enum entry to the end of the enumeration, > changing the status or an enum entry to deprecated, or improving the > description of an enumeration that does not change its defined > meaning. > > Non normative examples of updates to identity types in IANA > maintained modules that would be classified as non-backwards- > compatible changes are: Changing the status of an identity to > obsolete, removing an identity, renaming an identity, or changing the > described meaning of an identity. > > Non normative examples of updates to identity types in IANA > maintained modules that would be classified as backwards-compatible > changes are: Adding a new identity, changing the status or an > identity to deprecated, or improving the description of an identity > that does not change its defined meaning. > > IANA section for draft-ietf-netmod-yang-semver-02 > > 9.2. Guidance for YANG Semver in IANA maintained YANG modules > > Note for IANA (to be removed by the RFC editor): Please check that > the registries and IANA YANG modules are referenced in the > appropriate way. > > IANA is responsible for maintaining and versioning some YANG modules, > e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang > [RoutingTypesYang] . > > In addition to following the rules specified in the IANA > Considerations section of [I-D.ietf-netmod-yang-module-versioning] , > IANA maintained YANG modules MUST also include a YANG Semver revision > label for all new revisions, as defined in Section 3 . > > The YANG Semver version associated with the new revision MUST follow > the rules defined in Section 3.3 . > > Note: For IANA maintained YANG modules that have already been > published, revision labels MUST be retrospectively applied to all > existing revisions when the next new revision is created, starting at > version "1.0.0" for the initial published revision, and then > incrementing according to the YANG Semver version rules specified in > Section 3.3 . > > Most changes to IANA maintained YANG modules are expected to be > backwards-compatible changes and classified as MINOR version changes. > The PATCH version may be incremented instead when only editorial > changes are made, and the MAJOR version would be incremented if non- > backwards-compatible major changes are made. > > Given that IANA maintained YANG modules are versioned with a linear > history, it is anticipated that it should not be necessary to use the > "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT" > version element. > > Comments welcome. > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 3 08:02:14 2021 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 31C993A1596 for ; Wed, 3 Mar 2021 08:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=C0hbxdhx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Fn5Y0LYR 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 aGbq-V6psT9I for ; Wed, 3 Mar 2021 08:02:11 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380423A1594 for ; Wed, 3 Mar 2021 08:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2415; q=dns/txt; s=iport; t=1614787331; x=1615996931; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=i+xM6xygHoeJydjH16ycwdNcntt2uWwD67MhNQ+bjv0=; b=C0hbxdhxAahQzUVCtL8ZqjMCPvDF+XOaxX25EjW0OsRsJXsG6jgbk0uR 8J8buZMvOkYH9NGC7BN1BreF6bxC+4X2HT+1S9qdxqZTMwrzCjkeCTFP9 f/s0b2/fy108ldu/LU19cPkwOhrQ1kPDqfXbJtMd0ZE9afpDjmOKiSZRg Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A7HQ4xxdMeWh5ZhUR1F/cKtRHlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqBgB7sj9g/4gNJK1igQmBT4FTUQe?= =?us-ascii?q?BUDYxCgGHfgOFOYhVmSSBLhSBEQNUCwEBAQ0BATICBAEBgRMBgzkCgXoCJTQ?= =?us-ascii?q?JDgIDAQELAQEFAQEBAgEGBHGFYQEMhwUGAQE4EQE+QiYBBBuFPgMvAQOidwK?= =?us-ascii?q?KJXSBNIMEAQEGhSQYghIJgTiCdoZZhBocgUlCgRFDgimBcIMFARIBI4NIgiu?= =?us-ascii?q?BTxthATxCWwJECxR/LZBGqTsKgnycQqNWhjeOHp1khDkCAgICBAUCDgEBBoF?= =?us-ascii?q?UOmdwcBWDJFAXAg2SDopZczgCBgoBAQMJfIoIAYEOAQE?= X-IronPort-AV: E=Sophos;i="5.81,220,1610409600"; d="scan'208";a="871315912" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 16:01:02 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 123G12fj005338 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 3 Mar 2021 16:01:02 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 3 Mar 2021 10:01:02 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 3 Mar 2021 10:01:01 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 3 Mar 2021 11:01:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PVXLUjokX+LEsCboYIN0ugbvEElblNI6Q60XFJGGf0LPBkFGRaSVkE1Aj5YhLOKKYh5sxJtrtHVS8dXJHroFtyPYbBDRF9Ec0lTN4G1YPe3vAIFY52TD+4HDfR8i8jCxEUP11uAgav4Hq4/+iwixaaqJjAwjfRSlZqS81cduSnvwEDF3qi8UpqhsGBiW58vlBf8s0DTsIN/9KOKFPjc7ZxGOOwogMmFM215x9I6yq0xhW3p+uuzJ+CjL9vKmQBfz1KbsS6Px/4hXf4KL3dn4d0IcHlsYJEfavxUjTprdNFdUvmZmzBU5+krep8KX2YSaj1Ru8Ii/q0j/IkDuFv+zuA== 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=pFGVmXNHnd8ql4s9pCLKmAK/ZCLCZK09QELRyhi4SQQ=; b=bUfaYJvhc4E14jlEEGlulKKUH3AXuJS+QwMhz+z9ei+CAjUNV4ZYOdw9wOztDYhrlA42aZGQv5GV7f3fEHKnp+x0npcHph1ErPyDolWBZy1MumaQfhsR4yLHeDtFS7UMrHOHxhbOxitMIORnEri6V2UMudP0PDCXwIMJhExtm8njTsg41BVCwy+/iDMOSBFbdCbexM8kFvJlcvNv5UUQdjU25T2qh7WgHpktjRN8uo9ZHjY028Uy9reVqsx2YTJqLuJi4DVkVdX6+eLolPj/50RzCkjU1j6Tk25pFRbpYCsSi4M5lmOvrbsnxA0F8Iuum43tn6fnih136l305hn5gA== 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=pFGVmXNHnd8ql4s9pCLKmAK/ZCLCZK09QELRyhi4SQQ=; b=Fn5Y0LYR2KHc01Q+91eOORWzvLEZkeUKU0vZK+doV3bLNb6xStSf0OPSKXq90aAeYo8Vduk9kYjilxRhYRF+i9fXwnRLByFbPw6Huiy2rtdFedCnJSeYFDCoVVKuUTcUadtvRK9R//kQm02ZkJjUh2NfVJr7IkaGuydfKxUNahU= Received: from BY5PR11MB4355.namprd11.prod.outlook.com (2603:10b6:a03:1c3::13) by BYAPR11MB3573.namprd11.prod.outlook.com (2603:10b6:a03:fe::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Wed, 3 Mar 2021 16:01:00 +0000 Received: from BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::81c7:f68d:5e2f:a5d9]) by BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::81c7:f68d:5e2f:a5d9%7]) with mapi id 15.20.3912.018; Wed, 3 Mar 2021 16:01:00 +0000 From: "Rob Wilton (rwilton)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-03-02 Thread-Index: AdcQRg+Iu3AditEuSQCW3EB0OnMpcA== Date: Wed, 3 Mar 2021 16:01:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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: bf354355-f0dd-48bd-0d66-08d8de5d8a27 x-ms-traffictypediagnostic: BYAPR11MB3573: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hLQJ2q/sEyjdYy/vqXgfFLymRVVyGJ44es0bZlt2rIuGwPoFhUfbGYl/UEKdLInyGlFr0FGnoPmcWAM6larbva0V+2R7pf5qXV8bO64ktHYUCDgCqPFuxg9zHSrBLZTfamNG0wxI+iCPVb/vDwBvznrrDSnsgUOwQHj4uWDWhKRgwL1/4/RLQqDo/doldCsogM2oDj+Gv2KIbpxaL0gnWJz0g3gpMdnNfFcg3TLAIEJCWr2EgFkTahCqok5/zRJuYqhQNPhOqn+Iwzw0yV3Vn72LEMlIqiAsO/dookC8GrZB5HKvtcMW4vvhWPvAh9X6Vo7vKVQBGKgpSoki6P+C4RU0B+PK9bPZAAOhjVfA8p2zoyvsnvCUSl6FiLU75Es8FmBQ/fZ+5gjpow0SS3tcJ/wYJkR9TaHFpWmTfx60HJy/fxXNc3/BQE+k+MEYMBfC2Qf2t+rwa7Ci4cHcCQYUqx25oWluRVwrhXc58MwV/5WMcJWNiv4HOwEbpYG4IpD/sVkePsVD5a1ZTknGGSDk5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4355.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(136003)(396003)(366004)(71200400001)(66446008)(7696005)(6916009)(478600001)(26005)(316002)(8676002)(8936002)(64756008)(86362001)(66556008)(66946007)(2906002)(66476007)(55016002)(5660300002)(6506007)(76116006)(9686003)(33656002)(186003)(52536014)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?JTI+ljwOwGW4esR+rjPgQS97o9oUmxmWyWEthNG/15gTtawL7fn0akIL1zoc?= =?us-ascii?Q?vrjugFBi1DrONbTitAQP+p6sn1OiDdzEfqrB4ROzyhb0jBQBOlHNxNOmbCgh?= =?us-ascii?Q?vrvGL+ZCHimic8phObQ0VFFQggfOd2u0nMB5HwEfQdJUhTPTHunQ5FBtZNjn?= =?us-ascii?Q?gXN8UniQRk74yYzJRepfmOLjirJtivuJNKI3AvHcmo30voj7cjy/eC2yvZtN?= =?us-ascii?Q?qfu6AFgSbClX5QywhZknuz/2cyBK+AuX4BEeI8YlBQNrvWvSJ4sbEZHim5rD?= =?us-ascii?Q?eEuJ9CqLnD5hg9akt9cHb4+pCEYHknglPn4SoF7G0b0sPpeXbd/AJ5gTzJQM?= =?us-ascii?Q?v9iG/mvXoG79jHI+OcZaGJl/ECAyuXEExmd6XcUolVxOSogQxDDYvaG9frx2?= =?us-ascii?Q?znx3chcSwBCctZ6LEe0x9xGqJnQtCPnxrf07Fa7bwzS8JSOz0BZvEOM+c08j?= =?us-ascii?Q?CDYuR3TN+ov0LIHtZr0yW77iZk43wDLdmGIQsXGWu1GChpOsJ1OgE60MXVuZ?= =?us-ascii?Q?D7VqSqfykK5wIyDJSe4M7ZFmtDFJXF82YXIEvMrcS84LbytvLxFy4p4+5oM0?= =?us-ascii?Q?Cp6B3fLswCuy3iGRvWFwd2XDhQ1spEgWn8WWGfS0Np36xzicL5MFavQPD8xs?= =?us-ascii?Q?M/WoBO8ilwkOth9cMkiYQerl7rqx9j/1AhiIRrxfz+76vmA/X1W1R1OUf4Zp?= =?us-ascii?Q?ltan4i09HwPxA60YC67TBazPuVI+PSET3IU9ZnNMPe6+HMqqZtTz3PzW4pNO?= =?us-ascii?Q?QXjpTSH9dkvfqJBaAkUMlgsxkQs4HTaBNucpudvcJq0dpJNvyG9ohHajcr8a?= =?us-ascii?Q?ilcrpI8bHW3cW2oGhmZ7b6AcjWCrVN6yPzpnvZNy3cWH/yKm/lUGPXmwtZMz?= =?us-ascii?Q?4SQ4tpiDlHACYEdzjSQqoWHvE+kuOQEZbmJd5S7H4kMPLxrYzBeJusRS6eHt?= =?us-ascii?Q?L1JHrQiL/TuJ0jvPYGmgeJR5N+mAt9nUw68D294VEG299BQtGlH9SDRcwepn?= =?us-ascii?Q?Lu2fVenS/wR0ouubUVmznNI577AVzVcg5ETqDT9qj4FzI/eN3Weoji72pI9c?= =?us-ascii?Q?jaQall3ow3Ehm8ejERAZHpb3qfXmrWN0NAR5QCDVkb5WrcELWdmrwALN/4Un?= =?us-ascii?Q?+JDKdb+jpa9o9u6XQYha8qqePU+tu5U9yN4ZGut5d33o/Qm1DQuXDL5nvHIp?= =?us-ascii?Q?tFAuWuh2Wo6/+PnFDUpYlMPSZBOISCD1Hgo/79NQYpqUeH/SAOw6SP1MRSw1?= =?us-ascii?Q?UC/dZwlrpePpkSb+jmrjuuJa47DpPFuYxzRFQn2cqt2NbigZgPK+jnj5EqIC?= =?us-ascii?Q?NDRhShs7KTf6XvzzRieFBlvX?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4355.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf354355-f0dd-48bd-0d66-08d8de5d8a27 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 16:01:00.2865 (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: dY8hnCsS1YCIfwtChFvLVR8C1t52DQ4/Vme2SxrGXG3npa11+rEKB6FSgTI6bpK06yiy/fpLl+/h2zeiHfvTtg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3573 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-03-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 16:02:13 -0000 YANG Versioning Weekly Call Minutes - 2021-03-02 Meeting notes from Tuesday's meeting on YANG versioning. Regarding the NBC changes text (that have been discussed over email) - We are close to agreement that the current text - It was agreed that having a paragraph to reference the pre-release marke= rs would be useful Next step: Joe has the action of: - Merging Rob's pull request - Fixing XML to v3 format (e.g., rerun conversion tool) - Adding a paragraph to reference pre-release markers. =20 There was further discussion as to whether the "rev:nbc-changes" marker MAY= be added even when it is known that there are no nbc-changes. The consensus of the folk on the call (but Jason was absent) is that it sho= uld only be added when the changes are known to be, or suspected that they = may be, non-backwards-compatible. Next step: Still trying to reach consensus =20 We discussed changing "rev:nbc-changes" marker to expand nbc, and avoid pot= ential confusion. There is agreement to expand the tag, but there were two proposed expanded = versions, and there didn't seem to be strong consensus for, or against, eit= her of them: The two choices are: rev:non-backwards-compatible; rev:non-backwards-compatible-changes; - Reshad has the action of changing the module versioning doc to one of th= ese. Semver doc will also need to be updated. Rob to send IANA text to WG (now done). We also discussed Reshad's proposed slides for IETF 110. Of particular not= e was the discussion regarding whitespace: - Tom commented that the build metadata could be used to indicate where an= other version of a YANG module has been published with whitespace changes. - It was noted that this might help with Semver version numbers, but the i= mpact to revision date also need to be considered. - No conclusion on this, future discussion with the WG on this issue is li= kely needed. We also discussed a couple of issues that were raised by Joseph (in the con= text of the Semver 2.0.0 github repository): 1. Is Semver 2.0.0 a stable reference, or is the specification being change= d without changing the version number. Joe to check, whether the current S= emver 2.0.0 specification seems to be stable. 2. Check whether our usage of pre-release labels is aligned with Semver 2.0= .0, or requires tweaking. Action is on Joe to check. Rob From nobody Fri Mar 5 04:23:35 2021 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 EDBE23A2479 for ; Fri, 5 Mar 2021 04:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=gBjK/h1f; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kWM80YDB 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 1bfhkefe9eWn for ; Fri, 5 Mar 2021 04:23:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FAEC3A2477 for ; Fri, 5 Mar 2021 04:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10175; q=dns/txt; s=iport; t=1614947010; x=1616156610; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=C23KdpWrgXYLU+se/roLAECbA4Vpe1lVriT/gCmjj6w=; b=gBjK/h1fjQRWwpnTkqQtGmdadhh/FrmQf0n8ybxdc6VGKAPdWHc1jZHM I5ttL8NZEAUWIm68mIAbw+yQ2I0RBV0L/VIcHX7idIqBmo/VcFmrun9zL Qyge/EhDdCm5DxLgLAmLkwCMesFoDHGp285ZA0Vea+D7cEt+P9gDbLxOs 4=; X-IPAS-Result: =?us-ascii?q?A0DqAQCiIUJgmJldJa1ZCRwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgVMjLn1aNjEKh38DhTmIVwOZI4FCgREDVAsBAQENAQEdDQgCBAEBgRMBg?= =?us-ascii?q?nVEAoF6AiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhjYNhkQBA?= =?us-ascii?q?QEEAQE4BgEBLAwLBAIBCBEEAQEfECcLHQgBAQQBEggTglUBglUDLwEDC6MJA?= =?us-ascii?q?ooldIE0gwQBAQaBMwEDBINpGIITAwaBOYJ2ikwmHIFJQoERQ4FZUC4+glwBA?= =?us-ascii?q?QIBgTESAhqDSIIrgU8KEGEBATwmBBsMCCQgAiQVCzJFDhIGDyAKOJAdRIp3n?= =?us-ascii?q?GWBFAqCfolAkwiDOYpRhX6NFoJOjwmFVIILiTmSCIRgAgQCBAUCDgEBBoFrI?= =?us-ascii?q?YFZcBU7gmlQFwINjh8Zg1aFFIVFcwI2AgYKAQEDCXyNGwGBDgEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AKQJniR3VFuY0IICBsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWHtadrjVSPVpeIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI2+XCwd0NHS47yYlTIqSi06jgfUh?= =?us-ascii?q?z0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1ah6xqFbc?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,224,1610409600"; d="scan'208";a="696573712" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 12:23:28 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 125CNRdR018356 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 5 Mar 2021 12:23:28 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 06:23:27 -0600 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 06:23:27 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 5 Mar 2021 06:23:27 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YPV636eqENN61adbWjE3amZ5YjflyyyimWSFr1HewJeU0J7vZZab0CP/mH2L66eh7038O0+pbNPQ75ayeLN8ELnKaMOYjQPHi/Yi6iIFVgiWRj563KaQTzdQp0FMfj3JwiH7Ob+nAEh1NpCwC1QJaugqThpz7tGAWC87aZ9siG4tpkG+nQj03jpN4FhSPaFEBgwx6NTHx4Tl3pdNG8+bFbRSVcZ0f2oRr8vRbeoGKr/TjGiseg3hI1B1O9OebdCiC6RMbGGxXOvYRIiRn8rO3dLQEstWT8sMPsri9nIH+dkDezWX6c1D7zdUDhprK+VJIvu5TttD2WBsnI+sX7jvLA== 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=7fdpnUvlRYNSeDAQAgeuhN5g7zh0OWoy+/+CBSjlTzM=; b=VHoY5Cs1waDtZXahdSu1PQipQyZ0tRdJ/BtLn+GynMh8MZA+JoDMKkiBrvyJh1+zzMxBx94K+u+WMz+NCi39FK+fi8nLiVEcDYhJFfi5l3rTMH3Wvcr+vLhIxqXXOXBFDpNuT9Vp5ODsJYW29k2eh7L5t7BjXMR2eFYMAsYAX5A30TwJMWdXgFVi4zJ9uG0gX+waCtk1N3AtDlh46l/PQv0iCQvVoH1IjuPUUd0rsYz7QuFmMdq9XsrSzAV/k90eKS32h/7SaEcM0RVZdN7hbLIyPgm1rGT3QOi+ZT9dkjx9kvnbMQj/rHU82c7BGPI96i1hmQkppObZFpa/Hp9ctw== 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=7fdpnUvlRYNSeDAQAgeuhN5g7zh0OWoy+/+CBSjlTzM=; b=kWM80YDBeELeR0zdQurrp7liTNP+gA0V8iKa3FleB1w3FBLwu5tSaJjqhxwJUk3H/ZoLHQebzr1vqJ6tRjxECZV+hloek+y5MpvvnvnYOE9c5DdAihV47oiL7sm9lYYeLPWDzWzlaKwIGmLRpvjUUWuUQjBhzrKa74XL8SsN2TU= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4477.namprd11.prod.outlook.com (2603:10b6:208:17a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.23; Fri, 5 Mar 2021 12:23:25 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3912.022; Fri, 5 Mar 2021 12:23:25 +0000 From: "Rob Wilton (rwilton)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts Thread-Index: AdcQG/9VJO5KypwRTzuE8gHDegltpgAC2hYAAGEt/zA= Date: Fri, 5 Mar 2021 12:23:24 +0000 Message-ID: References: <87sg5cxwed.fsf@nic.cz> In-Reply-To: <87sg5cxwed.fsf@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; 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: 714980e5-fc45-4d8f-d4b8-08d8dfd17977 x-ms-traffictypediagnostic: MN2PR11MB4477: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vozD413Fm1IlFn5pL+iQRYUOizq+LbDfdj8svDPWhEaZgY4rTUSe/muGlPGC2uCaoY07ZEwW6rz6hAWI55z0jTzdhrMyFrt7sUmS15K9PnnyOPiOV+/qX8nMTWm6WJVe+e5Cqua0E4DfIWmaB+PybS7+J9T2/flVHMjibUmBRHVtxWbXBanNxQsD/aClD/XBLnaSJBlIJ46xovyAHCqHUGGucZy22610AUXMuYr2BcCHCImnEuCji3SdIALON5kSs71ECtnXarzobylQLlKBqr01BBsabAgg9a0Q7iY0mVmYnLsZgF7zhp0fufsLDx7T7axZCkkyt1NZroEtvXHwSWzOTdCwXhH/iZHK1T9F0IbOi5JyZ0adW70aHQzY4nXq4iJVn0l8K2kfiFSAL94zy6evuU42ZLTPkMxeKl/V0xT3GTJb0ZwdcJkW7tvADpg8ERURgm7G/2P/WUnYltsxxuOJ5V8Y18P6/aWDWxLW+sPhooODOuXcwfvuFtYa8LMXR/P7PDb4X37dDxt0NJSIjMT0THIKKT97eQeRW32xj30ehlJ+E4wRX5IZXGCifPIL6uO9b3WTmKXfPzkRsehIvhYDv9PXKX3CZtX/OHzHzLc= 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:(136003)(376002)(396003)(39860400002)(366004)(346002)(110136005)(8676002)(186003)(83380400001)(26005)(478600001)(966005)(66556008)(33656002)(86362001)(316002)(66476007)(8936002)(52536014)(66446008)(5660300002)(4001150100001)(64756008)(2906002)(6506007)(71200400001)(53546011)(66946007)(9686003)(7696005)(55016002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ZdF2L1g161Wxbjiho9Ol+pUmV2MTdD2q5jc1NCy3+KBLSFSaSCZpYVhev77B?= =?us-ascii?Q?jHWVivyBIuRbO92TkYtfFhlVQxpHdw94wFIdJfqRU7kVstojfXeIlnI14K7b?= =?us-ascii?Q?CmHmEqY7UPK9p42XtNR77brjxylyKNiyiUI69ulWWvmhPzcLMMPn/mzO+Mts?= =?us-ascii?Q?notPwJQ56P3a/J6gpBLqU0cPXxClPBsPUheODfjpPGLu48VB3GwyTRUM7j1m?= =?us-ascii?Q?sctENhi/oL9N1ricPfi2uuaTW+lDcj+ugaLSrN+B1rZSlUYQkiPhct57d61b?= =?us-ascii?Q?cA5R2KignsbF/tIYYNAQCStpt9D/DnyDsDDju6sNw5p7VTrd3ckYf1A6/cRK?= =?us-ascii?Q?5JKCS/KjJJyyOCuyag2t78Ae7J4tLOip8IdVPNLdXBUk/FxkrOg+9wHKNQs3?= =?us-ascii?Q?ikuQMJhsoszzejyiYcJ3ldDmi6w2GgeNnYkDsQ0SE8LbbFjMn+jVDVqyA8Wb?= =?us-ascii?Q?P4/ro0Yuuxuoi/gpe2nYuWaZaDuSqOzOCNcjck4cITnNgsLN3qE0a8ykpFNh?= =?us-ascii?Q?96YgAs3Bm3zmaO64r8PHDkg/6+QopNdrc//H+/NncF78LquWgKwpRYWvnlZo?= =?us-ascii?Q?nN+8xuAtg017HuZGAOjJ2itrfhTghNbgaSwFp/8OT3t2Nay2Qc7sn2ByLpsM?= =?us-ascii?Q?nwK+sNemFSafBJF9oc2eKdfyJHRgCJY0V0eZ5qJBiDAQBL/uCdh/D2f/CCi3?= =?us-ascii?Q?lJMZ8OjuS4/siC7/CD1tEffMIEt93L5Zv4Rgthn/8/rQxNguQHYJdPlbayKj?= =?us-ascii?Q?E/6mWivWwYBaJdzY4uQymScpRAx8xdqrc2xwPpgF0DgOVoC8iCH9oTm3T7pj?= =?us-ascii?Q?mQ5K8mKOt4+ruyujo7a9v7c68+/OyFSg+9g0lzYGpTN0KSRh+DW/LsD0zENE?= =?us-ascii?Q?WGN6rkVwgdWpwDEGscPaD/yNVBAHDSLtTw1tivlMQ2oRWzRTvTduT45qc2NG?= =?us-ascii?Q?q89GGJzRE6LGURqddBS8qqeYgBw/seEofi7mzrjft7QSVtQtD4IRYWWPJrYN?= =?us-ascii?Q?VyxajRiG3WfAfxoetWBkSmOpHcwXJS1MJxdyL4rFsZBiVKaRf//Bn56wUU//?= =?us-ascii?Q?mpvE8GwMU666XnkMEk1rQuXEwP+zvMIRcEpSihAPk4q/Lzs8pER2u9bYNw3l?= =?us-ascii?Q?WopgOtxGyzea4lwg9z8NztIiHH3JTUrOr9JAZe3ymao3iQjex/2+5pvNZa5m?= =?us-ascii?Q?INh7X8ycOLPGSpAGJPCl2jGt9sAavgqnjuXhQ2ZQ7X7USYKpKV532VAd2MHd?= =?us-ascii?Q?QBsTdBWgj8pGkyw+FbyngaFEbcjiX+jjbKEdt6wa37i9LOh84ZjtPRiMm4oH?= =?us-ascii?Q?twdiBugiUTEGhM0eEKO2saLp?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" 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: 714980e5-fc45-4d8f-d4b8-08d8dfd17977 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 12:23:25.0421 (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: Mr1LTVaxn0hfNQbhUPhEBr61GxODCjmV6Vcp7s1TMrjsqV0KzM9UsNkBDQRwWxdNFt9+FloloiBc2NdF+AjRZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4477 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 12:23:33 -0000 Hi Lada, Thanks for the feedback. I agree that we should think about this. Looking at those slides, it also asks the question as to whether a YANG fil= e derived from an IANA registry entry should ever differ. I agree with the= answer proposed in those slides: I.e., the two should always be kept in sy= nc, even if that ends causing a non-backwards-compatible change to the YANG= module. But my question is whether we should add any text to the IANA section of th= is document to make this explicit? Regarding your second issue: I agree that unifying the definitions between IANA and YANG would be ideal,= but I'm not sure whether that will be feasible in the short term. draft-ietf-netmod-yang-module-versioning-02 tries to encourage stricter YAN= G definitions of deprecated and obsolete (both in the rules defining what i= s backwards compatible, and also new YANG library leaves to advertise that = the server conforms to the stricter behaviour): I.e., the behaviour that it is trying to encourage is: - deprecated nodes must be implemented (just like status current nodes), = or otherwise explicitly deviated if they are not supported. - obsolete nodes must not be implemented. The reason that stricter semantics are proposed is so that the client can k= now the exact schema supported by the server rather than having to guess wh= ether or not deprecated or obsolete nodes are implemented. I read the IANA definition of deprecated as being "SHOULD NOT implement", a= nd YANG doesn't today have a status value that maps well to. In particular= , YANG doesn't currently have a way to express to a client that a deprecate= d node that "should not be implemented" actually is still implemented by a = server. E.g., the reverse semantics of "deviate not-supported". Hence, I wonder YANG shouldn't end up with 4 levels of status (better name = required for 'really-deprecated'): (1) "current": Current. Must implement or deviate not-supported (2) "deprecated": Going away. Should implement, but may deviate not= -supported (3) "really-deprecated": Really going away. Should not implement, but may= deviate to indicate it is still supported. (4) "obsolete": Dead. Must not implement. Cannot deviate. Note, that a separate status "experimental" has been proposed previously as= an addition for YANG Next, tracked by https://github.com/netmod-wg/yang-ne= xt/issues/59 The IANA version of "deprecated" would map to (3) "really-deprecated" in YA= NG, whilst the IANA definition of "obsolete" matches the YANG definition of= "obsolete". But this can't really be solved until we have a new revision of YANG. Rob > -----Original Message----- > From: netmod On Behalf Of Ladislav Lhotka > Sent: 03 March 2021 12:19 > To: Rob Wilton (rwilton) ; > netmod@ietf.org > Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and > Semver Drafts >=20 > Hi Rob, >=20 > I don't know whether this has been discussed, but one issue that might > need to be addressed is the difference between IANA and YANG in the > definitions of "obsolete" and "deprecated" - the details are here (slide > 5): >=20 > https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa= - > yang-types-for-dns-classes-and-resource-record-types-00 >=20 > The best solution would be to unify the definitions. If this is not > possible (in a short term), then it is IMO necessary to mark an entry tha= t > is made obsolete or deprecated in an IANA registry as "obsolete" in the > YANG module. >=20 > Lada >=20 > "Rob Wilton \(rwilton\)" writes: >=20 > > Hi, > > > > // As an individual contributor > > > > We discussed proposed IANA text at the last NETMOD interim on the YANG > versioning work. Tracked by issue https://github.com/netmod-wg/yang-ver- > dt/issues/59 > > > > I had the action of updating the text based on comments received in the > interim meeting and then sending that text to the list. > > > > The proposed text is below (that is in the current published versions o= f > both drafts). If the WG has no objections to this text, then the planned > next step is to ask IANA for an early review of this text. > > > > > > IANA section in draft-ietf-netmod-yang-module-versioning-02: > > > > 11.2. Guidance for versioning in IANA maintained YANG modules > > > > Note for IANA (to be removed by the RFC editor): Please check that > > the registries and IANA YANG modules are referenced in the > > appropriate way. > > > > IANA is responsible for maintaining and versioning YANG modules that > > are derived from other IANA registries. For example, "iana-if- > > type.yang" [IfTypeYang] is derived from the "Interface Types (ifType= ) > > IANA registry" [IfTypesReg], and "iana-routing-types.yang" > > [RoutingTypesYang] is derived from the "Address Family Numbers" > > [AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI) > > Parameters" [SAFIReg] IANA registries. > > > > Normally, updates to the registries cause any derived YANG modules t= o > > be updated in a backwards-compatible way, but there are some cases > > where the registry updates can cause non-backward-compatible updates > > to the derived YANG module. An example of such an update is the > > 2020-12-31 revision of iana-routing-types.yang > > > > [RoutingTypesDecRevision], where the enum name for two SAFI values > > was changed. > > > > In all cases, IANA MUST follow the versioning guidance specified in > > Section 3.1, and MUST include a "rev:nbc-changes" substatement to th= e > > latest revision statement whenever an IANA maintained module is > > updated in a non-backwards-compatible way, as described in > > Section 3.2. > > > > Note: For published IANA maintained YANG modules that contain non- > > backwards-compatible changes between revisions, a new revision shoul= d > > be published with the "rev:nbc-changes" substatement retrospectively > > added to any revisions containing non-backwards-compatible changes. > > > > Non normative examples of updates to enumeration types in IANA > > maintained modules that would be classified as non-backwards- > > compatible changes are: Changing the status of an enumeration typede= f > > to obsolete, changing the status of an enum entry to obsolete, > > removing an enum entry, changing the identifier of an enum entry, or > > changing the described meaning of an enum entry. > > > > Non normative examples of updates to enumeration types in IANA > > maintained modules that would be classified as backwards-compatible > > changes are: Adding a new enum entry to the end of the enumeration, > > changing the status or an enum entry to deprecated, or improving the > > description of an enumeration that does not change its defined > > meaning. > > > > Non normative examples of updates to identity types in IANA > > maintained modules that would be classified as non-backwards- > > compatible changes are: Changing the status of an identity to > > obsolete, removing an identity, renaming an identity, or changing th= e > > described meaning of an identity. > > > > Non normative examples of updates to identity types in IANA > > maintained modules that would be classified as backwards-compatible > > changes are: Adding a new identity, changing the status or an > > identity to deprecated, or improving the description of an identity > > that does not change its defined meaning. > > > > IANA section for draft-ietf-netmod-yang-semver-02 > > > > 9.2. Guidance for YANG Semver in IANA maintained YANG modules > > > > Note for IANA (to be removed by the RFC editor): Please check that > > the registries and IANA YANG modules are referenced in the > > appropriate way. > > > > IANA is responsible for maintaining and versioning some YANG modules= , > > e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang > > [RoutingTypesYang] . > > > > In addition to following the rules specified in the IANA > > Considerations section of [I-D.ietf-netmod-yang-module-versioning] , > > IANA maintained YANG modules MUST also include a YANG Semver revisio= n > > label for all new revisions, as defined in Section 3 . > > > > The YANG Semver version associated with the new revision MUST follow > > the rules defined in Section 3.3 . > > > > Note: For IANA maintained YANG modules that have already been > > published, revision labels MUST be retrospectively applied to all > > existing revisions when the next new revision is created, starting a= t > > version "1.0.0" for the initial published revision, and then > > incrementing according to the YANG Semver version rules specified in > > Section 3.3 . > > > > Most changes to IANA maintained YANG modules are expected to be > > backwards-compatible changes and classified as MINOR version changes= . > > The PATCH version may be incremented instead when only editorial > > changes are made, and the MAJOR version would be incremented if non- > > backwards-compatible major changes are made. > > > > Given that IANA maintained YANG modules are versioned with a linear > > history, it is anticipated that it should not be necessary to use th= e > > "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT" > > version element. > > > > Comments welcome. > > > > Thanks, > > Rob > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Mar 5 05:58:48 2021 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 275053A2598; Fri, 5 Mar 2021 05:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=NGSBgYK3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LOuTLNhE 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 sTHboHl0GJ3i; Fri, 5 Mar 2021 05:58:43 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EAC3A2595; Fri, 5 Mar 2021 05:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40992; q=dns/txt; s=iport; t=1614952722; x=1616162322; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6Nxa7DGxWkoXi+7AWJEMz1NdtBaoOLEdQJUIjbRhXvM=; b=NGSBgYK3W/9n0IWMFPeEGm9t8t0CLJqhC0zjHn506uVuZkibDcuElDpD tsY7mumGilgyxrFP+vC1E3IL7AY5Z8PwDs+yH4dbBc8B1h27K1ywZWJ/S Zs6N3zjAIOaODqeYT9pkHCTeW7blWJdbs2sy32fMGlgHj/vJTXrsqGs1M c=; IronPort-PHdr: =?us-ascii?q?9a23=3A18vglheKyp26vCVniawrBjZllGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaTB9fK9vdNlO3MsLumUmsFst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8Wyv6DcNHQ?= =?us-ascii?q?/8Lkx+IeGmUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAACUN0Jg/5FdJa1YChoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAYIPgSMwIy4Hdlo2MQqEN4NIA4U5iFcDgQW?= =?us-ascii?q?JIY59glMDVAsBAQENAQEyAgQBAYRNAheBYwIlOBMCAwEBCwEBBQEBAQIBBgR?= =?us-ascii?q?xhWENhkQBAQEEIwoTAQE3AQ8CAQgRAQMBASEHAwICAh8RFAMGCAEBBAENBQg?= =?us-ascii?q?TglaBflcDLwEDow4CiiV2gTKDBAEBBoUkDQuCEwmBOYJ2hAYBAYEMgUaDciY?= =?us-ascii?q?cgUlCgRFDgiI1PoIagXcEERo0gmA0giuBWGwGARcoCwEYBEMKKC0sOUgWAyE?= =?us-ascii?q?PCJBdgyiHSy+MKpA7OVsKgn6WeoVOgzmKUZVilF2OR45jLB6EOAICAgIEBQI?= =?us-ascii?q?OAQEGgWsjKoEtcBWDJFAXAg2OH4NvillzOAIGAQkBAQMJfItmAiYHgQYBMV0?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.81,224,1610409600"; d="scan'208,217";a="871014440" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 13:58:40 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 125Dwel7006327 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 5 Mar 2021 13:58:40 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 07:58:40 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 07:58:39 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 5 Mar 2021 08:58:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M3HZgtXW7KV9O4+cLpay9GMvyD5fg+Bf1z0k0mUU5hK6Q4mmbLBrzIfSJkiTIuISpbnT8gIpw5Qpv22yq/CF9SPGTnpxNJgtguTCixOZK+Y6bY6OpsvkwffQSaaIR40hPUf7orIWowR4+go8Oa3fJxRsW7CCzWfPjYoCquIzNZ62/9uQ1HgzxKolVc0uFFWn8aY8RjOAsvMdU4UgztyaYWHky0DHsuzb0NR/e6gAcMsHa/2/NxRA6FG1lIYR3/ztnXQ0QGER98yr0oaHtE849QkWG7ndNeMAVwkmWTGCkcKigHmuBBzYld6qS+zR1LtJ8kSK0Hu2soX1/voaVdcBBA== 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=6Nxa7DGxWkoXi+7AWJEMz1NdtBaoOLEdQJUIjbRhXvM=; b=cmWDcok3lrjBrk9LMl/MPIQ+xMnsI0hMgTkuOZj4G4RzD7+NAXO8Ec9Z81suIHmtPnl/5MUiJsaVo8FAR06XH4PWr1XMszo7tgPMK59lSKYVMHUm5bu0Mv8TSWGTDHi94UOQlJoeMzPS3/8C1LkZgQMz7wpG/oe/8GWWpjNwfC+t4qqHEBrutwvflC9azMpVt4ZqrnpZg6Cv47TKo3i8p6wrbzsF+E4DnnYI+Yf3CprRgZuHPr/9U6ovSZW35nEU5PWmDMDbH8mY/V0H0LLPdZZG2UZi9/xtuPtuu/+k6BmHs3Od11+NeruMtVCCosiRCmdw9pzNaTRqwetYS3uzig== 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=6Nxa7DGxWkoXi+7AWJEMz1NdtBaoOLEdQJUIjbRhXvM=; b=LOuTLNhEOgJ7hxEXcTG12cjcFRcmLDBLrdlJeXrusw1CPASTbBMtz9ZmAeYvv83+l5d4HCkbMe4wS1C5loyS/D2NeMt3xmW/VPNRIMDPFPDyaKkjxw7eE+EOr0hMpM3ZSBx16keLotg5uCpZ/gn+3lkx60sXDfSy6j3z5DRToNM= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4111.namprd11.prod.outlook.com (2603:10b6:208:138::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Fri, 5 Mar 2021 13:58:37 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3912.022; Fri, 5 Mar 2021 13:58:37 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman , joel jaeggli CC: "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-nmda-diff-07 Thread-Index: Adat+a/3DPT1aCJSTfuydcCuPD9V4wAX4/YAAAExU4AAtpAc8A== Date: Fri, 5 Mar 2021 13:58:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.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: b0d760b4-bf9c-4e8e-8bec-08d8dfdec636 x-ms-traffictypediagnostic: MN2PR11MB4111: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hej9+sfZuE5R8FRxhCT4F6S9X8gBK6MwpPuDlGckXAm9iag1sWyby8lzGBz5nTY30M+to4WbV3dz7ZkBIHNqREXXYgUtAHIIgn2wRrB040m8bpupRepNWlbwnzxKRXYs9G/JDfeC7vrnxzJaaVL+bTkaou12gYuT9AFIZclnWluRIUUSk07eZSs1zCxe5cns4qEXhN+ww92kuh1Vimt+mmNCA7dPlE+Gf7bNZSveG0Or00yS3xgEnad5hzaXo24EqCeja+lD/hY/CFIBfXgzFy9Gj8I8TAklpTNX8A906NmJDlNknPYLqK/AyC6XqHXlMw2I/irbfpo9QYeV3//yoax+amS0nW2r5iMtOOTgrV06Up5E7Z/Q6yrJtzSsCmN42dhfNWMY83BpQYGvOvtzDe9S/g9aSYe9PGkZVWe6bsnr6cni+T55f4DneaG2gqOhpwQXP0lU62XGWlOWm/O6ajR1hyotwbwQsRlHH4JoBfhUHI6t4YMshpzZ4ogn97On+p6obwrCkk8a+z1jb7Q3UA== 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)(39860400002)(396003)(376002)(136003)(346002)(8936002)(52536014)(71200400001)(478600001)(66476007)(64756008)(66946007)(54906003)(9686003)(76116006)(186003)(7696005)(66556008)(8676002)(6506007)(53546011)(4326008)(110136005)(26005)(2906002)(55016002)(316002)(5660300002)(66446008)(86362001)(83380400001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SGd5S1VOemZwcGtzVU9CdzBWQjF5enpRYUt5N3RLbXcyZEY2dG1aV0lXTVZ1?= =?utf-8?B?OTdEYjRkazhOcjl0OUpSaXVxanhNMlFZbGxTaEZOQXBlUGJpTzE3MU56bXFs?= =?utf-8?B?b0tpUWl3RGEyQUdFUjZFMEZhaCtsRGFiS3BEdnA2OU5ETTFrckJVNGM0VllF?= =?utf-8?B?NStERUdMYzdrU1RUT1BwMjdMclc1RXB5Vkl3bDhlaUdWLzdnaGNRSUNGOUNi?= =?utf-8?B?TUlCWEtDNXBML3ZnZDF5NXpSRTJhZjBIOW5JWVYvQkhkbmVKUlhlMVNvbFpT?= =?utf-8?B?eEhXTFJNL0JMN3hmbm5CODc5K2lUZ3U3MENaenNybXU4YlpoSll5Qm12R211?= =?utf-8?B?SWMvSk9VU21uTExoeUkyNTFaTXBsS2xSVkpsNkErUWQvMStaakVtOVFYdWx5?= =?utf-8?B?MHNhcjNKS2FkcG1WclN2Z2JWRE1sSG9RQzRQM0lGazYwckRVc21hekN3ZjdS?= =?utf-8?B?VUFqNW5wU3piZjNyNmY3eGpJL0ZtbHFqeUo2bTJkYkNVR0VGMGIwMVNuU3l4?= =?utf-8?B?NlQyRmsrS3lqaTRqNXFYSk1mYWp5Zy9zVG9IKzZVM1VFaWpSMjVEZ3VyWHM0?= =?utf-8?B?aHFsbzBmTFoxMTl3ZkdiQXVQaWxDdXlLdkdPaHM3Y05KOEQrczllM2VIS3B4?= =?utf-8?B?RDB4TjhJUVdQZHZWT09URXhJcW5ERXhOb1RXaHBWOXRNbDdRYzFicHZSTFpn?= =?utf-8?B?WjVpOGhmalBSUTYvcGxHRzdvc3Q1TFc3eHFXVk8yL1MwV2JINmFRdHVWb3R0?= =?utf-8?B?dm5rSVQrNmwxNzRmY1RKbnZQQXJYdEJ6TEVNWTJFcnZsblJVRjE5aGNBNWhN?= =?utf-8?B?bG96bzNtaDVCTmNxL0Zxb3JPMDNIUWZ3aGN6RkZ5ZDFOak1aMEswVndlWUk1?= =?utf-8?B?bENOcnNyR2VwSGNXVkJkL0hCOTE3R25xZXJuSHhkQ1VzTFVVaUEwMFhVMmRM?= =?utf-8?B?NmRZdEhyaTYrS2ZLV3FNODQxT0VaSmZ4cG5rT0xNVjN1TjFsRkhpTzVTdzNN?= =?utf-8?B?VWVjVkEzVElHVTVON1JvY1ZFWXJ2WWV6dGJhTjJZMEVIYXpoSlRUWXhhUUVZ?= =?utf-8?B?Mmk0dTREUzhpNEZ2aVNoK2RZNHZSWi9vd05sRkFxbExtRDlwaUZEa2pvdVEr?= =?utf-8?B?U1lTclc2N2JZMjZmKy9oazl3SjNoVEVQZFl2Y2VNT2plc0NsRXA2MThuZjVY?= =?utf-8?B?b055ZUVpK2NCN1psSS96dXc2M3NpM0VOOFFrR2NDc2NyMUM1SFhUcTN6MlMw?= =?utf-8?B?V1dQV0h4VE5uR3hLaS95UEdhMHZVMjc4eUlkYTZuVWFhZU9rdmg4L1lvTW95?= =?utf-8?B?aWZHeUQ4aGpFcVdVV0tWZU5YMFlUYTVmMGJobUlqOUFKbTh3SkhkL08wRzFM?= =?utf-8?B?a1p0dTBPdUhiLzhGT2dUbURhYllSWUVvQTVSRmhkaExjbjdZZFdCRkt1ZVBW?= =?utf-8?B?OVd6bkdpNXVaVk5MWnR5MVEwODg5TFJDQ0VVK1QrenY2UGg1U2o0ayt3OTE2?= =?utf-8?B?Z3F5LzlOOVVXbjNwTXkxN0RwOElLSTN0SmhTcmljblpERmUvbFBKdStVNHp1?= =?utf-8?B?a28rbkxPN2p5Nk5yTy8xOVI0djdYZXpUVHBzQjUvNTJZNk5XMEN5ckdGOFE0?= =?utf-8?B?OHhKQ2M2UXU2U2JqaUV4ZGRBcDl2ek85bmpnbzVjUmRaOGlqNDY5RXlRcGNR?= =?utf-8?B?VGJxRER1Q1BDNTY1cnlrRnR0NG1Icm0wNzJucE5BSmFWbHM0YXdIS2NmaVQw?= =?utf-8?Q?bGW5jHaqBTls9nwfo2izeVVQKTI9zPZ5EDKdbU8?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43667D00F54AB5879D3036C9B5969MN2PR11MB4366namp_" 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: b0d760b4-bf9c-4e8e-8bec-08d8dfdec636 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 13:58:37.2743 (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: N6vVfyoa65WwuKOFc8DrvVg2jHFH1lY1TbqnvQhkD9npEd6XnQemnwGV3YwrHAR4vwVy+tBnZijFrC3Opb98xg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4111 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 13:58:46 -0000 --_000_MN2PR11MB43667D00F54AB5879D3036C9B5969MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwgYXV0aG9ycywNCg0KU29ycnkgZm9yIHRoZSBsb25nIGRlbGF5IGluIHJlcGx5aW5n Lg0KDQpQbGVhc2Ugc2VlIFtSV10gaW5saW5lIGJlbG93IOKApg0KDQoNCkZyb206IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+Pg0KU2Vu dDogMzAgT2N0b2JlciAyMDIwIDAxOjQzDQpUbzogam9lbCBqYWVnZ2xpIDxqb2VsamFAZ21haWwu Y29tPG1haWx0bzpqb2VsamFAZ21haWwuY29tPj4NCkNjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8 cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj47IGRyYWZ0LWlldGYt bmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLW5t ZGEtZGlmZi5hbGxAaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1k aWZmLTA3DQoNCg0KDQpPbiBUaHUsIE9jdCAyOSwgMjAyMCBhdCA2OjA5IFBNIGpvZWwgamFlZ2ds aSA8am9lbGphQGdtYWlsLmNvbTxtYWlsdG86am9lbGphQGdtYWlsLmNvbT4+IHdyb3RlOg0KUm9i LA0KDQpUaGVzZSBzZWVtIGxpa2UgcmVhc29uYWJsZSBzdWdnZXN0aW9ucy4NCg0KTGV0cyBzZWUg d2hhdCB0aGUgYXV0aG9ycyBzYXkuDQoNClRoYW5rcyBmb3IgdGhpcw0Kam9lbA0KDQpPbiBUaHUs IE9jdCAyOSwgMjAyMCBhdCA2OjQ3IEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNp c2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiB3cm90ZToNCkhpLA0KDQpIZXJlIGlz IG15IEFEIHJldmlldyBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLTA3LiAgQXBvbG9n aWVzIGZvciB0aGUgZGVsYXkuDQoNClRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzIGRvY3VtZW50 LCBJIHRoaW5rIHRoYXQgaXQgaXMgdXNlZnVsLCBhbmQgbG9va3MgbGlrZSBpdCBpcyBpbiBnb29k IHNoYXBlLg0KDQoNCk1haW4gY29tbWVudHM6DQoNCjEuIFNob3VsZCB0aGVyZSBiZSBhbnkgdGV4 dCBhYm91dCBob3cgdG8gZmluZCBvdXQgd2hhdCBkYXRhc3RvcmVzIGFyZSBzdXBwb3J0ZWQgYnkg YSBkZXZpY2U/ICBFLmcuLCBwb2ludGluZyB0aGVtIHRvIGVpdGhlciBZQU5HIGxpYnJhcnksIG9y IHByb3RvY29sIHNwZWNpZmljIG1lY2hhbmlzbXMgaW4gdGhlIGNhc2Ugb2YgUkVTVENPTkYuDQoN CkRvIHlvdSBoYXZlIGEgc2VjdGlvbiBpbiBtaW5kIGFuZCBzdWdnZXN0ZWQgdGV4dD8NCltSV10N ClBlcmhhcHMgc29tZXdoZXJlIGluIHNlY3Rpb24gNCwgZWl0aGVyIGFzIHBhcnQgb2YgdGhlIGRl c2NyaXB0aW9uIG9mIHNvdXJjZSwgb3IgcGVyaGFwcyBiZWZvcmUgdGhlIHBhcmFtZXRlcnMgYXJl IGRlc2NyaWJlZC4NCg0KUHJvcG9zZWQgdGV4dDoNCuKAnEEgY2xpZW50IGNhbiBkaXNjb3ZlciB3 aGljaCBkYXRhc3RvcmVzIGEgc2VydmVyIHN1cHBvcnRzIGJ5IHJlYWRpbmcgWUFORyBsaWJyYXJ5 IFtSRkMgODUyNV0gZnJvbSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLuKAnQ0KDQoN Cg0KMi4gSXQgbWlnaHQgYmUgaGVscGZ1bCB0byBhZGQgYSBjb21tZW50IGFib3V0IHBvdGVudGlh bCBpc3N1ZXMgdGhhdCBjb3VsZCBhcmlzZSBieSBjb21wYXJpbmcgPHJ1bm5pbmc+IHRvIDxvcGVy YXRpb25hbD4sIGkuZS4sIGFkZGl0aW9uYWwgZGlmZmVyZW5jZXMgY291bGQgYmUgcmVwb3J0ZWQg ZHVlIHRvIGluYWN0aXZlIGNvbmZpZ3VyYXRpb24gYW5kIHRlbXBsYXRlIHByb2Nlc3NpbmcgYmV0 d2VlbiA8cnVubmluZz4gYW5kIDxvcGVyYXRpb25hbD4uDQoNCkRvIHlvdSBoYXZlIGEgc2VjdGlv biBpbiBtaW5kIGFuZCBzdWdnZXN0ZWQgdGV4dD8NCllvdSBtZWFuIGlmIHRoZXJlIGFyZSBkaWZm ZXJlbmNlcyBiZXR3ZWVuIDxydW5uaW5nPiBhbmQgPGludGVuZGVkPg0KdGhlbiBhIGRpZmYgYmV0 d2VlbiA8cnVubmluZz4gYW5kIDxvcGVyYXRpb25hbD4gd2lsbCBub3QgYmUgdGhlIHNhbWUNCmFz IGEgZGlmZiBiZXR3ZWVuIDxpbnRlbmRlZD4gYW5kIDxvcGVyYXRpb25hbD4uPw0KDQpbUlddDQpN eSBtYWluIGNvbmNlcm4gaXMgdGhhdCBpZiB5b3UgaGF2ZSB0ZW1wbGF0ZSBleHBhbnNpb24gdGhl biBjb21wYXJpbmcgPHJ1bm5pbmc+IGFuZCA8b3BlcmF0aW9uYWw+IG1heSBub3QgcmVhbGx5IGdp dmUgYSBtZWFuaW5nZnVsIGNvbXBhcmlzb24sIHNpbmNlIDxydW5uaW5nPiBpcyBwcmUtdGVtcGxh dGUgZXhwYW5zaW9uLCBhbmQgPG9wZXJhdGlvbmFsPiAoYW5kIDxpbnRlbmRlZD4pIGFyZSBib3Ro IHBvc3QgdGVtcGxhdGUgZXhwYW5zaW9uLg0KDQpJIHdvdWxkIHN1Z2dlc3QgcHV0dGluZyBzb21l IHRleHQgaW4gc2VjdGlvbiA0IG9yIHBlcmhhcHMgdGhlIFlBTkcgbW9kdWxlLg0KDQpQZXJoYXBz IHNvbWUgdGV4dCwgc29tZXRoaW5nIGxpa2U6DQoNCiAg4oCcQ2xpZW50cyBzaG91bGQgdG8gYmUg YXdhcmUgdGhhdCBjb21wYXJpbmcgPHJ1bm5pbmc+IHRvIDxvcGVyYXRpb25hbD4gd2lsbCByZXBv cnQgZGlmZmVyZW5jZXMgZHVlIHRvIGFueSBjb25maWd1cmF0aW9uIHRyYW5zZm9ybWF0aW9uIChl LmcuLCBpbmFjdGl2ZSBjb25maWd1cmF0aW9uLCBvciB0aGUgZXhwYW5zaW9uIG9mIHRlbXBsYXRl cykgYmV0d2VlbiB0aGUgPHJ1bm5pbmc+IGFuZCA8aW50ZW5kZWQ+IGRhdGFzdG9yZXMuICBJbiB0 aGVzZSBzY2VuYXJpb3MsIGNsaWVudHMgbWF5IGdldCBhIG1vcmUgdXNlZnVsIHJlc3VsdCBieSBj b21wYXJpbmcgdGhlIDxpbnRlbmRlZD4gYW5kIDxvcGVyYXRpb25hbD4gZGF0YXN0b3JlcyBpbnN0 ZWFkLuKAnQ0KDQoNCg0KDQozLiBJIHdvdWxkIHByZWZlciBpZiAnZXhjbHVkZT1vcmlnaW4nIHdh cyBpbiB0aGUgcmV2ZXJzZSBzZW5zZSBhbmQgcGVyaGFwcyBjYWxsZWQgJ3JlcG9ydC1vcmlnaW4n IGluc3RlYWQuICBXaXRoIHRoZSByZXZlcnNlIHNlbnNlIGl0IHNlZW1zIHRvIGJlIHNhZmVyIGlm IG5ldyBkYXRhc3RvcmVzIGFyZSBkZWZpbmVkLCB3aGVyZSBvdGhlcndpc2UgdGhlIGJlaGF2aW91 ciBjb3VsZCBlbmQgYmVpbmcgdW5kZXIgc3BlY2lmaWVkLg0KDQoNCklNTyB0aGUgV0cgYWxyZWFk eSBkZXNpZ25lZCB0aGUgZmVhdHVyZXMgc28gaWYgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRz IGhhdmUgY2hhbmdlZA0KdGhlbiB0aGUgZHJhZnQgc2hvdWxkIGdvIGJhY2sgdG8gdGhlIFdHIGZv ciBjaGFuZ2VzIGFuZCBuZXcgV0cgY29uc2Vuc3VzIGNhbGxzLg0KW1JXXQ0KDQpJIGRvbuKAmXQg c2VlIHRoaXMgYXMgcmVhbGx5IGNoYW5naW5nIHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cywg YnV0IGp1c3QgY2hhbmdpbmcgdGhlIGRlZmF1bHQgc2Vuc2UgYW5kIG5hbWUgb2YgYW4gQVBJIHBh cmFtZXRlci4gIEFsdGhvdWdoLCBnaXZlbiBteSBjb21tZW50cyBiZWxvdyDigJx3aXRoLW9yaWdp buKAnSBtaWdodCBiZSBiZXR0ZXIgdGhhbiDigJxyZXBvcnQtb3JpZ2lu4oCdLg0KDQpJbiBSRkMg ODUyNiwgdGhlIOKAnHdpdGgtb3JpZ2lu4oCdIHBhcmFtZXRlciBpcyBvZmYgYnkgZGVmYXVsdCwg YW5kIG9yaWdpbiBtZXRhZGF0YSBpcyBvbmx5IGluY2x1ZGVkIHdoZW4gdGhlIHBhcmFtZXRlciBp cyBpbmNsdWRlZC4gIFRoaXMga2V5d29yZCBpcyBhbHNvIHVuZGVyIGEgZmVhdHVyZS4NCg0KU28s IGNoYW5naW5nIHRoZSBwYXJhbWV0ZXIgbmFtZSB0byDigJx3aXRoLW9yaWdpbuKAnSBhbmQgcHV0 dGluZyBpdCB1bmRlciDigJ1pZi1mZWF0dXJlIGlldGYtbmV0Y29uZi1ubWRhOm9yaWdpbuKAnSwg YW5kIG1ha2luZyB0aGUgZGVmYXVsdCBvZmYsIHdvdWxkIG1ha2UgdGhlIGRlZmluaXRpb24gbW9y ZSBjb25zaXN0ZW50IHdpdGggUkZDIDg1MjYuDQoNCg0KDQo0LiBTaG91bGQgdGhlcmUgYmUgYW4g b3B0aW9uIHRvIGZpbHRlciBvbiBvcmlnaW4gbWV0YWRhdGE/ICBFLmcuLCBvbmx5IGluY2x1ZGUg dmFsdWVzIHRoYXQgY29tZSBmcm9tIGludGVuZGVkLiAgT3RoZXJ3aXNlLCB0aGluZ3MgbGlrZSBJ UCBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIERIQ1AgbWF5IGFsd2F5cyB0dXJuIHVwIGFzIGRpZmZl cmVuY2VzLg0KDQpJTU8gdGhlIFdHIGFscmVhZHkgZGVzaWduZWQgdGhlIGZlYXR1cmVzIHNvIGlm IHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBoYXZlIGNoYW5nZWR0aGVuIHRoZSBkcmFmdCBz aG91bGQgZ28gYmFjayB0byB0aGUgV0cgZm9yIGNoYW5nZXMgYW5kIG5ldyBXRyBjb25zZW5zdXMg Y2FsbHMuDQoNCltSV10NCg0KT2theS4NCg0KUmVnYXJkcywNClJvYg0KDQoNCg0KNS4gSSdtIG5v dCB0aGF0IGtlZW4gb24gdGhlICJQb3NzaWJsZSBGdXR1cmUgRXh0ZW5zaW9ucyIgc2VjdGlvbiBv ZiBhbiBSRkMuICBQZXJzb25hbGx5LCBJIHdvdWxkIHByZWZlciB0aGF0IHRoaXMgc2VjdGlvbiBp cyBkZWxldGVkLCBidXQgaWYgeW91IHdpc2ggdG8gcmV0YWluIGl0LCB0aGVuIHBsZWFzZSBjYW4g eW91IG1vdmUgaXQgdG8gYW4gYXBwZW5kaXguDQoNCk9LIHdpdGggbWUgdG8gcmVtb3ZlIGl0DQoN Cg0KDQpBbmR5DQoNCg0KDQpJJ3ZlIGFsc28gaW5jbHVkZWQgc29tZSBtaW5vciBjb21tZW50cyBp bmxpbmUgYmVsb3csIGFuZCBzb21lIG5pdHMgYXQgdGhlIGVuZDoNCg0KICAgIEFic3RyYWN0DQoN CiAgICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gUlBDIG9wZXJhdGlvbiB0byBjb21wYXJl IG1hbmFnZW1lbnQNCiAgICAgICBkYXRhc3RvcmVzIHRoYXQgY29tcGx5IHdpdGggdGhlIE5NREEg YXJjaGl0ZWN0dXJlLg0KDQpUaGUgYWJzdHJhY3QgaXMgcGVyaGFwcyBzb21ld2hhdCB0ZXJzZS4g IFBlcmhhcHM6DQoNCiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIFJQQyBvcGVyYXRp b24gdG8gY29tcGFyZSB0aGUNCiAgICBjb250ZW50cyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZGF0 YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRoDQogICAgdGhlIE5NREEgYXJjaGl0ZWN0dXJlIGFuZCBy ZXR1cm4gdGhlIGRpZmZlcmVuY2VzIGluIHRoZQ0KICAgIFlBTkctUGF0Y2ggZm9ybWF0Lg0KDQoN CiAgICAxLiAgSW50cm9kdWN0aW9uDQoNCiAgICAgICBUaGUgcmV2aXNlZCBOZXR3b3JrIE1hbmFn ZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSAoTk1EQSkNCiAgICAgICBbUkZDODM0Ml0gaW50 cm9kdWNlcyBhIHNldCBvZiBuZXcgZGF0YXN0b3JlcyB0aGF0IGVhY2ggaG9sZCBZQU5HLQ0KICAg ICAgIGRlZmluZWQgZGF0YSBbUkZDNzk1MF0gYW5kIHJlcHJlc2VudCBhIGRpZmZlcmVudCAidmll d3BvaW50IiBvbiB0aGUNCiAgICAgICBkYXRhIHRoYXQgaXMgbWFpbnRhaW5lZCBieSBhIHNlcnZl ci4gIE5ldyBZQU5HIGRhdGFzdG9yZXMgdGhhdCBhcmUNCiAgICAgICBpbnRyb2R1Y2VkIGluY2x1 ZGUgPGludGVuZGVkPiwgd2hpY2ggY29udGFpbnMgdmFsaWRhdGVkIGNvbmZpZ3VyYXRpb24NCiAg ICAgICBkYXRhIHRoYXQgYSBjbGllbnQgYXBwbGljYXRpb24gaW50ZW5kcyB0byBiZSBpbiBlZmZl Y3QsIGFuZA0KICAgICAgIDxvcGVyYXRpb25hbD4sIHdoaWNoIGNvbnRhaW5zIGF0IGxlYXN0IGNv bmNlcHR1YWxseSBvcGVyYXRpb25hbCBzdGF0ZQ0KICAgICAgIGRhdGEgKHN1Y2ggYXMgc3RhdGlz dGljcykgYXMgd2VsbCBhcyBjb25maWd1cmF0aW9uIGRhdGEgdGhhdCBpcw0KICAgICAgIGFjdHVh bGx5IGluIGVmZmVjdC4NCg0KSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5nICJhdCBsZWFzdCBjb25j ZXB0dWFsbHkiLCBzaW5jZSB0aGUgPG9wZXJhdGlvbmFsPg0KZGF0YXN0b3JlIGRvZXMgY29udGFp biBhbGwgb3BlcmF0aW9uYWwgc3RhdGUsIGJ1dCBpdCBtYXkgYmUgaW1wbGVtZW50ZWQgYXMgYSB2 aXJ0dWFsIGNvbnN0cnVjdCB0aGF0IHNwYW5zIG11bHRpcGxlIG5vZGVzIChlLmcuLCBsaW5lY2Fy ZHMpIGFuZCBwcm9jZXNzZXMuDQoNCg0KICAgICAgIE5NREEgaW50cm9kdWNlcyBpbiBlZmZlY3Qg YSBjb25jZXB0IG9mICJsaWZlY3ljbGUiIGZvciBtYW5hZ2VtZW50DQogICAgICAgZGF0YSwgYWxs b3dpbmcgdG8gY2xlYXJseSBkaXN0aW5ndWlzaCBiZXR3ZWVuIGRhdGEgdGhhdCBpcyBwYXJ0IG9m IGENCiAgICAgICBjb25maWd1cmF0aW9uIHRoYXQgd2FzIHN1cHBsaWVkIGJ5IGEgdXNlciwgY29u ZmlndXJhdGlvbiBkYXRhIHRoYXQNCiAgICAgICBoYXMgYWN0dWFsbHkgYmVlbiBzdWNjZXNzZnVs bHkgYXBwbGllZCBhbmQgdGhhdCBpcyBwYXJ0IG9mIHRoZQ0KICAgICAgIG9wZXJhdGlvbmFsIHN0 YXRlLCBhbmQgb3ZlcmFsbCBvcGVyYXRpb25hbCBzdGF0ZSB0aGF0IGluY2x1ZGVzIGJvdGgNCiAg ICAgICBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gZGF0YSBhcyB3ZWxsIGFzIHN0YXR1cyBhbmQgc3Rh dGlzdGljcy4NCg0KImFsbG93aW5nIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2giID0+IGRpc3Rpbmd1 aXNoaW5nIg0KInN0YXR1cyBhbmQgc3RhdGlzdGljcyIgPT4gInN0YXR1cyBpbmZvcm1hdGlvbiBh bmQgc3RhdGlzdGljcyINCg0KDQogICAgICAgQXMgYSByZXN1bHQsIGRhdGEgZnJvbSB0aGUgc2Ft ZSBtYW5hZ2VtZW50IG1vZGVsIGNhbiBiZSByZWZsZWN0ZWQgaW4NCiAgICAgICBtdWx0aXBsZSBk YXRhc3RvcmVzLiAgQ2xpZW50cyBuZWVkIHRvIHNwZWNpZnkgdGhlIHRhcmdldCBkYXRhc3RvcmUg dG8NCiAgICAgICBiZSBzcGVjaWZpYyBhYm91dCB3aGljaCB2aWV3cG9pbnQgb2YgdGhlIGRhdGEg dGhleSB3YW50IHRvIGFjY2Vzcy4NCiAgICAgICBUaGlzIHdheSwgYW4gYXBwbGljYXRpb24gY2Fu IGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGV5IGFyZSAoZm9yDQogICAgICAgZXhhbXBsZSkgaW50 ZXJlc3RlZCBpbiB0aGUgY29uZmlndXJhdGlvbiB0aGF0IGhhcyBiZWVuIGFwcGxpZWQgYW5kIGlz DQogICAgICAgYWN0dWFsbHkgaW4gZWZmZWN0LCBvciBpbiB0aGUgY29uZmlndXJhdGlvbiB0aGF0 IHdhcyBzdXBwbGllZCBieSBhDQogICAgICAgY2xpZW50IGFuZCB0aGF0IGlzIHN1cHBvc2VkIHRv IGJlIGluIGVmZmVjdC4NCg0KUGVyaGFwcyByZXdvcmQgdGhlIGxhc3Qgc2VudGVuY2UgdG8gbWF0 Y2ggdGhlIGxvZ2ljYWwgZGF0YSBmbG93IGluIHRoZSBzZXJ2ZXI6DQoNCiAgIEZvciBleGFtcGxl LCBhIGNsaWVudCBhcHBsaWNhdGlvbiBjYW4gZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZXkgYXJl DQogICBpbnRlcmVzdGVkIGluIHRoZSBjb25maWd1cmF0aW9uIHN1cHBsaWVkIHRvIGEgc2VydmVy IGFuZCB0aGF0IGlzDQogICBzdXBwb3NlZCB0byBiZSBpbiBlZmZlY3QsIG9yIHRoZSBjb25maWd1 cmF0aW9uIHRoYXQgaGFzIGJlZW4gYXBwbGllZCBhbmQgaXMNCiAgIGFjdHVhbGx5IGluIGVmZmVj dCBvbiB0aGUgc2VydmVyLg0KDQoNCiAgICAgICBXaGVuIGNvbmZpZ3VyYXRpb24gdGhhdCBpcyBp biBlZmZlY3QgaXMgZGlmZmVyZW50IGZyb20gY29uZmlndXJhdGlvbg0KICAgICAgIHRoYXQgd2Fz IGFwcGxpZWQsIG1hbnkgaXNzdWVzIGNhbiByZXN1bHQuICBJdCBiZWNvbWVzIG1vcmUgZGlmZmlj dWx0DQogICAgICAgdG8gb3BlcmF0ZSB0aGUgbmV0d29yayBwcm9wZXJseSBkdWUgdG8gbGltaXRl ZCB2aXNpYmlsaXR5IG9mIGFjdHVhbA0KICAgICAgIHN0YXR1cyB3aGljaCBtYWtlcyBpdCBtb3Jl IGRpZmZpY3VsdCB0byBhbmFseXplIGFuZCB1bmRlcnN0YW5kIHdoYXQNCiAgICAgICBpcyBnb2lu ZyBvbiBpbiB0aGUgbmV0d29yay4gIFNlcnZpY2VzIG1heSBiZSBuZWdhdGl2ZWx5IGFmZmVjdGVk IChmb3INCiAgICAgICBleGFtcGxlLCBicmVha2luZyBhIHNlcnZpY2UgaW5zdGFuY2UgcmVzdWx0 aW5nIGluIHNlcnZpY2UgaXMgbm90DQogICAgICAgcHJvcGVybHkgZGVsaXZlcmVkIHRvIGEgY3Vz dG9tZXIpIGFuZCBuZXR3b3JrIHJlc291cmNlcyBiZQ0KICAgICAgIG1pc2FsbG9jYXRlZC4NCg0K UGVyaGFwcyBjaGFuZ2UgImFjdHVhbCBzdGF0dXMiIHRvICJhY3R1YWwgb3BlcmF0aW9uYWwgc3Rh dHVzIi4NCg0KSSBhbHNvIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGxhc3Qgc2VudGVuY2UgdG86DQoN CiAgICBTZXJ2aWNlcyBtYXkgYmUgbmVnYXRpdmVseSBhZmZlY3RlZCAoZS5nLiwgZGVncmFkaW5n IG9yIGJyZWFraW5nIGEgY3VzdG9tZXIgc2VydmljZSkgb3IgbmV0d29yayByZXNvdXJjZXMgbWF5 IGJlIG1pc2FsbG9jYXRlZC4NCg0KDQogICAgICAgIDMuIERlZmluaXRpb25zOg0KDQpJdCBzaG91 bGQgcHJvYmFibHkgZGVmaW5lIHRoYXQgPGludGVuZGVkPiwgPG9wZXJhdGlvbmFsPiwgKGFuZCBw ZXJoYXBzIDxydW5uaW5nPikgYXJlIHVzZWQgdG8gaW5kaWNhdGUgbmFtZXMgb2YgZGF0YXN0b3Jl cy4NCg0KSXQgc2hvdWxkIGFsc28gZXhwbGFpbiB0aGF0IDxjb21wYXJlPiBpcyB1c2VkIGFzIHRo ZSBuYW1lIG9mIGEgWUFORyBSUEMuDQoNCg0KICAgIDQuICBEYXRhIE1vZGVsIE92ZXJ2aWV3DQoN CiAgICAgICBBdCB0aGUgY29yZSBvZiB0aGUgc29sdXRpb24gaXMgYSBuZXcgbWFuYWdlbWVudCBv cGVyYXRpb24sIDxjb21wYXJlPiwNCiAgICAgICB0aGF0IGFsbG93cyB0byBjb21wYXJlIHR3byBk YXRhc3RvcmVzIGZvciB0aGUgc2FtZSBkYXRhLg0KDQpTdWdnZXN0IHJld29yZGluZyB0aGlzIGZp cnN0IHNlbnRlbmNlIHRvOg0KDQogIFRoZSBjb3JlIG9mIHRoZSBzb2x1dGlvbiBpcyBhIG5ldyBt YW5hZ2VtZW50IG9wZXJhdGlvbiwgPGNvbXBhcmU+LA0KICB0aGF0IGNvbXBhcmVzIHRoZSBkYXRh IHRyZWUgY29udGVudHMgb2YgdHdvIGRhdGFzdG9yZXMuDQoNCiAgICAgICBvICB0YXJnZXQ6IFRo ZSB0YXJnZXQgaWRlbnRpZmllcyB0aGUgZGF0YXN0b3JlIHRvIGNvbXBhcmUgYWdhaW5zdCB0aGUN CiAgICAgICAgICBzb3VyY2UuDQoNClN1Z2dlc3QgYWRkaW5nIGFuIGV4YW1wbGUgIiwgZS5nLiwg PG9wZXJhdGlvbmFsPi4iDQoNCiAgICAgICBvICBmaWx0ZXItc3BlYzogVGhpcyBpcyBhIGNob2lj ZSBiZXR3ZWVuIGRpZmZlcmVudCBmaWx0ZXIgY29uc3RydWN0cw0KICAgICAgICAgIHRvIGlkZW50 aWZ5IHRoZSBwb3J0aW9ucyBvZiB0aGUgZGF0YXN0b3JlIHRvIGJlIHJldHJpZXZlZC4gIEl0DQog ICAgICAgICAgYWN0cyBhcyBhIG5vZGUgc2VsZWN0b3IgdGhhdCBzcGVjaWZpZXMgd2hpY2ggZGF0 YSBub2RlcyBhcmUgd2l0aGluDQogICAgICAgICAgdGhlIHNjb3BlIG9mIHRoZSBjb21wYXJpc29u IGFuZCB3aGljaCBub2RlcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUNCg== --_000_MN2PR11MB43667D00F54AB5879D3036C9B5969MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpIEFuZHksIGF1dGhvcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvcnJ5IGZvciB0aGUgbG9uZyBk ZWxheSBpbiByZXBseWluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UGxlYXNlIHNlZSBbUlddIGlubGluZSBiZWxvdyDigKY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gQW5keSBCaWVybWFuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZHlAeXVtYXdvcmtzLmNvbTwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAzMCBPY3RvYmVyIDIwMjAg MDE6NDM8YnI+DQo8Yj5Ubzo8L2I+IGpvZWwgamFlZ2dsaSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpqb2VsamFAZ21haWwuY29tIj48c3BhbiBsYW5nPSJFTi1VUyI+am9lbGphQGdtYWlsLmNv bTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvYiBX aWx0b24gKHJ3aWx0b24pICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28u Y29tIj48c3BhbiBsYW5nPSJFTi1VUyI+cndpbHRvbkBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW5l dG1vZC1ubWRhLWRpZmYuYWxsQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+ZHJhZnQtaWV0 Zi1uZXRtb2Qtbm1kYS1kaWZmLmFsbEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t VVMiPjsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj48c3BhbiBsYW5n PSJFTi1VUyI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1k YS1kaWZmLTA3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFRodSwgT2N0IDI5LCAyMDIwIGF0IDY6MDkgUE0gam9lbCBqYWVnZ2xpICZs dDs8YSBocmVmPSJtYWlsdG86am9lbGphQGdtYWlsLmNvbSI+am9lbGphQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Um9iLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGVzZSBzZWVtIGxpa2UgcmVhc29uYWJsZSBzdWdnZXN0aW9ucy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TGV0cyBzZWUgd2hhdCB0aGUgYXV0aG9ycyBzYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhpczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+am9lbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3QgMjksIDIwMjAgYXQg Njo0NyBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25A Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPkhpLDxicj4NCjxicj4NCkhlcmUgaXMgbXkgQUQgcmV2aWV3IGZvciBkcmFm dC1pZXRmLW5ldG1vZC1ubWRhLWRpZmYtMDcuJm5ic3A7IEFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5 Ljxicj4NCjxicj4NClRoYW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzIGRvY3VtZW50LCBJIHRoaW5r IHRoYXQgaXQgaXMgdXNlZnVsLCBhbmQgbG9va3MgbGlrZSBpdCBpcyBpbiBnb29kIHNoYXBlLjxi cj4NCjxicj4NCjxicj4NCk1haW4gY29tbWVudHM6PGJyPg0KPGJyPg0KMS4gU2hvdWxkIHRoZXJl IGJlIGFueSB0ZXh0IGFib3V0IGhvdyB0byBmaW5kIG91dCB3aGF0IGRhdGFzdG9yZXMgYXJlIHN1 cHBvcnRlZCBieSBhIGRldmljZT8mbmJzcDsgRS5nLiwgcG9pbnRpbmcgdGhlbSB0byBlaXRoZXIg WUFORyBsaWJyYXJ5LCBvciBwcm90b2NvbCBzcGVjaWZpYyBtZWNoYW5pc21zIGluIHRoZSBjYXNl IG9mIFJFU1RDT05GLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHlvdSBo YXZlIGEgc2VjdGlvbiBpbiBtaW5kIGFuZCBzdWdnZXN0ZWQgdGV4dD88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltSV10gPG86cD48L286cD48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlBlcmhhcHMgc29tZXdoZXJlIGluIHNlY3Rpb24g NCwgZWl0aGVyIGFzIHBhcnQgb2YgdGhlIGRlc2NyaXB0aW9uIG9mIHNvdXJjZSwgb3IgcGVyaGFw cyBiZWZvcmUgdGhlIHBhcmFtZXRlcnMgYXJlIGRlc2NyaWJlZC48bzpwPjwvbzpwPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlByb3Bvc2VkIHRleHQ6PG86cD48L286 cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox Ni41cHQiPjxiPjxpPuKAnEEgY2xpZW50IGNhbiBkaXNjb3ZlciB3aGljaCBkYXRhc3RvcmVzIGEg c2VydmVyIHN1cHBvcnRzIGJ5IHJlYWRpbmcgWUFORyBsaWJyYXJ5IFtSRkMgODUyNV0gZnJvbSB0 aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLuKAnTxvOnA+PC9vOnA+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Mi4gSXQg bWlnaHQgYmUgaGVscGZ1bCB0byBhZGQgYSBjb21tZW50IGFib3V0IHBvdGVudGlhbCBpc3N1ZXMg dGhhdCBjb3VsZCBhcmlzZSBieSBjb21wYXJpbmcgJmx0O3J1bm5pbmcmZ3Q7IHRvICZsdDtvcGVy YXRpb25hbCZndDssIGkuZS4sIGFkZGl0aW9uYWwgZGlmZmVyZW5jZXMgY291bGQgYmUgcmVwb3J0 ZWQgZHVlIHRvIGluYWN0aXZlIGNvbmZpZ3VyYXRpb24gYW5kIHRlbXBsYXRlDQogcHJvY2Vzc2lu ZyBiZXR3ZWVuICZsdDtydW5uaW5nJmd0OyBhbmQgJmx0O29wZXJhdGlvbmFsJmd0Oy48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgaGF2ZSBhIHNlY3Rpb24gaW4gbWlu ZCBhbmQgc3VnZ2VzdGVkIHRleHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3UgbWVhbiBpZiB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgYmV0d2Vl biAmbHQ7cnVubmluZyZndDsgYW5kICZsdDtpbnRlbmRlZCZndDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZW4gYSBkaWZmIGJldHdlZW4gJmx0 O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IHdpbGwgbm90IGJlIHRoZSBzYW1l PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcyBh IGRpZmYgYmV0d2VlbiAmbHQ7aW50ZW5kZWQmZ3Q7IGFuZCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7Lj88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+W1JXXSA8bzpwPjwvbzpwPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+TXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgaWYg eW91IGhhdmUgdGVtcGxhdGUgZXhwYW5zaW9uIHRoZW4gY29tcGFyaW5nICZsdDtydW5uaW5nJmd0 OyBhbmQgJmx0O29wZXJhdGlvbmFsJmd0OyBtYXkgbm90IHJlYWxseSBnaXZlIGEgbWVhbmluZ2Z1 bCBjb21wYXJpc29uLCBzaW5jZSAmbHQ7cnVubmluZyZndDsgaXMgcHJlLXRlbXBsYXRlIGV4cGFu c2lvbiwgYW5kICZsdDtvcGVyYXRpb25hbCZndDsgKGFuZCAmbHQ7aW50ZW5kZWQmZ3Q7KSBhcmUg Ym90aA0KIHBvc3QgdGVtcGxhdGUgZXhwYW5zaW9uLjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+SSB3b3VsZCBzdWdnZXN0IHB1dHRpbmcgc29tZSB0 ZXh0IGluIHNlY3Rpb24gNCBvciBwZXJoYXBzIHRoZSBZQU5HIG1vZHVsZS48bzpwPjwvbzpwPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlBlcmhhcHMgc29tZSB0ZXh0 LCBzb21ldGhpbmcgbGlrZTogPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT4mbmJzcDsg4oCcQ2xpZW50cyBzaG91bGQgdG8gYmUgYXdhcmUgdGhhdCBj b21wYXJpbmcgJmx0O3J1bm5pbmcmZ3Q7IHRvICZsdDtvcGVyYXRpb25hbCZndDsgd2lsbCByZXBv cnQgZGlmZmVyZW5jZXMgZHVlIHRvIGFueSBjb25maWd1cmF0aW9uIHRyYW5zZm9ybWF0aW9uIChl LmcuLCBpbmFjdGl2ZSBjb25maWd1cmF0aW9uLCBvciB0aGUgZXhwYW5zaW9uIG9mIHRlbXBsYXRl cykgYmV0d2VlbiB0aGUgJmx0O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7aW50ZW5kZWQmZ3Q7DQogZGF0 YXN0b3Jlcy4mbmJzcDsgSW4gdGhlc2Ugc2NlbmFyaW9zLCBjbGllbnRzIG1heSBnZXQgYSBtb3Jl IHVzZWZ1bCByZXN1bHQgYnkgY29tcGFyaW5nIHRoZSAmbHQ7aW50ZW5kZWQmZ3Q7IGFuZCAmbHQ7 b3BlcmF0aW9uYWwmZ3Q7IGRhdGFzdG9yZXMgaW5zdGVhZC7igJ08bzpwPjwvbzpwPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+My4gSSB3b3VsZCBwcmVmZXIgaWYgJ2V4Y2x1ZGU9b3JpZ2luJyB3YXMgaW4g dGhlIHJldmVyc2Ugc2Vuc2UgYW5kIHBlcmhhcHMgY2FsbGVkICdyZXBvcnQtb3JpZ2luJyBpbnN0 ZWFkLiZuYnNwOyBXaXRoIHRoZSByZXZlcnNlIHNlbnNlIGl0IHNlZW1zIHRvIGJlIHNhZmVyIGlm IG5ldyBkYXRhc3RvcmVzIGFyZSBkZWZpbmVkLCB3aGVyZSBvdGhlcndpc2UgdGhlIGJlaGF2aW91 ciBjb3VsZCBlbmQgYmVpbmcgdW5kZXIgc3BlY2lmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SU1PIHRoZSBXRyBhbHJlYWR5IGRlc2lnbmVkIHRoZSBmZWF0dXJlcyBz byBpZiB0aGUgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgaGF2ZSBjaGFuZ2VkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGVuIHRoZSBkcmFmdCBz aG91bGQgZ28gYmFjayB0byB0aGUgV0cgZm9yIGNoYW5nZXMgYW5kIG5ldyBXRyBjb25zZW5zdXMg Y2FsbHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5bUlddIDxv OnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZu YnNwOzwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+SSBkb27i gJl0IHNlZSB0aGlzIGFzIHJlYWxseSBjaGFuZ2luZyB0aGUgZnVuY3Rpb25hbCByZXF1aXJlbWVu dHMsIGJ1dCBqdXN0IGNoYW5naW5nIHRoZSBkZWZhdWx0IHNlbnNlIGFuZCBuYW1lIG9mIGFuIEFQ SSBwYXJhbWV0ZXIuJm5ic3A7IEFsdGhvdWdoLCBnaXZlbiBteSBjb21tZW50cyBiZWxvdyDigJx3 aXRoLW9yaWdpbuKAnSBtaWdodCBiZSBiZXR0ZXIgdGhhbiDigJxyZXBvcnQtb3JpZ2lu4oCdLjxv OnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZu YnNwOzwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+SW4gUkZD IDg1MjYsIHRoZSDigJx3aXRoLW9yaWdpbuKAnSBwYXJhbWV0ZXIgaXMgb2ZmIGJ5IGRlZmF1bHQs IGFuZCBvcmlnaW4gbWV0YWRhdGEgaXMgb25seSBpbmNsdWRlZCB3aGVuIHRoZSBwYXJhbWV0ZXIg aXMgaW5jbHVkZWQuJm5ic3A7IFRoaXMga2V5d29yZCBpcyBhbHNvIHVuZGVyIGEgZmVhdHVyZS48 bzpwPjwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4m bmJzcDs8L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlNvLCBj aGFuZ2luZyB0aGUgcGFyYW1ldGVyIG5hbWUgdG8g4oCcd2l0aC1vcmlnaW7igJ0gYW5kIHB1dHRp bmcgaXQgdW5kZXIg4oCdaWYtZmVhdHVyZSBpZXRmLW5ldGNvbmYtbm1kYTpvcmlnaW7igJ0sIGFu ZCBtYWtpbmcgdGhlIGRlZmF1bHQgb2ZmLCB3b3VsZCBtYWtlIHRoZSBkZWZpbml0aW9uIG1vcmUg Y29uc2lzdGVudCB3aXRoIFJGQyA4NTI2LjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo0LiBTaG91bGQgdGhlcmUgYmUgYW4gb3B0 aW9uIHRvIGZpbHRlciBvbiBvcmlnaW4gbWV0YWRhdGE/Jm5ic3A7IEUuZy4sIG9ubHkgaW5jbHVk ZSB2YWx1ZXMgdGhhdCBjb21lIGZyb20gaW50ZW5kZWQuJm5ic3A7IE90aGVyd2lzZSwgdGhpbmdz IGxpa2UgSVAgYWRkcmVzc2VzIGxlYXJuZWQgZnJvbSBESENQIG1heSBhbHdheXMgdHVybiB1cCBh cyBkaWZmZXJlbmNlcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gdGhl IFdHIGFscmVhZHkgZGVzaWduZWQgdGhlIGZlYXR1cmVzIHNvIGlmIHRoZSBmdW5jdGlvbmFsIHJl cXVpcmVtZW50cyBoYXZlIGNoYW5nZWR0aGVuIHRoZSBkcmFmdCBzaG91bGQgZ28gYmFjayB0byB0 aGUgV0cgZm9yIGNoYW5nZXMgYW5kIG5ldyBXRyBjb25zZW5zdXMgY2FsbHMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltSV10gPG86cD48L286cD48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5Pa2F5LjxvOnA+PC9vOnA+PC9pPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+UmVnYXJkcyw8bzpwPjwvbzpwPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+Um9iPG86cD48L286cD48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KNS4gSSdtIG5vdCB0aGF0IGtlZW4gb24gdGhlICZxdW90O1Bvc3NpYmxlIEZ1dHVyZSBF eHRlbnNpb25zJnF1b3Q7IHNlY3Rpb24gb2YgYW4gUkZDLiZuYnNwOyBQZXJzb25hbGx5LCBJIHdv dWxkIHByZWZlciB0aGF0IHRoaXMgc2VjdGlvbiBpcyBkZWxldGVkLCBidXQgaWYgeW91IHdpc2gg dG8gcmV0YWluIGl0LCB0aGVuIHBsZWFzZSBjYW4geW91IG1vdmUgaXQgdG8gYW4gYXBwZW5kaXgu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0sgd2l0aCBtZSB0byByZW1vdmUg aXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCkkndmUgYWxzbyBpbmNsdWRlZCBzb21lIG1pbm9yIGNvbW1lbnRzIGlubGluZSBiZWxv dywgYW5kIHNvbWUgbml0cyBhdCB0aGUgZW5kOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQWJz dHJhY3Q8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50 IGRlZmluZXMgYW4gUlBDIG9wZXJhdGlvbiB0byBjb21wYXJlIG1hbmFnZW1lbnQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhc3RvcmVzIHRoYXQgY29tcGx5IHdpdGggdGhlIE5N REEgYXJjaGl0ZWN0dXJlLjxicj4NCjxicj4NClRoZSBhYnN0cmFjdCBpcyBwZXJoYXBzIHNvbWV3 aGF0IHRlcnNlLiZuYnNwOyBQZXJoYXBzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgWUFORyBSUEMgb3BlcmF0aW9uIHRvIGNvbXBhcmUgdGhlPGJyPg0K Jm5ic3A7ICZuYnNwOyBjb250ZW50cyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZGF0YXN0b3JlcyB0 aGF0IGNvbXBseSB3aXRoPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgTk1EQSBhcmNoaXRlY3R1cmUg YW5kIHJldHVybiB0aGUgZGlmZmVyZW5jZXMgaW4gdGhlIDxicj4NCiZuYnNwOyAmbmJzcDsgWUFO Ry1QYXRjaCBmb3JtYXQuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAxLiZuYnNwOyBJ bnRyb2R1Y3Rpb248YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgcmV2 aXNlZCBOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSAoTk1EQSk8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUkZDODM0Ml0gaW50cm9kdWNlcyBhIHNldCBv ZiBuZXcgZGF0YXN0b3JlcyB0aGF0IGVhY2ggaG9sZCBZQU5HLTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RlZmluZWQgZGF0YSBbUkZDNzk1MF0gYW5kIHJlcHJlc2VudCBhIGRpZmZl cmVudCAmcXVvdDt2aWV3cG9pbnQmcXVvdDsgb24gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZGF0YSB0aGF0IGlzIG1haW50YWluZWQgYnkgYSBzZXJ2ZXIuJm5ic3A7IE5ldyBZ QU5HIGRhdGFzdG9yZXMgdGhhdCBhcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtp bnRyb2R1Y2VkIGluY2x1ZGUgJmx0O2ludGVuZGVkJmd0Oywgd2hpY2ggY29udGFpbnMgdmFsaWRh dGVkIGNvbmZpZ3VyYXRpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhIHRo YXQgYSBjbGllbnQgYXBwbGljYXRpb24gaW50ZW5kcyB0byBiZSBpbiBlZmZlY3QsIGFuZDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtvcGVyYXRpb25hbCZndDssIHdoaWNoIGNv bnRhaW5zIGF0IGxlYXN0IGNvbmNlcHR1YWxseSBvcGVyYXRpb25hbCBzdGF0ZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RhdGEgKHN1Y2ggYXMgc3RhdGlzdGljcykgYXMgd2VsbCBh cyBjb25maWd1cmF0aW9uIGRhdGEgdGhhdCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2FjdHVhbGx5IGluIGVmZmVjdC48YnI+DQo8YnI+DQpJIHdvdWxkIHN1Z2dlc3QgZGVsZXRp bmcgJnF1b3Q7YXQgbGVhc3QgY29uY2VwdHVhbGx5JnF1b3Q7LCBzaW5jZSB0aGUgJmx0O29wZXJh dGlvbmFsJmd0Ozxicj4NCmRhdGFzdG9yZSBkb2VzIGNvbnRhaW4gYWxsIG9wZXJhdGlvbmFsIHN0 YXRlLCBidXQgaXQgbWF5IGJlIGltcGxlbWVudGVkIGFzIGEgdmlydHVhbCBjb25zdHJ1Y3QgdGhh dCBzcGFucyBtdWx0aXBsZSBub2RlcyAoZS5nLiwgbGluZWNhcmRzKSBhbmQgcHJvY2Vzc2VzLjxi cj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05NREEgaW50cm9kdWNl cyBpbiBlZmZlY3QgYSBjb25jZXB0IG9mICZxdW90O2xpZmVjeWNsZSZxdW90OyBmb3IgbWFuYWdl bWVudDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RhdGEsIGFsbG93aW5nIHRvIGNs ZWFybHkgZGlzdGluZ3Vpc2ggYmV0d2VlbiBkYXRhIHRoYXQgaXMgcGFydCBvZiBhPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbiB0aGF0IHdhcyBzdXBwbGllZCBi eSBhIHVzZXIsIGNvbmZpZ3VyYXRpb24gZGF0YSB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aGFzIGFjdHVhbGx5IGJlZW4gc3VjY2Vzc2Z1bGx5IGFwcGxpZWQgYW5kIHRoYXQg aXMgcGFydCBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvcGVyYXRpb25h bCBzdGF0ZSwgYW5kIG92ZXJhbGwgb3BlcmF0aW9uYWwgc3RhdGUgdGhhdCBpbmNsdWRlcyBib3Ro PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXBwbGllZCBjb25maWd1cmF0aW9uIGRh dGEgYXMgd2VsbCBhcyBzdGF0dXMgYW5kIHN0YXRpc3RpY3MuPGJyPg0KPGJyPg0KJnF1b3Q7YWxs b3dpbmcgdG8gY2xlYXJseSBkaXN0aW5ndWlzaCZxdW90OyA9Jmd0OyBkaXN0aW5ndWlzaGluZyZx dW90Ozxicj4NCiZxdW90O3N0YXR1cyBhbmQgc3RhdGlzdGljcyZxdW90OyA9Jmd0OyAmcXVvdDtz dGF0dXMgaW5mb3JtYXRpb24gYW5kIHN0YXRpc3RpY3MmcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBcyBhIHJlc3VsdCwgZGF0YSBmcm9tIHRoZSBzYW1l IG1hbmFnZW1lbnQgbW9kZWwgY2FuIGJlIHJlZmxlY3RlZCBpbjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO211bHRpcGxlIGRhdGFzdG9yZXMuJm5ic3A7IENsaWVudHMgbmVlZCB0byBz cGVjaWZ5IHRoZSB0YXJnZXQgZGF0YXN0b3JlIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7YmUgc3BlY2lmaWMgYWJvdXQgd2hpY2ggdmlld3BvaW50IG9mIHRoZSBkYXRhIHRoZXkg d2FudCB0byBhY2Nlc3MuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyB3YXks IGFuIGFwcGxpY2F0aW9uIGNhbiBkaWZmZXJlbnRpYXRlIHdoZXRoZXIgdGhleSBhcmUgKGZvcjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4YW1wbGUpIGludGVyZXN0ZWQgaW4gdGhl IGNvbmZpZ3VyYXRpb24gdGhhdCBoYXMgYmVlbiBhcHBsaWVkIGFuZCBpczxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2FjdHVhbGx5IGluIGVmZmVjdCwgb3IgaW4gdGhlIGNvbmZpZ3Vy YXRpb24gdGhhdCB3YXMgc3VwcGxpZWQgYnkgYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2NsaWVudCBhbmQgdGhhdCBpcyBzdXBwb3NlZCB0byBiZSBpbiBlZmZlY3QuPGJyPg0KPGJy Pg0KUGVyaGFwcyByZXdvcmQgdGhlIGxhc3Qgc2VudGVuY2UgdG8gbWF0Y2ggdGhlIGxvZ2ljYWwg ZGF0YSBmbG93IGluIHRoZSBzZXJ2ZXI6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0ZvciBleGFt cGxlLCBhIGNsaWVudCBhcHBsaWNhdGlvbiBjYW4gZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZXkg YXJlPGJyPg0KJm5ic3A7ICZuYnNwO2ludGVyZXN0ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3Vw cGxpZWQgdG8gYSBzZXJ2ZXIgYW5kIHRoYXQgaXM8YnI+DQombmJzcDsgJm5ic3A7c3VwcG9zZWQg dG8gYmUgaW4gZWZmZWN0LCBvciB0aGUgY29uZmlndXJhdGlvbiB0aGF0IGhhcyBiZWVuIGFwcGxp ZWQgYW5kIGlzPGJyPg0KJm5ic3A7ICZuYnNwO2FjdHVhbGx5IGluIGVmZmVjdCBvbiB0aGUgc2Vy dmVyLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doZW4gY29u ZmlndXJhdGlvbiB0aGF0IGlzIGluIGVmZmVjdCBpcyBkaWZmZXJlbnQgZnJvbSBjb25maWd1cmF0 aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCB3YXMgYXBwbGllZCwgbWFu eSBpc3N1ZXMgY2FuIHJlc3VsdC4mbmJzcDsgSXQgYmVjb21lcyBtb3JlIGRpZmZpY3VsdDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIG9wZXJhdGUgdGhlIG5ldHdvcmsgcHJvcGVy bHkgZHVlIHRvIGxpbWl0ZWQgdmlzaWJpbGl0eSBvZiBhY3R1YWw8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtzdGF0dXMgd2hpY2ggbWFrZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8gYW5h bHl6ZSBhbmQgdW5kZXJzdGFuZCB3aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aXMgZ29pbmcgb24gaW4gdGhlIG5ldHdvcmsuJm5ic3A7IFNlcnZpY2VzIG1heSBiZSBuZWdhdGl2 ZWx5IGFmZmVjdGVkIChmb3I8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleGFtcGxl LCBicmVha2luZyBhIHNlcnZpY2UgaW5zdGFuY2UgcmVzdWx0aW5nIGluIHNlcnZpY2UgaXMgbm90 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvcGVybHkgZGVsaXZlcmVkIHRvIGEg Y3VzdG9tZXIpIGFuZCBuZXR3b3JrIHJlc291cmNlcyBiZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO21pc2FsbG9jYXRlZC48YnI+DQo8YnI+DQpQZXJoYXBzIGNoYW5nZSAmcXVvdDth Y3R1YWwgc3RhdHVzJnF1b3Q7IHRvICZxdW90O2FjdHVhbCBvcGVyYXRpb25hbCBzdGF0dXMmcXVv dDsuPGJyPg0KPGJyPg0KSSBhbHNvIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGxhc3Qgc2VudGVuY2Ug dG86PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBTZXJ2aWNlcyBtYXkgYmUgbmVnYXRpdmVseSBh ZmZlY3RlZCAoZS5nLiwgZGVncmFkaW5nIG9yIGJyZWFraW5nIGEgY3VzdG9tZXIgc2VydmljZSkg b3IgbmV0d29yayByZXNvdXJjZXMgbWF5IGJlIG1pc2FsbG9jYXRlZC48YnI+DQo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMy4gRGVmaW5pdGlvbnM6PGJyPg0KPGJyPg0K SXQgc2hvdWxkIHByb2JhYmx5IGRlZmluZSB0aGF0ICZsdDtpbnRlbmRlZCZndDssICZsdDtvcGVy YXRpb25hbCZndDssIChhbmQgcGVyaGFwcyAmbHQ7cnVubmluZyZndDspIGFyZSB1c2VkIHRvIGlu ZGljYXRlIG5hbWVzIG9mIGRhdGFzdG9yZXMuPGJyPg0KPGJyPg0KSXQgc2hvdWxkIGFsc28gZXhw bGFpbiB0aGF0ICZsdDtjb21wYXJlJmd0OyBpcyB1c2VkIGFzIHRoZSBuYW1lIG9mIGEgWUFORyBS UEMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyA0LiZuYnNwOyBEYXRhIE1vZGVsIE92 ZXJ2aWV3PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXQgdGhlIGNvcmUg b2YgdGhlIHNvbHV0aW9uIGlzIGEgbmV3IG1hbmFnZW1lbnQgb3BlcmF0aW9uLCAmbHQ7Y29tcGFy ZSZndDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBhbGxvd3MgdG8gY29t cGFyZSB0d28gZGF0YXN0b3JlcyBmb3IgdGhlIHNhbWUgZGF0YS48YnI+DQo8YnI+DQpTdWdnZXN0 IHJld29yZGluZyB0aGlzIGZpcnN0IHNlbnRlbmNlIHRvOjxicj4NCjxicj4NCiZuYnNwOyBUaGUg Y29yZSBvZiB0aGUgc29sdXRpb24gaXMgYSBuZXcgbWFuYWdlbWVudCBvcGVyYXRpb24sICZsdDtj b21wYXJlJmd0Oyw8YnI+DQombmJzcDsgdGhhdCBjb21wYXJlcyB0aGUgZGF0YSB0cmVlIGNvbnRl bnRzIG9mIHR3byBkYXRhc3RvcmVzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO28mbmJzcDsgdGFyZ2V0OiBUaGUgdGFyZ2V0IGlkZW50aWZpZXMgdGhlIGRhdGFzdG9yZSB0 byBjb21wYXJlIGFnYWluc3QgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBzb3VyY2UuPGJyPg0KPGJyPg0KU3VnZ2VzdCBhZGRpbmcgYW4gZXhhbXBsZSAmcXVvdDss IGUuZy4sICZsdDtvcGVyYXRpb25hbCZndDsuJnF1b3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7byZuYnNwOyBmaWx0ZXItc3BlYzogVGhpcyBpcyBhIGNob2ljZSBiZXR3 ZWVuIGRpZmZlcmVudCBmaWx0ZXIgY29uc3RydWN0czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgdG8gaWRlbnRpZnkgdGhlIHBvcnRpb25zIG9mIHRoZSBkYXRhc3RvcmUg dG8gYmUgcmV0cmlldmVkLiZuYnNwOyBJdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgYWN0cyBhcyBhIG5vZGUgc2VsZWN0b3IgdGhhdCBzcGVjaWZpZXMgd2hpY2ggZGF0 YSBub2RlcyBhcmUgd2l0aGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB0aGUgc2NvcGUgb2YgdGhlIGNvbXBhcmlzb24gYW5kIHdoaWNoIG5vZGVzIGFyZSBvdXRzaWRl IHRoZSBzY29wZTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_MN2PR11MB43667D00F54AB5879D3036C9B5969MN2PR11MB4366namp_-- From nobody Fri Mar 5 06:12:02 2021 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 C38623A25C3 for ; Fri, 5 Mar 2021 06:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 6nXCJZxagm3a for ; Fri, 5 Mar 2021 06:11:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21E13A25C0 for ; Fri, 5 Mar 2021 06:11:57 -0800 (PST) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 0907313FFA6; Fri, 5 Mar 2021 15:11:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1614953514; bh=XU8uz5rDSRaGyBQS6/FZyAcHoIdH7KlSmUtfuoQ2q6Y=; h=From:To:Date; b=iM9pU6Hcc4WKRBrEVB/bMeqQBShXcCUaMwljZ1JHDNzfmKhOYH2kRY/0GFW0xx5jr itu30R83Aqo+CkodqLAAnMX/zcTNPfQlm/aE4+W+4KnYBwalxx2YPRUIrtira+OWVH qDI7lEmnarHGKa5p9VgF+7lWghCEsbyGP7AuyV6s= From: Ladislav Lhotka To: "Rob Wilton (rwilton)" , "netmod@ietf.org" In-Reply-To: References: <87sg5cxwed.fsf@nic.cz> Mail-Followup-To: "Rob Wilton (rwilton)" , "netmod@ietf.org" Date: Fri, 05 Mar 2021 15:11:53 +0100 Message-ID: <87a6rhofkm.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 14:12:01 -0000 "Rob Wilton (rwilton)" writes: > Hi Lada, > > Thanks for the feedback. I agree that we should think about this. > > Looking at those slides, it also asks the question as to whether a YANG file derived from an IANA registry entry should ever differ. I agree with the answer proposed in those slides: I.e., the two should always be kept in sync, even if that ends causing a non-backwards-compatible change to the YANG module. This was actually a reaction to some voices in the DNSOP WG that went like "IANA registries are broken, why don't we abandon them and keep doing the right thing just in the YANG modules?" > > But my question is whether we should add any text to the IANA section of this document to make this explicit? Yes, I think so. The update rules of sec. 11 in RFC 7950 don't work well with these modules. In fact, an ideal outcome would be that no instructions to IANA need to be given, i.e. the correct YANG module could be generated automatically from the registry. The approach via XSLT adopted in https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-02 comes pretty close, at least for the DNS Parameters registry. I think that the rules for "rev:..." backward compatibility statements could also be implemented this way. > > > Regarding your second issue: > > I agree that unifying the definitions between IANA and YANG would be ideal, but I'm not sure whether that will be feasible in the short term. > > draft-ietf-netmod-yang-module-versioning-02 tries to encourage stricter YANG definitions of deprecated and obsolete (both in the rules defining what is backwards compatible, and also new YANG library leaves to advertise that the server conforms to the stricter behaviour): > > I.e., the behaviour that it is trying to encourage is: > - deprecated nodes must be implemented (just like status current nodes), or otherwise explicitly deviated if they are not supported. > - obsolete nodes must not be implemented. > > The reason that stricter semantics are proposed is so that the client can know the exact schema supported by the server rather than having to guess whether or not deprecated or obsolete nodes are implemented. > > I read the IANA definition of deprecated as being "SHOULD NOT implement", and YANG doesn't today have a status value that maps well to. In particular, YANG doesn't currently have a way to express to a client that a deprecated node that "should not be implemented" actually is still implemented by a server. E.g., the reverse semantics of "deviate not-supported". > > Hence, I wonder YANG shouldn't end up with 4 levels of status (better name required for 'really-deprecated'): > > (1) "current": Current. Must implement or deviate not-supported > (2) "deprecated": Going away. Should implement, but may deviate not-supported > (3) "really-deprecated": Really going away. Should not implement, but may deviate to indicate it is still supported. > (4) "obsolete": Dead. Must not implement. Cannot deviate. Perhaps the first three could be sufficient. It somebody feels the need to implement something in the category (4), they would do it anyway, and it is then better to indicate it via deviation. As I understand it, "obsolete" in the IANA sense is a mere statement of the fact that nobody uses that item any more. > > Note, that a separate status "experimental" has been proposed previously as an addition for YANG Next, tracked by https://github.com/netmod-wg/yang-next/issues/59 Yes, this is something that also frequently appears in IANA registries. Lada > > The IANA version of "deprecated" would map to (3) "really-deprecated" in YANG, whilst the IANA definition of "obsolete" matches the YANG definition of "obsolete". > > But this can't really be solved until we have a new revision of YANG. > > Rob > > >> -----Original Message----- >> From: netmod On Behalf Of Ladislav Lhotka >> Sent: 03 March 2021 12:19 >> To: Rob Wilton (rwilton) ; >> netmod@ietf.org >> Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and >> Semver Drafts >> >> Hi Rob, >> >> I don't know whether this has been discussed, but one issue that might >> need to be addressed is the difference between IANA and YANG in the >> definitions of "obsolete" and "deprecated" - the details are here (slide >> 5): >> >> https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa- >> yang-types-for-dns-classes-and-resource-record-types-00 >> >> The best solution would be to unify the definitions. If this is not >> possible (in a short term), then it is IMO necessary to mark an entry that >> is made obsolete or deprecated in an IANA registry as "obsolete" in the >> YANG module. >> >> Lada >> >> "Rob Wilton \(rwilton\)" writes: >> >> > Hi, >> > >> > // As an individual contributor >> > >> > We discussed proposed IANA text at the last NETMOD interim on the YANG >> versioning work. Tracked by issue https://github.com/netmod-wg/yang-ver- >> dt/issues/59 >> > >> > I had the action of updating the text based on comments received in the >> interim meeting and then sending that text to the list. >> > >> > The proposed text is below (that is in the current published versions of >> both drafts). If the WG has no objections to this text, then the planned >> next step is to ask IANA for an early review of this text. >> > >> > >> > IANA section in draft-ietf-netmod-yang-module-versioning-02: >> > >> > 11.2. Guidance for versioning in IANA maintained YANG modules >> > >> > Note for IANA (to be removed by the RFC editor): Please check that >> > the registries and IANA YANG modules are referenced in the >> > appropriate way. >> > >> > IANA is responsible for maintaining and versioning YANG modules that >> > are derived from other IANA registries. For example, "iana-if- >> > type.yang" [IfTypeYang] is derived from the "Interface Types (ifType) >> > IANA registry" [IfTypesReg], and "iana-routing-types.yang" >> > [RoutingTypesYang] is derived from the "Address Family Numbers" >> > [AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI) >> > Parameters" [SAFIReg] IANA registries. >> > >> > Normally, updates to the registries cause any derived YANG modules to >> > be updated in a backwards-compatible way, but there are some cases >> > where the registry updates can cause non-backward-compatible updates >> > to the derived YANG module. An example of such an update is the >> > 2020-12-31 revision of iana-routing-types.yang >> > >> > [RoutingTypesDecRevision], where the enum name for two SAFI values >> > was changed. >> > >> > In all cases, IANA MUST follow the versioning guidance specified in >> > Section 3.1, and MUST include a "rev:nbc-changes" substatement to the >> > latest revision statement whenever an IANA maintained module is >> > updated in a non-backwards-compatible way, as described in >> > Section 3.2. >> > >> > Note: For published IANA maintained YANG modules that contain non- >> > backwards-compatible changes between revisions, a new revision should >> > be published with the "rev:nbc-changes" substatement retrospectively >> > added to any revisions containing non-backwards-compatible changes. >> > >> > Non normative examples of updates to enumeration types in IANA >> > maintained modules that would be classified as non-backwards- >> > compatible changes are: Changing the status of an enumeration typedef >> > to obsolete, changing the status of an enum entry to obsolete, >> > removing an enum entry, changing the identifier of an enum entry, or >> > changing the described meaning of an enum entry. >> > >> > Non normative examples of updates to enumeration types in IANA >> > maintained modules that would be classified as backwards-compatible >> > changes are: Adding a new enum entry to the end of the enumeration, >> > changing the status or an enum entry to deprecated, or improving the >> > description of an enumeration that does not change its defined >> > meaning. >> > >> > Non normative examples of updates to identity types in IANA >> > maintained modules that would be classified as non-backwards- >> > compatible changes are: Changing the status of an identity to >> > obsolete, removing an identity, renaming an identity, or changing the >> > described meaning of an identity. >> > >> > Non normative examples of updates to identity types in IANA >> > maintained modules that would be classified as backwards-compatible >> > changes are: Adding a new identity, changing the status or an >> > identity to deprecated, or improving the description of an identity >> > that does not change its defined meaning. >> > >> > IANA section for draft-ietf-netmod-yang-semver-02 >> > >> > 9.2. Guidance for YANG Semver in IANA maintained YANG modules >> > >> > Note for IANA (to be removed by the RFC editor): Please check that >> > the registries and IANA YANG modules are referenced in the >> > appropriate way. >> > >> > IANA is responsible for maintaining and versioning some YANG modules, >> > e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang >> > [RoutingTypesYang] . >> > >> > In addition to following the rules specified in the IANA >> > Considerations section of [I-D.ietf-netmod-yang-module-versioning] , >> > IANA maintained YANG modules MUST also include a YANG Semver revision >> > label for all new revisions, as defined in Section 3 . >> > >> > The YANG Semver version associated with the new revision MUST follow >> > the rules defined in Section 3.3 . >> > >> > Note: For IANA maintained YANG modules that have already been >> > published, revision labels MUST be retrospectively applied to all >> > existing revisions when the next new revision is created, starting at >> > version "1.0.0" for the initial published revision, and then >> > incrementing according to the YANG Semver version rules specified in >> > Section 3.3 . >> > >> > Most changes to IANA maintained YANG modules are expected to be >> > backwards-compatible changes and classified as MINOR version changes. >> > The PATCH version may be incremented instead when only editorial >> > changes are made, and the MAJOR version would be incremented if non- >> > backwards-compatible major changes are made. >> > >> > Given that IANA maintained YANG modules are versioned with a linear >> > history, it is anticipated that it should not be necessary to use the >> > "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT" >> > version element. >> > >> > Comments welcome. >> > >> > Thanks, >> > Rob >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 5 08:36:06 2021 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 B7DE93A27D2 for ; Fri, 5 Mar 2021 08:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G5Q9JeA1K07 for ; Fri, 5 Mar 2021 08:36:00 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D803A27BE for ; Fri, 5 Mar 2021 08:36:00 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id r25so3511669ljk.11 for ; Fri, 05 Mar 2021 08:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hUUB/S8SOJrf+x+O0JfuZEDDgk+jOPZ7TVW0CONWCMQ=; b=pinVNJ+4yntrBvW+Ei4RaEgYL6m3foTRQfcsrU2x0FHrQC8lHZ5REoDMDaHDaif35j vu2uI8PGJ/XU186juKVtIXtVWzDbYWbBdRmlDt1W2hGKe01+TTzmlw3boJS53WR8Ig6w 3B+u7Uv4z8fGVfaXGmtJ7PyeJUiE2yOHkdIkdafswCdlFr2W0i0X9dYoIPBT7uUe+4P3 /Og2+y6uG/ikSvRryIEfWJfR4QBbXBmQIlz3Q4Sr6MplMTeI+hRbwaZMFDzAceMuQEft xvlNqXM9liOkZFHGie7HbeI4m/BHQmN7Fvpj6xKUBCHSJvK+o9Dyw47I7IQRRAKq/Ngo PEQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hUUB/S8SOJrf+x+O0JfuZEDDgk+jOPZ7TVW0CONWCMQ=; b=moQo7S5TPd7ZPmQpDKjJ6yZ8tg5/aFBYHnE4RxcVkTWjpL+69J6R8Kr0301abyAhep MSaAQIhUNZvBULi89kJlK7a5xL6UAbeBaO3hgM288ckXoLbLPTrFXp4MYe2yzF46BkCa z+HVWT/tmFGAvLHeADSnp5np1SrJs72kX5UVNasuA9H0dbO6dzj4cxXwG9WU+u2P9Kq+ OKIFOoTKAwHNks/cp/ak3I38eHejyVtt95YgjnUyqr28WKHl1bfKcMd8EZfHKPcM2p3U +3hiUmqFbfJumXmAnuK6Y/koh8vErO4kOBzBYQ2i0Xa4kFyVi6Jv2pSBQPhAkApDldk8 Wf7g== X-Gm-Message-State: AOAM533TqHeVSg+gnOD75t03Rb4UswKycqfO8rXCMyp4Ic2upFwxBZBj DAA20CZsM9/FN7aSPFGMqwMlZBeJe4AyFMRYH5ksig== X-Google-Smtp-Source: ABdhPJy2RTQANMpDLVIDyiaGR7NdQ1bsLAzZSFbB4M+T7SLJ9fXx57GHwuyCKhC9EBd4LkUsM37dM7tOgPifXFYT3m8= X-Received: by 2002:a2e:9d41:: with SMTP id y1mr5942757ljj.91.1614962153176; Fri, 05 Mar 2021 08:35:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Fri, 5 Mar 2021 08:35:42 -0800 Message-ID: To: "Rob Wilton (rwilton)" Cc: joel jaeggli , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007753a705bcccadc5" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 16:36:05 -0000 --0000000000007753a705bcccadc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) wrote: > Hi Andy, authors, > > > I think you mean to address this to the WG since the redesign issues need WG approval. I have no objections to any changes. Andy > Sorry for the long delay in replying. > > > > Please see [RW] inline below =E2=80=A6 > > > > > > *From:* Andy Bierman > *Sent:* 30 October 2020 01:43 > *To:* joel jaeggli > *Cc:* Rob Wilton (rwilton) ; > draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org > *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 > > > > > > > > On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli wrote: > > Rob, > > > > These seem like reasonable suggestions. > > > > Lets see what the authors say. > > > > Thanks for this > > joel > > > > On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) > wrote: > > Hi, > > Here is my AD review for draft-ietf-netmod-nmda-diff-07. Apologies for > the delay. > > Thank you for writing this document, I think that it is useful, and looks > like it is in good shape. > > > Main comments: > > 1. Should there be any text about how to find out what datastores are > supported by a device? E.g., pointing them to either YANG library, or > protocol specific mechanisms in the case of RESTCONF. > > > > Do you have a section in mind and suggested text? > > *[RW] * > > *Perhaps somewhere in section 4, either as part of the description of > source, or perhaps before the parameters are described.* > > > > *Proposed text:* > > *=E2=80=9CA client can discover which datastores a server supports by rea= ding YANG > library [RFC 8525] from the operational state datastore.=E2=80=9D* > > > > > > > > 2. It might be helpful to add a comment about potential issues that could > arise by comparing to , i.e., additional differenc= es > could be reported due to inactive configuration and template processing > between and . > > > > Do you have a section in mind and suggested text? > > You mean if there are differences between and > > then a diff between and will not be the same > > as a diff between and .? > > > > *[RW] * > > *My main concern is that if you have template expansion then comparing > and may not really give a meaningful comparison, > since is pre-template expansion, and (and > ) are both post template expansion.* > > > > *I would suggest putting some text in section 4 or perhaps the YANG > module.* > > > > *Perhaps some text, something like: * > > > > * =E2=80=9CClients should to be aware that comparing to > will report differences due to any configuration transformation (e.g., > inactive configuration, or the expansion of templates) between the > and datastores. In these scenarios, clients may get= a > more useful result by comparing the and datastor= es > instead.=E2=80=9D* > > > > > > > > > > 3. I would prefer if 'exclude=3Dorigin' was in the reverse sense and perh= aps > called 'report-origin' instead. With the reverse sense it seems to be > safer if new datastores are defined, where otherwise the behaviour could > end being under specified. > > > > > > IMO the WG already designed the features so if the functional requirement= s > have changed > > then the draft should go back to the WG for changes and new WG consensus > calls. > > *[RW] * > > > > *I don=E2=80=99t see this as really changing the functional requirements,= but just > changing the default sense and name of an API parameter. Although, given > my comments below =E2=80=9Cwith-origin=E2=80=9D might be better than =E2= =80=9Creport-origin=E2=80=9D.* > > > > *In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D parameter is off by defau= lt, and origin > metadata is only included when the parameter is included. This keyword i= s > also under a feature.* > > > > *So, changing the parameter name to =E2=80=9Cwith-origin=E2=80=9D and put= ting it under > =E2=80=9Dif-feature ietf-netconf-nmda:origin=E2=80=9D, and making the def= ault off, would > make the definition more consistent with RFC 8526.* > > > > > > > 4. Should there be an option to filter on origin metadata? E.g., only > include values that come from intended. Otherwise, things like IP > addresses learned from DHCP may always turn up as differences. > > > > IMO the WG already designed the features so if the functional requirement= s > have changedthen the draft should go back to the WG for changes and new W= G > consensus calls. > > > > *[RW] * > > > > *Okay.* > > > > *Regards,* > > *Rob* > > > > > > > 5. I'm not that keen on the "Possible Future Extensions" section of an > RFC. Personally, I would prefer that this section is deleted, but if you > wish to retain it, then please can you move it to an appendix. > > > > OK with me to remove it > > > > > > > > Andy > > > > > > > I've also included some minor comments inline below, and some nits at the > end: > > Abstract > > This document defines an RPC operation to compare management > datastores that comply with the NMDA architecture. > > The abstract is perhaps somewhat terse. Perhaps: > > This document defines a YANG RPC operation to compare the > contents of network management datastores that comply with > the NMDA architecture and return the differences in the > YANG-Patch format. > > > 1. Introduction > > The revised Network Management Datastore Architecture (NMDA) > [RFC8342] introduces a set of new datastores that each hold YANG- > defined data [RFC7950] and represent a different "viewpoint" on th= e > data that is maintained by a server. New YANG datastores that are > introduced include , which contains validated > configuration > data that a client application intends to be in effect, and > , which contains at least conceptually operational > state > data (such as statistics) as well as configuration data that is > actually in effect. > > I would suggest deleting "at least conceptually", since the > datastore does contain all operational state, but it may be implemented a= s > a virtual construct that spans multiple nodes (e.g., linecards) and > processes. > > > NMDA introduces in effect a concept of "lifecycle" for management > data, allowing to clearly distinguish between data that is part of= a > configuration that was supplied by a user, configuration data that > has actually been successfully applied and that is part of the > operational state, and overall operational state that includes bot= h > applied configuration data as well as status and statistics. > > "allowing to clearly distinguish" =3D> distinguishing" > "status and statistics" =3D> "status information and statistics" > > > As a result, data from the same management model can be reflected = in > multiple datastores. Clients need to specify the target datastore > to > be specific about which viewpoint of the data they want to access. > This way, an application can differentiate whether they are (for > example) interested in the configuration that has been applied and > is > actually in effect, or in the configuration that was supplied by a > client and that is supposed to be in effect. > > Perhaps reword the last sentence to match the logical data flow in the > server: > > For example, a client application can differentiate whether they are > interested in the configuration supplied to a server and that is > supposed to be in effect, or the configuration that has been applied > and is > actually in effect on the server. > > > When configuration that is in effect is different from configurati= on > that was applied, many issues can result. It becomes more difficu= lt > to operate the network properly due to limited visibility of actua= l > status which makes it more difficult to analyze and understand wha= t > is going on in the network. Services may be negatively affected > (for > example, breaking a service instance resulting in service is not > properly delivered to a customer) and network resources be > misallocated. > > Perhaps change "actual status" to "actual operational status". > > I also suggest changing the last sentence to: > > Services may be negatively affected (e.g., degrading or breaking a > customer service) or network resources may be misallocated. > > > 3. Definitions: > > It should probably define that , , (and perhaps > ) are used to indicate names of datastores. > > It should also explain that is used as the name of a YANG RPC. > > > 4. Data Model Overview > > At the core of the solution is a new management operation, > , > that allows to compare two datastores for the same data. > > Suggest rewording this first sentence to: > > The core of the solution is a new management operation, , > that compares the data tree contents of two datastores. > > o target: The target identifies the datastore to compare against > the > source. > > Suggest adding an example ", e.g., ." > > o filter-spec: This is a choice between different filter construc= ts > to identify the portions of the datastore to be retrieved. It > acts as a node selector that specifies which data nodes are > within > the scope of the comparison and which nodes are outside the sco= pe > > --0000000000007753a705bcccadc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 5, 2021 at 5:58 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:

Hi Andy, authors,

=C2=A0



I think you mean to address this to t= he WG since the redesign issues need WG approval.
I have no objec= tions to any changes.=C2=A0=C2=A0


A= ndy
=C2=A0

=

Sorry for the long delay in replying.

=C2=A0

Please see [RW] inline below =E2=80=A6<= u>

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 30 October 2020 01:43
To: joel jaeggli <joelja@gmail.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli <joelja@gmail.com>= wrote:

Rob,=C2=A0

=C2=A0

These seem like reasonable suggestions.=C2=A0=

=C2=A0

Lets see what the authors say.

=C2=A0

Thanks for this

joel

=C2=A0

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.=C2=A0 Apologies fo= r the delay.

Thank you for writing this document, I think that it is useful, and looks l= ike it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are suppo= rted by a device?=C2=A0 E.g., pointing them to either YANG library, or prot= ocol specific mechanisms in the case of RESTCONF.

=C2=A0

Do you have a section in mind and suggested text?=

[RW]

Perhaps somewhere in section 4, either as part= of the description of source, or perhaps before the parameters are describ= ed.

=C2=A0

Proposed text:

=E2=80=9CA client= can discover which datastores a server supports by reading YANG library [R= FC 8525] from the operational state datastore.=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

2. It might be helpful = to add a comment about potential issues that could arise by comparing <r= unning> to <operational>, i.e., additional differences could be re= ported due to inactive configuration and template processing between <running> and <operational>.<= /p>

=C2=A0

Do you have a section in mind and suggested text?=

You mean if there are differences between <runnin= g> and <intended>

then a diff between <running> and <operatio= nal> will not be the same

as a diff between <intended> and <operation= al>.?

=C2=A0

[RW]

My main concern is that if you have template e= xpansion then comparing <running> and <operational> may not rea= lly give a meaningful comparison, since <running> is pre-template exp= ansion, and <operational> (and <intended>) are both post template expansion.

=C2=A0

I would suggest putting some text in section 4= or perhaps the YANG module.

=C2=A0

Perhaps some text, something like: <= /u>

=C2=A0

=C2=A0 =E2=80=9CClients should to be aware tha= t comparing <running> to <operational> will report differences = due to any configuration transformation (e.g., inactive configuration, or t= he expansion of templates) between the <running> and <intended> datastores.=C2=A0 In these scenarios, clients may get a more useful result= by comparing the <intended> and <operational> datastores inste= ad.=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

=C2=A0

3. I would prefer if 'exclude=3Dorigin' was = in the reverse sense and perhaps called 'report-origin' instead.=C2= =A0 With the reverse sense it seems to be safer if new datastores are defin= ed, where otherwise the behaviour could end being under specified.

=C2=A0

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changed

then the draft should go back to the WG for changes = and new WG consensus calls.

[RW]

=C2=A0

I don=E2=80=99t see this as really changing th= e functional requirements, but just changing the default sense and name of = an API parameter.=C2=A0 Although, given my comments below =E2=80=9Cwith-ori= gin=E2=80=9D might be better than =E2=80=9Creport-origin=E2=80=9D.

=C2=A0

In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D= parameter is off by default, and origin metadata is only included when the= parameter is included.=C2=A0 This keyword is also under a feature.<= u>

=C2=A0

So, changing the parameter name to =E2=80=9Cwi= th-origin=E2=80=9D and putting it under =E2=80=9Dif-feature ietf-netconf-nm= da:origin=E2=80=9D, and making the default off, would make the definition m= ore consistent with RFC 8526.

=C2=A0

=C2=A0


4. Should there be an option to filter on origin metadata?=C2=A0 E.g., only= include values that come from intended.=C2=A0 Otherwise, things like IP ad= dresses learned from DHCP may always turn up as differences.<= /p>

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changedthen the draft should go back to the WG = for changes and new WG consensus calls.

=C2=A0

[RW]

=C2=A0

Okay.

=C2=A0

Regards,

Rob

=C2=A0

=C2=A0


5. I'm not that keen on the "Possible Future Extensions" sect= ion of an RFC.=C2=A0 Personally, I would prefer that this section is delete= d, but if you wish to retain it, then please can you move it to an appendix= .

=C2=A0

OK with me to remove it

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0


I've also included some minor comments inline below, and some nits at t= he end:

=C2=A0 =C2=A0 Abstract

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines an RPC operation to compar= e management
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastores that comply with the NMDA architectur= e.

The abstract is perhaps somewhat terse.=C2=A0 Perhaps:

=C2=A0 =C2=A0 This document defines a YANG RPC operation to compare the
=C2=A0 =C2=A0 contents of network management datastores that comply with =C2=A0 =C2=A0 the NMDA architecture and return the differences in the
=C2=A0 =C2=A0 YANG-Patch format.


=C2=A0 =C2=A0 1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0 =C2=A0The revised Network Management Datastore Archite= cture (NMDA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC8342] introduces a set of new datastores tha= t each hold YANG-
=C2=A0 =C2=A0 =C2=A0 =C2=A0defined data [RFC7950] and represent a different= "viewpoint" on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that is maintained by a server.=C2=A0 New Y= ANG datastores that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0introduced include <intended>, which conta= ins validated configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that a client application intends to be in = effect, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0<operational>, which contains at least con= ceptually operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0data (such as statistics) as well as configurati= on data that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect.

I would suggest deleting "at least conceptually", since the <o= perational>
datastore does contain all operational state, but it may be implemented as = a virtual construct that spans multiple nodes (e.g., linecards) and process= es.


=C2=A0 =C2=A0 =C2=A0 =C2=A0NMDA introduces in effect a concept of "lif= ecycle" for management
=C2=A0 =C2=A0 =C2=A0 =C2=A0data, allowing to clearly distinguish between da= ta that is part of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration that was supplied by a user, confi= guration data that
=C2=A0 =C2=A0 =C2=A0 =C2=A0has actually been successfully applied and that = is part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0operational state, and overall operational state= that includes both
=C2=A0 =C2=A0 =C2=A0 =C2=A0applied configuration data as well as status and= statistics.

"allowing to clearly distinguish" =3D> distinguishing" "status and statistics" =3D> "status information and stat= istics"


=C2=A0 =C2=A0 =C2=A0 =C2=A0As a result, data from the same management model= can be reflected in
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple datastores.=C2=A0 Clients need to speci= fy the target datastore to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be specific about which viewpoint of the data th= ey want to access.
=C2=A0 =C2=A0 =C2=A0 =C2=A0This way, an application can differentiate wheth= er they are (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example) interested in the configuration that ha= s been applied and is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect, or in the configuration that= was supplied by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0client and that is supposed to be in effect.

Perhaps reword the last sentence to match the logical data flow in the serv= er:

=C2=A0 =C2=A0For example, a client application can differentiate whether th= ey are
=C2=A0 =C2=A0interested in the configuration supplied to a server and that = is
=C2=A0 =C2=A0supposed to be in effect, or the configuration that has been a= pplied and is
=C2=A0 =C2=A0actually in effect on the server.


=C2=A0 =C2=A0 =C2=A0 =C2=A0When configuration that is in effect is differen= t from configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0that was applied, many issues can result.=C2=A0 = It becomes more difficult
=C2=A0 =C2=A0 =C2=A0 =C2=A0to operate the network properly due to limited v= isibility of actual
=C2=A0 =C2=A0 =C2=A0 =C2=A0status which makes it more difficult to analyze = and understand what
=C2=A0 =C2=A0 =C2=A0 =C2=A0is going on in the network.=C2=A0 Services may b= e negatively affected (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example, breaking a service instance resulting i= n service is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0properly delivered to a customer) and network re= sources be
=C2=A0 =C2=A0 =C2=A0 =C2=A0misallocated.

Perhaps change "actual status" to "actual operational status= ".

I also suggest changing the last sentence to:

=C2=A0 =C2=A0 Services may be negatively affected (e.g., degrading or break= ing a customer service) or network resources may be misallocated.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Definitions:

It should probably define that <intended>, <operational>, (and = perhaps <running>) are used to indicate names of datastores.

It should also explain that <compare> is used as the name of a YANG R= PC.


=C2=A0 =C2=A0 4.=C2=A0 Data Model Overview

=C2=A0 =C2=A0 =C2=A0 =C2=A0At the core of the solution is a new management = operation, <compare>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0that allows to compare two datastores for the sa= me data.

Suggest rewording this first sentence to:

=C2=A0 The core of the solution is a new management operation, <compare&= gt;,
=C2=A0 that compares the data tree contents of two datastores.

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 target: The target identifies the datast= ore to compare against the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 source.

Suggest adding an example ", e.g., <operational>."

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 filter-spec: This is a choice between di= fferent filter constructs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to identify the portions of the datastor= e to be retrieved.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acts as a node selector that specifies w= hich data nodes are within
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the scope of the comparison and which no= des are outside the scope

--0000000000007753a705bcccadc5-- From nobody Fri Mar 5 10:18:05 2021 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 D38AF3A296F; Fri, 5 Mar 2021 10:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=JVZXV9j6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pBdyXD6w 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 Y_2ELSjaL58s; Fri, 5 Mar 2021 10:18:00 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7B03A296C; Fri, 5 Mar 2021 10:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54338; q=dns/txt; s=iport; t=1614968280; x=1616177880; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qryl9/HVDvrKLrO2JQ3wyBlDkXSccPSEBKJaI4GXFoU=; b=JVZXV9j6QMTv8GPgX5BokS7czENkHevq+kziAEMi2frgJQ0vpckw9qfF 1+Gbuwi+VlxASVZBuOax3v/ImbGJE9aPedCzWIAqyC08+EJVqYjN/S55x fYsVj/3sIVLk6LF7+sMj9QKd+eeqWo1mzLnK5Mx7hO53v0YnzwD0fBTd1 8=; IronPort-PHdr: =?us-ascii?q?9a23=3ADsQ97hM51GZA3A2fML4l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK833k7UWIzE7OhHkKzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutdkDXq2K19z0JXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAACodEJg/5xdJa1YChoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAYIPgSMwIy4Hdlo2MQqEN4NIA4U5iFgDgQW?= =?us-ascii?q?JIY59glMDVAsBAQENAQEyAgQBAYRNAheBYwIlOBMCAwEBCwEBBQEBAQIBBgR?= =?us-ascii?q?xhWENhkQBAQEEHQYKEwEBNwEPAgEIEQEDAQEhAQYDAgICHxEUAwYIAQEEAQ0?= =?us-ascii?q?FCBOCVoF+VwMvAQOiZgKKJXaBMoMEAQEGhSQNC4ITCYE5gnaEBgEBgQyFOCY?= =?us-ascii?q?cgUlCgRFDgiI1PoIagXcEERo0gmA0giuBWAFrBgEXJgILARgEQwomAi0sOUg?= =?us-ascii?q?IDgMhDwiQXYJmQodLL4wqkDs5WwqCfpZ6hU6DOYpRlWKUXY5HjmMsHoQ4AgI?= =?us-ascii?q?CAgQFAg4BAQaBayMqgS1wFYMkUBcCDY4fg2+KWXM4AgYBCQEBAwl8i2YCJge?= =?us-ascii?q?BBgExXQEB?= X-IronPort-AV: E=Sophos;i="5.81,225,1610409600"; d="scan'208,217";a="856179240" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 18:17:58 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 125IHwkD006240 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 5 Mar 2021 18:17:58 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 12:17:58 -0600 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Mar 2021 13:17:57 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 5 Mar 2021 12:17:57 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W2y5risxagljhBi2ysAVAZDdIU7xehqaA+Yl0o4jsQIJc9+IAjVQhFI68mVbjRGJNf6nP4AK6m3bLyZMsX5mYqLFsnbPspX620AUzK5KdQ4v8tGmTXdSVItBZre8x3DC6DjzN1kI77SzAWHxXULjiQa/GYMb5pAcuPH2XRZRcYGfzAmAwcNl40UsNaxUTZs5xU5YUS/mSixprpUOUdILUhYjo1ngWvMOwG7kR1M0q1frhEXHxuSJiroAnNPNJ/dxR4HMggH0QI1TSIv75gZH16aHNVyiZNSj27h9WYgfoURvYmZSdzFkSa5Hi0BasHnuSJkzKQDo61zIpOnVwUKK9g== 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=Qryl9/HVDvrKLrO2JQ3wyBlDkXSccPSEBKJaI4GXFoU=; b=c8X7mVnPHv5CEJ1Q7I7l7HHoqXRtv9XmhxB9YcX4FUBl9F+u/Gb0dSHZdaf2f3FeeK2t+Xh6HX7FKYLtchFm6N7gPM+vhjxdeEXnRatIowhFwcku3O8NImI1hE0565OQxoTVNMuuo5WFpT/Inri1HR+ztPOZhqpAySC9blkT4AkNHyN+FZ6gy2DO1DY4NXiQUCgfQf2jSWhN/PmjlyUS2xTUGuX2cKAm4xa9dE0VLywSxs9NYB++vdTbxg+jFXfHYy45rQtnN1zi3cmWBeb7hS936+L5/9tpOZj/lPfhFrbqEsaItLUDg7NFjjmBUZvSXdNR5uBX7W+UcZFwCf83dQ== 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=Qryl9/HVDvrKLrO2JQ3wyBlDkXSccPSEBKJaI4GXFoU=; b=pBdyXD6wFALhQd7UFNKc6YU4J7FhBx77W6/SbUKq8R41I4AlYDFWUioZro/SAOS/gqExjtUZwCII7Vg0ywdcocJm4sxwWGGrNnNpiFm5ZY+z3ZJ3a8sCk+y7/EsWzDrexorqbgGGPmfaGJuDkTIgcBzUFe/Zs3tOuHoyeLvnRYU= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4446.namprd11.prod.outlook.com (2603:10b6:208:17a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.28; Fri, 5 Mar 2021 18:17:56 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3912.022; Fri, 5 Mar 2021 18:17:56 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman , NetMod WG Chairs CC: joel jaeggli , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-nmda-diff-07 Thread-Index: Adat+a/3DPT1aCJSTfuydcCuPD9V4wAX4/YAAAExU4AAtpAc8BgpU+wAAAMUy5A= Date: Fri, 5 Mar 2021 18:17:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.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: eb0f4c27-072b-4032-0fc6-08d8e003000a x-ms-traffictypediagnostic: MN2PR11MB4446: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: INp98Zm8Mg1Z0Zmne14+kcEU7PQ1JDNQdGti3TNCXIM6+6toE7FIddUntsAbzuBVy0L7yv8SnWHv5rl0YYuLmaa5xKhJcoxNYzrbM7zrNCMxWwjs4ktVKx13yt3wVCoNm0pdcw6oznOyHtU2k6daxTVXEo//tCQs8ds2d/Y/MS7lheDXNNRi6RkAmxoiMPis6rUo1fjlzRdeynhcsQ40X8fKIlu51LYj3211qEylhKqWGVnzdMBcC5n0uN/JyoZpS81c7yc3ouxwpQ8XolcYRPdGpPlJs0Xx/GEd2WDHmmdPZ2wuAFS+LRXrxPkeyUI9z2g4et8PSxBAnJZgm9FcTJtb/hRy2MgZW7kP0su0c/QcqE6777tobxJUKhcdGvJUHVXdQpWKen/rfVluFdi2bGBk/H6sYlFUPo44aj3l3e5r/tunRAHyL7AV5uJe7JHCJN3F3aNebybjJX+Hs1kUIAXsK0t7uB+LzaGUD4pOh5voqckSezxlgFPd0M9+FZ2XdrTRenOxumFXqWXzERkkpg== 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:(346002)(39860400002)(136003)(366004)(396003)(376002)(66446008)(64756008)(66556008)(66476007)(66946007)(5660300002)(52536014)(26005)(8676002)(9326002)(8936002)(2906002)(478600001)(186003)(76116006)(86362001)(71200400001)(6506007)(53546011)(7696005)(55016002)(4326008)(9686003)(316002)(54906003)(110136005)(33656002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VFZvT0FWRDhQUVZtNWMvc2VFVWdXb3ZacERITk1vOGlLekdKMndlRmtMMjJJ?= =?utf-8?B?NEhZOXp5NnNEeGYvVmhHdTF0cTlPR1p1UkFQYTZvUktKMTFQNFFDS0kxQ1Vv?= =?utf-8?B?N2Z4Q1l6K3owVGhuZmY1Q05NcjVocGdlMmtQWHRPQ203S0NVcWdZOEhoWk1i?= =?utf-8?B?QUlpSk1xamdDTXJRbnlqQ1lmRHhxYitIdnhwaFJSemM3cjVNaDRpYU1obnNU?= =?utf-8?B?ci9kWHdnMmxYbEhHWEdJZlRQZ3ArZ095TmRUYVBXWkNxN1B3T1ptbDhjYlkz?= =?utf-8?B?OWJqMmpmVDFxaEdsY2hyVE9OVGNsYmtUUjFweW5KbC9SWThZeTZYdW9oSXM2?= =?utf-8?B?K2FUU1Y1WkM1cUkvZTZqZzZRejE0aVd2MFJKZ2QrdTdId2E2L2Y2b0ZVNEpk?= =?utf-8?B?MElYb0dEU1VoSC9xVzhPcTNDWWRZSFBpRXdkY21MQTJIZVR0Q3RURXRrTjBS?= =?utf-8?B?SW9JbGRsTFgzSVpYZWVkdjhIYmlWanhHNFhkWHNJbTNuanBIUE45L3JQYzdp?= =?utf-8?B?R2QzSkdsRlQ5dld6R2ViU1FjSDFlRW5JMDdJTmdWc0kzZUVRcDdTSXM5Wkhx?= =?utf-8?B?VnR4bXRvR3l2ekFPczRLdStHRVB0REdZN1NMOTh0YmEwY21kRzV5ak9RcU83?= =?utf-8?B?bTlSQ0ZXKzZVTjk0TkUzNVlRN1VvSjg2Y1lyTjJjTDNDTFFiZlFJQ0JDOHFZ?= =?utf-8?B?c0dub0R1WDlaT1RPV1UxUXBnUmF4a1MzUEhDTUV2QlRaZVJEK1BGQ0dxWDQr?= =?utf-8?B?VVR2dUVSOTdncTMyNFhyTitQTVV3bC9pUXc5dzZIdXRaZGowV1RzSnRRZnNG?= =?utf-8?B?ekpleHBINEFtT0FYZ1BqTnFYRzNaLzcwQjVzOHJ1R1pJZjg2QTdyTzhNcUhL?= =?utf-8?B?MVB1QStBeFVLTFhGSi83SDVoOXhNWXN2akMzNnNtUU5MenFVeEtZSTBxOXdF?= =?utf-8?B?VEg0VjRBdVZnM0xBb1I0QlJQUWtodmhEZzFWZnJ3ZUE2WFhXQ0p1U2s1Wnho?= =?utf-8?B?MDJXWkV6Y0dObDdkN0E5WldWQnJpelUrcVAyYXY2MW00OFM2TndFNHliVDNi?= =?utf-8?B?MDZQWDJjRkZwVVNEdmdRZmNySFlUNXV1TEtJN0R2ZitBcFVJR2xwMkdWRndK?= =?utf-8?B?UmlqM2phQUt2d2xkMGdxc1E0bXhEeTQ5cG5DVmNKekxhMEtKMXVkVTh1Wm05?= =?utf-8?B?Sm56Z2pjNVFqOHJ0c3VXUUw4L09mS0FWSFFwQ2pWSmJINWx0VlJZa3djbE1u?= =?utf-8?B?VlJGNHhKT21jV3RiUHJITitTY3N4RW93cjJGMkhDYzRZWEVkbmRYSDB2UHo5?= =?utf-8?B?T2FMQlNmZ0lNZ0VLV1lOY3Z0cm14U2w5WDNGUHNORFJqZUg0clFCRW4xL01h?= =?utf-8?B?N3hHUGp3RkE5L3lHazQxTk85QmpjY0M4SkFncjZsV2w0M0ZsWUxLa2g3N3J2?= =?utf-8?B?S1U0QVlGTWJLdFFVUWlVNC8zaDZzamorV2x0V0pVa2xNR0FJb01PUUV1N01a?= =?utf-8?B?bWFzclhpNVRQOUJaSVZjTHNXZEY5bTBHcy9TZ1VabElnUzJJSHM0VlkxNWty?= =?utf-8?B?NTZhUm5TU3hMU2lTdXNSSDI5R3VDN2F5anBxY2haYkVZTVRQb3NZZ3JUUGN1?= =?utf-8?B?cDVRMTI2RVpzYVAvNCt3eFFEWjd3RDhpZmExTEIrV0JOa2Q0ZTBaVzBueGM2?= =?utf-8?B?emU4L3UyWjJNdC8xQ1lKQzJwRFlhZU56aG9qU0d3QTFiRml6WXFENWc0aW5v?= =?utf-8?Q?tUrbJcN3vXKw5WPKUyPypB4YHIYPJ9GhZBz0gIP?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366539F75C0C0892B8D9848B5969MN2PR11MB4366namp_" 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: eb0f4c27-072b-4032-0fc6-08d8e003000a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 18:17:56.1339 (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: XCG6IHbB1sSN/PL9S+cnaGYtjAdi+UD9YteqDZjECraALFZaHqM02T3voG7GzfLED23cc6Q336DnDiw4CnUm/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4446 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 18:18:04 -0000 --_000_MN2PR11MB4366539F75C0C0892B8D9848B5969MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KSeKAmW0gbm90IHN1cmUgd2hpY2ggb25lIHlvdSB0aGluayBpcyBzIGEgZGVz aWduIGNoYW5nZTogIERvIHlvdSBtZWFuIGlzc3VlIDMgb3IgaXNzdWUgNCBiZWxvdz8NCg0KSSBz ZWUgdGhhdCBteSByZXNwb25zZSB0byBpc3N1ZSA0IG1heSBub3QgaGF2ZSBiZWVuIGNsZWFyLCBz byB0byBjbGFyaWZ5Og0KDQpCeSDigJxva2F54oCdLCBJIG1lYW50LCB0aGF0IEkgYW0gb2theSB3 aXRoIGhvdyBpdCBpcyB3cml0dGVuIGluIHRoZSBjdXJyZW50IGRyYWZ0LiAgTXkgcHJlc3VtcHRp b24gaXMgdGhhdCB0aGlzIGNvdWxkIGJlIGFkZHJlc3NlZCBhcyBhIGZ1dHVyZSB2ZXJzaW9uIG9m IHRoZSBtb2R1bGUgaWYgdGhpcyB0dXJucyBvdXQgYmUgYW4gaXNzdWUsIG9yIHZlbmRvcnMgY2Fu IGRlZmluZSB0aGVpciBvd24gYXVnbWVudGF0aW9uIGlmIG5lZWRlZC4NCg0KSWYgeW91IHRoaW5r IGlzc3VlIDMgaXMgYSBkZXNpZ24gY2hhbmdlIHRoYXQgcmVxdWlyZXMgV0cgY29uc2Vuc3VzIHRo YXQgSSB3aWxsIGxlYXZlIGl0IHRvIHRoZSBXRyBjaGFpcnMgdG8gZGVjaWRlIGlmIHRoZXkgd2lz aCB0byBpc3N1ZSBhIGNvbnNlbnN1cyBjYWxsIGZvciBpdC4NCg0KUmVnYXJkcywNClJvYg0KDQoN CkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KU2VudDogMDUgTWFyY2gg MjAyMSAxNjozNg0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT4N CkNjOiBqb2VsIGphZWdnbGkgPGpvZWxqYUBnbWFpbC5jb20+OyBkcmFmdC1pZXRmLW5ldG1vZC1u bWRhLWRpZmYuYWxsQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBBRCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLTA3DQoNCg0KDQpPbiBGcmksIE1h ciA1LCAyMDIxIGF0IDU6NTggQU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28u Y29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwgYXV0aG9ycywN Cg0KDQoNCkkgdGhpbmsgeW91IG1lYW4gdG8gYWRkcmVzcyB0aGlzIHRvIHRoZSBXRyBzaW5jZSB0 aGUgcmVkZXNpZ24gaXNzdWVzIG5lZWQgV0cgYXBwcm92YWwuDQpJIGhhdmUgbm8gb2JqZWN0aW9u cyB0byBhbnkgY2hhbmdlcy4NCg0KDQpBbmR5DQoNClNvcnJ5IGZvciB0aGUgbG9uZyBkZWxheSBp biByZXBseWluZy4NCg0KUGxlYXNlIHNlZSBbUlddIGlubGluZSBiZWxvdyDigKYNCg0KDQpGcm9t OiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tPj4NClNlbnQ6IDMwIE9jdG9iZXIgMjAyMCAwMTo0Mw0KVG86IGpvZWwgamFlZ2dsaSA8am9l bGphQGdtYWlsLmNvbTxtYWlsdG86am9lbGphQGdtYWlsLmNvbT4+DQpDYzogUm9iIFdpbHRvbiAo cndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+OyBk cmFmdC1pZXRmLW5ldG1vZC1ubWRhLWRpZmYuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LW5ldG1vZC1ubWRhLWRpZmYuYWxsQGlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0 bW9kLW5tZGEtZGlmZi0wNw0KDQoNCg0KT24gVGh1LCBPY3QgMjksIDIwMjAgYXQgNjowOSBQTSBq b2VsIGphZWdnbGkgPGpvZWxqYUBnbWFpbC5jb208bWFpbHRvOmpvZWxqYUBnbWFpbC5jb20+PiB3 cm90ZToNClJvYiwNCg0KVGhlc2Ugc2VlbSBsaWtlIHJlYXNvbmFibGUgc3VnZ2VzdGlvbnMuDQoN CkxldHMgc2VlIHdoYXQgdGhlIGF1dGhvcnMgc2F5Lg0KDQpUaGFua3MgZm9yIHRoaXMNCmpvZWwN Cg0KT24gVGh1LCBPY3QgMjksIDIwMjAgYXQgNjo0NyBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSA8 cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQpIaSwN Cg0KSGVyZSBpcyBteSBBRCByZXZpZXcgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi0w Ny4gIEFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5Lg0KDQpUaGFuayB5b3UgZm9yIHdyaXRpbmcgdGhp cyBkb2N1bWVudCwgSSB0aGluayB0aGF0IGl0IGlzIHVzZWZ1bCwgYW5kIGxvb2tzIGxpa2UgaXQg aXMgaW4gZ29vZCBzaGFwZS4NCg0KDQpNYWluIGNvbW1lbnRzOg0KDQoxLiBTaG91bGQgdGhlcmUg YmUgYW55IHRleHQgYWJvdXQgaG93IHRvIGZpbmQgb3V0IHdoYXQgZGF0YXN0b3JlcyBhcmUgc3Vw cG9ydGVkIGJ5IGEgZGV2aWNlPyAgRS5nLiwgcG9pbnRpbmcgdGhlbSB0byBlaXRoZXIgWUFORyBs aWJyYXJ5LCBvciBwcm90b2NvbCBzcGVjaWZpYyBtZWNoYW5pc21zIGluIHRoZSBjYXNlIG9mIFJF U1RDT05GLg0KDQpEbyB5b3UgaGF2ZSBhIHNlY3Rpb24gaW4gbWluZCBhbmQgc3VnZ2VzdGVkIHRl eHQ/DQpbUlddDQpQZXJoYXBzIHNvbWV3aGVyZSBpbiBzZWN0aW9uIDQsIGVpdGhlciBhcyBwYXJ0 IG9mIHRoZSBkZXNjcmlwdGlvbiBvZiBzb3VyY2UsIG9yIHBlcmhhcHMgYmVmb3JlIHRoZSBwYXJh bWV0ZXJzIGFyZSBkZXNjcmliZWQuDQoNClByb3Bvc2VkIHRleHQ6DQrigJxBIGNsaWVudCBjYW4g ZGlzY292ZXIgd2hpY2ggZGF0YXN0b3JlcyBhIHNlcnZlciBzdXBwb3J0cyBieSByZWFkaW5nIFlB TkcgbGlicmFyeSBbUkZDIDg1MjVdIGZyb20gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9y ZS7igJ0NCg0KDQoNCjIuIEl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gYWRkIGEgY29tbWVudCBhYm91 dCBwb3RlbnRpYWwgaXNzdWVzIHRoYXQgY291bGQgYXJpc2UgYnkgY29tcGFyaW5nIDxydW5uaW5n PiB0byA8b3BlcmF0aW9uYWw+LCBpLmUuLCBhZGRpdGlvbmFsIGRpZmZlcmVuY2VzIGNvdWxkIGJl IHJlcG9ydGVkIGR1ZSB0byBpbmFjdGl2ZSBjb25maWd1cmF0aW9uIGFuZCB0ZW1wbGF0ZSBwcm9j ZXNzaW5nIGJldHdlZW4gPHJ1bm5pbmc+IGFuZCA8b3BlcmF0aW9uYWw+Lg0KDQpEbyB5b3UgaGF2 ZSBhIHNlY3Rpb24gaW4gbWluZCBhbmQgc3VnZ2VzdGVkIHRleHQ/DQpZb3UgbWVhbiBpZiB0aGVy ZSBhcmUgZGlmZmVyZW5jZXMgYmV0d2VlbiA8cnVubmluZz4gYW5kIDxpbnRlbmRlZD4NCnRoZW4g YSBkaWZmIGJldHdlZW4gPHJ1bm5pbmc+IGFuZCA8b3BlcmF0aW9uYWw+IHdpbGwgbm90IGJlIHRo ZSBzYW1lDQphcyBhIGRpZmYgYmV0d2VlbiA8aW50ZW5kZWQ+IGFuZCA8b3BlcmF0aW9uYWw+Lj8N Cg0KW1JXXQ0KTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgaWYgeW91IGhhdmUgdGVtcGxhdGUgZXhw YW5zaW9uIHRoZW4gY29tcGFyaW5nIDxydW5uaW5nPiBhbmQgPG9wZXJhdGlvbmFsPiBtYXkgbm90 IHJlYWxseSBnaXZlIGEgbWVhbmluZ2Z1bCBjb21wYXJpc29uLCBzaW5jZSA8cnVubmluZz4gaXMg cHJlLXRlbXBsYXRlIGV4cGFuc2lvbiwgYW5kIDxvcGVyYXRpb25hbD4gKGFuZCA8aW50ZW5kZWQ+ KSBhcmUgYm90aCBwb3N0IHRlbXBsYXRlIGV4cGFuc2lvbi4NCg0KSSB3b3VsZCBzdWdnZXN0IHB1 dHRpbmcgc29tZSB0ZXh0IGluIHNlY3Rpb24gNCBvciBwZXJoYXBzIHRoZSBZQU5HIG1vZHVsZS4N Cg0KUGVyaGFwcyBzb21lIHRleHQsIHNvbWV0aGluZyBsaWtlOg0KDQogIOKAnENsaWVudHMgc2hv dWxkIHRvIGJlIGF3YXJlIHRoYXQgY29tcGFyaW5nIDxydW5uaW5nPiB0byA8b3BlcmF0aW9uYWw+ IHdpbGwgcmVwb3J0IGRpZmZlcmVuY2VzIGR1ZSB0byBhbnkgY29uZmlndXJhdGlvbiB0cmFuc2Zv cm1hdGlvbiAoZS5nLiwgaW5hY3RpdmUgY29uZmlndXJhdGlvbiwgb3IgdGhlIGV4cGFuc2lvbiBv ZiB0ZW1wbGF0ZXMpIGJldHdlZW4gdGhlIDxydW5uaW5nPiBhbmQgPGludGVuZGVkPiBkYXRhc3Rv cmVzLiAgSW4gdGhlc2Ugc2NlbmFyaW9zLCBjbGllbnRzIG1heSBnZXQgYSBtb3JlIHVzZWZ1bCBy ZXN1bHQgYnkgY29tcGFyaW5nIHRoZSA8aW50ZW5kZWQ+IGFuZCA8b3BlcmF0aW9uYWw+IGRhdGFz dG9yZXMgaW5zdGVhZC7igJ0NCg0KDQoNCg0KMy4gSSB3b3VsZCBwcmVmZXIgaWYgJ2V4Y2x1ZGU9 b3JpZ2luJyB3YXMgaW4gdGhlIHJldmVyc2Ugc2Vuc2UgYW5kIHBlcmhhcHMgY2FsbGVkICdyZXBv cnQtb3JpZ2luJyBpbnN0ZWFkLiAgV2l0aCB0aGUgcmV2ZXJzZSBzZW5zZSBpdCBzZWVtcyB0byBi ZSBzYWZlciBpZiBuZXcgZGF0YXN0b3JlcyBhcmUgZGVmaW5lZCwgd2hlcmUgb3RoZXJ3aXNlIHRo ZSBiZWhhdmlvdXIgY291bGQgZW5kIGJlaW5nIHVuZGVyIHNwZWNpZmllZC4NCg0KDQpJTU8gdGhl IFdHIGFscmVhZHkgZGVzaWduZWQgdGhlIGZlYXR1cmVzIHNvIGlmIHRoZSBmdW5jdGlvbmFsIHJl cXVpcmVtZW50cyBoYXZlIGNoYW5nZWQNCnRoZW4gdGhlIGRyYWZ0IHNob3VsZCBnbyBiYWNrIHRv IHRoZSBXRyBmb3IgY2hhbmdlcyBhbmQgbmV3IFdHIGNvbnNlbnN1cyBjYWxscy4NCltSV10NCg0K SSBkb27igJl0IHNlZSB0aGlzIGFzIHJlYWxseSBjaGFuZ2luZyB0aGUgZnVuY3Rpb25hbCByZXF1 aXJlbWVudHMsIGJ1dCBqdXN0IGNoYW5naW5nIHRoZSBkZWZhdWx0IHNlbnNlIGFuZCBuYW1lIG9m IGFuIEFQSSBwYXJhbWV0ZXIuICBBbHRob3VnaCwgZ2l2ZW4gbXkgY29tbWVudHMgYmVsb3cg4oCc d2l0aC1vcmlnaW7igJ0gbWlnaHQgYmUgYmV0dGVyIHRoYW4g4oCccmVwb3J0LW9yaWdpbuKAnS4N Cg0KSW4gUkZDIDg1MjYsIHRoZSDigJx3aXRoLW9yaWdpbuKAnSBwYXJhbWV0ZXIgaXMgb2ZmIGJ5 IGRlZmF1bHQsIGFuZCBvcmlnaW4gbWV0YWRhdGEgaXMgb25seSBpbmNsdWRlZCB3aGVuIHRoZSBw YXJhbWV0ZXIgaXMgaW5jbHVkZWQuICBUaGlzIGtleXdvcmQgaXMgYWxzbyB1bmRlciBhIGZlYXR1 cmUuDQoNClNvLCBjaGFuZ2luZyB0aGUgcGFyYW1ldGVyIG5hbWUgdG8g4oCcd2l0aC1vcmlnaW7i gJ0gYW5kIHB1dHRpbmcgaXQgdW5kZXIg4oCdaWYtZmVhdHVyZSBpZXRmLW5ldGNvbmYtbm1kYTpv cmlnaW7igJ0sIGFuZCBtYWtpbmcgdGhlIGRlZmF1bHQgb2ZmLCB3b3VsZCBtYWtlIHRoZSBkZWZp bml0aW9uIG1vcmUgY29uc2lzdGVudCB3aXRoIFJGQyA4NTI2Lg0KDQoNCg0KNC4gU2hvdWxkIHRo ZXJlIGJlIGFuIG9wdGlvbiB0byBmaWx0ZXIgb24gb3JpZ2luIG1ldGFkYXRhPyAgRS5nLiwgb25s eSBpbmNsdWRlIHZhbHVlcyB0aGF0IGNvbWUgZnJvbSBpbnRlbmRlZC4gIE90aGVyd2lzZSwgdGhp bmdzIGxpa2UgSVAgYWRkcmVzc2VzIGxlYXJuZWQgZnJvbSBESENQIG1heSBhbHdheXMgdHVybiB1 cCBhcyBkaWZmZXJlbmNlcy4NCg0KSU1PIHRoZSBXRyBhbHJlYWR5IGRlc2lnbmVkIHRoZSBmZWF0 dXJlcyBzbyBpZiB0aGUgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgaGF2ZSBjaGFuZ2VkdGhlbiB0 aGUgZHJhZnQgc2hvdWxkIGdvIGJhY2sgdG8gdGhlIFdHIGZvciBjaGFuZ2VzIGFuZCBuZXcgV0cg Y29uc2Vuc3VzIGNhbGxzLg0KDQpbUlddDQoNCk9rYXkuDQoNClJlZ2FyZHMsDQpSb2INCg0KDQoN CjUuIEknbSBub3QgdGhhdCBrZWVuIG9uIHRoZSAiUG9zc2libGUgRnV0dXJlIEV4dGVuc2lvbnMi IHNlY3Rpb24gb2YgYW4gUkZDLiAgUGVyc29uYWxseSwgSSB3b3VsZCBwcmVmZXIgdGhhdCB0aGlz IHNlY3Rpb24gaXMgZGVsZXRlZCwgYnV0IGlmIHlvdSB3aXNoIHRvIHJldGFpbiBpdCwgdGhlbiBw bGVhc2UgY2FuIHlvdSBtb3ZlIGl0IHRvIGFuIGFwcGVuZGl4Lg0KDQpPSyB3aXRoIG1lIHRvIHJl bW92ZSBpdA0KDQoNCg0KQW5keQ0KDQoNCg0KSSd2ZSBhbHNvIGluY2x1ZGVkIHNvbWUgbWlub3Ig Y29tbWVudHMgaW5saW5lIGJlbG93LCBhbmQgc29tZSBuaXRzIGF0IHRoZSBlbmQ6DQoNCiAgICBB YnN0cmFjdA0KDQogICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIFJQQyBvcGVyYXRpb24g dG8gY29tcGFyZSBtYW5hZ2VtZW50DQogICAgICAgZGF0YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRo IHRoZSBOTURBIGFyY2hpdGVjdHVyZS4NCg0KVGhlIGFic3RyYWN0IGlzIHBlcmhhcHMgc29tZXdo YXQgdGVyc2UuICBQZXJoYXBzOg0KDQogICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBS UEMgb3BlcmF0aW9uIHRvIGNvbXBhcmUgdGhlDQogICAgY29udGVudHMgb2YgbmV0d29yayBtYW5h Z2VtZW50IGRhdGFzdG9yZXMgdGhhdCBjb21wbHkgd2l0aA0KICAgIHRoZSBOTURBIGFyY2hpdGVj dHVyZSBhbmQgcmV0dXJuIHRoZSBkaWZmZXJlbmNlcyBpbiB0aGUNCiAgICBZQU5HLVBhdGNoIGZv cm1hdC4NCg0KDQogICAgMS4gIEludHJvZHVjdGlvbg0KDQogICAgICAgVGhlIHJldmlzZWQgTmV0 d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpDQogICAgICAgW1JG QzgzNDJdIGludHJvZHVjZXMgYSBzZXQgb2YgbmV3IGRhdGFzdG9yZXMgdGhhdCBlYWNoIGhvbGQg WUFORy0NCiAgICAgICBkZWZpbmVkIGRhdGEgW1JGQzc5NTBdIGFuZCByZXByZXNlbnQgYSBkaWZm ZXJlbnQgInZpZXdwb2ludCIgb24gdGhlDQogICAgICAgZGF0YSB0aGF0IGlzIG1haW50YWluZWQg YnkgYSBzZXJ2ZXIuICBOZXcgWUFORyBkYXRhc3RvcmVzIHRoYXQgYXJlDQogICAgICAgaW50cm9k dWNlZCBpbmNsdWRlIDxpbnRlbmRlZD4sIHdoaWNoIGNvbnRhaW5zIHZhbGlkYXRlZCBjb25maWd1 cmF0aW9uDQogICAgICAgZGF0YSB0aGF0IGEgY2xpZW50IGFwcGxpY2F0aW9uIGludGVuZHMgdG8g YmUgaW4gZWZmZWN0LCBhbmQNCiAgICAgICA8b3BlcmF0aW9uYWw+LCB3aGljaCBjb250YWlucyBh dCBsZWFzdCBjb25jZXB0dWFsbHkgb3BlcmF0aW9uYWwgc3RhdGUNCiAgICAgICBkYXRhIChzdWNo IGFzIHN0YXRpc3RpY3MpIGFzIHdlbGwgYXMgY29uZmlndXJhdGlvbiBkYXRhIHRoYXQgaXMNCiAg ICAgICBhY3R1YWxseSBpbiBlZmZlY3QuDQoNCkkgd291bGQgc3VnZ2VzdCBkZWxldGluZyAiYXQg bGVhc3QgY29uY2VwdHVhbGx5Iiwgc2luY2UgdGhlIDxvcGVyYXRpb25hbD4NCmRhdGFzdG9yZSBk b2VzIGNvbnRhaW4gYWxsIG9wZXJhdGlvbmFsIHN0YXRlLCBidXQgaXQgbWF5IGJlIGltcGxlbWVu dGVkIGFzIGEgdmlydHVhbCBjb25zdHJ1Y3QgdGhhdCBzcGFucyBtdWx0aXBsZSBub2RlcyAoZS5n LiwgbGluZWNhcmRzKSBhbmQgcHJvY2Vzc2VzLg0KDQoNCiAgICAgICBOTURBIGludHJvZHVjZXMg aW4gZWZmZWN0IGEgY29uY2VwdCBvZiAibGlmZWN5Y2xlIiBmb3IgbWFuYWdlbWVudA0KICAgICAg IGRhdGEsIGFsbG93aW5nIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2ggYmV0d2VlbiBkYXRhIHRoYXQg aXMgcGFydCBvZiBhDQogICAgICAgY29uZmlndXJhdGlvbiB0aGF0IHdhcyBzdXBwbGllZCBieSBh IHVzZXIsIGNvbmZpZ3VyYXRpb24gZGF0YSB0aGF0DQogICAgICAgaGFzIGFjdHVhbGx5IGJlZW4g c3VjY2Vzc2Z1bGx5IGFwcGxpZWQgYW5kIHRoYXQgaXMgcGFydCBvZiB0aGUNCiAgICAgICBvcGVy YXRpb25hbCBzdGF0ZSwgYW5kIG92ZXJhbGwgb3BlcmF0aW9uYWwgc3RhdGUgdGhhdCBpbmNsdWRl cyBib3RoDQogICAgICAgYXBwbGllZCBjb25maWd1cmF0aW9uIGRhdGEgYXMgd2VsbCBhcyBzdGF0 dXMgYW5kIHN0YXRpc3RpY3MuDQoNCiJhbGxvd2luZyB0byBjbGVhcmx5IGRpc3Rpbmd1aXNoIiA9 PiBkaXN0aW5ndWlzaGluZyINCiJzdGF0dXMgYW5kIHN0YXRpc3RpY3MiID0+ICJzdGF0dXMgaW5m b3JtYXRpb24gYW5kIHN0YXRpc3RpY3MiDQoNCg0KICAgICAgIEFzIGEgcmVzdWx0LCBkYXRhIGZy b20gdGhlIHNhbWUgbWFuYWdlbWVudCBtb2RlbCBjYW4gYmUgcmVmbGVjdGVkIGluDQogICAgICAg bXVsdGlwbGUgZGF0YXN0b3Jlcy4gIENsaWVudHMgbmVlZCB0byBzcGVjaWZ5IHRoZSB0YXJnZXQg ZGF0YXN0b3JlIHRvDQogICAgICAgYmUgc3BlY2lmaWMgYWJvdXQgd2hpY2ggdmlld3BvaW50IG9m IHRoZSBkYXRhIHRoZXkgd2FudCB0byBhY2Nlc3MuDQogICAgICAgVGhpcyB3YXksIGFuIGFwcGxp Y2F0aW9uIGNhbiBkaWZmZXJlbnRpYXRlIHdoZXRoZXIgdGhleSBhcmUgKGZvcg0KICAgICAgIGV4 YW1wbGUpIGludGVyZXN0ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gdGhhdCBoYXMgYmVlbiBhcHBs aWVkIGFuZCBpcw0KICAgICAgIGFjdHVhbGx5IGluIGVmZmVjdCwgb3IgaW4gdGhlIGNvbmZpZ3Vy YXRpb24gdGhhdCB3YXMgc3VwcGxpZWQgYnkgYQ0KICAgICAgIGNsaWVudCBhbmQgdGhhdCBpcyBz dXBwb3NlZCB0byBiZSBpbiBlZmZlY3QuDQoNClBlcmhhcHMgcmV3b3JkIHRoZSBsYXN0IHNlbnRl bmNlIHRvIG1hdGNoIHRoZSBsb2dpY2FsIGRhdGEgZmxvdyBpbiB0aGUgc2VydmVyOg0KDQogICBG b3IgZXhhbXBsZSwgYSBjbGllbnQgYXBwbGljYXRpb24gY2FuIGRpZmZlcmVudGlhdGUgd2hldGhl ciB0aGV5IGFyZQ0KICAgaW50ZXJlc3RlZCBpbiB0aGUgY29uZmlndXJhdGlvbiBzdXBwbGllZCB0 byBhIHNlcnZlciBhbmQgdGhhdCBpcw0KICAgc3VwcG9zZWQgdG8gYmUgaW4gZWZmZWN0LCBvciB0 aGUgY29uZmlndXJhdGlvbiB0aGF0IGhhcyBiZWVuIGFwcGxpZWQgYW5kIGlzDQogICBhY3R1YWxs eSBpbiBlZmZlY3Qgb24gdGhlIHNlcnZlci4NCg0KDQogICAgICAgV2hlbiBjb25maWd1cmF0aW9u IHRoYXQgaXMgaW4gZWZmZWN0IGlzIGRpZmZlcmVudCBmcm9tIGNvbmZpZ3VyYXRpb24NCiAgICAg ICB0aGF0IHdhcyBhcHBsaWVkLCBtYW55IGlzc3VlcyBjYW4gcmVzdWx0LiAgSXQgYmVjb21lcyBt b3JlIGRpZmZpY3VsdA0KICAgICAgIHRvIG9wZXJhdGUgdGhlIG5ldHdvcmsgcHJvcGVybHkgZHVl IHRvIGxpbWl0ZWQgdmlzaWJpbGl0eSBvZiBhY3R1YWwNCiAgICAgICBzdGF0dXMgd2hpY2ggbWFr ZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8gYW5hbHl6ZSBhbmQgdW5kZXJzdGFuZCB3aGF0DQogICAg ICAgaXMgZ29pbmcgb24gaW4gdGhlIG5ldHdvcmsuICBTZXJ2aWNlcyBtYXkgYmUgbmVnYXRpdmVs eSBhZmZlY3RlZCAoZm9yDQogICAgICAgZXhhbXBsZSwgYnJlYWtpbmcgYSBzZXJ2aWNlIGluc3Rh bmNlIHJlc3VsdGluZyBpbiBzZXJ2aWNlIGlzIG5vdA0KICAgICAgIHByb3Blcmx5IGRlbGl2ZXJl ZCB0byBhIGN1c3RvbWVyKSBhbmQgbmV0d29yayByZXNvdXJjZXMgYmUNCiAgICAgICBtaXNhbGxv Y2F0ZWQuDQoNClBlcmhhcHMgY2hhbmdlICJhY3R1YWwgc3RhdHVzIiB0byAiYWN0dWFsIG9wZXJh dGlvbmFsIHN0YXR1cyIuDQoNCkkgYWxzbyBzdWdnZXN0IGNoYW5naW5nIHRoZSBsYXN0IHNlbnRl bmNlIHRvOg0KDQogICAgU2VydmljZXMgbWF5IGJlIG5lZ2F0aXZlbHkgYWZmZWN0ZWQgKGUuZy4s IGRlZ3JhZGluZyBvciBicmVha2luZyBhIGN1c3RvbWVyIHNlcnZpY2UpIG9yIG5ldHdvcmsgcmVz b3VyY2VzIG1heSBiZSBtaXNhbGxvY2F0ZWQuDQoNCg0KICAgICAgICAzLiBEZWZpbml0aW9uczoN Cg0KSXQgc2hvdWxkIHByb2JhYmx5IGRlZmluZSB0aGF0IDxpbnRlbmRlZD4sIDxvcGVyYXRpb25h bD4sIChhbmQgcGVyaGFwcyA8cnVubmluZz4pIGFyZSB1c2VkIHRvIGluZGljYXRlIG5hbWVzIG9m IGRhdGFzdG9yZXMuDQoNCkl0IHNob3VsZCBhbHNvIGV4cGxhaW4gdGhhdCA8Y29tcGFyZT4gaXMg dXNlZCBhcyB0aGUgbmFtZSBvZiBhIFlBTkcgUlBDLg0KDQoNCiAgICA0LiAgRGF0YSBNb2RlbCBP dmVydmlldw0KDQogICAgICAgQXQgdGhlIGNvcmUgb2YgdGhlIHNvbHV0aW9uIGlzIGEgbmV3IG1h bmFnZW1lbnQgb3BlcmF0aW9uLCA8Y29tcGFyZT4sDQogICAgICAgdGhhdCBhbGxvd3MgdG8gY29t cGFyZSB0d28gZGF0YXN0b3JlcyBmb3IgdGhlIHNhbWUgZGF0YS4NCg0KU3VnZ2VzdCByZXdvcmRp bmcgdGhpcyBmaXJzdCBzZW50ZW5jZSB0bzoNCg0KICBUaGUgY29yZSBvZiB0aGUgc29sdXRpb24g aXMgYSBuZXcgbWFuYWdlbWVudCBvcGVyYXRpb24sIDxjb21wYXJlPiwNCiAgdGhhdCBjb21wYXJl cyB0aGUgZGF0YSB0cmVlIGNvbnRlbnRzIG9mIHR3byBkYXRhc3RvcmVzLg0KDQogICAgICAgbyAg dGFyZ2V0OiBUaGUgdGFyZ2V0IGlkZW50aWZpZXMgdGhlIGRhdGFzdG9yZSB0byBjb21wYXJlIGFn YWluc3QgdGhlDQogICAgICAgICAgc291cmNlLg0KDQpTdWdnZXN0IGFkZGluZyBhbiBleGFtcGxl ICIsIGUuZy4sIDxvcGVyYXRpb25hbD4uIg0KDQogICAgICAgbyAgZmlsdGVyLXNwZWM6IFRoaXMg aXMgYSBjaG9pY2UgYmV0d2VlbiBkaWZmZXJlbnQgZmlsdGVyIGNvbnN0cnVjdHMNCiAgICAgICAg ICB0byBpZGVudGlmeSB0aGUgcG9ydGlvbnMgb2YgdGhlIGRhdGFzdG9yZSB0byBiZSByZXRyaWV2 ZWQuICBJdA0KICAgICAgICAgIGFjdHMgYXMgYSBub2RlIHNlbGVjdG9yIHRoYXQgc3BlY2lmaWVz IHdoaWNoIGRhdGEgbm9kZXMgYXJlIHdpdGhpbg0KICAgICAgICAgIHRoZSBzY29wZSBvZiB0aGUg Y29tcGFyaXNvbiBhbmQgd2hpY2ggbm9kZXMgYXJlIG91dHNpZGUgdGhlIHNjb3BlDQo= --_000_MN2PR11MB4366539F75C0C0892B8D9848B5969MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5J4oCZbSBub3Qgc3VyZSB3aGljaCBvbmUgeW91IHRoaW5rIGlzIHMgYSBkZXNpZ24g Y2hhbmdlOiZuYnNwOyBEbyB5b3UgbWVhbiBpc3N1ZSAzIG9yIGlzc3VlIDQgYmVsb3c/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkkgc2VlIHRoYXQgbXkgcmVzcG9uc2UgdG8gaXNzdWUgNCBtYXkgbm90IGhhdmUgYmVlbiBjbGVh ciwgc28gdG8gY2xhcmlmeTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Qnkg4oCcb2theeKAnSwgSSBtZWFudCwgdGhhdCBJIGFt IG9rYXkgd2l0aCBob3cgaXQgaXMgd3JpdHRlbiBpbiB0aGUgY3VycmVudCBkcmFmdC4gJm5ic3A7 TXkgcHJlc3VtcHRpb24gaXMgdGhhdCB0aGlzIGNvdWxkIGJlIGFkZHJlc3NlZCBhcyBhIGZ1dHVy ZSB2ZXJzaW9uIG9mIHRoZSBtb2R1bGUgaWYgdGhpcyB0dXJucyBvdXQgYmUgYW4gaXNzdWUsIG9y DQogdmVuZG9ycyBjYW4gZGVmaW5lIHRoZWlyIG93biBhdWdtZW50YXRpb24gaWYgbmVlZGVkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JZiB5b3UgdGhpbmsgaXNzdWUgMyBpcyBhIGRlc2lnbiBjaGFuZ2UgdGhhdCByZXF1aXJl cyBXRyBjb25zZW5zdXMgdGhhdCBJIHdpbGwgbGVhdmUgaXQgdG8gdGhlIFdHIGNoYWlycyB0byBk ZWNpZGUgaWYgdGhleSB3aXNoIHRvIGlzc3VlIGEgY29uc2Vuc3VzIGNhbGwgZm9yIGl0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9iPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFuZHkgQmllcm1h biAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDA1IE1hcmNo IDIwMjEgMTY6MzY8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2ls dG9uQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGpvZWwgamFlZ2dsaSAmbHQ7am9lbGph QGdtYWlsLmNvbSZndDs7IGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0Zi5vcmc7 IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQUQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1hciA1LCAyMDIxIGF0IDU6NTgg QU0gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2Nv LmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I aSBBbmR5LCBhdXRob3JzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgeW91IG1lYW4gdG8gYWRkcmVzcyB0 aGlzIHRvIHRoZSBXRyBzaW5jZSB0aGUgcmVkZXNpZ24gaXNzdWVzIG5lZWQgV0cgYXBwcm92YWwu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhh dmUgbm8gb2JqZWN0aW9ucyB0byBhbnkgY2hhbmdlcy4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Tb3JyeSBmb3IgdGhlIGxvbmcgZGVsYXkgaW4gcmVwbHlpbmcuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2Ugc2VlIFtSV10gaW5saW5lIGJlbG93IOKApjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IEFuZHkgQmllcm1hbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzph bmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+YW5k eUB5dW1hd29ya3MuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ow0KPGJyPg0K PGI+U2VudDo8L2I+IDMwIE9jdG9iZXIgMjAyMCAwMTo0Mzxicj4NCjxiPlRvOjwvYj4gam9lbCBq YWVnZ2xpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+am9lbGphQGdtYWlsLmNvbTwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0 b24pICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPnJ3aWx0b25AY2lzY28uY29tPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1uZXRtb2Qtbm1kYS1kaWZmLmFsbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxh bmc9IkVOLVVTIj5kcmFmdC1pZXRmLW5ldG1vZC1ubWRhLWRpZmYuYWxsQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+bmV0bW9kQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLTA3PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g VGh1LCBPY3QgMjksIDIwMjAgYXQgNjowOSBQTSBqb2VsIGphZWdnbGkgJmx0OzxhIGhyZWY9Im1h aWx0bzpqb2VsamFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9lbGphQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Sb2IsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVzZSBzZWVtIGxpa2UgcmVhc29uYWJsZSBzdWdnZXN0 aW9ucy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkxldHMgc2VlIHdoYXQgdGhlIGF1dGhvcnMgc2F5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB0 aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PmpvZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUaHUsIE9jdCAyOSwgMjAyMCBhdCA2OjQ3IEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8 YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5yd2lsdG9u QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+SGksPGJyPg0KPGJyPg0KSGVyZSBpcyBteSBBRCByZXZpZXcgZm9yIGRyYWZ0LWlldGYtbmV0 bW9kLW5tZGEtZGlmZi0wNy4mbmJzcDsgQXBvbG9naWVzIGZvciB0aGUgZGVsYXkuPGJyPg0KPGJy Pg0KVGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMgZG9jdW1lbnQsIEkgdGhpbmsgdGhhdCBpdCBp cyB1c2VmdWwsIGFuZCBsb29rcyBsaWtlIGl0IGlzIGluIGdvb2Qgc2hhcGUuPGJyPg0KPGJyPg0K PGJyPg0KTWFpbiBjb21tZW50czo8YnI+DQo8YnI+DQoxLiBTaG91bGQgdGhlcmUgYmUgYW55IHRl eHQgYWJvdXQgaG93IHRvIGZpbmQgb3V0IHdoYXQgZGF0YXN0b3JlcyBhcmUgc3VwcG9ydGVkIGJ5 IGEgZGV2aWNlPyZuYnNwOyBFLmcuLCBwb2ludGluZyB0aGVtIHRvIGVpdGhlciBZQU5HIGxpYnJh cnksIG9yIHByb3RvY29sIHNwZWNpZmljIG1lY2hhbmlzbXMgaW4gdGhlIGNhc2Ugb2YgUkVTVENP TkYuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvIHlvdSBoYXZlIGEg c2VjdGlvbiBpbiBtaW5kIGFuZCBzdWdnZXN0ZWQgdGV4dD88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+W1JXXQ0KPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+UGVyaGFwcyBzb21ld2hlcmUgaW4gc2VjdGlvbiA0 LCBlaXRoZXIgYXMgcGFydCBvZiB0aGUgZGVzY3JpcHRpb24gb2Ygc291cmNlLCBvciBwZXJoYXBz IGJlZm9yZSB0aGUgcGFyYW1ldGVycyBhcmUgZGVzY3JpYmVkLjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPlByb3Bvc2VkIHRleHQ6PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxNi41 cHQiPg0KPGI+PGk+4oCcQSBjbGllbnQgY2FuIGRpc2NvdmVyIHdoaWNoIGRhdGFzdG9yZXMgYSBz ZXJ2ZXIgc3VwcG9ydHMgYnkgcmVhZGluZyBZQU5HIGxpYnJhcnkgW1JGQyA4NTI1XSBmcm9tIHRo ZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUu4oCdPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij4yLiBJdCBtaWdodCBiZSBoZWxwZnVsIHRvIGFkZCBhIGNv bW1lbnQgYWJvdXQgcG90ZW50aWFsIGlzc3VlcyB0aGF0IGNvdWxkIGFyaXNlIGJ5IGNvbXBhcmlu ZyAmbHQ7cnVubmluZyZndDsgdG8gJmx0O29wZXJhdGlvbmFsJmd0OywgaS5lLiwgYWRkaXRpb25h bCBkaWZmZXJlbmNlcyBjb3VsZCBiZSByZXBvcnRlZCBkdWUgdG8gaW5hY3RpdmUNCiBjb25maWd1 cmF0aW9uIGFuZCB0ZW1wbGF0ZSBwcm9jZXNzaW5nIGJldHdlZW4gJmx0O3J1bm5pbmcmZ3Q7IGFu ZCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5EbyB5b3UgaGF2ZSBhIHNlY3Rpb24gaW4gbWluZCBhbmQgc3VnZ2VzdGVkIHRleHQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSBt ZWFuIGlmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBiZXR3ZWVuICZsdDtydW5uaW5nJmd0OyBhbmQg Jmx0O2ludGVuZGVkJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj50aGVuIGEgZGlmZiBiZXR3ZWVuICZsdDtydW5uaW5nJmd0OyBhbmQgJmx0 O29wZXJhdGlvbmFsJmd0OyB3aWxsIG5vdCBiZSB0aGUgc2FtZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hcyBhIGRpZmYgYmV0d2VlbiAmbHQ7 aW50ZW5kZWQmZ3Q7IGFuZCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7Lj88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxpPltSV10NCjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxpPk15IG1haW4gY29uY2VybiBpcyB0aGF0IGlmIHlvdSBoYXZlIHRl bXBsYXRlIGV4cGFuc2lvbiB0aGVuIGNvbXBhcmluZyAmbHQ7cnVubmluZyZndDsgYW5kICZsdDtv cGVyYXRpb25hbCZndDsgbWF5IG5vdCByZWFsbHkgZ2l2ZSBhIG1lYW5pbmdmdWwgY29tcGFyaXNv biwgc2luY2UgJmx0O3J1bm5pbmcmZ3Q7IGlzIHByZS10ZW1wbGF0ZQ0KIGV4cGFuc2lvbiwgYW5k ICZsdDtvcGVyYXRpb25hbCZndDsgKGFuZCAmbHQ7aW50ZW5kZWQmZ3Q7KSBhcmUgYm90aCBwb3N0 IHRlbXBsYXRlIGV4cGFuc2lvbi48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT5JIHdvdWxkIHN1Z2dlc3QgcHV0dGluZyBzb21lIHRleHQgaW4g c2VjdGlvbiA0IG9yIHBlcmhhcHMgdGhlIFlBTkcgbW9kdWxlLjwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPlBlcmhhcHMgc29tZSB0ZXh0LCBz b21ldGhpbmcgbGlrZToNCjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxpPiZuYnNwOyDigJxDbGllbnRzIHNob3VsZCB0byBiZSBhd2FyZSB0aGF0 IGNvbXBhcmluZyAmbHQ7cnVubmluZyZndDsgdG8gJmx0O29wZXJhdGlvbmFsJmd0OyB3aWxsIHJl cG9ydCBkaWZmZXJlbmNlcyBkdWUgdG8gYW55IGNvbmZpZ3VyYXRpb24gdHJhbnNmb3JtYXRpb24g KGUuZy4sIGluYWN0aXZlIGNvbmZpZ3VyYXRpb24sIG9yIHRoZQ0KIGV4cGFuc2lvbiBvZiB0ZW1w bGF0ZXMpIGJldHdlZW4gdGhlICZsdDtydW5uaW5nJmd0OyBhbmQgJmx0O2ludGVuZGVkJmd0OyBk YXRhc3RvcmVzLiZuYnNwOyBJbiB0aGVzZSBzY2VuYXJpb3MsIGNsaWVudHMgbWF5IGdldCBhIG1v cmUgdXNlZnVsIHJlc3VsdCBieSBjb21wYXJpbmcgdGhlICZsdDtpbnRlbmRlZCZndDsgYW5kICZs dDtvcGVyYXRpb25hbCZndDsgZGF0YXN0b3JlcyBpbnN0ZWFkLuKAnTwvaT48L2I+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4gSSB3b3VsZCBwcmVmZXIgaWYgJ2V4Y2x1ZGU9b3Jp Z2luJyB3YXMgaW4gdGhlIHJldmVyc2Ugc2Vuc2UgYW5kIHBlcmhhcHMgY2FsbGVkICdyZXBvcnQt b3JpZ2luJyBpbnN0ZWFkLiZuYnNwOyBXaXRoIHRoZSByZXZlcnNlIHNlbnNlIGl0IHNlZW1zIHRv IGJlIHNhZmVyIGlmIG5ldyBkYXRhc3RvcmVzIGFyZSBkZWZpbmVkLA0KIHdoZXJlIG90aGVyd2lz ZSB0aGUgYmVoYXZpb3VyIGNvdWxkIGVuZCBiZWluZyB1bmRlciBzcGVjaWZpZWQuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JTU8gdGhlIFdHIGFscmVhZHkgZGVz aWduZWQgdGhlIGZlYXR1cmVzIHNvIGlmIHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBoYXZl IGNoYW5nZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+dGhlbiB0aGUgZHJhZnQgc2hvdWxkIGdvIGJhY2sgdG8gdGhlIFdHIGZvciBjaGFuZ2Vz IGFuZCBuZXcgV0cgY29uc2Vuc3VzIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48aT5bUlddDQo8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48aT5JIGRvbuKAmXQgc2VlIHRoaXMgYXMgcmVhbGx5IGNoYW5n aW5nIHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cywgYnV0IGp1c3QgY2hhbmdpbmcgdGhlIGRl ZmF1bHQgc2Vuc2UgYW5kIG5hbWUgb2YgYW4gQVBJIHBhcmFtZXRlci4mbmJzcDsgQWx0aG91Z2gs IGdpdmVuIG15IGNvbW1lbnRzIGJlbG93IOKAnHdpdGgtb3JpZ2lu4oCdDQogbWlnaHQgYmUgYmV0 dGVyIHRoYW4g4oCccmVwb3J0LW9yaWdpbuKAnS48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5JbiBSRkMgODUyNiwgdGhlIOKAnHdpdGgtb3Jp Z2lu4oCdIHBhcmFtZXRlciBpcyBvZmYgYnkgZGVmYXVsdCwgYW5kIG9yaWdpbiBtZXRhZGF0YSBp cyBvbmx5IGluY2x1ZGVkIHdoZW4gdGhlIHBhcmFtZXRlciBpcyBpbmNsdWRlZC4mbmJzcDsgVGhp cyBrZXl3b3JkIGlzIGFsc28gdW5kZXIgYSBmZWF0dXJlLjwvaT48L2I+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPlNvLCBjaGFuZ2luZyB0aGUgcGFyYW1l dGVyIG5hbWUgdG8g4oCcd2l0aC1vcmlnaW7igJ0gYW5kIHB1dHRpbmcgaXQgdW5kZXIg4oCdaWYt ZmVhdHVyZSBpZXRmLW5ldGNvbmYtbm1kYTpvcmlnaW7igJ0sIGFuZCBtYWtpbmcgdGhlIGRlZmF1 bHQgb2ZmLCB3b3VsZCBtYWtlIHRoZSBkZWZpbml0aW9uIG1vcmUgY29uc2lzdGVudA0KIHdpdGgg UkZDIDg1MjYuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxicj4NCjQuIFNob3VsZCB0aGVyZSBiZSBhbiBvcHRpb24gdG8gZmls dGVyIG9uIG9yaWdpbiBtZXRhZGF0YT8mbmJzcDsgRS5nLiwgb25seSBpbmNsdWRlIHZhbHVlcyB0 aGF0IGNvbWUgZnJvbSBpbnRlbmRlZC4mbmJzcDsgT3RoZXJ3aXNlLCB0aGluZ3MgbGlrZSBJUCBh ZGRyZXNzZXMgbGVhcm5lZCBmcm9tIERIQ1AgbWF5IGFsd2F5cyB0dXJuIHVwIGFzIGRpZmZlcmVu Y2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JTU8gdGhlIFdHIGFs cmVhZHkgZGVzaWduZWQgdGhlIGZlYXR1cmVzIHNvIGlmIHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVt ZW50cyBoYXZlIGNoYW5nZWR0aGVuIHRoZSBkcmFmdCBzaG91bGQgZ28gYmFjayB0byB0aGUgV0cg Zm9yIGNoYW5nZXMgYW5kIG5ldyBXRyBjb25zZW5zdXMgY2FsbHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5bUlddDQo8L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT4mbmJzcDs8L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5Pa2F5LjwvaT48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPlJlZ2FyZHMsPC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+Um9iPC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjUuIEknbSBub3QgdGhh dCBrZWVuIG9uIHRoZSAmcXVvdDtQb3NzaWJsZSBGdXR1cmUgRXh0ZW5zaW9ucyZxdW90OyBzZWN0 aW9uIG9mIGFuIFJGQy4mbmJzcDsgUGVyc29uYWxseSwgSSB3b3VsZCBwcmVmZXIgdGhhdCB0aGlz IHNlY3Rpb24gaXMgZGVsZXRlZCwgYnV0IGlmIHlvdSB3aXNoIHRvIHJldGFpbiBpdCwgdGhlbiBw bGVhc2UgY2FuIHlvdSBtb3ZlIGl0IHRvIGFuIGFwcGVuZGl4LjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PSyB3aXRoIG1lIHRvIHJlbW92ZSBpdDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnI+DQpJJ3ZlIGFsc28gaW5jbHVkZWQgc29tZSBtaW5vciBjb21tZW50cyBpbmxpbmUgYmVsb3cs IGFuZCBzb21lIG5pdHMgYXQgdGhlIGVuZDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFic3Ry YWN0PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBk ZWZpbmVzIGFuIFJQQyBvcGVyYXRpb24gdG8gY29tcGFyZSBtYW5hZ2VtZW50PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRoIHRoZSBOTURB IGFyY2hpdGVjdHVyZS48YnI+DQo8YnI+DQpUaGUgYWJzdHJhY3QgaXMgcGVyaGFwcyBzb21ld2hh dCB0ZXJzZS4mbmJzcDsgUGVyaGFwczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIFlBTkcgUlBDIG9wZXJhdGlvbiB0byBjb21wYXJlIHRoZTxicj4NCiZu YnNwOyAmbmJzcDsgY29udGVudHMgb2YgbmV0d29yayBtYW5hZ2VtZW50IGRhdGFzdG9yZXMgdGhh dCBjb21wbHkgd2l0aDxicj4NCiZuYnNwOyAmbmJzcDsgdGhlIE5NREEgYXJjaGl0ZWN0dXJlIGFu ZCByZXR1cm4gdGhlIGRpZmZlcmVuY2VzIGluIHRoZSA8YnI+DQombmJzcDsgJm5ic3A7IFlBTkct UGF0Y2ggZm9ybWF0Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMS4mbmJzcDsgSW50 cm9kdWN0aW9uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHJldmlz ZWQgTmV0d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgKE5NREEpPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1JGQzgzNDJdIGludHJvZHVjZXMgYSBzZXQgb2Yg bmV3IGRhdGFzdG9yZXMgdGhhdCBlYWNoIGhvbGQgWUFORy08YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtkZWZpbmVkIGRhdGEgW1JGQzc5NTBdIGFuZCByZXByZXNlbnQgYSBkaWZmZXJl bnQgJnF1b3Q7dmlld3BvaW50JnF1b3Q7IG9uIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RhdGEgdGhhdCBpcyBtYWludGFpbmVkIGJ5IGEgc2VydmVyLiZuYnNwOyBOZXcgWUFO RyBkYXRhc3RvcmVzIHRoYXQgYXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW50 cm9kdWNlZCBpbmNsdWRlICZsdDtpbnRlbmRlZCZndDssIHdoaWNoIGNvbnRhaW5zIHZhbGlkYXRl ZCBjb25maWd1cmF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YSB0aGF0 IGEgY2xpZW50IGFwcGxpY2F0aW9uIGludGVuZHMgdG8gYmUgaW4gZWZmZWN0LCBhbmQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7b3BlcmF0aW9uYWwmZ3Q7LCB3aGljaCBjb250 YWlucyBhdCBsZWFzdCBjb25jZXB0dWFsbHkgb3BlcmF0aW9uYWwgc3RhdGU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhIChzdWNoIGFzIHN0YXRpc3RpY3MpIGFzIHdlbGwgYXMg Y29uZmlndXJhdGlvbiBkYXRhIHRoYXQgaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDthY3R1YWxseSBpbiBlZmZlY3QuPGJyPg0KPGJyPg0KSSB3b3VsZCBzdWdnZXN0IGRlbGV0aW5n ICZxdW90O2F0IGxlYXN0IGNvbmNlcHR1YWxseSZxdW90Oywgc2luY2UgdGhlICZsdDtvcGVyYXRp b25hbCZndDs8YnI+DQpkYXRhc3RvcmUgZG9lcyBjb250YWluIGFsbCBvcGVyYXRpb25hbCBzdGF0 ZSwgYnV0IGl0IG1heSBiZSBpbXBsZW1lbnRlZCBhcyBhIHZpcnR1YWwgY29uc3RydWN0IHRoYXQg c3BhbnMgbXVsdGlwbGUgbm9kZXMgKGUuZy4sIGxpbmVjYXJkcykgYW5kIHByb2Nlc3Nlcy48YnI+ DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOTURBIGludHJvZHVjZXMg aW4gZWZmZWN0IGEgY29uY2VwdCBvZiAmcXVvdDtsaWZlY3ljbGUmcXVvdDsgZm9yIG1hbmFnZW1l bnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhLCBhbGxvd2luZyB0byBjbGVh cmx5IGRpc3Rpbmd1aXNoIGJldHdlZW4gZGF0YSB0aGF0IGlzIHBhcnQgb2YgYTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmZpZ3VyYXRpb24gdGhhdCB3YXMgc3VwcGxpZWQgYnkg YSB1c2VyLCBjb25maWd1cmF0aW9uIGRhdGEgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2hhcyBhY3R1YWxseSBiZWVuIHN1Y2Nlc3NmdWxseSBhcHBsaWVkIGFuZCB0aGF0IGlz IHBhcnQgb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3BlcmF0aW9uYWwg c3RhdGUsIGFuZCBvdmVyYWxsIG9wZXJhdGlvbmFsIHN0YXRlIHRoYXQgaW5jbHVkZXMgYm90aDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FwcGxpZWQgY29uZmlndXJhdGlvbiBkYXRh IGFzIHdlbGwgYXMgc3RhdHVzIGFuZCBzdGF0aXN0aWNzLjxicj4NCjxicj4NCiZxdW90O2FsbG93 aW5nIHRvIGNsZWFybHkgZGlzdGluZ3Vpc2gmcXVvdDsgPSZndDsgZGlzdGluZ3Vpc2hpbmcmcXVv dDs8YnI+DQomcXVvdDtzdGF0dXMgYW5kIHN0YXRpc3RpY3MmcXVvdDsgPSZndDsgJnF1b3Q7c3Rh dHVzIGluZm9ybWF0aW9uIGFuZCBzdGF0aXN0aWNzJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXMgYSByZXN1bHQsIGRhdGEgZnJvbSB0aGUgc2FtZSBt YW5hZ2VtZW50IG1vZGVsIGNhbiBiZSByZWZsZWN0ZWQgaW48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttdWx0aXBsZSBkYXRhc3RvcmVzLiZuYnNwOyBDbGllbnRzIG5lZWQgdG8gc3Bl Y2lmeSB0aGUgdGFyZ2V0IGRhdGFzdG9yZSB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2JlIHNwZWNpZmljIGFib3V0IHdoaWNoIHZpZXdwb2ludCBvZiB0aGUgZGF0YSB0aGV5IHdh bnQgdG8gYWNjZXNzLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgd2F5LCBh biBhcHBsaWNhdGlvbiBjYW4gZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZXkgYXJlIChmb3I8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleGFtcGxlKSBpbnRlcmVzdGVkIGluIHRoZSBj b25maWd1cmF0aW9uIHRoYXQgaGFzIGJlZW4gYXBwbGllZCBhbmQgaXM8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDthY3R1YWxseSBpbiBlZmZlY3QsIG9yIGluIHRoZSBjb25maWd1cmF0 aW9uIHRoYXQgd2FzIHN1cHBsaWVkIGJ5IGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtjbGllbnQgYW5kIHRoYXQgaXMgc3VwcG9zZWQgdG8gYmUgaW4gZWZmZWN0Ljxicj4NCjxicj4N ClBlcmhhcHMgcmV3b3JkIHRoZSBsYXN0IHNlbnRlbmNlIHRvIG1hdGNoIHRoZSBsb2dpY2FsIGRh dGEgZmxvdyBpbiB0aGUgc2VydmVyOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtGb3IgZXhhbXBs ZSwgYSBjbGllbnQgYXBwbGljYXRpb24gY2FuIGRpZmZlcmVudGlhdGUgd2hldGhlciB0aGV5IGFy ZTxicj4NCiZuYnNwOyAmbmJzcDtpbnRlcmVzdGVkIGluIHRoZSBjb25maWd1cmF0aW9uIHN1cHBs aWVkIHRvIGEgc2VydmVyIGFuZCB0aGF0IGlzPGJyPg0KJm5ic3A7ICZuYnNwO3N1cHBvc2VkIHRv IGJlIGluIGVmZmVjdCwgb3IgdGhlIGNvbmZpZ3VyYXRpb24gdGhhdCBoYXMgYmVlbiBhcHBsaWVk IGFuZCBpczxicj4NCiZuYnNwOyAmbmJzcDthY3R1YWxseSBpbiBlZmZlY3Qgb24gdGhlIHNlcnZl ci48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGVuIGNvbmZp Z3VyYXRpb24gdGhhdCBpcyBpbiBlZmZlY3QgaXMgZGlmZmVyZW50IGZyb20gY29uZmlndXJhdGlv bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgd2FzIGFwcGxpZWQsIG1hbnkg aXNzdWVzIGNhbiByZXN1bHQuJm5ic3A7IEl0IGJlY29tZXMgbW9yZSBkaWZmaWN1bHQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0byBvcGVyYXRlIHRoZSBuZXR3b3JrIHByb3Blcmx5 IGR1ZSB0byBsaW1pdGVkIHZpc2liaWxpdHkgb2YgYWN0dWFsPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7c3RhdHVzIHdoaWNoIG1ha2VzIGl0IG1vcmUgZGlmZmljdWx0IHRvIGFuYWx5 emUgYW5kIHVuZGVyc3RhbmQgd2hhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lz IGdvaW5nIG9uIGluIHRoZSBuZXR3b3JrLiZuYnNwOyBTZXJ2aWNlcyBtYXkgYmUgbmVnYXRpdmVs eSBhZmZlY3RlZCAoZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhhbXBsZSwg YnJlYWtpbmcgYSBzZXJ2aWNlIGluc3RhbmNlIHJlc3VsdGluZyBpbiBzZXJ2aWNlIGlzIG5vdDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Byb3Blcmx5IGRlbGl2ZXJlZCB0byBhIGN1 c3RvbWVyKSBhbmQgbmV0d29yayByZXNvdXJjZXMgYmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDttaXNhbGxvY2F0ZWQuPGJyPg0KPGJyPg0KUGVyaGFwcyBjaGFuZ2UgJnF1b3Q7YWN0 dWFsIHN0YXR1cyZxdW90OyB0byAmcXVvdDthY3R1YWwgb3BlcmF0aW9uYWwgc3RhdHVzJnF1b3Q7 Ljxicj4NCjxicj4NCkkgYWxzbyBzdWdnZXN0IGNoYW5naW5nIHRoZSBsYXN0IHNlbnRlbmNlIHRv Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgU2VydmljZXMgbWF5IGJlIG5lZ2F0aXZlbHkgYWZm ZWN0ZWQgKGUuZy4sIGRlZ3JhZGluZyBvciBicmVha2luZyBhIGN1c3RvbWVyIHNlcnZpY2UpIG9y IG5ldHdvcmsgcmVzb3VyY2VzIG1heSBiZSBtaXNhbGxvY2F0ZWQuPGJyPg0KPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDMuIERlZmluaXRpb25zOjxicj4NCjxicj4NCkl0 IHNob3VsZCBwcm9iYWJseSBkZWZpbmUgdGhhdCAmbHQ7aW50ZW5kZWQmZ3Q7LCAmbHQ7b3BlcmF0 aW9uYWwmZ3Q7LCAoYW5kIHBlcmhhcHMgJmx0O3J1bm5pbmcmZ3Q7KSBhcmUgdXNlZCB0byBpbmRp Y2F0ZSBuYW1lcyBvZiBkYXRhc3RvcmVzLjxicj4NCjxicj4NCkl0IHNob3VsZCBhbHNvIGV4cGxh aW4gdGhhdCAmbHQ7Y29tcGFyZSZndDsgaXMgdXNlZCBhcyB0aGUgbmFtZSBvZiBhIFlBTkcgUlBD Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgNC4mbmJzcDsgRGF0YSBNb2RlbCBPdmVy dmlldzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0F0IHRoZSBjb3JlIG9m IHRoZSBzb2x1dGlvbiBpcyBhIG5ldyBtYW5hZ2VtZW50IG9wZXJhdGlvbiwgJmx0O2NvbXBhcmUm Z3Q7LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgYWxsb3dzIHRvIGNvbXBh cmUgdHdvIGRhdGFzdG9yZXMgZm9yIHRoZSBzYW1lIGRhdGEuPGJyPg0KPGJyPg0KU3VnZ2VzdCBy ZXdvcmRpbmcgdGhpcyBmaXJzdCBzZW50ZW5jZSB0bzo8YnI+DQo8YnI+DQombmJzcDsgVGhlIGNv cmUgb2YgdGhlIHNvbHV0aW9uIGlzIGEgbmV3IG1hbmFnZW1lbnQgb3BlcmF0aW9uLCAmbHQ7Y29t cGFyZSZndDssPGJyPg0KJm5ic3A7IHRoYXQgY29tcGFyZXMgdGhlIGRhdGEgdHJlZSBjb250ZW50 cyBvZiB0d28gZGF0YXN0b3Jlcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtvJm5ic3A7IHRhcmdldDogVGhlIHRhcmdldCBpZGVudGlmaWVzIHRoZSBkYXRhc3RvcmUgdG8g Y29tcGFyZSBhZ2FpbnN0IHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgc291cmNlLjxicj4NCjxicj4NClN1Z2dlc3QgYWRkaW5nIGFuIGV4YW1wbGUgJnF1b3Q7LCBl LmcuLCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiZxdW90Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO28mbmJzcDsgZmlsdGVyLXNwZWM6IFRoaXMgaXMgYSBjaG9pY2UgYmV0d2Vl biBkaWZmZXJlbnQgZmlsdGVyIGNvbnN0cnVjdHM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHRvIGlkZW50aWZ5IHRoZSBwb3J0aW9ucyBvZiB0aGUgZGF0YXN0b3JlIHRv IGJlIHJldHJpZXZlZC4mbmJzcDsgSXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGFjdHMgYXMgYSBub2RlIHNlbGVjdG9yIHRoYXQgc3BlY2lmaWVzIHdoaWNoIGRhdGEg bm9kZXMgYXJlIHdpdGhpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg dGhlIHNjb3BlIG9mIHRoZSBjb21wYXJpc29uIGFuZCB3aGljaCBub2RlcyBhcmUgb3V0c2lkZSB0 aGUgc2NvcGU8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_MN2PR11MB4366539F75C0C0892B8D9848B5969MN2PR11MB4366namp_-- From nobody Fri Mar 5 10:46:30 2021 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 D03883A29CA for ; Fri, 5 Mar 2021 10:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciqQKxyEW3yY for ; Fri, 5 Mar 2021 10:46:26 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8863A29CB for ; Fri, 5 Mar 2021 10:46:25 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id e2so4030007ljo.7 for ; Fri, 05 Mar 2021 10:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7ux3ZBPYqlOaI/z4SAicKroTRNjFKwJ5UKD8LkX9hNs=; b=HccePo0LzZDSv85D/pEWqAacht9yBUTI04WTKW2/4mxqFBHzfTvYJ1ZykaN8ADabUY GNG8UxtfRzLFsfCr8oiltR/xwXIPHZbpk61hcTgOId2DKTGCTBQhZhPm0MmjTEP/ZrvW iBpUZgud8XJ3GNDktxWF0MnHKZH6ns5Z0M/42lyrDB/PYqH4rSFaj8kQ/KYGS+yWW7Ro QWIeq0NhiwU/gl2GwJgfE3p1Puis01gCeJhEFGSF1oai9YCZUJP589l3cedtyz+MzfQT ZDd+GDVRpdhxbKGK4UcQgP7y2k3Tvra7YrgPKGdDlk6jYdcIf3hBCkWanPON+T8En6IG 3s/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7ux3ZBPYqlOaI/z4SAicKroTRNjFKwJ5UKD8LkX9hNs=; b=WEcvmoTR0upHrIXDqurVP16tkTYDrg6HTSqq7Wm8yEzOPUvCRRvQBF4IAAVZvwhHaR DtywcbcWLYZ8gCaUlU9PC+jqLjoxfDVNk7TGKbCUZpwn+lC9aS+jHcaEtxURwT5PKM7M LMzzp4maHcSnMMKIV+9xKwCT3PT5dCYOfduuSZDvrb1QgAYwJBgJ4OvktAoEIV9e4dHT azklCQuj5iiC0E7POEIrnnZ5XM7w5NAThdGjCWdugT0qtJvEjL20DoF9Nx/8g+vf1lX8 /r0hqTj3zSMieFCp66+1CKxyB/WPqgfEOGB1BZUfwlnEb3VEb30M/niWkRVvuKb7BLwX cEQQ== X-Gm-Message-State: AOAM531oCQRUXjIggRsGENLm0D2XRCsu/e9AIYW3+P3D1kj4wQf2Ja0Z bLVsU1yCdSN6Bprv2wvtl/P1FZv9oxxpTaQVHOz7gg== X-Google-Smtp-Source: ABdhPJxctp2hNlMPbiWndU0tuxhL2eJAWVDxzQh0wyZVz95o3iqfcQD6bfbuY/w870A3o79wrpPOr6lYFecJFDpp5x0= X-Received: by 2002:a2e:2f16:: with SMTP id v22mr5944637ljv.105.1614969983028; Fri, 05 Mar 2021 10:46:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Fri, 5 Mar 2021 10:46:12 -0800 Message-ID: To: "Rob Wilton (rwilton)" Cc: NetMod WG Chairs , joel jaeggli , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002aa01805bcce8088" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 18:46:29 -0000 --0000000000002aa01805bcce8088 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton) wrote: > Hi Andy, > > > > I=E2=80=99m not sure which one you think is s a design change: Do you me= an issue > 3 or issue 4 below? > > > > I see that my response to issue 4 may not have been clear, so to clarify: > > > > By =E2=80=9Cokay=E2=80=9D, I meant, that I am okay with how it is written= in the current > draft. My presumption is that this could be addressed as a future versio= n > of the module if this turns out be an issue, or vendors can define their > own augmentation if needed. > > > > If you think issue 3 is a design change that requires WG consensus that I > will leave it to the WG chairs to decide if they wish to issue a consensu= s > call for it. > > > The change: Current: default is to include origin attributes and client adds exclude-origin leaf to turn this off Proposed: default is to exclude origin attributes and client adds report-origin leaf to turn this on Also, report-origin has an if-feature because origin support in NMDA is optional. I have no objections to this proposal. My point all along has been that this is not my decision to make, it is a WG decision. It does not seem that there are any objections to making this change. Regards, > > Rob > > > Andy > > > *From:* Andy Bierman > *Sent:* 05 March 2021 16:36 > *To:* Rob Wilton (rwilton) > *Cc:* joel jaeggli ; > draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org > *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 > > > > > > > > On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) > wrote: > > Hi Andy, authors, > > > > > > > > I think you mean to address this to the WG since the redesign issues need > WG approval. > > I have no objections to any changes. > > > > > > Andy > > > > Sorry for the long delay in replying. > > > > Please see [RW] inline below =E2=80=A6 > > > > > > *From:* Andy Bierman > *Sent:* 30 October 2020 01:43 > *To:* joel jaeggli > *Cc:* Rob Wilton (rwilton) ; > draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org > *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 > > > > > > > > On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli wrote: > > Rob, > > > > These seem like reasonable suggestions. > > > > Lets see what the authors say. > > > > Thanks for this > > joel > > > > On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) > wrote: > > Hi, > > Here is my AD review for draft-ietf-netmod-nmda-diff-07. Apologies for > the delay. > > Thank you for writing this document, I think that it is useful, and looks > like it is in good shape. > > > Main comments: > > 1. Should there be any text about how to find out what datastores are > supported by a device? E.g., pointing them to either YANG library, or > protocol specific mechanisms in the case of RESTCONF. > > > > Do you have a section in mind and suggested text? > > *[RW] * > > *Perhaps somewhere in section 4, either as part of the description of > source, or perhaps before the parameters are described.* > > > > *Proposed text:* > > *=E2=80=9CA client can discover which datastores a server supports by rea= ding YANG > library [RFC 8525] from the operational state datastore.=E2=80=9D* > > > > > > > > 2. It might be helpful to add a comment about potential issues that could > arise by comparing to , i.e., additional differenc= es > could be reported due to inactive configuration and template processing > between and . > > > > Do you have a section in mind and suggested text? > > You mean if there are differences between and > > then a diff between and will not be the same > > as a diff between and .? > > > > *[RW] * > > *My main concern is that if you have template expansion then comparing > and may not really give a meaningful comparison, > since is pre-template expansion, and (and > ) are both post template expansion.* > > > > *I would suggest putting some text in section 4 or perhaps the YANG > module.* > > > > *Perhaps some text, something like: * > > > > * =E2=80=9CClients should to be aware that comparing to > will report differences due to any configuration transformation (e.g., > inactive configuration, or the expansion of templates) between the > and datastores. In these scenarios, clients may get= a > more useful result by comparing the and datastor= es > instead.=E2=80=9D* > > > > > > > > > > 3. I would prefer if 'exclude=3Dorigin' was in the reverse sense and perh= aps > called 'report-origin' instead. With the reverse sense it seems to be > safer if new datastores are defined, where otherwise the behaviour could > end being under specified. > > > > > > IMO the WG already designed the features so if the functional requirement= s > have changed > > then the draft should go back to the WG for changes and new WG consensus > calls. > > *[RW] * > > > > *I don=E2=80=99t see this as really changing the functional requirements,= but just > changing the default sense and name of an API parameter. Although, given > my comments below =E2=80=9Cwith-origin=E2=80=9D might be better than =E2= =80=9Creport-origin=E2=80=9D.* > > > > *In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D parameter is off by defau= lt, and origin > metadata is only included when the parameter is included. This keyword i= s > also under a feature.* > > > > *So, changing the parameter name to =E2=80=9Cwith-origin=E2=80=9D and put= ting it under > =E2=80=9Dif-feature ietf-netconf-nmda:origin=E2=80=9D, and making the def= ault off, would > make the definition more consistent with RFC 8526.* > > > > > > > 4. Should there be an option to filter on origin metadata? E.g., only > include values that come from intended. Otherwise, things like IP > addresses learned from DHCP may always turn up as differences. > > > > IMO the WG already designed the features so if the functional requirement= s > have changedthen the draft should go back to the WG for changes and new W= G > consensus calls. > > > > *[RW] * > > > > *Okay.* > > > > *Regards,* > > *Rob* > > > > > > > 5. I'm not that keen on the "Possible Future Extensions" section of an > RFC. Personally, I would prefer that this section is deleted, but if you > wish to retain it, then please can you move it to an appendix. > > > > OK with me to remove it > > > > > > > > Andy > > > > > > > I've also included some minor comments inline below, and some nits at the > end: > > Abstract > > This document defines an RPC operation to compare management > datastores that comply with the NMDA architecture. > > The abstract is perhaps somewhat terse. Perhaps: > > This document defines a YANG RPC operation to compare the > contents of network management datastores that comply with > the NMDA architecture and return the differences in the > YANG-Patch format. > > > 1. Introduction > > The revised Network Management Datastore Architecture (NMDA) > [RFC8342] introduces a set of new datastores that each hold YANG- > defined data [RFC7950] and represent a different "viewpoint" on th= e > data that is maintained by a server. New YANG datastores that are > introduced include , which contains validated > configuration > data that a client application intends to be in effect, and > , which contains at least conceptually operational > state > data (such as statistics) as well as configuration data that is > actually in effect. > > I would suggest deleting "at least conceptually", since the > datastore does contain all operational state, but it may be implemented a= s > a virtual construct that spans multiple nodes (e.g., linecards) and > processes. > > > NMDA introduces in effect a concept of "lifecycle" for management > data, allowing to clearly distinguish between data that is part of= a > configuration that was supplied by a user, configuration data that > has actually been successfully applied and that is part of the > operational state, and overall operational state that includes bot= h > applied configuration data as well as status and statistics. > > "allowing to clearly distinguish" =3D> distinguishing" > "status and statistics" =3D> "status information and statistics" > > > As a result, data from the same management model can be reflected = in > multiple datastores. Clients need to specify the target datastore > to > be specific about which viewpoint of the data they want to access. > This way, an application can differentiate whether they are (for > example) interested in the configuration that has been applied and > is > actually in effect, or in the configuration that was supplied by a > client and that is supposed to be in effect. > > Perhaps reword the last sentence to match the logical data flow in the > server: > > For example, a client application can differentiate whether they are > interested in the configuration supplied to a server and that is > supposed to be in effect, or the configuration that has been applied > and is > actually in effect on the server. > > > When configuration that is in effect is different from configurati= on > that was applied, many issues can result. It becomes more difficu= lt > to operate the network properly due to limited visibility of actua= l > status which makes it more difficult to analyze and understand wha= t > is going on in the network. Services may be negatively affected > (for > example, breaking a service instance resulting in service is not > properly delivered to a customer) and network resources be > misallocated. > > Perhaps change "actual status" to "actual operational status". > > I also suggest changing the last sentence to: > > Services may be negatively affected (e.g., degrading or breaking a > customer service) or network resources may be misallocated. > > > 3. Definitions: > > It should probably define that , , (and perhaps > ) are used to indicate names of datastores. > > It should also explain that is used as the name of a YANG RPC. > > > 4. Data Model Overview > > At the core of the solution is a new management operation, > , > that allows to compare two datastores for the same data. > > Suggest rewording this first sentence to: > > The core of the solution is a new management operation, , > that compares the data tree contents of two datastores. > > o target: The target identifies the datastore to compare against > the > source. > > Suggest adding an example ", e.g., ." > > o filter-spec: This is a choice between different filter construc= ts > to identify the portions of the datastore to be retrieved. It > acts as a node selector that specifies which data nodes are > within > the scope of the comparison and which nodes are outside the sco= pe > > --0000000000002aa01805bcce8088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 5, 2021 at 10:18 AM Rob W= ilton (rwilton) <rwilton@cisco.com<= /a>> wrote:

Hi Andy,

=C2=A0

I=E2=80=99m not sure which one you think is s = a design change:=C2=A0 Do you mean issue 3 or issue 4 below?<= /span>

=C2=A0

I see that my response to issue 4 may not have= been clear, so to clarify:

=C2=A0

By =E2=80=9Cokay=E2=80=9D, I meant, that I am = okay with how it is written in the current draft.=C2=A0 My presumption is t= hat this could be addressed as a future version of the module if this turns= out be an issue, or vendors can define their own augmentation if needed.<= /p>

=C2=A0

If you think issue 3 is a design change that r= equires WG consensus that I will leave it to the WG chairs to decide if the= y wish to issue a consensus call for it.

=C2=A0



The change:
=C2=A0=C2=A0
=C2=A0 =C2=A0Current: default is to include origin attributes and c= lient adds exclude-origin leaf to turn this off
=C2=A0 =C2=A0Prop= osed: default is to exclude origin attributes and client adds report-origin= leaf to turn this on
=C2=A0 =C2=A0 Also, report-origin has an if= -feature because origin support in NMDA is optional.

I have no objections to this proposal.
My point all along has = been that this is not my decision to make, it is a WG decision.
I= t does not seem that there are any objections to making this change.
<= div>


=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 05 March 2021 16:36
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: joel jaeggli <joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.or= g; netmod@ietf.org=
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) = <rwilton@cisco.co= m> wrote:

Hi Andy, authors,

=C2=A0

=C2=A0

=C2=A0

I think you mean to address this to the WG since the= redesign issues need WG approval.

I have no objections to any changes.=C2=A0=C2=A0<= /u>

=C2=A0

=C2=A0

Andy

=C2=A0

Sorry for the long delay in replying.<= /p>

=C2=A0

Please see [RW] inline below =E2=80=A6=

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 30 October 2020 01:43
To: joel jaeggli <joelja@gmail.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli <joelja@gmail.com>= wrote:

Rob,=C2=A0

=C2=A0

These seem like reasonable suggestions.=C2=A0=

=C2=A0

Lets see what the authors say.

=C2=A0

Thanks for this

joel

=C2=A0

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.=C2=A0 Apologies fo= r the delay.

Thank you for writing this document, I think that it is useful, and looks l= ike it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are suppo= rted by a device?=C2=A0 E.g., pointing them to either YANG library, or prot= ocol specific mechanisms in the case of RESTCONF.

=C2=A0

Do you have a section in mind and suggested text?=

[RW]

Perhaps somewhere in section 4, either as part= of the description of source, or perhaps before the parameters are describ= ed.

=C2=A0

Proposed text:

=E2=80=9CA client can discover which datastores a server supports by = reading YANG library [RFC 8525] from the operational state datastore.=E2=80= =9D

=C2=A0

=C2=A0

=C2=A0

2. It might be helpful = to add a comment about potential issues that could arise by comparing <r= unning> to <operational>, i.e., additional differences could be re= ported due to inactive configuration and template processing between <running> and <oper= ational>.

=C2=A0

Do you have a section in mind and suggested text?=

You mean if there are differences between <runnin= g> and <intended>

then a diff between <running> and <operatio= nal> will not be the same

as a diff between <intended> and <operation= al>.?

=C2=A0

[RW]

My main concern is that if you have template e= xpansion then comparing <running> and <operational> may not rea= lly give a meaningful comparison, since <running> is pre-template expansion, and <operational> (and <intended>) are both post te= mplate expansion.

=C2=A0

I would suggest putting some text in section 4= or perhaps the YANG module.

=C2=A0

Perhaps some text, something like:

=C2=A0

=C2=A0 =E2=80=9CClients should to be aware tha= t comparing <running> to <operational> will report differences = due to any configuration transformation (e.g., inactive configuration, or t= he expansion of templates) between the <running> and <intended> d= atastores.=C2=A0 In these scenarios, clients may get a more useful result b= y comparing the <intended> and <operational> datastores instead= .=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

=C2=A0

3. I would prefer if 'exclude=3Dorigin' was = in the reverse sense and perhaps called 'report-origin' instead.=C2= =A0 With the reverse sense it seems to be safer if new datastores are defin= ed, where otherwise the behaviour could end being under specified.

=C2=A0

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changed

then the draft should go back to the WG for changes = and new WG consensus calls.

[RW]

=C2=A0

I don=E2=80=99t see this as really changing th= e functional requirements, but just changing the default sense and name of = an API parameter.=C2=A0 Although, given my comments below =E2=80=9Cwith-ori= gin=E2=80=9D might be better than =E2=80=9Creport-origin=E2=80=9D.

=C2=A0

In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D= parameter is off by default, and origin metadata is only included when the= parameter is included.=C2=A0 This keyword is also under a feature.=

=C2=A0

So, changing the parameter name to =E2=80=9Cwi= th-origin=E2=80=9D and putting it under =E2=80=9Dif-feature ietf-netconf-nm= da:origin=E2=80=9D, and making the default off, would make the definition m= ore consistent with RFC 8526.

=C2=A0

=C2=A0


4. Should there be an option to filter on origin metadata?=C2=A0 E.g., only= include values that come from intended.=C2=A0 Otherwise, things like IP ad= dresses learned from DHCP may always turn up as differences.<= /p>

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changedthen the draft should go back to the WG = for changes and new WG consensus calls.

=C2=A0

[RW]

=C2=A0

Okay.

=C2=A0

Regards,

Rob

=C2=A0

=C2=A0


5. I'm not that keen on the "Possible Future Extensions" sect= ion of an RFC.=C2=A0 Personally, I would prefer that this section is delete= d, but if you wish to retain it, then please can you move it to an appendix= .

=C2=A0

OK with me to remove it

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0


I've also included some minor comments inline below, and some nits at t= he end:

=C2=A0 =C2=A0 Abstract

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines an RPC operation to compar= e management
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastores that comply with the NMDA architectur= e.

The abstract is perhaps somewhat terse.=C2=A0 Perhaps:

=C2=A0 =C2=A0 This document defines a YANG RPC operation to compare the
=C2=A0 =C2=A0 contents of network management datastores that comply with =C2=A0 =C2=A0 the NMDA architecture and return the differences in the
=C2=A0 =C2=A0 YANG-Patch format.


=C2=A0 =C2=A0 1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0 =C2=A0The revised Network Management Datastore Archite= cture (NMDA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC8342] introduces a set of new datastores tha= t each hold YANG-
=C2=A0 =C2=A0 =C2=A0 =C2=A0defined data [RFC7950] and represent a different= "viewpoint" on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that is maintained by a server.=C2=A0 New Y= ANG datastores that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0introduced include <intended>, which conta= ins validated configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that a client application intends to be in = effect, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0<operational>, which contains at least con= ceptually operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0data (such as statistics) as well as configurati= on data that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect.

I would suggest deleting "at least conceptually", since the <o= perational>
datastore does contain all operational state, but it may be implemented as = a virtual construct that spans multiple nodes (e.g., linecards) and process= es.


=C2=A0 =C2=A0 =C2=A0 =C2=A0NMDA introduces in effect a concept of "lif= ecycle" for management
=C2=A0 =C2=A0 =C2=A0 =C2=A0data, allowing to clearly distinguish between da= ta that is part of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration that was supplied by a user, confi= guration data that
=C2=A0 =C2=A0 =C2=A0 =C2=A0has actually been successfully applied and that = is part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0operational state, and overall operational state= that includes both
=C2=A0 =C2=A0 =C2=A0 =C2=A0applied configuration data as well as status and= statistics.

"allowing to clearly distinguish" =3D> distinguishing" "status and statistics" =3D> "status information and stat= istics"


=C2=A0 =C2=A0 =C2=A0 =C2=A0As a result, data from the same management model= can be reflected in
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple datastores.=C2=A0 Clients need to speci= fy the target datastore to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be specific about which viewpoint of the data th= ey want to access.
=C2=A0 =C2=A0 =C2=A0 =C2=A0This way, an application can differentiate wheth= er they are (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example) interested in the configuration that ha= s been applied and is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect, or in the configuration that= was supplied by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0client and that is supposed to be in effect.

Perhaps reword the last sentence to match the logical data flow in the serv= er:

=C2=A0 =C2=A0For example, a client application can differentiate whether th= ey are
=C2=A0 =C2=A0interested in the configuration supplied to a server and that = is
=C2=A0 =C2=A0supposed to be in effect, or the configuration that has been a= pplied and is
=C2=A0 =C2=A0actually in effect on the server.


=C2=A0 =C2=A0 =C2=A0 =C2=A0When configuration that is in effect is differen= t from configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0that was applied, many issues can result.=C2=A0 = It becomes more difficult
=C2=A0 =C2=A0 =C2=A0 =C2=A0to operate the network properly due to limited v= isibility of actual
=C2=A0 =C2=A0 =C2=A0 =C2=A0status which makes it more difficult to analyze = and understand what
=C2=A0 =C2=A0 =C2=A0 =C2=A0is going on in the network.=C2=A0 Services may b= e negatively affected (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example, breaking a service instance resulting i= n service is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0properly delivered to a customer) and network re= sources be
=C2=A0 =C2=A0 =C2=A0 =C2=A0misallocated.

Perhaps change "actual status" to "actual operational status= ".

I also suggest changing the last sentence to:

=C2=A0 =C2=A0 Services may be negatively affected (e.g., degrading or break= ing a customer service) or network resources may be misallocated.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Definitions:

It should probably define that <intended>, <operational>, (and = perhaps <running>) are used to indicate names of datastores.

It should also explain that <compare> is used as the name of a YANG R= PC.


=C2=A0 =C2=A0 4.=C2=A0 Data Model Overview

=C2=A0 =C2=A0 =C2=A0 =C2=A0At the core of the solution is a new management = operation, <compare>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0that allows to compare two datastores for the sa= me data.

Suggest rewording this first sentence to:

=C2=A0 The core of the solution is a new management operation, <compare&= gt;,
=C2=A0 that compares the data tree contents of two datastores.

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 target: The target identifies the datast= ore to compare against the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 source.

Suggest adding an example ", e.g., <operational>."

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 filter-spec: This is a choice between di= fferent filter constructs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to identify the portions of the datastor= e to be retrieved.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acts as a node selector that specifies w= hich data nodes are within
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the scope of the comparison and which no= des are outside the scope

--0000000000002aa01805bcce8088-- From nobody Sun Mar 7 12:48:23 2021 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 836E63A1C9E; Sun, 7 Mar 2021 12:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Oq2kwS9V; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MaOO7BP3 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 wNBi96k-AkUD; Sun, 7 Mar 2021 12:48:19 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F41B3A1C9D; Sun, 7 Mar 2021 12:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10374; q=dns/txt; s=iport; t=1615150099; x=1616359699; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ImSu6CychGR4l7Hv/ZbbtD2uM8uppUQ2zT31OihfCEA=; b=Oq2kwS9V33WRlE7FTJlcIIS/ay8T3UTLC6WjrPsFm4B2U6fHck1kpUoJ Xov9ZueBQK4kRmxX/jKQ27s/dpSKtAow8S1MFGQjUK52OQshXNcjW+pZZ auxdGBWSOTF9g1OlGMBwrYxluLaU4SwmYxsBKtKvUUUnlIq3hr6lYMxyo U=; IronPort-PHdr: =?us-ascii?q?9a23=3AyEZYBRbF3Got33fb9GKLDYv/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD47b7OpckKzRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutbF3VumWpqzkIFU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvCgA1O0Vg/5BdJa1YCoEJgyIjLge?= =?us-ascii?q?BUDYxCod/A4U5iFiPIIoGglMDVAsBAQENAQEyAgQBAYETAYM5AoF6AiU4EwI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBHGFYQ2HBQYBATcBEQEWKEImAQQBDQ2FPgMvAQNIoRg?= =?us-ascii?q?CiiV0gTSDBAEBBoUkGIITCYE5gnaKchyBSUKBVIcmL4NIgiuBWBJaBgI8JgE?= =?us-ascii?q?DFAQyDR41gQYBGQUGAQEBDRlJkAoCjmCaZQqCfo93jFGjbJRdnVUECyKEJgI?= =?us-ascii?q?EAgQFAg4BAQaBI0gjN4EgcBWDJFAXAg2OKxaDTYpZczgCBgoBAQMJfI0bAYE?= =?us-ascii?q?OAQE?= X-IronPort-AV: E=Sophos;i="5.81,231,1610409600"; d="scan'208";a="869611003" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Mar 2021 20:48:18 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 127KmIwn009464 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sun, 7 Mar 2021 20:48:18 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Sun, 7 Mar 2021 14:48:18 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Sun, 7 Mar 2021 14:48:17 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Sun, 7 Mar 2021 14:48:17 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HDXZ4EGc+4tcQHZfHAP5j/tC4HlvWVCSyOIBAgwi7AsgGIfTWsyR4XVgEIT8709iTZL2EjRcmiYR1+NjZzVLc+tTPUuHxrd2jP/3TchAPo5v7wa/+ZCOtqV9Cniykf+ukugbjVO8qdyZ25yGvgI1y4ADBB3/SCcu35QiSoLYZH0HY+Bv9T/S9Z5jSlsA5+CkF8tCjV/f3Bv+fT23L/lNpeAzcNNlN54rqAi5CQeXVTDB4WwPq599zKCwdUvkmoYoqJ3VckKdUF0NY97vLvExNSx4Ejgia1c8Sxs9Z3U5EfJmf6aMt28f7agvtLbYE6Llv7BjuEBMjPpyDZ6EEUJMIw== 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=arvn2OWij80eBAlV9qXLbT+OF45N6jVig5/0ZD+lJRs=; b=NYBMHxGWV1m7jMLHLnCFhY/FVgPiq0HSi+Ck+UUES35c+msGaL8SGjbhSU4mTljxFZynkObwFNSxf+rzQ2gHx316346F55xby8U1ngNy4YySLcDFs8MJnMa9FrYlq1EfV1vfWtBAiDEu5kmfReEyDL6MVG8KZ1TM1Todr8LWn9hsDg72xgQlIcsaGXh4ekBCGchYlgJh4Mp+pJNZ4KOqr1BkT8SkBKiy/bPfBuskO3+agQW8tgFBUga02lJcm2VrYfutkBnoeggfZNdJS2u+9YPR5OkHisxwF5M3K4h7cfV81J8Bnh0dOoA1wNbJAQq5mHbWcHRvigfaNNcDo2sv8Q== 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=arvn2OWij80eBAlV9qXLbT+OF45N6jVig5/0ZD+lJRs=; b=MaOO7BP33tXIjKbNLK6aJXSXTYbWBTe3H2gH2jMHkRXoryg7XRr0WzcH6j5n7lr12HmHBuCzd+G6w/6jTUcj9s9P6NlDCrVxAot0HFy140Yr9vzG2rwKcCpueTIelwWqjqgO41TtJTP8PNxfaZOUqLLeDeYGQ6M7E8pw2d2ys+s= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3490.namprd11.prod.outlook.com (2603:10b6:208:7e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Sun, 7 Mar 2021 20:48:13 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3912.027; Sun, 7 Mar 2021 20:48:13 +0000 From: "Rob Wilton (rwilton)" To: Christian Hopps , "netmod@ietf.org" CC: "draft-ietf-netmod-geo-location.all@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-geo-location-07 Thread-Index: AdcTkShqN1Smhf9ATFKg3L8WBycm5Q== Date: Sun, 7 Mar 2021 20:48:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; 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: 351fb04d-038b-4f3c-4409-08d8e1aa5388 x-ms-traffictypediagnostic: BL0PR11MB3490: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ulzQqk0E+4zOXbOVp2B3Em5/IwAwcjtGkxuwtpHw+7RTnthEhY/AX6EuMfia+VAmoSDJphR3J+AG6WwFnbsUMdbPsKniFDz552uPCxyGyt954p9kXt+oMg5B0ksuMp0b7Y3UambFJC/epjPeUM2C8ppB/a2gSSwIrMX1peiVrACZeavSrGGw7Nkt1xc6nSfxLcshMLb640pHIWByBMTYm3kFpBiN7eaWYiBSItK8ZzyJq7hnefR2EmercDQuuZMdjJQA0Anb7+APu2Ico0EUktAFKPoBpGWUHN2iLM0sYgWPPrW7CgPlJ4oUjeiiVgFF38hO1xbzmxi8hsdMHasJPXsFXn+XmzYLvt3D0RFYuSUfKyvJ4vhwGDZxjn7Vy9XV44io3egPad3chwG9uORRMZJwdnxDACKkyul9O0UZ+nTBCnYMBeB4VCdFr1k8fuxzxQgbb5JmjP1nKbNz94EnsNVy00uZ5I1l5CqWwvK4jzTUw6pVcFG+ghubnw1lzGEoiYxptQqZJ/FEyxeNXuOuhQ== 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:(136003)(346002)(376002)(39860400002)(396003)(366004)(26005)(186003)(66556008)(86362001)(8676002)(76116006)(6506007)(8936002)(66476007)(66946007)(55016002)(7696005)(4326008)(71200400001)(52536014)(83380400001)(110136005)(33656002)(316002)(5660300002)(2906002)(478600001)(9686003)(66446008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Zwba4ygti8EmsWZWAphsnjpGsmuhYt3MzUCzoB7M9lseWgz9AA1OW15dYevP?= =?us-ascii?Q?H+pvlTkGr364sxF2P1m2TMIqPH9cZG2sfw/4dOmcJCwFDDXSUvRPHr6oFTxz?= =?us-ascii?Q?RhZLDqc6qcY12BNzpXEI7IOwJB/aNDJgPlq/Rq3C6HhUJFDqcmOFzoXbHJZw?= =?us-ascii?Q?5HRKAP7xAuBGoiOvBWhZMoYO85WMZsH9Z4fm2Oh3nttOc1VbWrg/1xgkrm0h?= =?us-ascii?Q?/Sg5rH3/JJZWdq+27t2Bp68b87v9ySaPWCZxF91zC2ahwvS1uHXpaeF7nkqK?= =?us-ascii?Q?HK5iExpwxtOkMhGZa6PQ8DOx2dLpx2vlXoDhbB7VlAo2q0X7vAXpRk9bH8K1?= =?us-ascii?Q?sX7AkqnJGEaun+Y7BeCdsG1nLSNFd4Yul+j7RuowBYU5bo1ubw5NQXgdPz4H?= =?us-ascii?Q?Dnx4H2a5jZIApa6QXswPXj4J1EqDTDNdgfolOyNFZ6h1Ze52stf6Yz8zb05Q?= =?us-ascii?Q?JvsyGaqjnwpoO/KqhBt6B7KzhNpsAX32ZJOyb/c1HczikPj3iHuNnbmzqGE+?= =?us-ascii?Q?e3sFqD7vJtw+cF55FOmj2nV2fQBoQ2favPrh1J8qsP0q6iVu38mn0pwMroEF?= =?us-ascii?Q?OeWuOZoHz+8510jaOppzGo28B8T2aOHUQzimt6aRfL9wVlbc82gA5QgwIkNQ?= =?us-ascii?Q?FbySzPJpwi+JchMVKBlXV01vRNRvE3PcUQai8W/TOyxi7j4hxlQgV0JD/pDD?= =?us-ascii?Q?zu3Ez2cKId3hqsmF3qCLqnAG1Xi36k+sGI2aqlWUDl97sGYqgsSiTQDZuC1+?= =?us-ascii?Q?g3uNaTqJnJgN3qatG+pDl9rXi6kTvCyhCzVtZC5sHlBJfmi39auUAdKfaSZa?= =?us-ascii?Q?XOQ5HC2e6tNqbyRYL76Fi+nH+uisdVTE+8w+vSfYVMeCOl6IQjSsK/UBHm6x?= =?us-ascii?Q?R5iuJm63T3r1OSjE7R0GxqmJtpnRAVf2P7SeVaEcILrb4sgajfYy6/dNG5LL?= =?us-ascii?Q?1ohpehRDaHh+UlDYkKElj65qmAZ+47gMSU8ZWx0+F8SPvgbmAsCk5XQUBuzu?= =?us-ascii?Q?YKdwM6+DhJpF5j6HPHb7dzjurGRczcDIcOgRw8Qw/0hgF7mSOpJz+C+66Gs0?= =?us-ascii?Q?zkwXDHAd2ehZTF9gt1wv5wya2XhRQO8ZKfgi2+FPeAqMs2XZlv9gH7103xm3?= =?us-ascii?Q?nJKJVzhwLzDlL+9WpHGeZvGOCBdIECELqXplv0ftxG8WNkFz5zqSXZvaWYEK?= =?us-ascii?Q?zNuEbOC+RiDSBJE9AezEioKzUgaZhfAMM6FohHhCLJi3D7BraN/tT2JqGDcl?= =?us-ascii?Q?fuAdeu9u+HNxZS73nkyH6de9atraaPgKjOPYvKDAjFNtPwNn/agG8QzngTdV?= =?us-ascii?Q?T8iDOUrUPbzS+H8d5LT91cP5?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" 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: 351fb04d-038b-4f3c-4409-08d8e1aa5388 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2021 20:48:13.4084 (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: /5A9JHyv2scODQ1V3fOg4vGsvWVF6a4G51T711w4jbZMQLuDhIETY/pEdz5UPor4xBOj0oHMSfKyiZJp1hpZfQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3490 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: [netmod] AD review of draft-ietf-netmod-geo-location-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 20:48:22 -0000 Hi Chris, Apologies for the delayed AD review of this document. I found that this document to be interesting, enlightening, and well writte= n, so thank you. I only have a few minor comments, the rest are grammatical nits. Some I spo= tted manually; the rest are from a beta version of a grammar tool that I am= playing with. Minor comments/questions: 1. In the YANG module, the pattern statements have 3 ranges of characters, but the description only indicates two ranges. Is there a reason that the following pattern doesn't work? pattern '[ -@\[-~]*'; 2. I note that the YANG module allows just a lat, or a long, or a height to be specified, rather than requiring at least a pair of lat/long or x/y coordinates. I think that this is fine (and keeps the model flexible), but wanted to check that this is the intentional. 3. I also note that that grouping doesn't require that any coordinates be specified at all. I presume that this is intentional, it makes sense to me (e.g., if it is intended to be optional). 4. In the YANG module, "v-east is the rate of change (i.e., speed) perpendicular to truth-north as defined by the geodetic-system."; As a nit, this doesn't actually define whether a positive v-east value is in the East or West direction. I appreciate that this is obvious, but for the other two components in the vector, it is unambiguously specified. 5. In Security Considerations: Since the grouping defined in this module identifies locations, authors using this grouping SHOULD consider any privacy issues that may arise when the data is readable. Perhaps, expand this paragraph to give an example, e.g., revealing the physical location of a device, or data center. The rest are just grammar nits: In addition to identifying the astronomical body we also need to define the meaning of the coordinates =3D> In addition to identifying the astronomical body, we also need to define the meaning of the coordinates In addition to the "geodetic-datum" value we allow refining the coordinate and height accuracy using "coord-accuracy" and "height- accuracy" respectively. =3D> In addition to the "geodetic-datum" value, we allow refinement of the coordinate and height accuracy using "coord-accuracy" and "height- accuracy" respectively. This is the location on or relative to the astronomical object. It is specified using 2 or 3 coordinates values. =3D> This is the location on, or relative to, the astronomical object. It is specified using 2 or 3 coordinates values. The intent of the grouping being defined here is to identify where something is located, and generally this is expected to be somewhere on or relative to Earth (or another astronomical body). =3D> The intent of the grouping being defined here is to identify where something is located, and generally this is expected to be somewhere on, or relative to, Earth (or another astronomical body). At least two options are available to YANG models that wish to use this grouping with objects that are changing location frequently in non- simple ways, they can add additional motion data to their model directly, or if the application allows it can require more frequent queries to keep the location data current. =3D> At least two options are available to YANG models that wish to use this grouping with objects that are changing location frequently in non- simple ways. They can add additional motion data to their model directly. Or, if the application allows, it can require more frequent queries to keep the location data current. When coord-accuracy is specified it overrides the geodetic-datum implied accuracy. =3D> When coord-accuracy is specified, it overrides the geodetic-datum implied accuracy. When specified it overrides the geodetic-datum implied default. =3D> When specified, it overrides the geodetic-datum implied default.=20 indicated by the reference-frame value. =3D> indicated by the reference-frame. For a formula to convert these values to speed and heading see this modules defining document RFC XXXX."; =3D> For a formula to convert these values to speed and heading see RFC XXXX."; You have "truth-north" and "truth north" and "true-north". Should these all be "true north"? YANG grouping using decimal64 values rather than strings. For the relative height cases the application doing the transformation is expected to have the data available to transform the relative height into an absolute height which can then be expressed using the YANG grouping. =3D> YANG grouping using decimal64 values rather than strings. For the relative height cases, the application doing the transformation is expected to have the data available to transform the relative height into an absolute height, which can then be expressed using the YANG grouping. Grammar Warnings (generated by a tool): Draft Text: Indeed it is easy to imagine a network or device located on The Moon, on Ma= rs, on Enceladus (the moon of Saturn) or even a comet (e.g., 67p/churyumov-= gerasimenko). Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Indeed," Draft Text: This document defines a "geo-location" YANG grouping that allows for all of= the above data to be captured. Warning: Consider using all the. Suggested change: "all the" Draft Text: When specified these values override the defaults implied by the "geodetic-= datum" value. Warning: "When" at the beginning of a sentence usually requires a 2nd clau= se. Maybe a comma, question or exclamation mark is missing, or the sentence= is incomplete and should be joined with the following sentence. Suggested change: "When specified, " Draft Text: In both choices the exact meanings of all of the values are defined by the = "geodetic-datum" value in the [xref]. Warning: Consider using all the. Suggested change: "all the" Draft Text: During the development of this module, the question of whether it would sup= port data such as orientation arose.=20 Warning: Wordiness: Consider shortening this phrase. Suggested change: "whether" Draft Text: For test "A.1.2.1" the YANG geo location object either includes a CRS ("ref= erence-frame") or has a default defined ([xref]). Warning: This word is normally spelled as one. Suggested change: "geolocation" Draft Text: Many systems make use of geo-location data, and so it's important to be abl= e describe this data using this geo-location object defined in this documen= t. Warning: The preposition 'to' is required in front of the verb 'describe'. Suggested change: "able to describe" Draft Text: For accuracy it has a single "u" parameter for specifying uncertainty.=20 Warning: The comma is probably missing here: accuracy, it. Suggested change: "accuracy, it" Draft Text: This is used by many application (e.g., Google Maps API). Warning: Possible agreement error. The noun application seems to be counta= ble; consider using: many applications. Suggested change: "many applications" Draft Text: Thus GML "gml:pos" values can be mapped directly to the YANG grouping, with= the caveat that some loss of precision (in the extremes) may occur due to = the YANG grouping using decimal64 values rather than doubles. Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Thus," Draft Text: Furthermore "gml:validTime" can either be an Instantaneous measure ("gml:Ti= meInstant") or a time period ("gml:TimePeriod").=20 Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Furthermore," Draft Text: As with the "kml:altitudeMode" value, the YANG grouping supports the ignore= case but not the relative case. Warning: After 'the', do not use a verb. Make sure that the spelling of 'i= gnore' is correct. If 'ignore' is the first word in a compound adjective, u= se a hyphen between the two words. Note: This error message can occur if yo= u use a verb as a noun, and the word is not a noun in standard English. Draft Text: Thus the YANG grouping and KML values can be directly mapped in both direct= ions (when using a supported altitude mode) with the caveat that some loss = of precision (in the extremes) may occur due to the YANG grouping using dec= imal64 values rather than strings.=20 Warning: Did you forget a comma after a conjunctive/linking adverb? Suggested change: "Thus," Draft Text: The allocation policy for this registry is First Come First Served, [xref] = as the intent is simply to avoid duplicate values. Warning: It seems that a comma is missing. Suggested change: "Come," Draft Text: All of the data nodes defined in this YANG module are writable/creatable/de= letable (i.e., "config true", which is the default).=20 Warning: Consider using all the. Suggested change: "All the" Draft Text: These are the subtrees and data nodes and their sensitivity/vulnerability: None of the writable/creatable/deletable data nodes in the YANG module defi= ned in this document are by themselves considered more sensitive or vulnera= ble then standard configuration. Warning: Did you mean than? Suggested change: "than" Draft Text: Some of the readable data nodes in this YANG module may be considered sensi= tive or vulnerable in some network environments.=20 Warning: If the text is a generality, 'of the' is not necessary. Suggested change: "Some" Draft Text: Below is a the YANG tree for the fictitious module that uses the geo-locati= on grouping. Warning: Maybe you need to remove one determiner so that only a or the is = left. Suggested change: "a" Draft Text: We would also like to thank Peter Lothberg for the motivation as well as he= lp in defining a broadly useful geographic location object, and Acee Lindem= and Qin Wu for their work on a geographic location object that led to this= documents creation. Warning: Possible typo: apostrophe is missing. Did you mean documents' or = document's? Suggested change: "documents'" Regards, Rob From nobody Mon Mar 8 03:58:33 2021 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 AC9AC3A0C99 for ; Mon, 8 Mar 2021 03:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGdulGGKJDnA for ; Mon, 8 Mar 2021 03:58:30 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2101.outbound.protection.outlook.com [40.107.20.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3513A0C88 for ; Mon, 8 Mar 2021 03:58:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gy7UTJhoEV6UjJsvL7lcTNVsKJq2IRaah4/BH4DpCDLbM5IBJZwJbrAvXNANT0i/t5fJjYN6AWTbWIl6qF2VkpX+0dxxbdDCrLWxbzBiayvldqdqH/nLu+thlLTHiZftglWLLGdJEMKewhuYPHxmd8vgMcUm7SjeoDxRyeM/WtC0rv1FTwI1DD1Q1Q5B0IhiARFGGyCNq1YJeqeaGoypATCZGHSF1M7djJhEJkIWcTQ2PDlmGn8yGFWh39L/ywUWGmSg1eK2JHVT3VtnrfBwLVK1BKXkbUAURc+G3HLhQCXCWWxazMIE0K9af8M6/wuQESYGJ+DzYLloKyReEk0j6A== 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=lJPUeYcQ6ZDpgnab9Z5K3sKSgK/Kna+eAvaDwSl95N4=; b=DKb1CemJdJTons/OIMqNDb6WyJSV3RLpDlAZnEmiX0FJ7C6vNSuK+UF6gR9G95YoABwMC4ayfttuyAaG8GAhWPP0sUX1Z5bjxub14akkXPaDs6a04/l4AoeEyDd3+IycVNz9GoXgmmL/jVjGSCYUeYl/fGJP4ZaLkEuGBQPlZZK+8tRgxRcskdN4bDv8UlOfRRieZTLn4hOQUsoAgGff31WVGrf/pAPE5C099ATXAtk/ZFdqNEt4PJehsADHt5LzxnClC4XJt7Y7w5cGAa2iW2D3HfD6kA4qQvs08kA+rbGa6xCZykPsgAtNs14XB1H546/CCPt1NzHvHTY7A2zgsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lJPUeYcQ6ZDpgnab9Z5K3sKSgK/Kna+eAvaDwSl95N4=; b=xwtnZIZPEVq3ymFOWfFY8/W2a7NVfTtEGx2uOY0xBBbKcVeYDBCe9hRNYgW0XPgotDIsC5qKE+6KJijnF1f3xp/j2dEHlTjMNw8OTD29UdzzbPORux1jvtcGTc9LWm6AgWOwIXoDcDUEfCWLBoSp2yI/sFDsvIwKB9/WNeVVvE4= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5107.eurprd07.prod.outlook.com (2603:10a6:20b:5e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Mon, 8 Mar 2021 11:58:26 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::8115:3afd:18f6:c6d1]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::8115:3afd:18f6:c6d1%8]) with mapi id 15.20.3912.026; Mon, 8 Mar 2021 11:58:26 +0000 From: tom petch To: "Rob Wilton (rwilton)" , Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts Thread-Index: AdcQG/9VJO5KypwRTzuE8gHDegltpgAC2hYAAGEt/zAAmULO3Q== Date: Mon, 8 Mar 2021 11:58:26 +0000 Message-ID: References: <87sg5cxwed.fsf@nic.cz>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b4bbf267-c1ef-4364-caff-08d8e2297b9c x-ms-traffictypediagnostic: AM6PR07MB5107: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XNStaY9mMhJXo7b9FyxhYUK/HV1S8e0nBEYBxWnfuyP/yMQJMSwvh6j1PfrMzyG1Tf7xhBUq9Copks2sqeYz99ODVtehNC56T1v+ADj7t5pV5jnVGpKqCVGoG1/L7XGmeW/iBRfktpBPAzXOwDR5HryLwSfZio3paUvZa5pbdZV442Njh4lg008Rs7OiRHImpXIeUhPg7ZVN7TlV4ojY+o3VBB0wxPJxXwpxB9WRVj3rmwFTEh9k3GZikykLEiGV9ohdRocqN4PEwJh9ZuT24pue0m2T9AXXMUZEvtB/aS3B1hzzohJC3uTfuaAhfDWFGC+w26vT2JQ8OY/r0yjwmzdMBfVqAKgbK2QEuy058UJmzTEtz9I29Zzq22AdHX7jPlbamHM5QRP10xaoQ/oeZBr8TgMOHn1bDLUf4KqiYIG0icEu25vcH7+Sne1T8dtOBqlQ9TkbqOfgmqOubzLq73oK6kgVoxwr7pPXCu2FbpCHXwiVfmetAmWrOxSNhnJxYhcYZyJu+8WWgIcc2F2vk4AMohrtfmRYCY0zARnPCdvZXLJNueYJfdpquJKcoVeYicP/o6Wiub5EY3GaJRKcgQ3Zv22wUurqF4bkvB0y8UM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(26005)(9686003)(110136005)(53546011)(8676002)(76116006)(30864003)(2906002)(7696005)(71200400001)(966005)(66476007)(6506007)(498600001)(66446008)(52536014)(64756008)(66946007)(91956017)(5660300002)(83380400001)(66556008)(4001150100001)(186003)(8936002)(33656002)(55016002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?VhZhoj+Zeo7DEc9TayXUXfFMH4wRnrPK0E+f26woDinWnb+MqVUUn9zbX9?= =?iso-8859-1?Q?EIyPHG1XsqUGvONGagU7kRAXXx9IgDHWDvH8siaLqxbVZrXQgY047Z2IKk?= =?iso-8859-1?Q?KjYqETe1Lb3aQXtG2oiHRiznVCCS+CZX7s+tf0auowcrvykrCQuMsDiyVH?= =?iso-8859-1?Q?lmlvSan9fhsqMokjrJJEAxqQtmLVINDVkWjK5YCSnxqRc6Iok6XKmVHigX?= =?iso-8859-1?Q?12EAqTrOerERnyyfuUz5Ij391HxbS4ikVONZ+FW9PQuFj2IwBCrAktP5qp?= =?iso-8859-1?Q?yTPqDOz7eWwREjYyP6HpBq/BxEgdI8cydTlcHN7HO4pm2DEaWvl/mROOn/?= =?iso-8859-1?Q?/Jdc2cTJYoktJUUSYq9Y2+DwUHpLDz9Rkuf6svkRf4HU6kvzA5ON0uMFwj?= =?iso-8859-1?Q?a8nYKe7expw8+TC3fQ1JeXgKKR/edNAHZnVjXyz+CI9bXCk57yJftulh3e?= =?iso-8859-1?Q?Vp5gramTNpiEOKJARWgGPN6jfmLc2exybIOLEfFapuvpZTkPfpF6+gRWzt?= =?iso-8859-1?Q?75F9SGjJtGXCVOJMIT9oSfQtRvlVc5aV1zojJKP/8YZdXVhXYzSkionCaS?= =?iso-8859-1?Q?zH5+/0zwq7iLIVftl1mB3Kz3ajn66r9CrLUj+J0W0pA+BlY6HkHIDcr4QC?= =?iso-8859-1?Q?YqktUuKqxSj9I5aYrg5t9g0OzKNiFwDRMghIYOQr0zRY5RJMTTu809VEJ8?= =?iso-8859-1?Q?zBWDPiAEzqLnrRGgYsLh72d6ZNdufvqGSTOg0CtEdKo+3RzJPMd5+tb/jC?= =?iso-8859-1?Q?WzXKj6aorD06Ul/9SSuriZyRESqKoeYjUjeWiogQ0XvOicyWwym7a9hSK0?= =?iso-8859-1?Q?R9JyGm+JPDyi+zMEq+VkDqVL+B/RJwJPm0WVtDi8fJvZ2Ve9Mops67B21E?= =?iso-8859-1?Q?SFUZTdVQaghOfnMMkOqeDHS0qvfss9ripVrRNAW46wNhnjvEgZdz2iDdMA?= =?iso-8859-1?Q?tbxzkBQu+xRUNjELXlRo5pUbE3r6UF1cHoIsynu8mc0byRQfQne9Y9Xo6F?= =?iso-8859-1?Q?brp4gCAZ8wO9MTzO7AyvZNUpo/x5QRajPpkX3ze2n8zNIleHNuwcuhxaWH?= =?iso-8859-1?Q?OkXjXelLegM20jjtaP8sn94R5ed2q2pllycXvJaOubkPbMAQMqJETtH63h?= =?iso-8859-1?Q?YAv3QQrkoQwoxJde69Ig9sSl3CHWNNtRWNaau7H6m0ifJuGJ/Eq/3Asnyc?= =?iso-8859-1?Q?ypW+2SP5ZuVL9b6mIAkXz7Sedikh6tW7kfTmTcF09R80gXfyGH/3JtN6/h?= =?iso-8859-1?Q?ZCons2IPGR5gnPCUnyC0sFIllMtn357+xyTMoQKPasLBkXcj0P36VlzxEf?= =?iso-8859-1?Q?ZWAJQBIOfLTNtWFlmWVFy+FktxZVU24QgYQraXSQJtBoCgk=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4bbf267-c1ef-4364-caff-08d8e2297b9c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2021 11:58:26.7578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yBWMOfqZbuby4bHi56xzcr8zBg+UTZMtRgNfm5JNhFg0JqvRWjeU9QL5Cke1Frpc1j2MnuWm4jF/kSYeYTeUxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5107 Archived-At: Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 11:58:33 -0000 From: netmod on behalf of Rob Wilton (rwilton) =0A= Sent: 05 March 2021 12:23=0A= =0A= Hi Lada,=0A= =0A= Thanks for the feedback. I agree that we should think about this.=0A= =0A= Looking at those slides, it also asks the question as to whether a YANG fil= e derived from an IANA registry entry should ever differ. I agree with the= answer proposed in those slides: I.e., the two should always be kept in sy= nc, even if that ends causing a non-backwards-compatible change to the YANG= module.=0A= =0A= But my question is whether we should add any text to the IANA section of th= is document to make this explicit?=0A= =0A= =0A= Regarding your second issue:=0A= =0A= I agree that unifying the definitions between IANA and YANG would be ideal,= but I'm not sure whether that will be feasible in the short term.=0A= =0A= =0A= I think that it is safe to say that that will never be feasible.=0A= =0A= Code - SMI, YANG ... - needs the concept of backwards compatible to protec= t users and others, which is why it has existed for decades even if the det= ails are a bit flakey.=0A= =0A= IANA Registries have no such concept and lack the need for one. Look in va= in in RFC8126 for any constraint on changes that can be made, changes that = would be ruinous for YANG.=0A= =0A= So the first step is to come up with rules for what changes to an IANA Regi= stry come in which category and I am not optimistic that the IETF will ever= reach consensus on that. In which case the rules for YANG will never be i= n line.=0A= =0A= Tom Petch=0A= =0A= =0A= draft-ietf-netmod-yang-module-versioning-02 tries to encourage stricter YAN= G definitions of deprecated and obsolete (both in the rules defining what i= s backwards compatible, and also new YANG library leaves to advertise that = the server conforms to the stricter behaviour):=0A= =0A= I.e., the behaviour that it is trying to encourage is:=0A= - deprecated nodes must be implemented (just like status current nodes), = or otherwise explicitly deviated if they are not supported.=0A= - obsolete nodes must not be implemented.=0A= =0A= The reason that stricter semantics are proposed is so that the client can k= now the exact schema supported by the server rather than having to guess wh= ether or not deprecated or obsolete nodes are implemented.=0A= =0A= I read the IANA definition of deprecated as being "SHOULD NOT implement", a= nd YANG doesn't today have a status value that maps well to. In particular= , YANG doesn't currently have a way to express to a client that a deprecate= d node that "should not be implemented" actually is still implemented by a = server. E.g., the reverse semantics of "deviate not-supported".=0A= =0A= Hence, I wonder YANG shouldn't end up with 4 levels of status (better name = required for 'really-deprecated'):=0A= =0A= (1) "current": Current. Must implement or deviate not-supported= =0A= (2) "deprecated": Going away. Should implement, but may deviate not= -supported=0A= (3) "really-deprecated": Really going away. Should not implement, but may= deviate to indicate it is still supported.=0A= (4) "obsolete": Dead. Must not implement. Cannot deviate.=0A= =0A= Note, that a separate status "experimental" has been proposed previously as= an addition for YANG Next, tracked by https://github.com/netmod-wg/yang-ne= xt/issues/59=0A= =0A= The IANA version of "deprecated" would map to (3) "really-deprecated" in YA= NG, whilst the IANA definition of "obsolete" matches the YANG definition of= "obsolete".=0A= =0A= But this can't really be solved until we have a new revision of YANG.=0A= =0A= Rob=0A= =0A= =0A= > -----Original Message-----=0A= > From: netmod On Behalf Of Ladislav Lhotka=0A= > Sent: 03 March 2021 12:19=0A= > To: Rob Wilton (rwilton) ;=0A= > netmod@ietf.org=0A= > Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and= =0A= > Semver Drafts=0A= >=0A= > Hi Rob,=0A= >=0A= > I don't know whether this has been discussed, but one issue that might=0A= > need to be addressed is the difference between IANA and YANG in the=0A= > definitions of "obsolete" and "deprecated" - the details are here (slide= =0A= > 5):=0A= >=0A= > https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa= -=0A= > yang-types-for-dns-classes-and-resource-record-types-00=0A= >=0A= > The best solution would be to unify the definitions. If this is not=0A= > possible (in a short term), then it is IMO necessary to mark an entry tha= t=0A= > is made obsolete or deprecated in an IANA registry as "obsolete" in the= =0A= > YANG module.=0A= >=0A= > Lada=0A= >=0A= > "Rob Wilton \(rwilton\)" writes:= =0A= >=0A= > > Hi,=0A= > >=0A= > > // As an individual contributor=0A= > >=0A= > > We discussed proposed IANA text at the last NETMOD interim on the YANG= =0A= > versioning work. Tracked by issue https://github.com/netmod-wg/yang-ver-= =0A= > dt/issues/59=0A= > >=0A= > > I had the action of updating the text based on comments received in the= =0A= > interim meeting and then sending that text to the list.=0A= > >=0A= > > The proposed text is below (that is in the current published versions o= f=0A= > both drafts). If the WG has no objections to this text, then the planned= =0A= > next step is to ask IANA for an early review of this text.=0A= > >=0A= > >=0A= > > IANA section in draft-ietf-netmod-yang-module-versioning-02:=0A= > >=0A= > > 11.2. Guidance for versioning in IANA maintained YANG modules=0A= > >=0A= > > Note for IANA (to be removed by the RFC editor): Please check that= =0A= > > the registries and IANA YANG modules are referenced in the=0A= > > appropriate way.=0A= > >=0A= > > IANA is responsible for maintaining and versioning YANG modules that= =0A= > > are derived from other IANA registries. For example, "iana-if-=0A= > > type.yang" [IfTypeYang] is derived from the "Interface Types (ifType= )=0A= > > IANA registry" [IfTypesReg], and "iana-routing-types.yang"=0A= > > [RoutingTypesYang] is derived from the "Address Family Numbers"=0A= > > [AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI)=0A= > > Parameters" [SAFIReg] IANA registries.=0A= > >=0A= > > Normally, updates to the registries cause any derived YANG modules t= o=0A= > > be updated in a backwards-compatible way, but there are some cases= =0A= > > where the registry updates can cause non-backward-compatible updates= =0A= > > to the derived YANG module. An example of such an update is the=0A= > > 2020-12-31 revision of iana-routing-types.yang=0A= > >=0A= > > [RoutingTypesDecRevision], where the enum name for two SAFI values= =0A= > > was changed.=0A= > >=0A= > > In all cases, IANA MUST follow the versioning guidance specified in= =0A= > > Section 3.1, and MUST include a "rev:nbc-changes" substatement to th= e=0A= > > latest revision statement whenever an IANA maintained module is=0A= > > updated in a non-backwards-compatible way, as described in=0A= > > Section 3.2.=0A= > >=0A= > > Note: For published IANA maintained YANG modules that contain non-= =0A= > > backwards-compatible changes between revisions, a new revision shoul= d=0A= > > be published with the "rev:nbc-changes" substatement retrospectively= =0A= > > added to any revisions containing non-backwards-compatible changes.= =0A= > >=0A= > > Non normative examples of updates to enumeration types in IANA=0A= > > maintained modules that would be classified as non-backwards-=0A= > > compatible changes are: Changing the status of an enumeration typede= f=0A= > > to obsolete, changing the status of an enum entry to obsolete,=0A= > > removing an enum entry, changing the identifier of an enum entry, or= =0A= > > changing the described meaning of an enum entry.=0A= > >=0A= > > Non normative examples of updates to enumeration types in IANA=0A= > > maintained modules that would be classified as backwards-compatible= =0A= > > changes are: Adding a new enum entry to the end of the enumeration,= =0A= > > changing the status or an enum entry to deprecated, or improving the= =0A= > > description of an enumeration that does not change its defined=0A= > > meaning.=0A= > >=0A= > > Non normative examples of updates to identity types in IANA=0A= > > maintained modules that would be classified as non-backwards-=0A= > > compatible changes are: Changing the status of an identity to=0A= > > obsolete, removing an identity, renaming an identity, or changing th= e=0A= > > described meaning of an identity.=0A= > >=0A= > > Non normative examples of updates to identity types in IANA=0A= > > maintained modules that would be classified as backwards-compatible= =0A= > > changes are: Adding a new identity, changing the status or an=0A= > > identity to deprecated, or improving the description of an identity= =0A= > > that does not change its defined meaning.=0A= > >=0A= > > IANA section for draft-ietf-netmod-yang-semver-02=0A= > >=0A= > > 9.2. Guidance for YANG Semver in IANA maintained YANG modules=0A= > >=0A= > > Note for IANA (to be removed by the RFC editor): Please check that= =0A= > > the registries and IANA YANG modules are referenced in the=0A= > > appropriate way.=0A= > >=0A= > > IANA is responsible for maintaining and versioning some YANG modules= ,=0A= > > e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang=0A= > > [RoutingTypesYang] .=0A= > >=0A= > > In addition to following the rules specified in the IANA=0A= > > Considerations section of [I-D.ietf-netmod-yang-module-versioning] ,= =0A= > > IANA maintained YANG modules MUST also include a YANG Semver revisio= n=0A= > > label for all new revisions, as defined in Section 3 .=0A= > >=0A= > > The YANG Semver version associated with the new revision MUST follow= =0A= > > the rules defined in Section 3.3 .=0A= > >=0A= > > Note: For IANA maintained YANG modules that have already been=0A= > > published, revision labels MUST be retrospectively applied to all=0A= > > existing revisions when the next new revision is created, starting a= t=0A= > > version "1.0.0" for the initial published revision, and then=0A= > > incrementing according to the YANG Semver version rules specified in= =0A= > > Section 3.3 .=0A= > >=0A= > > Most changes to IANA maintained YANG modules are expected to be=0A= > > backwards-compatible changes and classified as MINOR version changes= .=0A= > > The PATCH version may be incremented instead when only editorial=0A= > > changes are made, and the MAJOR version would be incremented if non-= =0A= > > backwards-compatible major changes are made.=0A= > >=0A= > > Given that IANA maintained YANG modules are versioned with a linear= =0A= > > history, it is anticipated that it should not be necessary to use th= e=0A= > > "_compatible" or "_non_compatible" modifiers to the "Z_COMPAT"=0A= > > version element.=0A= > >=0A= > > Comments welcome.=0A= > >=0A= > > Thanks,=0A= > > Rob=0A= > >=0A= > > _______________________________________________=0A= > > netmod mailing list=0A= > > netmod@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/netmod=0A= >=0A= > --=0A= > Ladislav Lhotka=0A= > Head, CZ.NIC Labs=0A= > PGP Key ID: 0xB8F92B08A9F76C67=0A= >=0A= > _______________________________________________=0A= > netmod mailing list=0A= > netmod@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netmod=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Mon Mar 8 12:19:47 2021 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 F32393A16AA for ; Mon, 8 Mar 2021 12:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NyQJFPI0M2En for ; Mon, 8 Mar 2021 12:19:43 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99603A16A7 for ; Mon, 8 Mar 2021 12:19:42 -0800 (PST) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DvV0T30p1z67sZC; Tue, 9 Mar 2021 04:13:45 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Mar 2021 21:19:39 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Mon, 8 Mar 2021 21:19:39 +0100 From: Italo Busi To: 'Juergen Schoenwaelder' CC: "'netmod@ietf.org'" Thread-Topic: [netmod] Questions about how to assign default values with YANG Thread-Index: AdbvCmZgzen+a6G4QWicT/glaRAynP///QGA///e3yCAAEHcAP//waGggACHKYD/tcyd8A== Date: Mon, 8 Mar 2021 20:19:39 +0000 Message-ID: <521a9ccd02e14d178a6e62971b4809ea@huawei.com> References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> In-Reply-To: <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.24.210] Content-Type: multipart/alternative; boundary="_000_521a9ccd02e14d178a6e62971b4809eahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:19:46 -0000 --_000_521a9ccd02e14d178a6e62971b4809eahuaweicom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Juergen, Thanks again for your clear explanation on this topic I have found a similar but slightly different issue. In this case, a YANG d= efault statement exists in the base module but the intention with the augme= ntation is to "overwrite" the default value on the basis of another attribu= te, defined in the module which augments the base module. For example, I am wondering whether such a code is valid: module example-base { container example { leaf foo { type uint8; default 0; } } } module example-augment { import example { prefix ex; } augment "ex:example" { leaf bar { type empty; description "When present, the default value for foo is 10."; } } } In this case, when the leaf foo is not configured but the leaf bar is prese= nt, the value of foo in the operational datastore should be 10 (rather than= 0). In this case, I think that it would be better/cleaner if the origin is mark= ed as system. Maybe a better YANG description for bar could be: "When present, the system= overrides the default value of foo to 10." What is your and/or WG opinion? Thanks again Italo > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: mercoled=EC 20 gennaio 2021 17:05 > To: Italo Busi > Cc: 'netmod@ietf.org' > Subject: Re: [netmod] Questions about how to assign default values with > YANG > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > > > What about the case the leaf is not conditional (but still mandatory fa= lse > since a YANG default statement is defined)? > > > > May the server still decide not to use/implement this leaf in the opera= tional > datastore? > > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by > default. > > What should be the behavior of a system which does not implement auto- > negotiation? > > Return the value false or no value (in the operational datastore)? > > > > Here are some of the rules I personally like: > > - is the ground truth about what a system has and does > - do not implement leafs that do not apply > > Hence, interfaces supporting auto-negotiation have either auto- > negotiation/enabled =3D true or auto-negotiation/enabled =3D false in > . And interfaces not supporting auto-negotiation have nothin= g > to report about auto-negotiation. Yes, I do not want to see auto- > negotiation/enabled =3D false on a loopback interface. > > My historic Ethernet interface from the last century would also not repor= t > auto-negotiation/enabled in . You may hit applications that = love > to have auto-negotiation/enabled available on all Ethernet interfaces and= then > you end in a debate where the application developers tell you that no > information in may have many reasons (instrumentation not > implemented, access control rules, whatever and by reporting enabled=3Dfa= lse > you do them a favor) but the true answer in such a debate is often that > modeling things as a boolean is simplistic since there are often more tha= n > exactly two states (in this case, enabled, disabled, failed, not-availabl= e, ...). > So you settle on blaming the model writer. ;-) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --_000_521a9ccd02e14d178a6e62971b4809eahuaweicom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Juergen,
 
Thanks again for your clear explanation on this topic
 
I have found a similar but slightly different issue. In this case, a Y= ANG default statement exists in the base module but the intention with the = augmentation is to "overwrite" the default value on the basis of = another attribute, defined in the module which augments the base module.
 
For example, I am wondering whether such a code is valid:
 
module example-base {
  container example {=
    <= font color=3D"#C586C0">leaf<= /font> foo {
     &n= bsp;= type uint8;
     &n= bsp;= default 0;
    }=
  }
}
 
module example-augment {
  import example {
    <= font color=3D"#C586C0">prefix ex;
  }
 
 --000000000000bb224305bdbfebe4-- From nobody Wed Mar 17 12:45:21 2021 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 CC3DB3A1282 for ; Wed, 17 Mar 2021 12:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QetslVqfRnJ for ; Wed, 17 Mar 2021 12:45:18 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3AB3A1281 for ; Wed, 17 Mar 2021 12:45:17 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id j3so3734132edp.11 for ; Wed, 17 Mar 2021 12:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lvIxcdb2K+KGcA6Js0cHHnbbQKSqmQAMvenFP6mC2kg=; b=bTyuYJ4oVVSUTBCiI/HznDJZxhJMDahGd01eM6VX2StoGewKy2DyP6g1hX8xZwggGC FMKeTWNSEWY1EpfxMETCNUkgPu/TtI81u758nYpfIsWPUj+sHRLtFlrhR69m/q67OU/g CXrT52/fJmRsrjeOHdl4WUusthfwAEcXMPFPbLwKqw2wq1nuBh6Zhd0gwRjHVfiB0VqQ Pc2fs+Vg82HCfLXcdWi490ROm3hk2xX65dGT4xe3aAzkM1lrt1E0H6+RiQZA1ThXM/XB qHyxgayj57D1J+7k7PnMgEfYilBVQGPlB2ZmxUKUEAmfOPLx5V5dnpJLJqM13Vbmv+MN lgGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lvIxcdb2K+KGcA6Js0cHHnbbQKSqmQAMvenFP6mC2kg=; b=bgbVSpZm0WfgvwWozSHulqYOEQQbPHYtnAQ6F/WAm1f4bkEV0Mer1S6c/tPUDpmsca Y4lhg99KxnAt/tF1zAGZXjpuZm13YGZMOEHTTCSSWZ9sQGauBE03jJrSPXTR95KzY6jJ mSgPyCqsOsnVUBfckoHuADmBZreA1iRIUCgNRUgAwK+vnHdJBUyRXX2dky39v/Jte1WD qIgmVufZPQKKOC10t0vW5kqwqB1KpMbvmpFf5P7zI2j6FkB6s+TP7uY3lSwKF7f9czYb 11ofm44snpQ1/AlQ9jWc87YAm5AwUmj+dvp6K6z+yKBTm2t9/NNz4KJhGnV4vMbY/xmy DqOw== X-Gm-Message-State: AOAM530n90qpB6NStUKo/BoekP2/Xz5pNwI43OLYHMw4VfqSSC0XTNGl QEraZX2XEIXfu/cwX5RrknRA0GWXS5wtLcH5pIvbZ5B2rj8= X-Google-Smtp-Source: ABdhPJxvrECqnYllNCNQGftWNvaqDTJSBKF5Z+30La9cQKZxHRzvv/IscPTzdNytzlQ8VKn/0BiUfrYaYEmh3giIwpI= X-Received: by 2002:a05:6402:6cb:: with SMTP id n11mr44815135edy.198.1616010316217; Wed, 17 Mar 2021 12:45:16 -0700 (PDT) MIME-Version: 1.0 References: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> In-Reply-To: From: William Lupton Date: Wed, 17 Mar 2021 19:45:04 +0000 Message-ID: To: Andy Bierman Cc: Vladimir Vassilev , NetMod WG Content-Type: multipart/alternative; boundary="000000000000da14a705bdc0b850" Archived-At: Subject: Re: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 19:45:20 -0000 --000000000000da14a705bdc0b850 Content-Type: text/plain; charset="UTF-8" I thought it might also be so as not to impose a module naming convention on external organisations? On Wed, 17 Mar 2021, 18:47 Andy Bierman, wrote: > > > On Wed, Mar 17, 2021 at 11:36 AM William Lupton < > wlupton@broadband-forum.org> wrote: > >> Also note that the YANG catalog keys modules by (name, revision, >> organization). >> > > This 3rd key implies that some organizations have their own versions of > YANG modules from SDOs. > We have a bit of that only to fix known Errara in some IETF modules. > YANG has deviations so vendors can change the modules from other > organizations > without hacking the original modules. > > > Andy > > > >> On Wed, 17 Mar 2021 at 18:21, Andy Bierman wrote: >> >>> >>> >>> On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev < >>> vladimir@lightside-instruments.com> wrote: >>> >>>> >>>> On 16/03/2021 13.36, Vladimir Vassilev wrote: >>>> > Hei, >>>> > >>>> > Many drafts and RFCs are flagged with warnings by the tracker >>>> > validation tools: >>>> > >>>> > ... >>>> > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p >>>> > {draftlib} -p {ianalib} -p {cataloglib} {model} -i: >>>> > warn: Module's revisions are not unique (2018-06-28). >>>> > >>>> > ... >>>> > >>>> > Does anyone know what causes this warning? >>>> >>>> Seems the warning is issued when iana-if-type@2020-01-10.yang is >>>> processed. It contains 2 revision (history) statements with identical >>>> dates 2018-06-28. >>>> >>>> IMO Multiple revision statements with the same date are valid so the >>>> tool reporting the warning has to be fixed. >>>> >>>> >>> >>> I disagree. Our compiler has a similar warning. >>> >>> The YANG Library treats entries with the exact same module name and >>> revision-date as >>> the same module. The protocols that currently advertise YANG module >>> capabilities >>> all use module name and revision-date to identify a unique module >>> revision. >>> >>> A compiler warning simply means "Are you sure you meant to do this?" >>> This is usually a cut-and-paste error. >>> >>> >>> >>>> >>>> Vladimir >>>> >>>> >>> Andy >>> >>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> --000000000000da14a705bdc0b850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought it might also be so as not to impose a module n= aming convention on external organisations?

On Wed, 17 Mar 2021, 18:47 Andy = Bierman, <andy@yumaworks.com&g= t; wrote:


On Wed, Mar 17, 2021 at 11:36 AM William Lupton <w= lupton@broadband-forum.org> wrote:
Also note that the YANG catalog = keys modules by (name, revision, organization).

=
This 3rd key implies that some organizations have their own vers= ions of YANG modules from SDOs.
We have a bit of that only to fix= known Errara in some IETF modules.
YANG has deviations so vendor= s can change the modules from other organizations
without hacking= the original modules.


Andy



On = Wed, 17 Mar 2021 at 18:21, Andy Bierman <andy@yumaworks.com> wrot= e:


On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev = <vladimir@lightside-instruments.com> wrote:

On 16/03/2021 13.36, Vladimir Vassilev wrote:
> Hei,
>
> Many drafts and RFCs are flagged with warnings by the tracker
> validation tools:
>
> ...
> yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
> {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
> warn: Module's revisions are not unique (2018-06-28).
>
> ...
>
> Does anyone know what causes this warning?

Seems the warning is issued when iana-if-type@2020-01-10.yang is
processed. It contains 2 revision (history) statements with identical
dates 2018-06-28.

IMO Multiple revision statements with the same date are valid so the
tool reporting the warning has to be fixed.



I disagree.=C2=A0 Our c= ompiler has a similar warning.

The YANG Library tr= eats entries with the exact same module name and revision-date as
the same module.=C2=A0 The protocols that currently advertise YANG module = capabilities
all use module name and revision-date to identify a = unique module revision.

A compiler warning simply = means "Are you sure you meant to do this?"
This is usua= lly a cut-and-paste error.

=C2=A0

Vladimir


Andy
=C2=A0
_______________________________________________
netmod mailing list
net= mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod<= /a>
_______________________________________________
netmod mailing list
net= mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod<= /a>
--000000000000da14a705bdc0b850-- From nobody Wed Mar 17 13:36:29 2021 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 F12D53A1377 for ; Wed, 17 Mar 2021 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA5lbjiXS4jU for ; Wed, 17 Mar 2021 13:36:27 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F783A136E for ; Wed, 17 Mar 2021 13:36:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=agNr8NkNg8WoKK6x7w2LN1vYhGOOIoVY7AeUEyHBYeHWwaQMLgwTW55EK2Yx+bti1sLfzTq0plb4/TeFxM5/CtIwAwHHin2qsgg1Acnu7vkoutNDVjQR0wUU2dcvQPYwtsyim3hT2Twq+5rucIGfhbLo3o0AZF1o8L1GhWyIaNPCxPOJgkKMdejOYzYD5S+HsARrhoNeU6W8Bectpw/RhxcPjnoXJKQFxih7a+tqENBGssRMtOXAMBufQysx6IKRz41s75LSWLVTQgN85HWpad+GKfQY326AOv4QCGsx74IB/2TU0VCPEuBxCLdZX2siQ4Xdkp0dUAlAObqso/kZvQ== 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=IQzEeJJaQHVZwi8beGkgGxWD+mylAXH5yXhEyoBWQ4I=; b=YObg1yChuUrvBdKu80lYgOPfXXIXzyTrMX5FABGqhRBCyVz+ctR6pLtaFc6BOPOQJO7J+i+9bKwSO0kf18++g+Q6e+9AWz785057UKGzsVs/7IniKYg0QqDEoFwdVvzr64VIdC+ZcW9eZ9h25xflbfZRqRawJg85cW8q2nzw7kr9hXbcsOVZx+HN/nIvwqEXKV753dU0ftenVTFkYOmsfYT+rWIBjMhQL/QaRuD5BD1Ro3Bo21qgR4WQ5HciTtRR1ecJk7vq8HtdsJCwMSMEQQI5lyLRPgT5iDQIx89S4KSgRAHeUCl98j6sT+ALi1fvLDCZl7CLPkeXX2y631AaAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQzEeJJaQHVZwi8beGkgGxWD+mylAXH5yXhEyoBWQ4I=; b=ELYxnF6vltoDl6nLIqVkgsXJRwslMN6vj1Fbpf+5luMICPlCADgLg9VPU1TTROVPu6l/4ILbJ38keOVy1WDFcpXEH2rXCrq47SYoLH+gTbJ96PCiA1EgNqcvnWdTgne47/wV7RE7YqZ4GiBeKQhNerhuyhlTWcrGBvIDxKVkcU8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=lightside-instruments.com; Received: from AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) by AM0PR08MB3345.eurprd08.prod.outlook.com (2603:10a6:208:5c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Wed, 17 Mar 2021 20:36:22 +0000 Received: from AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::84b4:6a0a:9a03:af99]) by AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::84b4:6a0a:9a03:af99%4]) with mapi id 15.20.3955.018; Wed, 17 Mar 2021 20:36:22 +0000 From: Vladimir Vassilev To: "netmod@ietf.org" References: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> Message-ID: <3dad9725-d56d-f8b6-d51a-963d2e5865b6@lightside-instruments.com> Date: Wed, 17 Mar 2021 21:36:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [84.209.6.28] X-ClientProxiedBy: OL1P279CA0043.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::12) To AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.19] (84.209.6.28) by OL1P279CA0043.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Wed, 17 Mar 2021 20:36:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8e690197-a45c-4f2b-1754-08d8e98453ec X-MS-TrafficTypeDiagnostic: AM0PR08MB3345: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:151; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Md8CEf6WRvJULG1bdFnjDtAubzbVLAQQ/KWiQXQVF3zH0GEd6jb+hVytqICg0bikpKGuvBVV4GNxTTZyuLxZpGKHy09UMIEw0dXBezCd+oEmuX0iffCuk1uWz0WOZrqaK2E2JjgEZTp3I2KtOtz1Zz1vxadCT0A5WF5p8VVOfOTY+MDelgWEEcCJ9MbNcFDwynZy65vSKgFgK/hNfMHuScFMLHe2ZcJHSs8dg5mQ9NbKhK+UkUVYmuXbKT7M4rV7+AU40XiJqBZqb5e/3XUfZgESJEovIVncldYx5I/VOxasr0g71d+qV+9bPVnOs+y5wPLpvDytZHxXV890Pg8Zm/REHUuhE5nuxHzRngl0eVbuTjOqAW4bFUJ6xHjgKXP04kBqBP/7g75iUBC11I1qokHzxZR+G57ef4HF7s/ylXN2lqlyuzBxy11VGq7azIcKiV3yBCnaTKvxmX2zuPOYQkIku40WlMu1HL1/0sad5VwSvRZKmszH2HguLFQJM9UNovcXD6TY8c0hFrg8HkF1Vz9OZxywqhUvKChISVdT+No8OFVh2xQpJL1359NfI/ziUcgC7qs3CdFAZ4PTpsk9uI4zGBjY54U3yKedJP1pK8ePlmucnI4f4gpn0gzSbv7BoYt01gVARtbB7e+Uwr6GkQKe38IxJk8jrdFMPvkRBMSs+KUczGINCC0brgs8fSMAq1mQQaGQBVjTGwov2lbkcAIzHdYoUr9NDLCZyb0SRIE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB4084.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(39830400003)(396003)(366004)(376002)(83380400001)(16576012)(316002)(5660300002)(2616005)(478600001)(86362001)(52116002)(186003)(966005)(66476007)(16526019)(956004)(6916009)(6486002)(36756003)(26005)(66946007)(31686004)(8676002)(31696002)(2906002)(8936002)(66556008)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RTFyejFxbkZ1QTdOVHpvY3J3azhabFAwbjdpeFlCcE5sNVhtYmxralpMSXRV?= =?utf-8?B?RnNOQlBRaEZNNWFXWXVHZFF5WFhHdDIyaWpjMVZCTzk0RnZoYkswMHZLWER5?= =?utf-8?B?cjZGZGxHazZNSkZhK2lUZ2ZSN1NkMTByNVZwbjBuL29lT0FJKytWbHpjNU5I?= =?utf-8?B?cGNpODU0bm5kaCtuQy9GMnRMcnJVcFp5WnA5T2NCY1pPQ0J3VUlQWFArNVJZ?= =?utf-8?B?ZEVjYXlCbmIvRTYvV1c1cmczTVI5WjRXdGFHZUQ3c1FBTlNHMDB1ZzUxT1FJ?= =?utf-8?B?Vk5mM095aWkrMTNLTDNLNXNiTUkzeGlWSktWUXcyS0FoNGRMaVNqNG5uUkpr?= =?utf-8?B?bmJVQlJ1U0xMUWhHb1Y2cmluWjRUdytkOUYzNGttQTFIWUY5K1ZNeWRQYkhv?= =?utf-8?B?dWE5YkF2bjR4U2l2TXJDSlNQSjJ2dUJPMGNpK3dnTlN4L3I3Q3VDUEVpemNn?= =?utf-8?B?TnUxVjJ1MXZVUEMxU1hiZkE2L2Q3Y3BzQzUrdHBOQWU1dEhuRGk5NUo4UWZB?= =?utf-8?B?M1F5U1JBNW1sM3psbjA1N1RXT2p3cEUzallOWHdVMjhGakFGSnN3MkpzQzgr?= =?utf-8?B?dGFhaHp0ZVBtQU04bWlVTUhKUk1uekxRVnEra29KWkQ5YkpITDlqeE01TE1k?= =?utf-8?B?ejNWL3ptQkdjTXJrdlhVOU1GMnNadzRvT3d6UVJuNW5TOWFUUkQxY1BmRzAw?= =?utf-8?B?QUlkaFZmbjY0akc1dk1wbDhveDIyV3JJZXZmcFV5cWR4bUJ1L2NISmtkRWJ0?= =?utf-8?B?QklBT3hTbS91cmEyYWdPZTEwSGE2SlQ2RTZPMjhBSGRtK3poT0IwVTJhUlVT?= =?utf-8?B?U1dTMEVtZmRjRnZ6OTZsUDBLVHdyOGR1ckZtR0w2LzVaT2N6cHVGSXpYNDRq?= =?utf-8?B?Q3UweHdvWk10QTRYSzRtNXE5dkNsN1NSdUZ4aEhBdkxsbm1IWi9sdTRzdkRE?= =?utf-8?B?dTNMWDZoVDMxVlRqY09RejJKY1dyM0thaEF6c09paXN0VmlTd1E0OG1Tb3Ix?= =?utf-8?B?cWNsQW9GdkxHQjBTSG41aWZFWXdUbWY2VGxwbG95bitPOW1VVFhDQUI0eFVt?= =?utf-8?B?YXYzM1JHTDRxT2xLbXlxRXdzd1Y0a3UzaDl6MDYvZjFYS3ZvZHBNaVdLNFc0?= =?utf-8?B?ZDdabmwrS3YwdGt3SGdJUWJCb0JDbmtaODBJRHFSOGhRcmt5dG5Ed0JDc2Nj?= =?utf-8?B?bFB1QW5LQWU4QlozZWUySno5eUlJZ1dhTUN2NUQyZVE2UDFZZnpISUdVcTFx?= =?utf-8?B?Q0hDdmJleDhxZzZjWTl1NGhLcmdyVFNYaloybWdMeEtyRnpSOE5URTRCTTNi?= =?utf-8?B?VjZZblYwdVRFL1QvYThUZGtoc2c1UVRHcTh0TXIveXFFbXF1N2I3bnFmUFFh?= =?utf-8?B?TTYxZzlqZEFONVFvZjNUV1N0Z204RVNsckhhcEoySkRZWGZFbXNGQmxWY2hI?= =?utf-8?B?QjN1VlN1K09wQW1JYXJ2bzV1YWNPZEF2SGsxRDIzM2lXT3N3c0FDVS9PeWRm?= =?utf-8?B?U0tvOXdhQlM2YXJ4MnFqS085QW1odFlwcWZ5eFJLRzIvOWJQTUlBSUNOejVz?= =?utf-8?B?WWY1NlEwczBPR2VhNGhEc1VRMi9sVnJoRnRoOC9ySlhrMUVqNlBWWDZ5UThr?= =?utf-8?B?QzFhd0duQUhGdWJRU2Q3MDJsYmtCQ2JZVHBVZzhKV0FQMDdOYmxnNTgrWlJy?= =?utf-8?B?U2p2M2x1V3FWTFdLTzBVZFllODNaTHM2ZXg4Ti9qV0hiVWt6WmxDeDVvUXdI?= =?utf-8?Q?d0Ur/e7T2nO2/dhvy4xESu3OTnGKvJGHv7F76MP?= X-OriginatorOrg: lightside-instruments.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e690197-a45c-4f2b-1754-08d8e98453ec X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB4084.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2021 20:36:22.6730 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c0326317-f373-4461-a96f-7946e0abb603 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nLxUUpVmsmVeZPcLLgCcJJ4tq9jVxuInAS9pFETBQwHZRXQmYqbyw3ONEeLlEHzJAqrUtN2eXQWDQy/Y8hTy0EthEMAn++ihYqlCyT5mfSwkyHaxbYGbUFewXGfIoH+l X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3345 Archived-At: Subject: Re: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 20:36:29 -0000 On 17/03/2021 19.21, Andy Bierman wrote: > > > On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev > > wrote: > > > On 16/03/2021 13.36, Vladimir Vassilev wrote: > > Hei, > > > > Many drafts and RFCs are flagged with warnings by the tracker > > validation tools: > > > > ... > > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p > > {draftlib} -p {ianalib} -p {cataloglib} {model} -i: > > warn: Module's revisions are not unique (2018-06-28). > > > > ... > > > > Does anyone know what causes this warning? > > Seems the warning is issued when iana-if-type@2020-01-10.yang is > processed. It contains 2 revision (history) statements with identical > dates 2018-06-28. > > IMO Multiple revision statements with the same date are valid so the > tool reporting the warning has to be fixed. > > > > I disagree.  Our compiler has a similar warning. > > The YANG Library treats entries with the exact same module name and > revision-date as > the same module.  The protocols that currently advertise YANG module > capabilities > all use module name and revision-date to identify a unique module > revision. > > A compiler warning simply means "Are you sure you meant to do this?" > This is usually a cut-and-paste error. If the tools could some how indicate that the warning is for an imported module and not the one validated it would be easier to differentiate between that case and the case the warning is caused by an imported standard module like iana-if-type. Vladimir > > Vladimir > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Mar 17 15:47:07 2021 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 A50C13A16F7 for ; Wed, 17 Mar 2021 15:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YNgb45IRbGOD for ; Wed, 17 Mar 2021 15:47:03 -0700 (PDT) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4383A16F5 for ; Wed, 17 Mar 2021 15:47:03 -0700 (PDT) Received: by mail-pj1-f44.google.com with SMTP id s21so1907549pjq.1 for ; Wed, 17 Mar 2021 15:47:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xh6fkPHvGleVhBdM4zp0gPInYQp/t/cxg71lX3zpfws=; b=tQ5x9mtB6OTwuEHDeHmO2K9goCV5CS5Bdv1AvWQXjE5xoXvd7JG3XnTpa/NDkoNyI8 Z5jG/S71pRh4DcK/SWJ0u5SVUn5YiNm1AkYou77G22gxkiTjEa5p515d2bnmY9hS8DOA i1eMgZW/QUmOzTSHR9D0ksM4Tgv6mzUcWPUwYCw+3e8RDg0bWZr7COCRQa9Ku0cFNqiZ GRVSXtwZfnfTWyCCNJdgTR2lRlhhZgNyf4iBBOXX+KWNF98UKH+T9REa9RCEET1pxwHx 7mJfMP2v7kloT2szG+p78JDlOggRZMEbMUov4EZVZeO9VJIVE62/W9YpGmUNifCeg7kd okHA== X-Gm-Message-State: AOAM530JS053pGKQxRpGsVVzxade+BLWAR/LKYabsN5z9Xm7XdlKNNlX d2fbP3a7Y82qaC6ECvR/2WEedbm4yMVSQw== X-Google-Smtp-Source: ABdhPJzG5xi1FCkudpcfmjNRroudXbQnMomSapKylhdy2n+m8OaHu6pILmsFjKKEmcmkxMqbl0Qyvg== X-Received: by 2002:a17:902:e80e:b029:e4:b2b8:e36e with SMTP id u14-20020a170902e80eb02900e4b2b8e36emr6472299plg.45.1616021222782; Wed, 17 Mar 2021 15:47:02 -0700 (PDT) Received: from ?IPv6:2601:646:9300:791:5c07:a14c:d7de:6687? ([2601:646:9300:791:5c07:a14c:d7de:6687]) by smtp.gmail.com with ESMTPSA id a24sm141837pff.18.2021.03.17.15.47.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 15:47:02 -0700 (PDT) To: "netmod@ietf.org" References: <20210310084324.xkr4xbsainfnxrvr@anna.jacobs.jacobs-university.de> From: Randy Presuhn Message-ID: Date: Wed, 17 Mar 2021 15:47:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 22:47:05 -0000 Hi - On 2021-03-17 4:15 AM, tom petch wrote: > From: netmod on behalf of Randy Presuhn > Sent: 10 March 2021 18:28 > On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: >> Dear Qin, >> >> I believe this work repeats failures of the past but since the WG >> agreed to entertain this, I will keep my mouth shut. I suggest you do >> not spend your energy to convince the that this work is viable since >> it is rather unlikely that I will change my mind. > > > > Meanwhile the ITU-T has just liaised the IETF that it is starting work on intent-based management. I have not looked to see if the same words mean the same thing but guess that they do. :-) A risky guess, based on my experience. I vividly remember an X3T5.4 meeting in which we *thought* we were wrapping things up, until someone (me) foolishly drew an E-R diagram on the whiteboard, causing us to realize that although we thought we had reached agreement, we had in fact been using the same words strung together in the same order to talk about radically different models. Randy From nobody Wed Mar 17 17:03:19 2021 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 A294B3A1882 for ; Wed, 17 Mar 2021 17:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc0FUAyeItAk for ; Wed, 17 Mar 2021 17:03:16 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE993A1880 for ; Wed, 17 Mar 2021 17:03:16 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id e14so369656plj.2 for ; Wed, 17 Mar 2021 17:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=BG9OSR/G+lxa68GKoX5nx8kSejh4TB470HEViAR62ao=; b=ZxsaNsVR9JdeBI53u5tCRKEVjGesaNEqMAB5SI6TTSGov/0qZ6QG7EmrInZcMaHr9b 9/Sw+L6esp+3c0ce6TH5MeARWicMtv2D4tvEF2p+86l6GcyVzYJs7nGQXwLNA+W/NMkZ CcDdxrmNzHbBApKcTFekV+HZYIFbILFZUTMBGvcIIJAekZaMtqlrSm0RZR6ascgOCzjM hz2WxQ3c7H5vrx0HUdRAzi96DZTFIdywoaXNAdqpCCuxdu5/FeMk7HV6467AO01GsCN/ koGzkIr76AgOOuP7SZvmFMK9Ejsv4VUwcP/rAaLA6jj9mFcgdvnIg5NWed7Ns2HE9q8A Ow3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=BG9OSR/G+lxa68GKoX5nx8kSejh4TB470HEViAR62ao=; b=LTn1pdd4FwGrBeKTqHt/CwidI++9IcKdsPV+LC++O8IZC292nlf6+CyuHxiCfelQ6E IU5ZtOsn8ezppumenGrp6QlK7gFfm9RhzC0KIwpnHUwNnsq3Ts2VtJrhdP7ZUuDqeQ1i UkzLnKVpgI9JygL5ovs26otXfXRpfJlNLQTFumjJjti0fOoZLJVjITJ4kKfxbjcHAyat 9WWAyhHCfc+X+povl9a17JKS1XAkDkUEJLPg00SYTZvnFTr71cRSP/BVrp72guue8zUk FDCv1CWgMQIAB6UkTJcESGGKjY10XmoKufG79Ir2hnfGz5tluvwtLtPBDSGZhnF5f7yZ YrvA== X-Gm-Message-State: AOAM531RqdvuXdiGp60iGdaSyIJMc/T+tQoZZchOEhctgEaGP/k/HDCX YT+KMZipBMZ8ZYl9Mw47h8Czpc7CxA90+g== X-Google-Smtp-Source: ABdhPJxHqH+mKbhGlrLugSR4Q/ymkG6olXzl5uEJz/cr+mj837EEc/Qr3L4IH4aebvwcJca6tjjKzg== X-Received: by 2002:a17:90a:8505:: with SMTP id l5mr1314822pjn.100.1616025793960; Wed, 17 Mar 2021 17:03:13 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:e834:82e3:cfdc:e68d? ([2601:647:5600:5020:e834:82e3:cfdc:e68d]) by smtp.gmail.com with ESMTPSA id v3sm185648pff.217.2021.03.17.17.03.13 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Mar 2021 17:03:13 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_BE20BFF1-9686-4033-B161-346240505316" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> Date: Wed, 17 Mar 2021 17:03:11 -0700 To: netmod@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 00:03:18 -0000 --Apple-Mail=_BE20BFF1-9686-4033-B161-346240505316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have seen the debate on the use of prefixes in YANG models, specially = as it relates to their use when importing a model. I think it would nice = to be clear on what is required, what is nice, and what is not ok to do. = I do not want to confuse this discussion with the length of the prefix, = which I believe is somewhat related but not the same discussion. RFC 7950 says: All prefixes, including the prefix for the module itself, MUST be unique within the module or submodule. This is a requirement, as is clear by the MUST. Then RFC 7950 says: To improve readability of YANG modules, the prefix defined by a module SHOULD be used when the module is imported, unless there is a conflict. It also says: When used inside the "import" statement, the "prefix" statement defines the prefix to be used when accessing definitions inside the imported module. Clearly, the scope of the =E2=80=9Cprefix" statement used with an = =E2=80=9Cimport=E2=80=9D statement is limited to the module where it is = imported and does not impact the imported module. As such, and because = it is a SHOULD and not a MUST, this is a =E2=80=9Cnice to have=E2=80=9D = without conflicts, but one would not be wrong using a different prefix = from the one defined in the imported module. Add to this, most tools, = e.g. pyang or yanglint do not complain if you do define a different = prefix when there are no conflicts. I have not seen a problem in the = implementation of the module when the prefix is different. RFC 8407 confuses this whole situation by saying: The proper module prefix MUST be used for all identifiers imported from other modules. which as written is true for identifiers (but not for other types of = imports??). Besides, it does not define what is =E2=80=9Cproper module = prefix". In the absence of a proper definition, one should follow what = RFC 7950 says. Comments? Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_BE20BFF1-9686-4033-B161-346240505316 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have seen the debate on the use of prefixes in YANG models, specially as = it relates to their use when importing a model. I think it would nice to = be clear on what is required, what is nice, and what is not ok to do. I = do not want to confuse this discussion with the length of the prefix, = which I believe is somewhat related but not the same discussion.

RFC 7950 says:

   All prefixes, including the =
prefix for the module itself, MUST be
   unique within the module or submodule.

This is a = requirement, as is clear by the MUST.

Then RFC 7950 says:

   To
   improve readability of YANG modules, the prefix defined by a module
   SHOULD be used when the module is imported, unless there is a
   conflict.

It also says:

   When used inside the "import" =
statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.

Clearly, the scope of the =E2=80=9Cprefix" statement used = with an =E2=80=9Cimport=E2=80=9D statement is limited to the module = where it is imported and does not impact the imported module. As such, = and because it is a SHOULD and not a MUST, this is a =E2=80=9Cnice to = have=E2=80=9D  without conflicts, but one would not be wrong using = a different prefix from the one defined in the imported module. Add to = this, most tools, e.g. pyang or yanglint do not complain if you do = define a different prefix when there are no conflicts. I have not seen a = problem in the implementation of the module when the prefix is = different.

RFC = 8407 confuses this whole situation by saying:

      The proper module prefix =
MUST be used for all identifiers imported
      from other modules.

which as written is true for = identifiers (but not for other types of imports??). Besides, it does not = define what is =E2=80=9Cproper module prefix". In the absence of a = proper definition, one should follow what RFC 7950 says.

Comments?




= --Apple-Mail=_BE20BFF1-9686-4033-B161-346240505316-- From nobody Wed Mar 17 18:06:49 2021 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 20B1C3A19E2 for ; Wed, 17 Mar 2021 18:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dA9xs-SNMa8P for ; Wed, 17 Mar 2021 18:06:40 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B64E3A19CF for ; Wed, 17 Mar 2021 18:06:40 -0700 (PDT) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F17yt69gWz681Cg for ; Thu, 18 Mar 2021 09:01:58 +0800 (CST) Received: from fraeml793-chm.china.huawei.com (10.206.15.14) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 18 Mar 2021 02:06:34 +0100 Received: from fraeml793-chm.china.huawei.com (10.206.15.14) by fraeml793-chm.china.huawei.com (10.206.15.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 18 Mar 2021 02:06:33 +0100 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by fraeml793-chm.china.huawei.com (10.206.15.14) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Thu, 18 Mar 2021 02:06:33 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.181]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0513.000; Thu, 18 Mar 2021 09:06:29 +0800 From: Qin Wu To: Randy Presuhn , "netmod@ietf.org" Thread-Topic: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent Thread-Index: AdcbkRBxuELdWksRRV2d/CqO6fYAHg== Date: Thu, 18 Mar 2021 01:06:29 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 01:06:48 -0000 UmFuZHk6DQpXZSBmZWVsIHRoYXQgd2UgYXJlIHZpY3RpbSBvZiB0aGlzIGRpc2N1c3Npb24gd2l0 aCBjb25mdXNpbmcgdGl0bGUuIEkgZG9uoa90IHdhbnQgdG8gY29tbWVudCBvbiB3aGV0aGVyIHRo ZSBpbnRlbnQgaXMgcmlnaHQgb3IgaXQgaXMgdGltZSBmb3IgaW50ZW50IG9yIG5vdCwgeW91IGhh dmUgeW91ciBqdWRnZW1lbnQsIGJ1dDoNCjEuIFRoZSBsaWFpc29uIGlzIHNlbnQgdG8gTk1SRyBp bnN0ZWFkIG9mIHRoaXMgV0cgc2luY2UgdGhleSBiZWxpZXZlIHRoZSBtb3JlIHJlbGV2YW50IHdv cmsgaXMgb3ZlciB0aGVyZS4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8x NzI0LykNCjIuIFRoZSBpbnRlbnQgaW4gZGlmZmVyZW50IGNvbnRleHQgbWVhbnMgZGlmZmVyZW50 IHRoaW5ncywgaW50ZW50IHRyYW5zbGF0aW9uLCBpbnRlbnQgbWFwcGluZywgY29tYmluaW5nIHdp dGggQUwvTUwgaXMgbm90IGluIHRoZSBzY29wZSBvZiB0aGlzIHdvcmsuDQozLiBUaGUgRUNBIG1v ZGVsIGJvcnJvd3Mgc2ltaWxhciBjb25jZXB0IGZyb20gUk1PTiB3aGljaCBpcyBzdWNjZXNzZnVs bHkgc3BlY2lmaWVkIGJ5IElFVEYsIFJPTU4gaXMgZXh0ZW5zaW9uIG9mIFNOTVAsIHByb3ZpZGVz IHRyYWZmaWMgZmxvdyBkYXRhIGZvciB0cm91Ymxlc2hvb3RpbmcgYW5kIHByb3ZpZGVzIHRoZSBj b250cm9sIHRvIGFkanVzdCBmb3IgYmV0dGVyIHBlcmZvcm1hbmNlLiBTbyB3aHkgbm90IEVDQQ0K NC4gRUNBIGlzIGFic3RyYWN0ZWQgZnJvbSBib3R0b20gdXAgYW5kIHVzZSB0ZWxlbWV0cnkgcHJv dG9jb2wgYXMgYSBnb29kIGJhc2lzIGFuZCBwcm92aWRlIGEgY2xlYXIgc2VtYW50aWNzIHdoaWNo IGlzIGRpZmZlcmVudCBmcm9tIGludGVudCB5b3UgcXVvdGVkIGZyb20gZWxzZXdoZXJlLg0KDQot UWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gUmFuZHkgUHJlc3Vobg0Kt6LLzcqxvOQ6IDIwMjHE6jPUwjE4 yNUgNjo0Nw0KytW8/sjLOiBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbmV0bW9kXSBFQ0Eg UG9saWN5OiBXaGF0IGlzIGFuIGFkZXF1YXRlIGFic3RyYWN0aW9uIGxldmVsIHRvIGV4cHJlc3Mg cG9saWNpZXMgYW5kIGludGVudA0KDQpIaSAtDQoNCk9uIDIwMjEtMDMtMTcgNDoxNSBBTSwgdG9t IHBldGNoIHdyb3RlOg0KPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgUmFuZHkgUHJlc3VobiANCj4gPHJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5m b3JkLmVkdT4NCj4gU2VudDogMTAgTWFyY2ggMjAyMSAxODoyOA0KPiBPbiAyMDIxLTAzLTEwIDEy OjQzIEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+PiBEZWFyIFFpbiwNCj4+DQo+ PiBJIGJlbGlldmUgdGhpcyB3b3JrIHJlcGVhdHMgZmFpbHVyZXMgb2YgdGhlIHBhc3QgYnV0IHNp bmNlIHRoZSBXRyANCj4+IGFncmVlZCB0byBlbnRlcnRhaW4gdGhpcywgSSB3aWxsIGtlZXAgbXkg bW91dGggc2h1dC4gSSBzdWdnZXN0IHlvdSBkbyANCj4+IG5vdCBzcGVuZCB5b3VyIGVuZXJneSB0 byBjb252aW5jZSB0aGUgdGhhdCB0aGlzIHdvcmsgaXMgdmlhYmxlIHNpbmNlIA0KPj4gaXQgaXMg cmF0aGVyIHVubGlrZWx5IHRoYXQgSSB3aWxsIGNoYW5nZSBteSBtaW5kLg0KPiANCj4gPHRwPg0K PiANCj4gTWVhbndoaWxlIHRoZSBJVFUtVCBoYXMganVzdCBsaWFpc2VkIHRoZSBJRVRGIHRoYXQg aXQgaXMgc3RhcnRpbmcgd29yayBvbiBpbnRlbnQtYmFzZWQgbWFuYWdlbWVudC4gIEkgaGF2ZSBu b3QgbG9va2VkIHRvIHNlZSBpZiB0aGUgc2FtZSB3b3JkcyBtZWFuIHRoZSBzYW1lIHRoaW5nIGJ1 dCBndWVzcyB0aGF0IHRoZXkgZG8uDQoNCjotKSAgQSByaXNreSBndWVzcywgYmFzZWQgb24gbXkg ZXhwZXJpZW5jZS4gIEkgdml2aWRseSByZW1lbWJlciBhbg0KWDNUNS40IG1lZXRpbmcgaW4gd2hp Y2ggd2UgKnRob3VnaHQqIHdlIHdlcmUgd3JhcHBpbmcgdGhpbmdzIHVwLCB1bnRpbCBzb21lb25l IChtZSkgZm9vbGlzaGx5IGRyZXcgYW4gRS1SIGRpYWdyYW0gb24gdGhlIHdoaXRlYm9hcmQsIGNh dXNpbmcgdXMgdG8gcmVhbGl6ZSB0aGF0IGFsdGhvdWdoIHdlIHRob3VnaHQgd2UgaGFkIHJlYWNo ZWQgYWdyZWVtZW50LCB3ZSBoYWQgaW4gZmFjdCBiZWVuIHVzaW5nIHRoZSBzYW1lIHdvcmRzIHN0 cnVuZyB0b2dldGhlciBpbiB0aGUgc2FtZSBvcmRlciB0byB0YWxrIGFib3V0IHJhZGljYWxseSBk aWZmZXJlbnQgbW9kZWxzLg0KDQpSYW5keQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Wed Mar 17 18:35:52 2021 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 B67A53A1A2D for ; Wed, 17 Mar 2021 18:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3HFpG9tn12Zn for ; Wed, 17 Mar 2021 18:35:49 -0700 (PDT) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1836D3A1A08 for ; Wed, 17 Mar 2021 18:35:49 -0700 (PDT) Received: by mail-pl1-f177.google.com with SMTP id w11so459929ply.6 for ; Wed, 17 Mar 2021 18:35:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tzaQ3nOtt3zveKCv1uWExB7KEuJEMM2EBj3Ha29hQ/Q=; b=hmIbEiQVIHK+kJMPCF3txeyKYdLtz/ci5IsqiKL0fnlB4WKQEX0OtuMNeoPA/LC2B5 i4Xcw7f1LP2OEIn3KWGM0nKLHMT6ENt9lhl9TPNZRrya1WTuZl836jlrnj4IDy0FFvV7 TYZbERjH4lHmIHPxXrQ1Ws3m2HgpdplaFjtlbBCAO7iIQEYKcBNuiDRaSeDhiM7OWVJ2 WH85wQj3C05WCtoRhyd+ZxUTC/d5YUMKiQQX8B6A5HQMTkjWBQntGin3qiPHA2r8Kcu6 2VEOzdcgpdXX9q5XqX87TDyUMOhnMHslRVEUmBHzhP6apQAmRuM+18FhAO+K8eLajzMh mPJg== X-Gm-Message-State: AOAM533n0q0P5N2VLHxzXoYmOdGzT9Xkc6cwFq+222aV493uw/Qm8Bbc wUhnVOqMLEeSYKz6f+ozjispAZ5TWvE22A== X-Google-Smtp-Source: ABdhPJwaewE3hyHkxGcEuzdAnamqdDLdiVxIRgzWOd6mpDQ6mmPhR8IvlVadeAG+3yIkmLLungb1Yw== X-Received: by 2002:a17:90a:540c:: with SMTP id z12mr1569636pjh.163.1616031348474; Wed, 17 Mar 2021 18:35:48 -0700 (PDT) Received: from ?IPv6:2601:646:9300:791:98ea:368a:aa94:5daa? ([2601:646:9300:791:98ea:368a:aa94:5daa]) by smtp.gmail.com with ESMTPSA id v14sm302260pju.19.2021.03.17.18.35.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 18:35:48 -0700 (PDT) To: Qin Wu , "netmod@ietf.org" References: From: Randy Presuhn Message-ID: <39ce0b05-08de-e91d-7398-f785ead191fb@alumni.stanford.edu> Date: Wed, 17 Mar 2021 18:35:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 01:35:51 -0000 Qin - It puzzles me that you should take umbrage at my statement, when it seems that you are in full agreement with my point in response to Tom's stated assumption. Randy On 2021-03-17 6:06 PM, Qin Wu wrote: > Randy: > We feel that we are victim of this discussion with confusing title. I don’t want to comment on whether the intent is right or it is time for intent or not, you have your judgement, but: > 1. The liaison is sent to NMRG instead of this WG since they believe the more relevant work is over there. (https://datatracker.ietf.org/liaison/1724/) > 2. The intent in different context means different things, intent translation, intent mapping, combining with AL/ML is not in the scope of this work. > 3. The ECA model borrows similar concept from RMON which is successfully specified by IETF, ROMN is extension of SNMP, provides traffic flow data for troubleshooting and provides the control to adjust for better performance. So why not ECA > 4. ECA is abstracted from bottom up and use telemetry protocol as a good basis and provide a clear semantics which is different from intent you quoted from elsewhere. > > -Qin > -----邮件原件----- > å‘件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Randy Presuhn > å‘é€æ—¶é—´: 2021å¹´3月18æ—¥ 6:47 > 收件人: netmod@ietf.org > 主题: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent > > Hi - > > On 2021-03-17 4:15 AM, tom petch wrote: >> From: netmod on behalf of Randy Presuhn >> >> Sent: 10 March 2021 18:28 >> On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: >>> Dear Qin, >>> >>> I believe this work repeats failures of the past but since the WG >>> agreed to entertain this, I will keep my mouth shut. I suggest you do >>> not spend your energy to convince the that this work is viable since >>> it is rather unlikely that I will change my mind. >> >> >> >> Meanwhile the ITU-T has just liaised the IETF that it is starting work on intent-based management. I have not looked to see if the same words mean the same thing but guess that they do. > > :-) A risky guess, based on my experience. I vividly remember an > X3T5.4 meeting in which we *thought* we were wrapping things up, until someone (me) foolishly drew an E-R diagram on the whiteboard, causing us to realize that although we thought we had reached agreement, we had in fact been using the same words strung together in the same order to talk about radically different models. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Mar 17 18:50:02 2021 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 5EE1F3A1A7A for ; Wed, 17 Mar 2021 18:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mFYHbrRSmJJ for ; Wed, 17 Mar 2021 18:49:58 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FFD3A1A79 for ; Wed, 17 Mar 2021 18:49:57 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id u20so5513395lja.13 for ; Wed, 17 Mar 2021 18:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eqSCoUdfbFum74WVK6ds6KGbaNKUutNaas/Y1IlD2dI=; b=vQT2fi3jk59Pt2d3PGGkyWbmfitY+CUTlL3GdA45Fjq+VUefLwwJRNgMGHstRYX8/g y0wQeh0EfFFjY+1etuy58zTD+a1JsSByV4RFXUuPD2okbo8wnggIArn6QJ7XZSKLpqqF IWpCvhbq/ITO3lGm2YhC2X7FcG5TLwVwQPtTH10Bp2R73F/pD9u2cX3+p7bMPN3ChQBV T1NA+CIsK9wnvFS6pcOPjgnFeBs7QIyHslMKzFNKDHhGEVaZghfqeBcmHXwICnMHgpYV 2mN5/XilYYttS5XHFCriexl716ApX3wcw1wd5HHj/NxrY9BSDr0QHjJfI7wzWsVjilIh Orew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eqSCoUdfbFum74WVK6ds6KGbaNKUutNaas/Y1IlD2dI=; b=pyAz/mpHNxxa6WYptqSI0elQwOGSsiL/FuBQH9aK7Jncs+23GgRr14QeCifVxa8mqF aFeNAemDC/BLXLne3pmZFk4c7zlnt2uggSg7bCm5+AdqdynE4Aj2/lI8GBAngwWMmPWg N2SyhW+x78L1jY0EhXvOB2nfTyUIG/Q3lQeBWd4EcFnBr/FHOnype5OrZpjZPQvnBhlp kEqdaAhOZpPRb+pNaYz7e/HgUSq4n0WbCTeQSfjmrXxdDMNjIbyoog4Ud3t/PkNe5GOo GNY0e2jD7GFnvEKxOVi9HXgzAMxWVJJZ80z4J6SZRpfp+dRb3L8iJC2QCz7xqAjE+HLS vUsg== X-Gm-Message-State: AOAM530fCIDq0JLFpZbMqxgPqHMux9mqoaGbfcbN8P3w1RY/QOolJ24S EGbbT0nPhQ2LdfP+dtp/lLRAW6wt2c1CpMpYoKXnDQ== X-Google-Smtp-Source: ABdhPJwo2tA/FN0LIMTyKMwu9uoW/5tOu9ZiQhtkMxoLXqGHhulq3iuJaXVXzXQQrUiCOp5MixcykJTXWDgga0z0QmU= X-Received: by 2002:a2e:9195:: with SMTP id f21mr3752340ljg.160.1616032194864; Wed, 17 Mar 2021 18:49:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 17 Mar 2021 18:49:43 -0700 Message-ID: To: Qin Wu Cc: Randy Presuhn , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ebb96e05bdc5d0ba" Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 01:50:00 -0000 --000000000000ebb96e05bdc5d0ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Addressing only point 3 below... Some article in the 90s claimed that RMON was going to replace SNMP. RMON is just another set of MIB modules. It does not extend or replace SNMP= . It is SNMP. (pet peeve of former RMONMIB WG Chair). Most of the RMON RFCs were widely deployed, but not all of them. One lesson learned from these failed MIB modules: It is quite possible to use the SMIv2 language to create a data model that nobody can implement within the business constraints given to them. And therefore, no implementations of such a module ever get written or deployed. Andy On Wed, Mar 17, 2021 at 6:07 PM Qin Wu wrote: > Randy: > We feel that we are victim of this discussion with confusing title. I > don=E2=80=99t want to comment on whether the intent is right or it is tim= e for > intent or not, you have your judgement, but: > 1. The liaison is sent to NMRG instead of this WG since they believe the > more relevant work is over there. ( > https://datatracker.ietf.org/liaison/1724/) > 2. The intent in different context means different things, intent > translation, intent mapping, combining with AL/ML is not in the scope of > this work. > 3. The ECA model borrows similar concept from RMON which is successfully > specified by IETF, ROMN is extension of SNMP, provides traffic flow data > for troubleshooting and provides the control to adjust for better > performance. So why not ECA > 4. ECA is abstracted from bottom up and use telemetry protocol as a good > basis and provide a clear semantics which is different from intent you > quoted from elsewhere. > > -Qin > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Randy Presuhn > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B43=E6=9C=8818=E6=97=A5 = 6:47 > =E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org > =E4=B8=BB=E9=A2=98: Re: [netmod] ECA Policy: What is an adequate abstract= ion level to > express policies and intent > > Hi - > > On 2021-03-17 4:15 AM, tom petch wrote: > > From: netmod on behalf of Randy Presuhn > > > > Sent: 10 March 2021 18:28 > > On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: > >> Dear Qin, > >> > >> I believe this work repeats failures of the past but since the WG > >> agreed to entertain this, I will keep my mouth shut. I suggest you do > >> not spend your energy to convince the that this work is viable since > >> it is rather unlikely that I will change my mind. > > > > > > > > Meanwhile the ITU-T has just liaised the IETF that it is starting work > on intent-based management. I have not looked to see if the same words > mean the same thing but guess that they do. > > :-) A risky guess, based on my experience. I vividly remember an > X3T5.4 meeting in which we *thought* we were wrapping things up, until > someone (me) foolishly drew an E-R diagram on the whiteboard, causing us = to > realize that although we thought we had reached agreement, we had in fact > been using the same words strung together in the same order to talk about > radically different models. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000ebb96e05bdc5d0ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Addressing only point 3 below...
Some article in the 90s claimed that RMON was going to replace SNMP= .
RMON is just another set of MIB modules. It does not extend or = replace SNMP.
It is SNMP.=C2=A0 (pet peeve of former RMONMIB=C2= =A0WG Chair).

Most of the RMON RFCs were widely de= ployed, but not all of them.
One lesson learned from these failed= MIB modules:
It is quite possible to use the SMIv2 language to c= reate a data model that
nobody can implement within the business = constraints given to them.
And therefore, no implementations of s= uch a module ever get written or deployed.

Andy


On Wed, Mar 17, 2021 at 6:07 PM Qin Wu <bill.wu@huawei.com> wrote:
Randy:
We feel that we are victim of this discussion with confusing title. I don= =E2=80=99t want to comment on whether the intent is right or it is time for= intent or not, you have your judgement, but:
1. The liaison is sent to NMRG instead of this WG since they believe the mo= re relevant work is over there. (https://datatracker.ietf.= org/liaison/1724/)
2. The intent in different context means different things, intent translati= on, intent mapping, combining with AL/ML is not in the scope of this work.<= br> 3. The ECA model borrows similar concept from RMON which is successfully sp= ecified by IETF, ROMN is extension of SNMP, provides traffic flow data for = troubleshooting and provides the control to adjust for better performance. = So why not ECA
4. ECA is abstracted from bottom up and use telemetry protocol as a good ba= sis and provide a clear semantics which is different from intent you quoted= from elsewhere.

-Qin
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 Randy Presuhn
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B43=E6=9C=8818=E6=97=A5 6:= 47
=E6=94=B6=E4=BB=B6=E4=BA=BA: netmod@ietf.org
=E4=B8=BB=E9=A2=98: Re: [netmod] ECA Policy: What is an adequate abstractio= n level to express policies and intent

Hi -

On 2021-03-17 4:15 AM, tom petch wrote:
> From: netmod <netmod-bounces@ietf.org> on behalf of Randy Presuhn
> <randy_presuhn@alumni.stanford.edu>
> Sent: 10 March 2021 18:28
> On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote:
>> Dear Qin,
>>
>> I believe this work repeats failures of the past but since the WG =
>> agreed to entertain this, I will keep my mouth shut. I suggest you= do
>> not spend your energy to convince the that this work is viable sin= ce
>> it is rather unlikely that I will change my mind.
>
> <tp>
>
> Meanwhile the ITU-T has just liaised the IETF that it is starting work= on intent-based management.=C2=A0 I have not looked to see if the same wor= ds mean the same thing but guess that they do.

:-)=C2=A0 A risky guess, based on my experience.=C2=A0 I vividly remember a= n
X3T5.4 meeting in which we *thought* we were wrapping things up, until some= one (me) foolishly drew an E-R diagram on the whiteboard, causing us to rea= lize that although we thought we had reached agreement, we had in fact been= using the same words strung together in the same order to talk about radic= ally different models.

Randy

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000ebb96e05bdc5d0ba-- From nobody Thu Mar 18 01:05:19 2021 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 12EB33A21AE for ; Thu, 18 Mar 2021 01:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5dpIj0rLHWv for ; Thu, 18 Mar 2021 01:05:14 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1DD3A2422 for ; Thu, 18 Mar 2021 01:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEEIOhY2htxh5yfDsM/ffMBK4oBWQrBMv0dSL+GUfGUcXlNZ+KLoNMAyDEQsGXuuTlhK/ohK1GBy92rk7Iz/Ya43WReIZth2EW2r/VAE03H3e8qKupvBh3nA0IyzsjFEKgKGLpF+O7NNcGPEwcxvSIYCSqw4yyqKKiHFkokVvh6h+Q95WfMCYfJ8UY0cgB8nZsEVMXbP1XT62YWOFoSexdRkZ+ZmMmfzjpzsek5Yn2XN3farZTXTiiKOs8T9hNla+n6CpKBnSxUMGjlt0hsAVdbv0SwzNan+Ntij/U8/MQfldpqMSEqZDF5nem3VzbrxqRqGW+S0yT2uOj98T20uMg== 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=CFZPtkbPzD7Mx5qU93DsLo4dMhaQNiddzRXUJ0mC9ZY=; b=lDFXx0TUC05EmmXZ+NrAsFqVX1Fnv3ZSCfk8N9QnepPBDrSGk/9LKs3aYkSUaCFpo21UTWCK+BQmMY9Pu1WmMHrAGR9DqQfJWLwUCRmckrp4KhF/R3SKhYA0QKvhH8oN70maz2TLYizMQ1JGOPosHkCicsSgeYeppeDFhVgjLhhTycK9WQE7bYmlx/nY1IWiibXe4wyb38Z6TfAmPY8DcvD8S+nBpFhz+aRq8rkNDx/dkAZhB5eProX02xPRpDlsyOwt34euYzaxMchZCv438N39VxQS+pzAPXPWUCwrG1263LkOsmPN2Ys+6Tiz3BsjlWEUQtT+iRvKQ/Bwcj48KQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CFZPtkbPzD7Mx5qU93DsLo4dMhaQNiddzRXUJ0mC9ZY=; b=fnh8zftuKg9W9mV8+SXRoyQvCwzIpeMjVTq3YcZsUDomUO6Dz4MygzUSkoNXY7TVsHOGjfv7eUcBEiJKPGFqNccrtpu9vCfVJN1tS3Vgh6aLiREu0cXYtJlCGXcIjNMhgTcGUGWZRQ1PoQWqlD6Xuyl4Rj7BodD1zlISAWf2iRk= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0739.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Thu, 18 Mar 2021 08:05:11 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3955.018; Thu, 18 Mar 2021 08:05:11 +0000 Date: Thu, 18 Mar 2021 09:05:07 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: netmod@ietf.org Message-ID: <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , netmod@ietf.org References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR04CA0061.eurprd04.prod.outlook.com (2603:10a6:208:1::38) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR04CA0061.eurprd04.prod.outlook.com (2603:10a6:208:1::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Thu, 18 Mar 2021 08:05:11 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2fd3ed05-4888-49ba-978e-08d8e9e48da5 X-MS-TrafficTypeDiagnostic: AM0P190MB0739: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +pek2jaODaAl5cvID9gDxUzvbXN4UxIG6WqlXUQyi3wqS43MwgjEs68sDdvVM1PeIz3psAYm562c7FGekoIqcdb/+CJAp4gHFCE9LlhWjtriaT0FeYHZCgnalUkQgFn3fVu+Mes0D4BB+DgRincUzVZe597Eb93oT2GwrbF1d41H5BGgeQLsDklFmakb1DkQEQIG7C7YluwrklJpr1AR8dUdzIk1Pdzyatmy4UGl9GIHCETf5Kq6aF1RYaF1hJlbFElZcCwb8/z7YAmoZVGWoxymO0DocpAMlnKPs7cOA9CP2u5DJluMdEOyZZFMe4qRQIDPpyOM1B5k6ulPeHI8ue3erHnwkbza1MqfTcCTNRmsotgxeJ6IggKTBmGkbOeU73jKRrvLyehYtJVV5h3Uh4s2HVS2SfLbT6NHTbrR3RjW4H0OO1F8SRBRIiWDdYw7i3ayGwn8bT8BjM4YhEePjDkT9gh3mgccbHl/d9piiUric0e+r/ddhaMfbmF61kkGMMurVxiI33aY1TAp3uGIJjlHxo/drzqc/sssgJpfOFCGPxnbEXTvwbV5cPPDQiqydPzx+4OuV26WG6e6ui8/i4kYDXmHsKfbSjrQ0hZoYDVPW7btSZSMq76vaSc0IrAIRyjl7axs1tf3wspSfpGDNbe603K6Y+K0YP29l6uMmuMXgisCB3k0W7sSXFgHehFB0Hqn2IgvTu1xmZ2csh5dUA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(136003)(39850400004)(396003)(956004)(66476007)(66556008)(6496006)(4326008)(6666004)(16526019)(8676002)(6486002)(1076003)(66946007)(8936002)(52116002)(86362001)(5660300002)(186003)(966005)(478600001)(3450700001)(6916009)(2906002)(316002)(38100700001)(83380400001)(786003)(26005)(170073001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ZktQb0NvNmRFN2xQU0xiaGltc1Q3RzJybUdZbW96b1B3bjRGSEdESWpPajhq?= =?utf-8?B?ak5BVmF2RzA1bEJoWjQyczd1TTJBN1c0QUk0a1ZWRGwyQUtJSGIzUEk0MzdT?= =?utf-8?B?YWVxSjdWbldNSVBUWnZQR0hVTDJxM2NlUUhlVXByZjRXanVwTXdrNkh6bFdz?= =?utf-8?B?S0JGYXNDUGl0MER4N3VuaSswTTJzWS9uN3pVV0ZnNThVYUZ4UFRnWGJUZWZE?= =?utf-8?B?WlZiM0xlV2szc0RvNnRIeDRPNXArZjRjQTVsN1J5YVp6L0Rkc0lxRUlENllh?= =?utf-8?B?aUcweVJuaUc3T1ZWOHk2VVJnSS9pTU0wUHljTlE1a2ZWLzNzdVBsa2J4WFl0?= =?utf-8?B?SjR2dWFvUEc5bnY2UVQ0WGxEVnVkR3FpaW5OY01MS1BUNzZnclFLZDlTNFZi?= =?utf-8?B?UDRZbkU5anFhSDh2bm5jQ0NzWEsraVNMYUJPOFU3M29DUXIySFAvSHdZbHd0?= =?utf-8?B?cHdEcUNIMW9TQ2gxdExQNXgvNUU2ekprMnErYTM4a1h5ZlBPUTdMeERaQ0VM?= =?utf-8?B?Vk9FMDFuNjlwOVAyclhKTWJOaWV6VkFzek9jRFAvazRkU3M0TE5rM1JKRkpy?= =?utf-8?B?dVpTMjU0d0RPNXF6ZFZHOW1NMEZaTG9lb1JxcmJzalFkRHkwZ1FZY2RyT3ZB?= =?utf-8?B?cmR4RFd3bTc5b0NNU0g0dDlFS0RjcjNaQnlvazdGaDh3OWllZUZOYjlZZDBr?= =?utf-8?B?NUsxdnlNRnE2MkNLTWFUWEVteUZEaE05TmJWa2ZHZUhiRTh3TGlqYkExNzNo?= =?utf-8?B?SDQ2K1FIZmsyNGFLU0dhQzBPbTVBcmR6djdzSkhwb0VCNTdjU3M3QVVieWd5?= =?utf-8?B?Y2wxQ1lhWENEZXAvQTFYeTBGUmVXZVVlT2ZkMUp4a3VGd2VWNE80cEpFR0hI?= =?utf-8?B?NEpMVHdWTWpBVHVDZnBUT0pWTmFsMGIrUWJvbnBSajB6ZE1KdUkzZlpvVzAx?= =?utf-8?B?NlRjNWlXOHozNGtycHpubHhHYlRlWUV1VEZJM3JYcThJV0h6TUJRN1B3b3Ev?= =?utf-8?B?K0oydktiMzJUajJNNXc1aWhINlBpekRDR2ZiTzRYaVhGTUtyRlZFNkRSOHFB?= =?utf-8?B?a3M5bGRxYmhLVElVYjI5cTdHcG9YN3lHRyt2NGRrOVpuWEUzRmdRTCthNW55?= =?utf-8?B?NEppeFAvb1NKY2dDdkdpZ2F3NkxhcjdXLzMyR3hwYWJ5c2MrR0FKRndMUWZn?= =?utf-8?B?andIbnF3cThtcXBNaVJFdjNGc2FhM1QrNkJVQm5vNEtBcmYvTzN2ejhjQkJs?= =?utf-8?B?dmVlY0o4Sk9HU2trbGdERVFoVFhKQTM4N3g3SklFRnF3ZGYzSS9PM1ZFdVp1?= =?utf-8?B?WFB0ODNKTlp2cmZKNjZMVVdMazAvK29wclRXMUhHY29oaUZ2Z3JWb0UxVGFV?= =?utf-8?B?eWhPOUttK1MwdGJzTXE0NFh0aVhoMHFibTFkYjlvKzFCNW1VeDhyQmNvaVBa?= =?utf-8?B?T1NVbUJGSHRNbEM5eVllMWoyV3gyRnBFcmFhMEJOSUI1bmJsWm9EUG5wMTYv?= =?utf-8?B?ZXB4V0lHbWUydjFDOGRpRjNyaHo2UzN0cyt1VDB0eXBaVkxvdXJTOTNGK000?= =?utf-8?B?bHFKenZxdVFtZUtpbUE2R2ZIQWs0ZUpsR0MrUUNLRXIvTzFuN2g4TnE2RmFy?= =?utf-8?B?RVBVWmRJcmJEZ05KTytqU1JRRm5tT05Mc3JwMDdiUnBrSXBYbDgzc3BqVHdj?= =?utf-8?B?V1hLWXZPL3ZPRzE1MEpzVGIrRHh6NlM3SWUxZE5Ed0VYaEljT0w5Mk15VVo5?= =?utf-8?Q?g21Ntapybl7mvOREQLZNZDfe4P/Sb7BCl8yPzPq?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2fd3ed05-4888-49ba-978e-08d8e9e48da5 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2021 08:05:11.3709 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: l/ioMT9bKj4clsN+QMnCZ6XS7MG1bnvKaVrOIs6A7ZG/FZrcusK50pP0KXpWTxWbkDzTe9LZ8D1zOHDxM+eiNVkQEowgG+XGz5u0BxcO/dc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0739 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 08:05:17 -0000 We often do not do a good job in distinguishing technical requirements from usage guidelines. (And RFC 2119 keywords make things worse.) As far as I recall, the intent of the RFC 8407 text was to say that it is helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 'date-and-time' defined in 'ietf-yang-types'. I believe we agreed that module authors assigning a prefix different from the default prefix during an import should have either technical reasons for doing so (resolving prefixes clashes) or some other good reason to depart from the general guideline aiming to reduce human confusion. /js (who stopped believing that RFC 2119 keywords are helpful years ago) On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > I have seen the debate on the use of prefixes in YANG models, specially as it relates to their use when importing a model. I think it would nice to be clear on what is required, what is nice, and what is not ok to do. I do not want to confuse this discussion with the length of the prefix, which I believe is somewhat related but not the same discussion. > > RFC 7950 says: > > All prefixes, including the prefix for the module itself, MUST be > unique within the module or submodule. > > This is a requirement, as is clear by the MUST. > > Then RFC 7950 says: > > To > improve readability of YANG modules, the prefix defined by a module > SHOULD be used when the module is imported, unless there is a > conflict. > > It also says: > > When used inside the "import" statement, the "prefix" statement > defines the prefix to be used when accessing definitions inside the > imported module. > > Clearly, the scope of the “prefix" statement used with an “import†statement is limited to the module where it is imported and does not impact the imported module. As such, and because it is a SHOULD and not a MUST, this is a “nice to have†without conflicts, but one would not be wrong using a different prefix from the one defined in the imported module. Add to this, most tools, e.g. pyang or yanglint do not complain if you do define a different prefix when there are no conflicts. I have not seen a problem in the implementation of the module when the prefix is different. > > RFC 8407 confuses this whole situation by saying: > > The proper module prefix MUST be used for all identifiers imported > from other modules. > > which as written is true for identifiers (but not for other types of imports??). Besides, it does not define what is “proper module prefix". In the absence of a proper definition, one should follow what RFC 7950 says. > > Comments? > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 18 04:50:00 2021 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 1116F3A2900 for ; Thu, 18 Mar 2021 04:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWqd_ChBeZaB for ; Thu, 18 Mar 2021 04:49:55 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2098.outbound.protection.outlook.com [40.107.20.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5AD3A28FE for ; Thu, 18 Mar 2021 04:49:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LglIDwe2ttarOR8aax+Qg8YtW/2BnCIvD7bfLarnrcPPixE2iYBXeRuDYXQJrWhBHqxEK8E19LlIuulC1BSQtuKpTyhGJd5dI4sawIuSXv63fNGCdan4wGu05cV1a0z6ZBL0l7w8jgTckH3cgIev4CvfbOLM8qvD4xUNCXCVJGKISZmLGcKuEpi4xUsmTJpQzH03OJG/uQa/Ith3OxReK9ZeC3RZWic6PVpsDAAMEt5GFyKzR4rhsOUjzGGsB+kqs4B1gknDOS3S7MJEZFkfDmBiabiVNZlh1YNmXmNhrWGAfubsokdbI/ndAaXovBXpx6qXOANiA8g2Keqhcvlk1A== 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=o/cvOvbeCXokQMqPTvg1I21HSTmo4hRG21lgwNAzGJE=; b=Cucb2fLqijbJeB5PYl2gC5nHFRM09teTAs2NIkU3vMIEDZsqfGtf/sJFbcr/jjsFMbGloAl+pRAQodwvfWFy3hdABazk1qhbzw15zI7qpR2oevvUv9Lmti4gkMT72Xn2YTNteXMQ1TLHIgaVCz63Ezt+66pPvA1B3sGhli2X93sT113sqZ76dTZMh55M8tDW1KREhrNVHhBD3fLpcZCLbi3eMyjpARFvDY+aTfI4UQejY8qRl5ILNuDajkTNXf3+Zz27+Jn7cgpzxidBVIn8lTpBBPs5FhXNgM3jztLtbDqj9Xr5pthL4MBR4ibZFoIYcqsDXUucHql5M8sBXmhmbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o/cvOvbeCXokQMqPTvg1I21HSTmo4hRG21lgwNAzGJE=; b=YLcQCeJZJcq6Y93IUlKrtnTQ9wo7AccAI7MFKnO1/iHdplnDkiEFqJ5/c05mzOJ476BZZ/1t50rWx/nzzTmNo3gOzUj7K8Hr+a4om2p+T5SRDyFy5UPBg73eufxscj+HwbsDxa+SJzn6OqxBWVTyjvnadp+/oQScDqfgOX5rgT0= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR0702MB3560.eurprd07.prod.outlook.com (2603:10a6:209:10::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.9; Thu, 18 Mar 2021 11:49:52 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3955.010; Thu, 18 Mar 2021 11:49:52 +0000 From: tom petch To: Mahesh Jethanandani , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Use of prefixes in YANG models Thread-Index: AQHXG4oeNuzkx0+3DEiWrin2IABkWaqJY72AgAA85lI= Date: Thu, 18 Mar 2021 11:49:52 +0000 Message-ID: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com>, <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> In-Reply-To: <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e93831e0-c233-4113-e259-08d8ea03f119 x-ms-traffictypediagnostic: AM6PR0702MB3560: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FZ91GEAhhXQZqTJKigyBhTDt1+NinmOR8i7VISqcd56zIaS72u6VefGuA/suuTdtl4Jz5N4nuQ62OmYK4f4Ul3xvOEPTLncQf4CxOGVsv9JDGW1qoDgKvRTgtcn6TCU4xMrIyfgs5Az/dMYF2erTS0zX5MZn4RA2rF2AMpLa0k4aM8M2OZd9E6wzzP5bR9pXeZzdodU/OU8iOIPCNqfvfeZFEpP1INbhwcaN2eCloC2R0XufTzNFWXgdlMuJQcxjAx46i5qvBheMycA0rKrM6foa4GhpfpHzM+rq9Z61FC4gD7/2HYwod5X8r8VtCPBgZdBNMqOIFvcP7Iuww4wtsPL5W0NxoLG2/7lyIDb688q0pc4ALJwG5N4I6ScXe/yyTEhlEvqtjjlD9+MyiYGI29uTYcVaGhgH7DO+b6vTd+IHHKM5dfqbnKtOmzui0Xi4OVedKspKzoJZkALzT9CmA7UstK60jz6BRtAfPRH69u33/T7cmccZmJ3VvB4Xq3M6JTmHaZ1beMdLhV4YdPp2LSjqfmsCFIEoNSilmVKYQ4BKlV6ii5l0bCCU6mtNqL7VlKp+f82dwuLj+jNeAng9+ELHxBdWRK247GZOIEMXHVrgxzVc0rsEy7zMATqyCY6yrcjgQEcCdFma/EcNzS1DvxA4u+ZdkozLpotzrzxWzod9LcL6Xojbuv8MkVfOb1Xrh9uRhzLaGk5mfV0lT9rw3y7vXwDAS3WfM1m7SJriybI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(396003)(39860400002)(346002)(136003)(66446008)(9686003)(2906002)(66476007)(55016002)(91956017)(64756008)(66946007)(478600001)(66556008)(110136005)(8936002)(76116006)(38100700001)(33656002)(4326008)(8676002)(71200400001)(5660300002)(83380400001)(316002)(6506007)(86362001)(26005)(7696005)(186003)(966005)(52536014)(170073001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?SWdSvH/2YnWLzEo2pcFRNvg/2vXPwiO9naM2folVHN49Wh+j2pkgGJgx?= =?Windows-1252?Q?6jzQ5ZRXIS086DzipGtl1zqdBiT6HBqDOv43Saukvm3L8fqImh1AUAKd?= =?Windows-1252?Q?VBGYqtT6PkqTzbJRNgoY66Tkuz+a9PmLPRn6FOgXRe/Levlb5ZGdDSXP?= =?Windows-1252?Q?xzSOao25/GZWoXuT2GzKXXB2bQH7kmT6QSBnw9FskKHllfkkl5NIFzto?= =?Windows-1252?Q?UQewnsf7I3EEdDxHBmMvAunl4QU090YbYEtRRGPHQH1guaTfu71yLS/V?= =?Windows-1252?Q?O1zQ2cES4vt3JowdjoVy3VKoq3kYuXtmLDL5NfCaQj3fz9ay/tsjeAEr?= =?Windows-1252?Q?HFjaWGoPY3mwIZrXTsOJQdP0O3dL8wapMRwsqFRr32/q/a/FtMtXereG?= =?Windows-1252?Q?T22LK4coSag6O0FIsa0D31ZbsJAtl3xRxzhlw0ZVfTcw1fnEN8XXsp7e?= =?Windows-1252?Q?jfCKPTkC/NynJiyK4DINhsbcHHDfSxVO1RudWy0LDIstQjDrPnPGIGFH?= =?Windows-1252?Q?QHWfDkTumOtq+UFCfxphfBoPjr0pqhb/5uZWhZWprzO6d7xnbw95ITe/?= =?Windows-1252?Q?t94rDoIg+2XesPTHhkrkEb183wacCZLT7lBUbHuFx1Jhr9Jn90DhZo5R?= =?Windows-1252?Q?NPYfAp7aLmHs7Yjf45UAKkz5GDxB4kYraGjzTM3LVvOsvcpu71M0FKSx?= =?Windows-1252?Q?9cwSTXjxl5pSxHsLigNkS/xv/N1bVdq5/G6uA1Nd6sMf0PrmML2c1Dw6?= =?Windows-1252?Q?VDBAFNidOmp+P+cRDqajn7Zoagqr8ppXlTJfOVhBxHgxHf8/ra+ElTmb?= =?Windows-1252?Q?HexrSZDBPWVDKdXnJ8DpQa65bgaa44oD50vxh3Pk+tEM5ogTJUusq54u?= =?Windows-1252?Q?P6/8FXylbqUP+kp4fk246cX2GMCmx5AOe3PBvzMNl4J0vL1YnFreOtrG?= =?Windows-1252?Q?lofOEo/UPVF0a2J93YA7NFn+3D34n6TJJmxrp2NhoE33GNTW2peMuqwu?= =?Windows-1252?Q?pwNbUuDvbCbgHNHyNOOEuZ38Vy0+4k1n8QHHRL5oX1sPYA+Z+A5AOTq8?= =?Windows-1252?Q?k9BsE2CExSPlptPiTcoL0+ZJneH8OD+7Y71iCqCsnxn0g+nMdbCtMsEk?= =?Windows-1252?Q?JlGL1M9J/0pXkTEOmvZUgj805b0qg2rQCGQEt/sr9EshNUihgD4qHsA9?= =?Windows-1252?Q?w51KKBn98ryIDyLhCh5mtZR+fAIzQIG5dxbsgohX+2wGtsfe5WiFdM4F?= =?Windows-1252?Q?OHyCfg0ps+gxtsdASEFNkFdxRHj3XbmUO8ejL/Z6U0Rw6r+CQqP1b6rh?= =?Windows-1252?Q?8Sr+FgIiqBRI8tw7gHrHv136+bJpBLAWgUawIp2P5rgl7Zeyo17naur4?= =?Windows-1252?Q?89Hge2/hhVmkVIga+LeWDoSPoXZqg3OTEhM6eSbeiGuQF3lUZKNbMtqO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e93831e0-c233-4113-e259-08d8ea03f119 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2021 11:49:52.3064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RRO0tcQnNIdl3y62jP8A+wTDUjDwuNFQ7wsaiJg1uo15mnWzLl5zJXhmT+N5atvxqzxvTpFtyV/MoEproqYong== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3560 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 11:49:58 -0000 From: netmod on behalf of Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de>=0A= Sent: 18 March 2021 08:05=0A= =0A= We often do not do a good job in distinguishing technical requirements=0A= from usage guidelines. (And RFC 2119 keywords make things worse.)=0A= =0A= As far as I recall, the intent of the RFC 8407 text was to say that it=0A= is helpful for _humans_ to always use 'if:name' when you refer to the=0A= leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when=0A= you refer to 'date-and-time' defined in 'ietf-yang-types'.=0A= =0A= I believe we agreed that module authors assigning a prefix different=0A= from the default prefix during an import should have either technical=0A= reasons for doing so (resolving prefixes clashes) or some other good=0A= reason to depart from the general guideline aiming to reduce human=0A= confusion.=0A= =0A= =0A= To make an abstract concept concrete, draft-ietf-babel-yang-model imports y= ang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time o= r yt:counter32. An early YANG Doctor review by Radek did not comment on th= is aspect of the I-D. More recently, I have.=0A= =0A= Tom Petch=0A= =0A= =0A= =0A= /js (who stopped believing that RFC 2119 keywords are helpful years ago)=0A= =0A= On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:=0A= > I have seen the debate on the use of prefixes in YANG models, specially a= s it relates to their use when importing a model. I think it would nice to = be clear on what is required, what is nice, and what is not ok to do. I do = not want to confuse this discussion with the length of the prefix, which I = believe is somewhat related but not the same discussion.=0A= >=0A= > RFC 7950 says:=0A= >=0A= > All prefixes, including the prefix for the module itself, MUST be=0A= > unique within the module or submodule.=0A= >=0A= > This is a requirement, as is clear by the MUST.=0A= >=0A= > Then RFC 7950 says:=0A= >=0A= > To=0A= > improve readability of YANG modules, the prefix defined by a module=0A= > SHOULD be used when the module is imported, unless there is a=0A= > conflict.=0A= >=0A= > It also says:=0A= >=0A= > When used inside the "import" statement, the "prefix" statement=0A= > defines the prefix to be used when accessing definitions inside the=0A= > imported module.=0A= >=0A= > Clearly, the scope of the =93prefix" statement used with an =93import=94 = statement is limited to the module where it is imported and does not impact= the imported module. As such, and because it is a SHOULD and not a MUST, t= his is a =93nice to have=94 without conflicts, but one would not be wrong = using a different prefix from the one defined in the imported module. Add t= o this, most tools, e.g. pyang or yanglint do not complain if you do define= a different prefix when there are no conflicts. I have not seen a problem = in the implementation of the module when the prefix is different.=0A= >=0A= > RFC 8407 confuses this whole situation by saying:=0A= >=0A= > The proper module prefix MUST be used for all identifiers imported= =0A= > from other modules.=0A= >=0A= > which as written is true for identifiers (but not for other types of impo= rts??). Besides, it does not define what is =93proper module prefix". In th= e absence of a proper definition, one should follow what RFC 7950 says.=0A= >=0A= > Comments?=0A= >=0A= > Mahesh Jethanandani=0A= > mjethanandani@gmail.com=0A= >=0A= >=0A= >=0A= >=0A= >=0A= =0A= > _______________________________________________=0A= > netmod mailing list=0A= > netmod@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netmod=0A= =0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Thu Mar 18 10:07:07 2021 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 A770E3A2FDE for ; Thu, 18 Mar 2021 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5QSBda9DD3w for ; Thu, 18 Mar 2021 10:07:03 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2116.outbound.protection.outlook.com [40.107.92.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF223A2FDC for ; Thu, 18 Mar 2021 10:07:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OnQIyiNsbM43rpcpaNREsmR0pmRukIs9OwUonre8IdfyWxskEb0XVevRpvlPo8N84fAtbKEQ57T2cFa+y4JxuaXg2ZXUy1nn65j/9UFp3d5kvghqQF0paxehdKQDhcvoZb6h/58YRxTVOOUShjf9k7WmL/w1GAU/Anjn7sNs9iha6LfOb9mZSaJ5/oi60yk3PK2i5EdrFkZiF5fWLsLiSRSDEIKr+ZyP8b695tc4cxp2DukDqaBJH79KNJTAAD+5T6DdtM1Cnd7LUqOtEefP4sj9tU/zMh2kftVsJxyc5/y+satBbjOqvuJSl7VRVemQXRSWSgOtui0i0frlAj4eKg== 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=GUB4+pLm6daq3QLpgNBAwy+sw0A0NNJ4KdaKIBYSzdU=; b=N+pi8CK/O1WTftLTCiS0xTeLTdnD6S24goaurGmeGB8AmCKYViJiQJKIiE7z7CtdY7SsMqm6V+VynZmnAB43/S6Wm8LmsxpYUCXdzcE6YTjiCOal2e7xsQ4JaMH0oLUeMtCEhpO7cHpQVKydrbSquDJyWX8cCNM/A3ZhOxnB8gYsDywXHbd09aOXaR6MvMhdQpoo6hqUaPOocVSh4RhVixNUIkRQLINWZhTGLo2XfARz2CZVEYcGfglivPk7VIJhwd8GikLzoEpA1o7MnqZiMRG2HMK4S5P2Ij/ymuS2Pqy/AuJYgLe2DrRPORMaYXYywR1POckqeqscRKYWiW/7sQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GUB4+pLm6daq3QLpgNBAwy+sw0A0NNJ4KdaKIBYSzdU=; b=J0cgFUh1ZGoBqJ8L5Kev0PzZqOEC4WLpND0k53EkdpVa6C9OiDMNmr9+wEbC0PkZghWfAraYknSqzlIw/HoQv3kv+8F5TWroO3c21TTt9jVdrZCo41BXSClSsUHvgNz8VCnAaxDA/Wow414EQOaMP1DlwWS0TQD1KkoWX2Rvi1A= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by BL0PR14MB3716.namprd14.prod.outlook.com (2603:10b6:208:1cd::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Thu, 18 Mar 2021 17:07:00 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a%6]) with mapi id 15.20.3955.018; Thu, 18 Mar 2021 17:07:00 +0000 From: Don Fedyk To: tom petch , Mahesh Jethanandani , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Use of prefixes in YANG models Thread-Index: AQHXG4oeBf3NvMSv8UyT0rE9HMwK0qqJY72AgAA+ywCAAFPJMA== Date: Thu, 18 Mar 2021 17:06:59 +0000 Message-ID: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com>, <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2fba383b-f6ff-4275-287e-08d8ea303e7d x-ms-traffictypediagnostic: BL0PR14MB3716: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uojHss7Eh4nnzHjdwSbfYEJULS5BsFG9AQs87wxiM5D9K3qOQxbv/mLlh+97vxIlgk26SuQoz4M2lBv9yrj7DvMs3I+2uqdLPsb5UiX3ZH9UGUSwEmv/4RAHNEMHlo+2rulPy13xzbSnU7d0oMN7uqw95l2QXdtfYnSJuTriuMTRZrJaasFAWx/GY7e52Nd5pBk7oSbUhbHWij6RSW+ZXiRV+vgg/mbyUiNo8OZFhmUF9E3AA3H/A221pVE2Oier93EeLLQJxiOFh6gBZYYMdjz5NWZAwff28wrAS+0aM+0VDp6FsizG99yaKZr+G1OZx52MfW4+39eb7VSSr4wO5jYlrckDy8GF8p+7cYm4aUlmhnYBwZ0A4/TYClN7b8bSWkdBwLulX5ZhMgzj6IP5iBMsjqPL33fAQ/eVafvNzq4EyubrqeVHjBTDfuMwTIhj1WCDS7SoekZqgOWpQvW3EsjAQmpI2DkxE4QGcJy3MCJR3hPgKI0yI26IgRE8cW3VoIhn5CSOB76KXxg4/X45TXODRzmSgf2Cd/94Ec3vYnJtrkBSdDz82MKHNg+DHAUZat1/jnaPh7Uuee365QIRhSte5kGJiX9OtGL9KeE1gBee9yLRPOVAh87qJreYqf9rxjbtrtAZDIZhUPSL9narVdgAVDbl38GTm64Eej5fvc7Ied19AKEL9e1O0XE/6zhDaxYmqHsdvai7idT3IeLgZByhrq7/T51KWGkE09lGqzg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(396003)(346002)(366004)(376002)(136003)(83380400001)(7696005)(86362001)(478600001)(26005)(9686003)(296002)(71200400001)(966005)(64756008)(53546011)(4326008)(316002)(8936002)(55016002)(38100700001)(6506007)(110136005)(66556008)(8676002)(66946007)(33656002)(66446008)(66476007)(76116006)(186003)(5660300002)(2906002)(52536014)(170073001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?uV4Un+d6G1gFoSNkkbaMbphIYEcsN7MbAc6V/4sx4BJGVIguY3JAHsqipSfz?= =?us-ascii?Q?wdfLATO6nAunJ3mRr8Cqm9ycjzoHFNKil+bnQNUvm/ffV0KiJVYBDzPuV31A?= =?us-ascii?Q?BMqy9BoYtcOBIUgWWwHbykkSvN1T/7120s+E+dGZ8S/Msw/7+RiLGANORxc3?= =?us-ascii?Q?mbB79IuaVl3PKgLMLABdG2D1SYClt5++k7qPoXfj5hrJKqWTEKSdBLU+981m?= =?us-ascii?Q?eKdAWcT7VVznT81MPXbpiTtTzhRsUOuoBDgyQyY1//EF4LnFDjL/UxHo3iZ5?= =?us-ascii?Q?Nbv8Kox2GhPmCg702lwgrwRlbSUBE/h4YQ8OhZJIsw2vcpcN+wXFECAZ6BmE?= =?us-ascii?Q?pIEnalqkPGP2/t//mCxkjTLk1kqfPHLe7Th1Pc3prrYRWVW1PAqmiMb1ibE1?= =?us-ascii?Q?jq5Sc8G6bLeg4InTIbhk01C7kQjNoy0gpd5fgNOai3HZZSW8m8DR3zn2g6MK?= =?us-ascii?Q?YUHfDnFUIajKvy4XhsCMx4CLZ6oxV1eWGA9pNGWu6JVLHHcLCahLq/F69qFu?= =?us-ascii?Q?RXwnZ+jP9QviHgSA9s55iMNZK0xRyWnSWLmuqaw+SZdaB6Z279qOjd+FD68O?= =?us-ascii?Q?xUwNmvNzxlXbr002M5lVJ+P8lV20zwMEenKkRWipnHn+81Pa5nNyAsiYPRxZ?= =?us-ascii?Q?rKliyk37YnkznhuiA5+MXHCfsWdYTcIub4s1UUyauL5QE2JtiEjZ7W6cmAM6?= =?us-ascii?Q?B5Ua/oApOsmbCGyMf4sMtr2+x4jguNVUvQbTmr5wZ09zgHIf73KOdJKybbGo?= =?us-ascii?Q?A1RvV+Hu629ywly1CDgB+OpxXkAnt/QKyu/OQAC/82lpXS/C00/RspSVf6pw?= =?us-ascii?Q?0j8PXf2GsyozvRkfZEkoaGahfx1xTgDXDbXswgo6kfL9qnkIlTBZVFI216YA?= =?us-ascii?Q?tC3pl53RO5moZEyLZC3Mebg9GbPy9qIvG7VYXus8BPR7i5qfZui6fcVPl1jG?= =?us-ascii?Q?lrnOrO2G3npA6vJPI4/7BMVVHYlsgJPIQa2hEcpeFrl7N4hMuHo8oeIhafF5?= =?us-ascii?Q?ApTY3aUx9c66YMKYe/gXVCacWyOlDzMUypNzStbDi1b8E9GqWUXwJFvH5QTn?= =?us-ascii?Q?sYiW8fWt4tBHP9I/FRtMK12+OYCAujeaBgNxi4BHKJ+l/RqRBeH9vaG0sAnp?= =?us-ascii?Q?C9sa1rDRdWcrvVsgBnuR4DeZf5aqd0jP981AJLgFkxb7qC/1bVvmA368IZes?= =?us-ascii?Q?Jy+rlRi1QUPfE8P3zpESlL0k+UU/bNZWMglSdkhgUFR2jEjS3tCpd64ow1Wp?= =?us-ascii?Q?eaJcFqtyuf3kzHEihxAwspfSzNuVRnL0hiBy74TwVNefCw7ZkaRMIU+8jWNp?= =?us-ascii?Q?rYApeshPGTUJfVI1/8krA3KS?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2fba383b-f6ff-4275-287e-08d8ea303e7d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2021 17:06:59.8787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: h2ldVlEKuEalDu4GdrZjKeSPL4dzGCWrcuKNRFRI2GdH2+0pAQ0X7Y7nozr70HE1AOGqpIlSanZQapClayziKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR14MB3716 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:07:06 -0000 Clarity and consistency would help. Many of the supporting tool chains are picky about prefixes. IE they must b= e the same as in the definition file. I have a case where yanglint wants "= local prefixes or derived-from(-or-self) construct" for an local identity i= n an xpath statement. (either remedy seems to work.) I argued for the prefi= xes in but others argue they are not necessary but I cannot validate withou= t them.=20 "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works (p= refix/no prefix) But "../../bridge-type !=3D 'dot1q:two-port-mac-relay-bridge' works too. Thanks Don=20 =20 -----Original Message----- From: netmod On Behalf Of tom petch Sent: Thursday, March 18, 2021 7:50 AM To: Mahesh Jethanandani ; Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] Use of prefixes in YANG models From: netmod on behalf of Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de> Sent: 18 March 2021 08:05 We often do not do a good job in distinguishing technical requirements from= usage guidelines. (And RFC 2119 keywords make things worse.) As far as I recall, the intent of the RFC 8407 text was to say that it is h= elpful for _humans_ to always use 'if:name' when you refer to the leaf 'nam= e' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to '= date-and-time' defined in 'ietf-yang-types'. I believe we agreed that module authors assigning a prefix different from t= he default prefix during an import should have either technical reasons for= doing so (resolving prefixes clashes) or some other good reason to depart = from the general guideline aiming to reduce human confusion. To make an abstract concept concrete, draft-ietf-babel-yang-model imports y= ang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time o= r yt:counter32. An early YANG Doctor review by Radek did not comment on th= is aspect of the I-D. More recently, I have. Tom Petch /js (who stopped believing that RFC 2119 keywords are helpful years ago) On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > I have seen the debate on the use of prefixes in YANG models, specially a= s it relates to their use when importing a model. I think it would nice to = be clear on what is required, what is nice, and what is not ok to do. I do = not want to confuse this discussion with the length of the prefix, which I = believe is somewhat related but not the same discussion. > > RFC 7950 says: > > All prefixes, including the prefix for the module itself, MUST be > unique within the module or submodule. > > This is a requirement, as is clear by the MUST. > > Then RFC 7950 says: > > To > improve readability of YANG modules, the prefix defined by a module > SHOULD be used when the module is imported, unless there is a > conflict. > > It also says: > > When used inside the "import" statement, the "prefix" statement > defines the prefix to be used when accessing definitions inside the > imported module. > > Clearly, the scope of the "prefix" statement used with an "import" statem= ent is limited to the module where it is imported and does not impact the i= mported module. As such, and because it is a SHOULD and not a MUST, this is= a "nice to have" without conflicts, but one would not be wrong using a di= fferent prefix from the one defined in the imported module. Add to this, mo= st tools, e.g. pyang or yanglint do not complain if you do define a differe= nt prefix when there are no conflicts. I have not seen a problem in the imp= lementation of the module when the prefix is different. > > RFC 8407 confuses this whole situation by saying: > > The proper module prefix MUST be used for all identifiers imported > from other modules. > > which as written is true for identifiers (but not for other types of impo= rts??). Besides, it does not define what is "proper module prefix". In the = absence of a proper definition, one should follow what RFC 7950 says. > > Comments? > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Mar 18 10:23:13 2021 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 8E4D63A3023 for ; Thu, 18 Mar 2021 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2d9J3Zl9sa-Y for ; Thu, 18 Mar 2021 10:23:08 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256173A3022 for ; Thu, 18 Mar 2021 10:23:08 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id o10so5797016lfb.9 for ; Thu, 18 Mar 2021 10:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wd70mz7ntO+2GMHA1KHhubOTC9IRO0mhXhaTI7En698=; b=ihxNcKTg+XUWA3peTSjInPPhTtfUR84Yk7eb7+nSJzZ3Otjk1oqOtkGh0CZzmzdzo9 AJPYyadhgsc1Cjrt84NQvOsB6f6vozabtmOkKhDHkDnUDXK2lHD+cu/StZp06EkwFlLe 9bET5WVqbrFXOO9dOlcAYx1Fp4e0AikvUlIPP472B+3e2Od+D4ZErJPtLi9K0TkhsBgI 29KR97Nh5/NiFPMjV2WFl1WYmOcyon5zVtjtDHDue3gWCWC4H/waP9OXZiglseH8GhVK zQWRHr3PKbMHZ9Cr2QCxM8rjGs7vcXH70y/dBgMc0RV7Di2rCZEauNYDQB/zwsB/L/F/ iZaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wd70mz7ntO+2GMHA1KHhubOTC9IRO0mhXhaTI7En698=; b=oLGg9DslH/ekullPsHYZBZvxcs6cVv2uP3yKWQKU/JTAR9FXVlysxnF/REZ9fzFwZL NPIiiQ8We+a3KURvcIrjnRy/cCWudZ3XVeLm0Ax+3WOHMD2SlsWERGkkWQsZaazfex3L RW1Ua0dRhQZCePSESqC+UyvbQWzQtfiEFuSLjM0/NJyQEfPNtE4gWwkkBJeqRDM66iDZ e1UroE1BFuQtgBboxV49HZvIBaSI4ghDYrUtdLs9AScyB2X50LemzPyNoh5BfcIZzlBx /WgSFyJjOZmnIi3lU4rsuHwNnXYKl34Nm5FxlKnfgQDgfSvMzqMsL+TUotMylaItkY1b iefA== X-Gm-Message-State: AOAM5309TArpyqEAdPdb8JrbYzOjI/C9Lf5OUDPuBIrasrXKKLseB9ja FQqxBqppZiNNBsRgg73BCa8udJ9QsTdVCqU0+eu5/g== X-Google-Smtp-Source: ABdhPJxwNYL5LrVxbqyJNTmOp+GiKTK5vIy3dE6krB//LaShG7Hob+3xL8bqW70HiebIx0+mXl4SVXW6qhnxv4D3IfU= X-Received: by 2002:a19:b81:: with SMTP id 123mr6026809lfl.553.1616088186309; Thu, 18 Mar 2021 10:23:06 -0700 (PDT) MIME-Version: 1.0 References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Thu, 18 Mar 2021 10:22:55 -0700 Message-ID: To: Don Fedyk Cc: tom petch , Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000045670405bdd2da7e" Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:23:11 -0000 --00000000000045670405bdd2da7e Content-Type: text/plain; charset="UTF-8" On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk wrote: > Clarity and consistency would help. > > Many of the supporting tool chains are picky about prefixes. IE they must > be the same as in the definition file. I have a case where yanglint wants > "local prefixes or derived-from(-or-self) construct" for an local identity > in an xpath statement. (either remedy seems to work.) I argued for the > prefixes in but others argue they are not necessary but I cannot validate > without them. > > The tool makers should understand that YANG prefixes are not required to be unique. It is understood that short character sequences have a high probability of duplication. So what if the server wants to support 2 modules with the same prefix defined in the YANG module? Is it not clear that the ENTIRE point of having the prefix-stmt in the import-stmt is because the imported modules may have prefixes that collide? Andy "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works > (prefix/no prefix) > But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge' works too. > > Thanks > Don > > > > -----Original Message----- > From: netmod On Behalf Of tom petch > Sent: Thursday, March 18, 2021 7:50 AM > To: Mahesh Jethanandani ; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> > Cc: netmod@ietf.org > Subject: Re: [netmod] Use of prefixes in YANG models > > From: netmod on behalf of Juergen Schoenwaelder > > Sent: 18 March 2021 08:05 > > We often do not do a good job in distinguishing technical requirements > from usage guidelines. (And RFC 2119 keywords make things worse.) > > As far as I recall, the intent of the RFC 8407 text was to say that it is > helpful for _humans_ to always use 'if:name' when you refer to the leaf > 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer > to 'date-and-time' defined in 'ietf-yang-types'. > > I believe we agreed that module authors assigning a prefix different from > the default prefix during an import should have either technical reasons > for doing so (resolving prefixes clashes) or some other good reason to > depart from the general guideline aiming to reduce human confusion. > > > To make an abstract concept concrete, draft-ietf-babel-yang-model imports > yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time > or yt:counter32. An early YANG Doctor review by Radek did not comment on > this aspect of the I-D. More recently, I have. > > Tom Petch > > > > /js (who stopped believing that RFC 2119 keywords are helpful years ago) > > On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > > I have seen the debate on the use of prefixes in YANG models, specially > as it relates to their use when importing a model. I think it would nice to > be clear on what is required, what is nice, and what is not ok to do. I do > not want to confuse this discussion with the length of the prefix, which I > believe is somewhat related but not the same discussion. > > > > RFC 7950 says: > > > > All prefixes, including the prefix for the module itself, MUST be > > unique within the module or submodule. > > > > This is a requirement, as is clear by the MUST. > > > > Then RFC 7950 says: > > > > To > > improve readability of YANG modules, the prefix defined by a module > > SHOULD be used when the module is imported, unless there is a > > conflict. > > > > It also says: > > > > When used inside the "import" statement, the "prefix" statement > > defines the prefix to be used when accessing definitions inside the > > imported module. > > > > Clearly, the scope of the "prefix" statement used with an "import" > statement is limited to the module where it is imported and does not impact > the imported module. As such, and because it is a SHOULD and not a MUST, > this is a "nice to have" without conflicts, but one would not be wrong > using a different prefix from the one defined in the imported module. Add > to this, most tools, e.g. pyang or yanglint do not complain if you do > define a different prefix when there are no conflicts. I have not seen a > problem in the implementation of the module when the prefix is different. > > > > RFC 8407 confuses this whole situation by saying: > > > > The proper module prefix MUST be used for all identifiers imported > > from other modules. > > > > which as written is true for identifiers (but not for other types of > imports??). Besides, it does not define what is "proper module prefix". In > the absence of a proper definition, one should follow what RFC 7950 says. > > > > Comments? > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000045670405bdd2da7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 18, 2021 at 10:07 AM Don = Fedyk <dfedyk@labn.net> wrote:=
Clarity and con= sistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must b= e the same as in the definition file.=C2=A0 I have a case where yanglint wa= nts "local prefixes or derived-from(-or-self) construct" for an l= ocal identity in an xpath statement. (either remedy seems to work.) I argue= d for the prefixes in but others argue they are not necessary but I cannot = validate without them.



The tool makers should = understand that YANG prefixes are not required to be unique.
It i= s understood that short character sequences have a high probability of dupl= ication.
So what if the server wants to support 2 modules with th= e same prefix defined in the YANG module?
Is it not clear that th= e ENTIRE point of having the prefix-stmt in the import-stmt is
be= cause the imported modules may have prefixes that collide?



Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'= ;))" works (prefix/no prefix)
But "../../bridge-type !=3D 'dot1q:two-port-mac-relay-bridge'= =C2=A0 =C2=A0 =C2=A0 works too.

Thanks
Don



-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>; Juergen Schoenwaelder <j.s= choenwaelder@jacobs-university.de>
Cc: netmod@ietf.org
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod <netmod-bounces@ietf.org> on behalf of Juergen Schoenwaelder <<= a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D"_blank">j.= schoenwaelder@jacobs-university.de>
Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements from= usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is h= elpful for _humans_ to always use 'if:name' when you refer to the l= eaf 'name' defined in 'ietf-interfaces' or 'yang:date-a= nd-time' when you refer to 'date-and-time' defined in 'ietf= -yang-types'.

I believe we agreed that module authors assigning a prefix different from t= he default prefix during an import should have either technical reasons for= doing so (resolving prefixes clashes) or some other good reason to depart = from the general guideline aiming to reduce human confusion.

<tp>
To make an abstract concept concrete, draft-ietf-babel-yang-model imports y= ang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time o= r yt:counter32.=C2=A0 An early YANG Doctor review by Radek did not comment = on this aspect of the I-D.=C2=A0 More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)
On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, speciall= y as it relates to their use when importing a model. I think it would nice = to be clear on what is required, what is nice, and what is not ok to do. I = do not want to confuse this discussion with the length of the prefix, which= I believe is somewhat related but not the same discussion.
>
> RFC 7950 says:
>
>=C2=A0 =C2=A0 All prefixes, including the prefix for the module itself,= MUST be
>=C2=A0 =C2=A0 unique within the module or submodule.
>
> This is a requirement, as is clear by the MUST.
>
> Then RFC 7950 says:
>
>=C2=A0 =C2=A0 To
>=C2=A0 =C2=A0 improve readability of YANG modules, the prefix defined b= y a module
>=C2=A0 =C2=A0 SHOULD be used when the module is imported, unless there = is a
>=C2=A0 =C2=A0 conflict.
>
> It also says:
>
>=C2=A0 =C2=A0 When used inside the "import" statement, the &q= uot;prefix" statement
>=C2=A0 =C2=A0 defines the prefix to be used when accessing definitions = inside the
>=C2=A0 =C2=A0 imported module.
>
> Clearly, the scope of the "prefix" statement used with an &q= uot;import" statement is limited to the module where it is imported an= d does not impact the imported module. As such, and because it is a SHOULD = and not a MUST, this is a "nice to have"=C2=A0 without conflicts,= but one would not be wrong using a different prefix from the one defined i= n the imported module. Add to this, most tools, e.g. pyang or yanglint do n= ot complain if you do define a different prefix when there are no conflicts= . I have not seen a problem in the implementation of the module when the pr= efix is different.
>
> RFC 8407 confuses this whole situation by saying:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The proper module prefix MUST be used for al= l identifiers imported
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from other modules.
>
> which as written is true for identifiers (but not for other types of i= mports??). Besides, it does not define what is "proper module prefix&q= uot;. In the absence of a proper definition, one should follow what RFC 795= 0 says.
>
> Comments?
>
> Mahesh Jethanandani
> mjethanan= dani@gmail.com
>
>
>
>
>

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000045670405bdd2da7e-- From nobody Thu Mar 18 10:41:48 2021 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 4B9393A3073 for ; Thu, 18 Mar 2021 10:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4QGGXCwH0mA for ; Thu, 18 Mar 2021 10:41:45 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2110.outbound.protection.outlook.com [40.107.237.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DFF3A3071 for ; Thu, 18 Mar 2021 10:41:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TjwksiZza2hGECg4HCu65wAv3sZ3W+tQ6Vutxxm8QAVBHFMZ1z4xjt1C8FzpnRKhgbn2YHwdZLjsrEgZG84jWf0kyRaITELpCZ0y3pn92l50yHqZp0akESfhIAUdrALEEA1nI6Oq/bnR+fDzso1wdJUY9qWODDuUxhdDzrFxEB28QF9e6eyK16u2oFD2Xh6w8MaCmdOo7VSGsqJIbk8xONeJH+dtognkxM+pvTZwn63MkhlKUp2pNboYSLIM7+vw9Owmw1gnwH1d1Gvsmvm8yKp8owFxrGJx6lgiBEHOSFf9EGDeOlQex//D0DjNQrMqa2qgUi5b/WY4Ws7I+/N7HA== 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=1YpvmXvto6nQk1E/ySrCAmZ42AOOB6u46NO0001GbC4=; b=iouMmIsF4hW4pa0iVElA3M+O6aiq8s/slgaWeKpL/WlloxvjWrYGqvNzdFYm3Ga3WcGD9HXJrfLL8asuSmQ2qwF0ReP62YQzmXGhhdRUrGSw4NfX9t4DmUXKChQTkU8MVmJtFyfTO8T36KtqiP9hXAMIVhCRYqKqXoBxUS2RE8MA/PMC6OPE2DcSYwlCS44haTVsvjI2OLcDViiPcP/hyjaiBifTBNABt4eN1m4FtGd3BmZ+T7UGfUrmpcuFB/AKJdA6WTGGB87ubhGrA6X/lvYeLP68QzRyFW7zBHCm6DL6A8mren/xYdXrnUWG1sktFzFRymptaPSIrr9RcGo6gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1YpvmXvto6nQk1E/ySrCAmZ42AOOB6u46NO0001GbC4=; b=Aw8IJBVK7Sm4i/146zvTxBMRiNrWOKCUa/7io+Y9LqLrtAGAEZuTu9wYA+QPtiKiLojKL/4sBjiTBHGpid0wh7SUpkypHIwy/+Iz0AdW8j9mwTIMEor+f/RhFSGX1uwLXThw7grR+RvTGfv9bb+4Md1eEdDPNTjKPyDQP0DcDSA= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB4093.namprd14.prod.outlook.com (2603:10b6:208:1d2::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Thu, 18 Mar 2021 17:41:41 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a%6]) with mapi id 15.20.3955.018; Thu, 18 Mar 2021 17:41:41 +0000 From: Don Fedyk To: Andy Bierman CC: tom petch , Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Use of prefixes in YANG models Thread-Index: AQHXG4oeBf3NvMSv8UyT0rE9HMwK0qqJY72AgAA+ywCAAFPJMIAACUWAgAADxzA= Date: Thu, 18 Mar 2021 17:41:41 +0000 Message-ID: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 911f06e2-b78b-4b9f-29d8-08d8ea351738 x-ms-traffictypediagnostic: MN2PR14MB4093: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T9hQfsAWaQ/5PCliyW9YTsRRAC5FvqrJok4E2sF/eLoNX3Y+3z6LyilU+1Bi5G0mzgYv25lkylN8xAeegjnRKYGJVG8CWef81wxvmmGT9c2RxgXpq8Ef0aRxIEnmOYCmN67rMJ84+HfzBi/zFkSoEFAA52kDZfviE3rd3T713Ie6DGjBB6ALRG9ivKtw80g0KHV9rFjOYaEPZ8/Tezmo/kpFrnjZhoZDHQTv8EmADph+db4WufAMicCrgbRviv+HvYS6eImnSDargICqPG54/tVu0oNMX6KV07QViMysiOo75/QwB2szK0rZmsFrJrFVdt4eu8g95pc6a5iHjnLOoDMPiIY7Trj3g4gi8gXMAowH2FCf7qPMRYGiMABaktvVdSEu5GyenBw7AJ95JYWbgP0bKb/zQ12beQJ9Dht0ovCHXiz5qscAJrnLT4Ha1Mi1n2aoZPT/q2vCYGBRRrmeQIP4tgcxZkK90zAaAh8epa11fzNKIDLKOAMBxO8Bl/grBzV0BLfRsnyPjzJXIocNVk0AZgERXFT41RbGB68mn0RW1KcdlsL+fjEzjzlANorientL1ur7FtEkXkUfVAlTjKLMYPtC76Q7Bd5ssjYbyCbvvh8CLbJsDvrcUuIyQWjRNDe0Qx/mUGs6g+f6agBzv1Tt+cjKhj/EjMRheZC+WqOygNWZ9BJCXFc2iMYKpryFj5hl3OCZ5JbqroSqtchFgU7FviJ0mXBQ4aggbiWYiyo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(396003)(346002)(39830400003)(8936002)(71200400001)(316002)(33656002)(966005)(86362001)(4326008)(186003)(55016002)(9686003)(66556008)(64756008)(8676002)(66446008)(38100700001)(54906003)(52536014)(76116006)(7696005)(66476007)(26005)(66946007)(6916009)(53546011)(5660300002)(6506007)(83380400001)(2906002)(166002)(478600001)(170073001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?SDgxbGNORDUwaWJxVUZuQ01vaFRnOGpRRVQ2UEZ1VndDZHZNRGUxa2U2N1d5?= =?utf-8?B?UU1HZTJHNUZsQ2YxQ3ZRK1B1UkVNSkF1VlcyME5tRUdWdGRDaitad2FPajRL?= =?utf-8?B?NEt5SysyclhiT3RqbzR5ci9yVE10eEdsVFVEdXRTZUQ0V3ZvUU1TTlRDRWNR?= =?utf-8?B?dTdOTU1DRUNSelMzTU9mcDBrbjd0NXBUbjMxellVeXQwZDdBQkJlTVAvZWJ6?= =?utf-8?B?SUVuUnMwczFRUFZhVHRDYXoyY2tUVVVwRXNoY1ZKRDByT29RTDNGbW5GRzJa?= =?utf-8?B?RFFvT2pFWmd2TndoeE1FVkswcXp3UHVUMUk0Q0tYMmYxMjNETTVBbXVMeEo2?= =?utf-8?B?ZitBQXF4c2dpd2MyMU4yL3BWbHh5TmRGMUM5MEhWcWh0TkZ2b2lBTlJ2T0RY?= =?utf-8?B?NVRwZlhBemZmSGpyYmlmamYvUzJaZWdpQ2pNVWVwZlM3NjFSM29HZVQ5NkJF?= =?utf-8?B?bGd1N1YxTXlSYVJSTmVrMTFDclV6eEhUeGpHeVpwWlFVZ1ZaSXpFWUl0andr?= =?utf-8?B?b1ZmWjVyU0RZalBsOEdPV3VBWGpQdUgybVEwV29kY2I4ZzNKUkdvK1pyWity?= =?utf-8?B?c1dPNTFWQ095UnB3akpGMENuN3ZKOWlrNjVlVFNLQm8vUnNNQWpUYnY5dE4x?= =?utf-8?B?bEFQUndoM3NSbzdJZUVWMlhlSEtGWlhaZUYrZkU2RmZDUVNIZnprbTMrWDhv?= =?utf-8?B?NDZOYllHTzRnYVZZRStLMThIWHFwUG80QndpdXR5NlJteUlkbnBmc05QS0ly?= =?utf-8?B?L2RvUlk3dTF0NFBqdWFDdUFYZnJQTENzWHhhZkVpMGVJL0d6N0pGVTRpbVZQ?= =?utf-8?B?bENITERFUTZTRnd1djQ2Vi9xcUNWUVNYdDVQVXNjMmszbDRZSE16VHJRaFVn?= =?utf-8?B?VFgrYzNKVEpGY282UWVnQWxKM1RJQ0htMm5CVmtpSFJ3YzRMYkl4a1FrWWUz?= =?utf-8?B?MHVyRWdVMzJQR25HQlplWDEyWm5NS0lOL2hyOXhGWUpEWjA4TDdXeHZnMGl2?= =?utf-8?B?Um94WE1hQ0NRL2I1VW01RnF5SGNpTnQxdGUxY29oM2hZOU5zR1dxWjEwNGxa?= =?utf-8?B?bUxRbUJUM2ZSOWY5RUVLZmt6cGdUQzFON3NwUXJ1aXRMZVNNS3hpMTFVOFdP?= =?utf-8?B?b3dGQ0xxRVNmVUN2cEp6aGVCTEhCVzk0eTN0bFp4Ty9aSDhhT1lsdFF3cktB?= =?utf-8?B?UStPSm9IczBOQzQ3eTd0RnFKYzRwZEJITE1WL3l5alRicnNXcVZvdU01SHcr?= =?utf-8?B?ZzhrTEE5SGJTTSt2cFZsQzVTZEF5WjhiMlozWnAvekJZdjlOa1lHT1luR3d4?= =?utf-8?B?RTkyaEtmOHkxZTk3ZnQ2aEh4MWtOUDhaejlKODJ3ODgxWURPd1hybjNsd3Js?= =?utf-8?B?b01aSWE5M1hwNzlwRmR4N0NGTUJFK29tN0h2TXNvWUxBMWswUENndkl6OXhG?= =?utf-8?B?RU1DaVNVSjMvSmhRUDArb2tUV09FOHp0QzNKaml3eUF0cm42cXJEWXdVQms5?= =?utf-8?B?VEFqaU9TNnB1WFRxQk14R3RCQXR6Y3RCOGhoeSt4aHN6VkZKalB5SnlkbjNJ?= =?utf-8?B?Z0RxSVFVTkM0NlJFMGt3bUJ4YzA3bGVHc0VtZ3RSUmNIWnMxb3ZDdVliWFZh?= =?utf-8?B?UTI0TTlRWnA4RE5rTkF2STBSc2RETTBHSTU2SkJZUWtwRlFHQUx5djdXa0FT?= =?utf-8?B?R0M4bkUwNFIvWFRsaG80MmJncm5Fa281aXNzWmJoSHlETStpOGZBczRkWmsv?= =?utf-8?Q?byt/n7gyv212mirJRpHnQSUOy9fBOaukOiNlk6S?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR14MB40301954EFE7C667DFE94405BB699MN2PR14MB4030namp_" MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 911f06e2-b78b-4b9f-29d8-08d8ea351738 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2021 17:41:41.5697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UYQKBBbj8wptISQMylzZoDoVY+Ym2/pVNXYBzI6b3KoqBGJMousspunWp5biGivNzaS/W+92CMxKRG/nS8wwaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB4093 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 17:41:47 -0000 --_000_MN2PR14MB40301954EFE7C667DFE94405BB699MN2PR14MB4030namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28geW91IGFyZSBzYXlpbmcgSSBzaG91bGQgYmVhdCB1cCBvbiB0aGUgdG9vbCBjaGFpbiBwZW9w bGUgdGhhdCBoYXZlIG5vdCBmb2xsb3dlZCB0aGUgc3BlYy4gSSB0cmllZCB0aGF0IGFscmVhZHkg 8J+YiiAsIGJ1dCBzaW5jZSBJIGNhbiByZWRlZmluZSB0aGUgcHJlZml4ZXMgbG9jYWxseSBhcyBh IHdvcmthcm91bmQsIGFuZCBJIGNvdWxkbuKAmXQgY29udmluY2UgdGhlbSBpdCB3YXMgYW4gaXNz dWUsIGl0IGZlbGwgYnkgdGhlIHdheXNpZGUgd2l0aCBvbmUgdG9vbCBzbyBmYXIuDQoNCklmICB0 aGUgc3BlYyB3YXMgbW9yZSBwcmVjaXNlIGl0IHdvdWxkIHNldHRsZSB0aGUgYXJndW1lbnRzLg0K UmVnYXJkcywNCkRvbg0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4N ClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAyMSAxOjIzIFBNDQpUbzogRG9uIEZlZHlrIDxk ZmVkeWtAbGFibi5uZXQ+DQpDYzogdG9tIHBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPjsgTWFo ZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+OyBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT47IG5ldG1vZEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFVzZSBvZiBwcmVmaXhlcyBpbiBZQU5HIG1v ZGVscw0KDQoNCg0KT24gVGh1LCBNYXIgMTgsIDIwMjEgYXQgMTA6MDcgQU0gRG9uIEZlZHlrIDxk ZmVkeWtAbGFibi5uZXQ8bWFpbHRvOmRmZWR5a0BsYWJuLm5ldD4+IHdyb3RlOg0KQ2xhcml0eSBh bmQgY29uc2lzdGVuY3kgd291bGQgaGVscC4NCg0KTWFueSBvZiB0aGUgc3VwcG9ydGluZyB0b29s IGNoYWlucyBhcmUgcGlja3kgYWJvdXQgcHJlZml4ZXMuIElFIHRoZXkgbXVzdCBiZSB0aGUgc2Ft ZSBhcyBpbiB0aGUgZGVmaW5pdGlvbiBmaWxlLiAgSSBoYXZlIGEgY2FzZSB3aGVyZSB5YW5nbGlu dCB3YW50cyAibG9jYWwgcHJlZml4ZXMgb3IgZGVyaXZlZC1mcm9tKC1vci1zZWxmKSBjb25zdHJ1 Y3QiIGZvciBhbiBsb2NhbCBpZGVudGl0eSBpbiBhbiB4cGF0aCBzdGF0ZW1lbnQuIChlaXRoZXIg cmVtZWR5IHNlZW1zIHRvIHdvcmsuKSBJIGFyZ3VlZCBmb3IgdGhlIHByZWZpeGVzIGluIGJ1dCBv dGhlcnMgYXJndWUgdGhleSBhcmUgbm90IG5lY2Vzc2FyeSBidXQgSSBjYW5ub3QgdmFsaWRhdGUg d2l0aG91dCB0aGVtLg0KDQoNClRoZSB0b29sIG1ha2VycyBzaG91bGQgdW5kZXJzdGFuZCB0aGF0 IFlBTkcgcHJlZml4ZXMgYXJlIG5vdCByZXF1aXJlZCB0byBiZSB1bmlxdWUuDQpJdCBpcyB1bmRl cnN0b29kIHRoYXQgc2hvcnQgY2hhcmFjdGVyIHNlcXVlbmNlcyBoYXZlIGEgaGlnaCBwcm9iYWJp bGl0eSBvZiBkdXBsaWNhdGlvbi4NClNvIHdoYXQgaWYgdGhlIHNlcnZlciB3YW50cyB0byBzdXBw b3J0IDIgbW9kdWxlcyB3aXRoIHRoZSBzYW1lIHByZWZpeCBkZWZpbmVkIGluIHRoZSBZQU5HIG1v ZHVsZT8NCklzIGl0IG5vdCBjbGVhciB0aGF0IHRoZSBFTlRJUkUgcG9pbnQgb2YgaGF2aW5nIHRo ZSBwcmVmaXgtc3RtdCBpbiB0aGUgaW1wb3J0LXN0bXQgaXMNCmJlY2F1c2UgdGhlIGltcG9ydGVk IG1vZHVsZXMgbWF5IGhhdmUgcHJlZml4ZXMgdGhhdCBjb2xsaWRlPw0KDQoNCg0KQW5keQ0KDQoi bm90KGRlcml2ZWQtZnJvbSguLi8uLi9icmlkZ2UtdHlwZSwndHdvLXBvcnQtbWFjLXJlbGF5LWJy aWRnZScpKSIgd29ya3MgKHByZWZpeC9ubyBwcmVmaXgpDQpCdXQgIi4uLy4uL2JyaWRnZS10eXBl ICE9ICdkb3QxcTp0d28tcG9ydC1tYWMtcmVsYXktYnJpZGdlJyAgICAgIHdvcmtzIHRvby4NCg0K VGhhbmtzDQpEb24NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuZXRt b2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Zz4+IE9uIEJlaGFsZiBPZiB0b20gcGV0Y2gNClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAy MSA3OjUwIEFNDQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5j b208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj47IEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+Pg0KQ2M6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFVzZSBvZiBwcmVmaXhlcyBp biBZQU5HIG1vZGVscw0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4NClNlbnQ6IDE4IE1hcmNoIDIwMjEg MDg6MDUNCg0KV2Ugb2Z0ZW4gZG8gbm90IGRvIGEgZ29vZCBqb2IgaW4gZGlzdGluZ3Vpc2hpbmcg dGVjaG5pY2FsIHJlcXVpcmVtZW50cyBmcm9tIHVzYWdlIGd1aWRlbGluZXMuIChBbmQgUkZDIDIx MTkga2V5d29yZHMgbWFrZSB0aGluZ3Mgd29yc2UuKQ0KDQpBcyBmYXIgYXMgSSByZWNhbGwsIHRo ZSBpbnRlbnQgb2YgdGhlIFJGQyA4NDA3IHRleHQgd2FzIHRvIHNheSB0aGF0IGl0IGlzIGhlbHBm dWwgZm9yIF9odW1hbnNfIHRvIGFsd2F5cyB1c2UgJ2lmOm5hbWUnIHdoZW4geW91IHJlZmVyIHRv IHRoZSBsZWFmICduYW1lJyBkZWZpbmVkIGluICdpZXRmLWludGVyZmFjZXMnIG9yICd5YW5nOmRh dGUtYW5kLXRpbWUnIHdoZW4geW91IHJlZmVyIHRvICdkYXRlLWFuZC10aW1lJyBkZWZpbmVkIGlu ICdpZXRmLXlhbmctdHlwZXMnLg0KDQpJIGJlbGlldmUgd2UgYWdyZWVkIHRoYXQgbW9kdWxlIGF1 dGhvcnMgYXNzaWduaW5nIGEgcHJlZml4IGRpZmZlcmVudCBmcm9tIHRoZSBkZWZhdWx0IHByZWZp eCBkdXJpbmcgYW4gaW1wb3J0IHNob3VsZCBoYXZlIGVpdGhlciB0ZWNobmljYWwgcmVhc29ucyBm b3IgZG9pbmcgc28gKHJlc29sdmluZyBwcmVmaXhlcyBjbGFzaGVzKSBvciBzb21lIG90aGVyIGdv b2QgcmVhc29uIHRvIGRlcGFydCBmcm9tIHRoZSBnZW5lcmFsIGd1aWRlbGluZSBhaW1pbmcgdG8g cmVkdWNlIGh1bWFuIGNvbmZ1c2lvbi4NCg0KPHRwPg0KVG8gbWFrZSBhbiBhYnN0cmFjdCBjb25j ZXB0IGNvbmNyZXRlLCBkcmFmdC1pZXRmLWJhYmVsLXlhbmctbW9kZWwgaW1wb3J0cyB5YW5nIHR5 cGVzIGZyb20gUkZDNjk5MSBhbmQgZ2l2ZXMgaXQgdGhlIHByZWZpeCB5dDogYXMgaW4geXQ6ZGF0 ZS1hbmQtdGltZSBvciB5dDpjb3VudGVyMzIuICBBbiBlYXJseSBZQU5HIERvY3RvciByZXZpZXcg YnkgUmFkZWsgZGlkIG5vdCBjb21tZW50IG9uIHRoaXMgYXNwZWN0IG9mIHRoZSBJLUQuICBNb3Jl IHJlY2VudGx5LCBJIGhhdmUuDQoNClRvbSBQZXRjaA0KDQoNCg0KL2pzICh3aG8gc3RvcHBlZCBi ZWxpZXZpbmcgdGhhdCBSRkMgMjExOSBrZXl3b3JkcyBhcmUgaGVscGZ1bCB5ZWFycyBhZ28pDQoN Ck9uIFdlZCwgTWFyIDE3LCAyMDIxIGF0IDA1OjAzOjExUE0gLTA3MDAsIE1haGVzaCBKZXRoYW5h bmRhbmkgd3JvdGU6DQo+IEkgaGF2ZSBzZWVuIHRoZSBkZWJhdGUgb24gdGhlIHVzZSBvZiBwcmVm aXhlcyBpbiBZQU5HIG1vZGVscywgc3BlY2lhbGx5IGFzIGl0IHJlbGF0ZXMgdG8gdGhlaXIgdXNl IHdoZW4gaW1wb3J0aW5nIGEgbW9kZWwuIEkgdGhpbmsgaXQgd291bGQgbmljZSB0byBiZSBjbGVh ciBvbiB3aGF0IGlzIHJlcXVpcmVkLCB3aGF0IGlzIG5pY2UsIGFuZCB3aGF0IGlzIG5vdCBvayB0 byBkby4gSSBkbyBub3Qgd2FudCB0byBjb25mdXNlIHRoaXMgZGlzY3Vzc2lvbiB3aXRoIHRoZSBs ZW5ndGggb2YgdGhlIHByZWZpeCwgd2hpY2ggSSBiZWxpZXZlIGlzIHNvbWV3aGF0IHJlbGF0ZWQg YnV0IG5vdCB0aGUgc2FtZSBkaXNjdXNzaW9uLg0KPg0KPiBSRkMgNzk1MCBzYXlzOg0KPg0KPiAg ICBBbGwgcHJlZml4ZXMsIGluY2x1ZGluZyB0aGUgcHJlZml4IGZvciB0aGUgbW9kdWxlIGl0c2Vs ZiwgTVVTVCBiZQ0KPiAgICB1bmlxdWUgd2l0aGluIHRoZSBtb2R1bGUgb3Igc3VibW9kdWxlLg0K Pg0KPiBUaGlzIGlzIGEgcmVxdWlyZW1lbnQsIGFzIGlzIGNsZWFyIGJ5IHRoZSBNVVNULg0KPg0K PiBUaGVuIFJGQyA3OTUwIHNheXM6DQo+DQo+ICAgIFRvDQo+ICAgIGltcHJvdmUgcmVhZGFiaWxp dHkgb2YgWUFORyBtb2R1bGVzLCB0aGUgcHJlZml4IGRlZmluZWQgYnkgYSBtb2R1bGUNCj4gICAg U0hPVUxEIGJlIHVzZWQgd2hlbiB0aGUgbW9kdWxlIGlzIGltcG9ydGVkLCB1bmxlc3MgdGhlcmUg aXMgYQ0KPiAgICBjb25mbGljdC4NCj4NCj4gSXQgYWxzbyBzYXlzOg0KPg0KPiAgICBXaGVuIHVz ZWQgaW5zaWRlIHRoZSAiaW1wb3J0IiBzdGF0ZW1lbnQsIHRoZSAicHJlZml4IiBzdGF0ZW1lbnQN Cj4gICAgZGVmaW5lcyB0aGUgcHJlZml4IHRvIGJlIHVzZWQgd2hlbiBhY2Nlc3NpbmcgZGVmaW5p dGlvbnMgaW5zaWRlIHRoZQ0KPiAgICBpbXBvcnRlZCBtb2R1bGUuDQo+DQo+IENsZWFybHksIHRo ZSBzY29wZSBvZiB0aGUgInByZWZpeCIgc3RhdGVtZW50IHVzZWQgd2l0aCBhbiAiaW1wb3J0IiBz dGF0ZW1lbnQgaXMgbGltaXRlZCB0byB0aGUgbW9kdWxlIHdoZXJlIGl0IGlzIGltcG9ydGVkIGFu ZCBkb2VzIG5vdCBpbXBhY3QgdGhlIGltcG9ydGVkIG1vZHVsZS4gQXMgc3VjaCwgYW5kIGJlY2F1 c2UgaXQgaXMgYSBTSE9VTEQgYW5kIG5vdCBhIE1VU1QsIHRoaXMgaXMgYSAibmljZSB0byBoYXZl IiAgd2l0aG91dCBjb25mbGljdHMsIGJ1dCBvbmUgd291bGQgbm90IGJlIHdyb25nIHVzaW5nIGEg ZGlmZmVyZW50IHByZWZpeCBmcm9tIHRoZSBvbmUgZGVmaW5lZCBpbiB0aGUgaW1wb3J0ZWQgbW9k dWxlLiBBZGQgdG8gdGhpcywgbW9zdCB0b29scywgZS5nLiBweWFuZyBvciB5YW5nbGludCBkbyBu b3QgY29tcGxhaW4gaWYgeW91IGRvIGRlZmluZSBhIGRpZmZlcmVudCBwcmVmaXggd2hlbiB0aGVy ZSBhcmUgbm8gY29uZmxpY3RzLiBJIGhhdmUgbm90IHNlZW4gYSBwcm9ibGVtIGluIHRoZSBpbXBs ZW1lbnRhdGlvbiBvZiB0aGUgbW9kdWxlIHdoZW4gdGhlIHByZWZpeCBpcyBkaWZmZXJlbnQuDQo+ DQo+IFJGQyA4NDA3IGNvbmZ1c2VzIHRoaXMgd2hvbGUgc2l0dWF0aW9uIGJ5IHNheWluZzoNCj4N Cj4gICAgICAgVGhlIHByb3BlciBtb2R1bGUgcHJlZml4IE1VU1QgYmUgdXNlZCBmb3IgYWxsIGlk ZW50aWZpZXJzIGltcG9ydGVkDQo+ICAgICAgIGZyb20gb3RoZXIgbW9kdWxlcy4NCj4NCj4gd2hp Y2ggYXMgd3JpdHRlbiBpcyB0cnVlIGZvciBpZGVudGlmaWVycyAoYnV0IG5vdCBmb3Igb3RoZXIg dHlwZXMgb2YgaW1wb3J0cz8/KS4gQmVzaWRlcywgaXQgZG9lcyBub3QgZGVmaW5lIHdoYXQgaXMg InByb3BlciBtb2R1bGUgcHJlZml4Ii4gSW4gdGhlIGFic2VuY2Ugb2YgYSBwcm9wZXIgZGVmaW5p dGlvbiwgb25lIHNob3VsZCBmb2xsb3cgd2hhdCBSRkMgNzk1MCBzYXlzLg0KPg0KPiBDb21tZW50 cz8NCj4NCj4gTWFoZXNoIEpldGhhbmFuZGFuaQ0KPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQo+DQo+DQo+DQo+DQo+DQoNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQotLQ0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5l dG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== --_000_MN2PR14MB40301954EFE7C667DFE94405BB699MN2PR14MB4030namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TbyB5b3UgYXJlIHNheWluZyBJIHNob3VsZCBiZWF0IHVwIG9uIHRoZSB0b29sIGNo YWluIHBlb3BsZSB0aGF0IGhhdmUgbm90IGZvbGxvd2VkIHRoZSBzcGVjLiBJIHRyaWVkIHRoYXQg YWxyZWFkeQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1 b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIyOzwvc3Bhbj4gLCBidXQgc2luY2UgSSBjYW4gcmVkZWZp bmUgdGhlIHByZWZpeGVzIGxvY2FsbHkgYXMgYSB3b3JrYXJvdW5kLCBhbmQgSSBjb3VsZG7igJl0 IGNvbnZpbmNlIHRoZW0gaXQgd2FzIGFuIGlzc3VlLCBpdCBmZWxsIGJ5IHRoZSB3YXlzaWRlIHdp dGggb25lIHRvb2wgc28gZmFyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmICZuYnNwO3Ro ZSBzcGVjIHdhcyBtb3JlIHByZWNpc2UgaXQgd291bGQgc2V0dGxlIHRoZSBhcmd1bWVudHMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLCAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFuZHkgQmllcm1hbiAm bHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1h cmNoIDE4LCAyMDIxIDE6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IERvbiBGZWR5ayAmbHQ7ZGZlZHlr QGxhYm4ubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gdG9tIHBldGNoICZsdDtpZXRmY0BidGNvbm5l Y3QuY29tJmd0OzsgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7bWpldGhhbmFuZGFuaUBnbWFpbC5j b20mZ3Q7OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZSZndDs7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW25ldG1vZF0gVXNlIG9mIHByZWZpeGVzIGluIFlBTkcgbW9kZWxzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWFyIDE4LCAyMDIxIGF0IDEwOjA3 IEFNIERvbiBGZWR5ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRmZWR5a0BsYWJuLm5ldCI+ZGZlZHlr QGxhYm4ubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkNs YXJpdHkgYW5kIGNvbnNpc3RlbmN5IHdvdWxkIGhlbHAuPGJyPg0KPGJyPg0KTWFueSBvZiB0aGUg c3VwcG9ydGluZyB0b29sIGNoYWlucyBhcmUgcGlja3kgYWJvdXQgcHJlZml4ZXMuIElFIHRoZXkg bXVzdCBiZSB0aGUgc2FtZSBhcyBpbiB0aGUgZGVmaW5pdGlvbiBmaWxlLiZuYnNwOyBJIGhhdmUg YSBjYXNlIHdoZXJlIHlhbmdsaW50IHdhbnRzICZxdW90O2xvY2FsIHByZWZpeGVzIG9yIGRlcml2 ZWQtZnJvbSgtb3Itc2VsZikgY29uc3RydWN0JnF1b3Q7IGZvciBhbiBsb2NhbCBpZGVudGl0eSBp biBhbiB4cGF0aCBzdGF0ZW1lbnQuIChlaXRoZXIgcmVtZWR5DQogc2VlbXMgdG8gd29yay4pIEkg YXJndWVkIGZvciB0aGUgcHJlZml4ZXMgaW4gYnV0IG90aGVycyBhcmd1ZSB0aGV5IGFyZSBub3Qg bmVjZXNzYXJ5IGJ1dCBJIGNhbm5vdCB2YWxpZGF0ZSB3aXRob3V0IHRoZW0uDQo8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHRvb2wgbWFrZXJzIHNob3VsZCB1bmRlcnN0YW5kIHRoYXQgWUFORyBwcmVmaXhlcyBhcmUgbm90 IHJlcXVpcmVkIHRvIGJlIHVuaXF1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHVuZGVyc3Rvb2QgdGhhdCBzaG9ydCBjaGFyYWN0ZXIg c2VxdWVuY2VzIGhhdmUgYSBoaWdoIHByb2JhYmlsaXR5IG9mIGR1cGxpY2F0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gd2hhdCBpZiB0 aGUgc2VydmVyIHdhbnRzIHRvIHN1cHBvcnQgMiBtb2R1bGVzIHdpdGggdGhlIHNhbWUgcHJlZml4 IGRlZmluZWQgaW4gdGhlIFlBTkcgbW9kdWxlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgaXQgbm90IGNsZWFyIHRoYXQgdGhlIEVOVElSRSBw b2ludCBvZiBoYXZpbmcgdGhlIHByZWZpeC1zdG10IGluIHRoZSBpbXBvcnQtc3RtdCBpczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmVjYXVzZSB0 aGUgaW1wb3J0ZWQgbW9kdWxlcyBtYXkgaGF2ZSBwcmVmaXhlcyB0aGF0IGNvbGxpZGU/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZxdW90O25vdChkZXJpdmVkLWZyb20oLi4vLi4vYnJpZGdlLXR5cGUsJ3R3by1wb3J0LW1h Yy1yZWxheS1icmlkZ2UnKSkmcXVvdDsgd29ya3MgKHByZWZpeC9ubyBwcmVmaXgpPGJyPg0KQnV0 ICZxdW90Oy4uLy4uL2JyaWRnZS10eXBlICE9ICdkb3QxcTp0d28tcG9ydC1tYWMtcmVsYXktYnJp ZGdlJyZuYnNwOyAmbmJzcDsgJm5ic3A7IHdvcmtzIHRvby48YnI+DQo8YnI+DQpUaGFua3M8YnI+ DQpEb24gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiBuZXRtb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24g QmVoYWxmIE9mIHRvbSBwZXRjaDxicj4NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAyMSA3 OjUwIEFNPGJyPg0KVG86IE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPC9hPiZndDs7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5v cmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFVzZSBvZiBwcmVmaXhlcyBpbiBZQU5H IG1vZGVsczxicj4NCjxicj4NCkZyb206IG5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1v ZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVm PSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9i bGFuayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDs8YnI+DQpT ZW50OiAxOCBNYXJjaCAyMDIxIDA4OjA1PGJyPg0KPGJyPg0KV2Ugb2Z0ZW4gZG8gbm90IGRvIGEg Z29vZCBqb2IgaW4gZGlzdGluZ3Vpc2hpbmcgdGVjaG5pY2FsIHJlcXVpcmVtZW50cyBmcm9tIHVz YWdlIGd1aWRlbGluZXMuIChBbmQgUkZDIDIxMTkga2V5d29yZHMgbWFrZSB0aGluZ3Mgd29yc2Uu KTxicj4NCjxicj4NCkFzIGZhciBhcyBJIHJlY2FsbCwgdGhlIGludGVudCBvZiB0aGUgUkZDIDg0 MDcgdGV4dCB3YXMgdG8gc2F5IHRoYXQgaXQgaXMgaGVscGZ1bCBmb3IgX2h1bWFuc18gdG8gYWx3 YXlzIHVzZSAnaWY6bmFtZScgd2hlbiB5b3UgcmVmZXIgdG8gdGhlIGxlYWYgJ25hbWUnIGRlZmlu ZWQgaW4gJ2lldGYtaW50ZXJmYWNlcycgb3IgJ3lhbmc6ZGF0ZS1hbmQtdGltZScgd2hlbiB5b3Ug cmVmZXIgdG8gJ2RhdGUtYW5kLXRpbWUnIGRlZmluZWQgaW4gJ2lldGYteWFuZy10eXBlcycuPGJy Pg0KPGJyPg0KSSBiZWxpZXZlIHdlIGFncmVlZCB0aGF0IG1vZHVsZSBhdXRob3JzIGFzc2lnbmlu ZyBhIHByZWZpeCBkaWZmZXJlbnQgZnJvbSB0aGUgZGVmYXVsdCBwcmVmaXggZHVyaW5nIGFuIGlt cG9ydCBzaG91bGQgaGF2ZSBlaXRoZXIgdGVjaG5pY2FsIHJlYXNvbnMgZm9yIGRvaW5nIHNvIChy ZXNvbHZpbmcgcHJlZml4ZXMgY2xhc2hlcykgb3Igc29tZSBvdGhlciBnb29kIHJlYXNvbiB0byBk ZXBhcnQgZnJvbSB0aGUgZ2VuZXJhbCBndWlkZWxpbmUgYWltaW5nDQogdG8gcmVkdWNlIGh1bWFu IGNvbmZ1c2lvbi48YnI+DQo8YnI+DQombHQ7dHAmZ3Q7PGJyPg0KVG8gbWFrZSBhbiBhYnN0cmFj dCBjb25jZXB0IGNvbmNyZXRlLCBkcmFmdC1pZXRmLWJhYmVsLXlhbmctbW9kZWwgaW1wb3J0cyB5 YW5nIHR5cGVzIGZyb20gUkZDNjk5MSBhbmQgZ2l2ZXMgaXQgdGhlIHByZWZpeCB5dDogYXMgaW4g eXQ6ZGF0ZS1hbmQtdGltZSBvciB5dDpjb3VudGVyMzIuJm5ic3A7IEFuIGVhcmx5IFlBTkcgRG9j dG9yIHJldmlldyBieSBSYWRlayBkaWQgbm90IGNvbW1lbnQgb24gdGhpcyBhc3BlY3Qgb2YgdGhl IEktRC4mbmJzcDsgTW9yZSByZWNlbnRseSwNCiBJIGhhdmUuPGJyPg0KPGJyPg0KVG9tIFBldGNo PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KL2pzICh3aG8gc3RvcHBlZCBiZWxpZXZpbmcgdGhhdCBS RkMgMjExOSBrZXl3b3JkcyBhcmUgaGVscGZ1bCB5ZWFycyBhZ28pPGJyPg0KPGJyPg0KT24gV2Vk LCBNYXIgMTcsIDIwMjEgYXQgMDU6MDM6MTFQTSAtMDcwMCwgTWFoZXNoIEpldGhhbmFuZGFuaSB3 cm90ZTo8YnI+DQomZ3Q7IEkgaGF2ZSBzZWVuIHRoZSBkZWJhdGUgb24gdGhlIHVzZSBvZiBwcmVm aXhlcyBpbiBZQU5HIG1vZGVscywgc3BlY2lhbGx5IGFzIGl0IHJlbGF0ZXMgdG8gdGhlaXIgdXNl IHdoZW4gaW1wb3J0aW5nIGEgbW9kZWwuIEkgdGhpbmsgaXQgd291bGQgbmljZSB0byBiZSBjbGVh ciBvbiB3aGF0IGlzIHJlcXVpcmVkLCB3aGF0IGlzIG5pY2UsIGFuZCB3aGF0IGlzIG5vdCBvayB0 byBkby4gSSBkbyBub3Qgd2FudCB0byBjb25mdXNlIHRoaXMgZGlzY3Vzc2lvbg0KIHdpdGggdGhl IGxlbmd0aCBvZiB0aGUgcHJlZml4LCB3aGljaCBJIGJlbGlldmUgaXMgc29tZXdoYXQgcmVsYXRl ZCBidXQgbm90IHRoZSBzYW1lIGRpc2N1c3Npb24uPGJyPg0KJmd0Ozxicj4NCiZndDsgUkZDIDc5 NTAgc2F5czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgQWxsIHByZWZpeGVzLCBp bmNsdWRpbmcgdGhlIHByZWZpeCBmb3IgdGhlIG1vZHVsZSBpdHNlbGYsIE1VU1QgYmU8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyB1bmlxdWUgd2l0aGluIHRoZSBtb2R1bGUgb3Igc3VibW9kdWxlLjxi cj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaXMgYSByZXF1aXJlbWVudCwgYXMgaXMgY2xlYXIgYnkg dGhlIE1VU1QuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlbiBSRkMgNzk1MCBzYXlzOjxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUbzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGltcHJv dmUgcmVhZGFiaWxpdHkgb2YgWUFORyBtb2R1bGVzLCB0aGUgcHJlZml4IGRlZmluZWQgYnkgYSBt b2R1bGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBTSE9VTEQgYmUgdXNlZCB3aGVuIHRoZSBtb2R1 bGUgaXMgaW1wb3J0ZWQsIHVubGVzcyB0aGVyZSBpcyBhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Y29uZmxpY3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgYWxzbyBzYXlzOjxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBXaGVuIHVzZWQgaW5zaWRlIHRoZSAmcXVvdDtpbXBvcnQmcXVv dDsgc3RhdGVtZW50LCB0aGUgJnF1b3Q7cHJlZml4JnF1b3Q7IHN0YXRlbWVudDxicj4NCiZndDsm bmJzcDsgJm5ic3A7IGRlZmluZXMgdGhlIHByZWZpeCB0byBiZSB1c2VkIHdoZW4gYWNjZXNzaW5n IGRlZmluaXRpb25zIGluc2lkZSB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpbXBvcnRlZCBt b2R1bGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2xlYXJseSwgdGhlIHNjb3BlIG9mIHRoZSAmcXVv dDtwcmVmaXgmcXVvdDsgc3RhdGVtZW50IHVzZWQgd2l0aCBhbiAmcXVvdDtpbXBvcnQmcXVvdDsg c3RhdGVtZW50IGlzIGxpbWl0ZWQgdG8gdGhlIG1vZHVsZSB3aGVyZSBpdCBpcyBpbXBvcnRlZCBh bmQgZG9lcyBub3QgaW1wYWN0IHRoZSBpbXBvcnRlZCBtb2R1bGUuIEFzIHN1Y2gsIGFuZCBiZWNh dXNlIGl0IGlzIGEgU0hPVUxEIGFuZCBub3QgYSBNVVNULCB0aGlzIGlzIGEgJnF1b3Q7bmljZSB0 byBoYXZlJnF1b3Q7Jm5ic3A7IHdpdGhvdXQgY29uZmxpY3RzLA0KIGJ1dCBvbmUgd291bGQgbm90 IGJlIHdyb25nIHVzaW5nIGEgZGlmZmVyZW50IHByZWZpeCBmcm9tIHRoZSBvbmUgZGVmaW5lZCBp biB0aGUgaW1wb3J0ZWQgbW9kdWxlLiBBZGQgdG8gdGhpcywgbW9zdCB0b29scywgZS5nLiBweWFu ZyBvciB5YW5nbGludCBkbyBub3QgY29tcGxhaW4gaWYgeW91IGRvIGRlZmluZSBhIGRpZmZlcmVu dCBwcmVmaXggd2hlbiB0aGVyZSBhcmUgbm8gY29uZmxpY3RzLiBJIGhhdmUgbm90IHNlZW4gYSBw cm9ibGVtIGluIHRoZQ0KIGltcGxlbWVudGF0aW9uIG9mIHRoZSBtb2R1bGUgd2hlbiB0aGUgcHJl Zml4IGlzIGRpZmZlcmVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSRkMgODQwNyBjb25mdXNlcyB0 aGlzIHdob2xlIHNpdHVhdGlvbiBieSBzYXlpbmc6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgcHJvcGVyIG1vZHVsZSBwcmVmaXggTVVTVCBiZSB1c2Vk IGZvciBhbGwgaWRlbnRpZmllcnMgaW1wb3J0ZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZnJvbSBvdGhlciBtb2R1bGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IHdoaWNoIGFz IHdyaXR0ZW4gaXMgdHJ1ZSBmb3IgaWRlbnRpZmllcnMgKGJ1dCBub3QgZm9yIG90aGVyIHR5cGVz IG9mIGltcG9ydHM/PykuIEJlc2lkZXMsIGl0IGRvZXMgbm90IGRlZmluZSB3aGF0IGlzICZxdW90 O3Byb3BlciBtb2R1bGUgcHJlZml4JnF1b3Q7LiBJbiB0aGUgYWJzZW5jZSBvZiBhIHByb3BlciBk ZWZpbml0aW9uLCBvbmUgc2hvdWxkIGZvbGxvdyB3aGF0IFJGQyA3OTUwIHNheXMuPGJyPg0KJmd0 Ozxicj4NCiZndDsgQ29tbWVudHM/PGJyPg0KJmd0Ozxicj4NCiZndDsgTWFoZXNoIEpldGhhbmFu ZGFuaTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBuZXRt b2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+ DQo8YnI+DQo8YnI+DQotLTxicj4NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI PGJyPg0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQpGYXg6Jm5i c3A7ICZuYnNwOys0OSA0MjEgMjAwIDMxMDMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K bmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5l dG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_MN2PR14MB40301954EFE7C667DFE94405BB699MN2PR14MB4030namp_-- From nobody Thu Mar 18 11:02:39 2021 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 5C6DE3A30CD for ; Thu, 18 Mar 2021 11:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5qHCQAQIejq for ; Thu, 18 Mar 2021 11:02:34 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBDB3A30CC for ; Thu, 18 Mar 2021 11:02:34 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id s17so8646452ljc.5 for ; Thu, 18 Mar 2021 11:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JOJ7rU5WLNCOLOypDag7D44/73jqFClCMxTNA/RmGdo=; b=e6A6GSvg2nSEzJjzXgbMOba/D6KMFYhCtwbUFCeNx9eYlybj/qfDcAjsn5kW9qedBO nbPiYpXhQyrY6JIF/Bn+II6RUaoRjfZ1tIgdicDXum73jyR0QqUkNFsSdm3Tz5qzzC4I 4KQLqYwqqwCSrXJ/hmfpz94ZPsBkxweE+lc1GVa3BX472WM/N6UkIfFgmtPa/xvVPY0n fubfLaTrmrOSHy9Xz+rXfSHwwOzcEOM7TsIgOiRpiu4873in9fSGIKR5ds5do8Gke1G+ XpHN8351BwN1T92wm19wKVcEnEM9G6XLSIwao+yEKNLMJ3Ra0M/cchdVLBaryZJtGSmu LB0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JOJ7rU5WLNCOLOypDag7D44/73jqFClCMxTNA/RmGdo=; b=AWeVP52D5+TAMdQ7TLw6SgzPz5D04Bf/Zn2vVwmtGU7zckWBfLw2/hEq7YbvR+U1il GxTWhfZhD2x7VW8/EEBGG8LwVo0tRJdHetim7lNyxxYOD/mrhqc8CXLtOKHMjgtuon4C 9N9oq0TRXrhIbjlZ+eHvOB1gahz2SMLFutc2pGHgXc80EiUqqfhuQAETSeLhqL8R/m6Z Lrb7PTtN2Fv2VJYdhTYb0i+yyurWksstg9ZkYEfpoF6byu8RWxf5m3n8XuWYny/GMAk2 4YivQotVEhnkcVSIty3Rz3Za0qFc5yVUnonTf5ry4Dxx0Con2GfB5E2exRwDaO7L4lfB 0cWw== X-Gm-Message-State: AOAM530z/EBai+iXamVDYh9WPXSNZhS951KCuoc+b8+WdtANayXjZ8ae jUyK+pyXLvAR5pwsRJJC7rCRvYx9lBNkvFOj3Ilrzw== X-Google-Smtp-Source: ABdhPJwKmIAHYpfjq5W+iHlQ0NFSVW3gLK4qxeUjdujE+8cttBGOrbW/Nz/qO6NRI+51Oz+5eV6bQFwoI0Uo88WUc/Q= X-Received: by 2002:a05:651c:1051:: with SMTP id x17mr6362854ljm.91.1616090551645; Thu, 18 Mar 2021 11:02:31 -0700 (PDT) MIME-Version: 1.0 References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Thu, 18 Mar 2021 11:02:20 -0700 Message-ID: To: Don Fedyk Cc: tom petch , Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000418ea305bdd36731" Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 18:02:37 -0000 --000000000000418ea305bdd36731 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk wrote: > So you are saying I should beat up on the tool chain people that have not > followed the spec. I tried that already =F0=9F=98=8A , but since I can re= define the > prefixes locally as a workaround, and I couldn=E2=80=99t convince them it= was an > issue, it fell by the wayside with one tool so far. > > > > If the spec was more precise it would settle the arguments. > I think it is unfortunate that the IETF wanted so many clever little rules for the creation of YANG modules. Also unfortunate that RFC 2119 terms in the style guide get confused with similar terms in the YANG RFC. RFC 8407 is normative for IETF YANG module authors. RFC 7950 is for YANG module tool-makers. People should know the difference, especially since 8407 only applies to the IETF, not other organizations. Regards, > > Don > Andy > > > *From:* Andy Bierman > *Sent:* Thursday, March 18, 2021 1:23 PM > *To:* Don Fedyk > *Cc:* tom petch ; Mahesh Jethanandani < > mjethanandani@gmail.com>; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de>; netmod@ietf.org > *Subject:* Re: [netmod] Use of prefixes in YANG models > > > > > > > > On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk wrote: > > Clarity and consistency would help. > > Many of the supporting tool chains are picky about prefixes. IE they must > be the same as in the definition file. I have a case where yanglint want= s > "local prefixes or derived-from(-or-self) construct" for an local identit= y > in an xpath statement. (either remedy seems to work.) I argued for the > prefixes in but others argue they are not necessary but I cannot validate > without them. > > > > > > The tool makers should understand that YANG prefixes are not required to > be unique. > > It is understood that short character sequences have a high probability o= f > duplication. > > So what if the server wants to support 2 modules with the same prefix > defined in the YANG module? > > Is it not clear that the ENTIRE point of having the prefix-stmt in the > import-stmt is > > because the imported modules may have prefixes that collide? > > > > > > > > Andy > > > > "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works > (prefix/no prefix) > But "../../bridge-type !=3D 'dot1q:two-port-mac-relay-bridge' works = too. > > Thanks > Don > > > > -----Original Message----- > From: netmod On Behalf Of tom petch > Sent: Thursday, March 18, 2021 7:50 AM > To: Mahesh Jethanandani ; Juergen Schoenwaelder = < > j.schoenwaelder@jacobs-university.de> > Cc: netmod@ietf.org > Subject: Re: [netmod] Use of prefixes in YANG models > > From: netmod on behalf of Juergen Schoenwaelder > > Sent: 18 March 2021 08:05 > > We often do not do a good job in distinguishing technical requirements > from usage guidelines. (And RFC 2119 keywords make things worse.) > > As far as I recall, the intent of the RFC 8407 text was to say that it is > helpful for _humans_ to always use 'if:name' when you refer to the leaf > 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refe= r > to 'date-and-time' defined in 'ietf-yang-types'. > > I believe we agreed that module authors assigning a prefix different from > the default prefix during an import should have either technical reasons > for doing so (resolving prefixes clashes) or some other good reason to > depart from the general guideline aiming to reduce human confusion. > > > To make an abstract concept concrete, draft-ietf-babel-yang-model imports > yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-tim= e > or yt:counter32. An early YANG Doctor review by Radek did not comment on > this aspect of the I-D. More recently, I have. > > Tom Petch > > > > /js (who stopped believing that RFC 2119 keywords are helpful years ago) > > On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > > I have seen the debate on the use of prefixes in YANG models, specially > as it relates to their use when importing a model. I think it would nice = to > be clear on what is required, what is nice, and what is not ok to do. I d= o > not want to confuse this discussion with the length of the prefix, which = I > believe is somewhat related but not the same discussion. > > > > RFC 7950 says: > > > > All prefixes, including the prefix for the module itself, MUST be > > unique within the module or submodule. > > > > This is a requirement, as is clear by the MUST. > > > > Then RFC 7950 says: > > > > To > > improve readability of YANG modules, the prefix defined by a module > > SHOULD be used when the module is imported, unless there is a > > conflict. > > > > It also says: > > > > When used inside the "import" statement, the "prefix" statement > > defines the prefix to be used when accessing definitions inside the > > imported module. > > > > Clearly, the scope of the "prefix" statement used with an "import" > statement is limited to the module where it is imported and does not impa= ct > the imported module. As such, and because it is a SHOULD and not a MUST, > this is a "nice to have" without conflicts, but one would not be wrong > using a different prefix from the one defined in the imported module. Add > to this, most tools, e.g. pyang or yanglint do not complain if you do > define a different prefix when there are no conflicts. I have not seen a > problem in the implementation of the module when the prefix is different. > > > > RFC 8407 confuses this whole situation by saying: > > > > The proper module prefix MUST be used for all identifiers importe= d > > from other modules. > > > > which as written is true for identifiers (but not for other types of > imports??). Besides, it does not define what is "proper module prefix". I= n > the absence of a proper definition, one should follow what RFC 7950 says. > > > > Comments? > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --000000000000418ea305bdd36731 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 18, 2021 at 10:41 AM Don = Fedyk <dfedyk@labn.net> wrote:=

So you are saying I should beat up on the tool chain= people that have not followed the spec. I tried that already =F0=9F=98= =8A , but since I can redefine the prefixes locally as a workaround,= and I couldn=E2=80=99t convince them it was an issue, it fell by the waysi= de with one tool so far.

=C2=A0

If =C2=A0the spec was more precise it would settle t= he arguments.


I think it is= unfortunate that the IETF wanted so many clever little rules for the creat= ion of YANG modules.
Also unfortunate that RFC 2119 terms in the = style guide get confused with similar terms in the YANG RFC.

=
RFC 8407 is normative for IETF YANG module authors.
RF= C 7950 is for YANG module tool-makers.
People should know the dif= ference, especially since 8407 only applies to the IETF, not other organiza= tions.


<= div class=3D"gmail-m_6005169802676718965WordSection1">

Regards, =C2=A0

Don


=
Andy
=C2=A0
<= div class=3D"gmail-m_6005169802676718965WordSection1">

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk <dfedyk@labn.net>
Cc: tom petch <ietfc@btconnect.com>; Mahesh Jethanandani <mjethanandani@gmail.com&g= t;; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; = netmod@ietf.org Subject: Re: [netmod] Use of prefixes in YANG models

=C2=A0

=C2=A0

=C2=A0

On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk <dfedyk@labn.net> wro= te:

Clarity and consistency= would help.

Many of the supporting tool chains are picky about prefixes. IE they must b= e the same as in the definition file.=C2=A0 I have a case where yanglint wa= nts "local prefixes or derived-from(-or-self) construct" for an l= ocal identity in an xpath statement. (either remedy seems to work.) I argued for the prefixes in but others argue they are not= necessary but I cannot validate without them.

=C2=A0

=C2=A0

The tool makers should understand that YANG prefixes= are not required to be unique.

It is understood that short character sequences have= a high probability of duplication.

So what if the server wants to support 2 modules wit= h the same prefix defined in the YANG module?

Is it not clear that the ENTIRE point of having the = prefix-stmt in the import-stmt is

because the imported modules may have prefixes that = collide?

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

"not(derived-from(../../bridge-type,'two-po= rt-mac-relay-bridge'))" works (prefix/no prefix)
But "../../bridge-type !=3D 'dot1q:two-port-mac-relay-bridge'= =C2=A0 =C2=A0 =C2=A0 works too.

Thanks
Don



-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>; Juergen Schoenwaelder <j.s= choenwaelder@jacobs-university.de>
Cc: netmod@ietf.org
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod <netmod-bounces@ietf.org> on behalf of Juergen Schoenwaelder <<= a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D"_blank">j.= schoenwaelder@jacobs-university.de>
Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements from= usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is h= elpful for _humans_ to always use 'if:name' when you refer to the l= eaf 'name' defined in 'ietf-interfaces' or 'yang:date-a= nd-time' when you refer to 'date-and-time' defined in 'ietf= -yang-types'.

I believe we agreed that module authors assigning a prefix different from t= he default prefix during an import should have either technical reasons for= doing so (resolving prefixes clashes) or some other good reason to depart = from the general guideline aiming to reduce human confusion.

<tp>
To make an abstract concept concrete, draft-ietf-babel-yang-model imports y= ang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time o= r yt:counter32.=C2=A0 An early YANG Doctor review by Radek did not comment = on this aspect of the I-D.=C2=A0 More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)
On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, speciall= y as it relates to their use when importing a model. I think it would nice = to be clear on what is required, what is nice, and what is not ok to do. I = do not want to confuse this discussion with the length of the prefix, which I believe is somewhat related but not= the same discussion.
>
> RFC 7950 says:
>
>=C2=A0 =C2=A0 All prefixes, including the prefix for the module itself,= MUST be
>=C2=A0 =C2=A0 unique within the module or submodule.
>
> This is a requirement, as is clear by the MUST.
>
> Then RFC 7950 says:
>
>=C2=A0 =C2=A0 To
>=C2=A0 =C2=A0 improve readability of YANG modules, the prefix defined b= y a module
>=C2=A0 =C2=A0 SHOULD be used when the module is imported, unless there = is a
>=C2=A0 =C2=A0 conflict.
>
> It also says:
>
>=C2=A0 =C2=A0 When used inside the "import" statement, the &q= uot;prefix" statement
>=C2=A0 =C2=A0 defines the prefix to be used when accessing definitions = inside the
>=C2=A0 =C2=A0 imported module.
>
> Clearly, the scope of the "prefix" statement used with an &q= uot;import" statement is limited to the module where it is imported an= d does not impact the imported module. As such, and because it is a SHOULD = and not a MUST, this is a "nice to have"=C2=A0 without conflicts, but one would not be wrong using a different prefix from the one defined i= n the imported module. Add to this, most tools, e.g. pyang or yanglint do n= ot complain if you do define a different prefix when there are no conflicts= . I have not seen a problem in the implementation of the module when the prefix is different.
>
> RFC 8407 confuses this whole situation by saying:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The proper module prefix MUST be used for al= l identifiers imported
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from other modules.
>
> which as written is true for identifiers (but not for other types of i= mports??). Besides, it does not define what is "proper module prefix&q= uot;. In the absence of a proper definition, one should follow what RFC 795= 0 says.
>
> Comments?
>
> Mahesh Jethanandani
> mjethanan= dani@gmail.com
>
>
>
>
>

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jac= obs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

--000000000000418ea305bdd36731-- From nobody Fri Mar 19 01:59:20 2021 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 56DCA3A17FE for ; Fri, 19 Mar 2021 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 am1tpYCBZeAN for ; Fri, 19 Mar 2021 01:59:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DE23A17E4 for ; Fri, 19 Mar 2021 01:59:14 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 84337140B54; Fri, 19 Mar 2021 09:59:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1616144347; bh=vf1lb/U0+TxCwo767JEq/Mjff3I53H28VeLh89LZZKo=; h=From:To:Date; b=i0fuvW8TucHssKu4GGkRlwRT2aV87LkBOTnFCjXTtCrthuIPx7mpUWsa6EcCnzH/X Z6aqi6ppbghb3QYM0R3FzT8LdFBE/nMemoBTlk0+IC4MFUxlr6Awk33oWC6C1rPtD3 j7HOYbgvIremVgFAbNDgUkT3oxKSpivxYGgduMgY= From: Ladislav Lhotka To: Don Fedyk , tom petch , Mahesh Jethanandani , Juergen Schoenwaelder Cc: "netmod@ietf.org" In-Reply-To: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> Mail-Followup-To: Don Fedyk , tom petch , Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Date: Fri, 19 Mar 2021 09:59:07 +0100 Message-ID: <877dm3frj8.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 08:59:19 -0000 Don Fedyk writes: > Clarity and consistency would help. Right, but mainly human readers. Properly written tools should have no problems with > > Many of the supporting tool chains are picky about prefixes. IE they > must be the same as in the definition file. I have a case where This is simply wrong, but it is in fact the same problem that plagued XML. James Clark, one of XML gurus, identified the namespace/prefix duality as a serious design flaw in XML. This is an instructive reading: https://blog.jclark.com/2010/01/xml-namespaces.html > yanglint wants "local prefixes or derived-from(-or-self) construct" > for an local identity in an xpath statement. (either remedy seems to > work.) I argued for the prefixes in but others argue they are not > necessary but I cannot validate without them. > > "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works (prefix/no prefix) > But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge' works too. The latter is known to be brittle and shoould not be used. That's why the derived-from function was introduced. Lada > > Thanks > Don > > > > -----Original Message----- > From: netmod On Behalf Of tom petch > Sent: Thursday, March 18, 2021 7:50 AM > To: Mahesh Jethanandani ; Juergen Schoenwaelder > Cc: netmod@ietf.org > Subject: Re: [netmod] Use of prefixes in YANG models > > From: netmod on behalf of Juergen Schoenwaelder > Sent: 18 March 2021 08:05 > > We often do not do a good job in distinguishing technical requirements from usage guidelines. (And RFC 2119 keywords make things worse.) > > As far as I recall, the intent of the RFC 8407 text was to say that it is helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 'date-and-time' defined in 'ietf-yang-types'. > > I believe we agreed that module authors assigning a prefix different from the default prefix during an import should have either technical reasons for doing so (resolving prefixes clashes) or some other good reason to depart from the general guideline aiming to reduce human confusion. > > > To make an abstract concept concrete, draft-ietf-babel-yang-model imports yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or yt:counter32. An early YANG Doctor review by Radek did not comment on this aspect of the I-D. More recently, I have. > > Tom Petch > > > > /js (who stopped believing that RFC 2119 keywords are helpful years ago) > > On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: >> I have seen the debate on the use of prefixes in YANG models, specially as it relates to their use when importing a model. I think it would nice to be clear on what is required, what is nice, and what is not ok to do. I do not want to confuse this discussion with the length of the prefix, which I believe is somewhat related but not the same discussion. >> >> RFC 7950 says: >> >> All prefixes, including the prefix for the module itself, MUST be >> unique within the module or submodule. >> >> This is a requirement, as is clear by the MUST. >> >> Then RFC 7950 says: >> >> To >> improve readability of YANG modules, the prefix defined by a module >> SHOULD be used when the module is imported, unless there is a >> conflict. >> >> It also says: >> >> When used inside the "import" statement, the "prefix" statement >> defines the prefix to be used when accessing definitions inside the >> imported module. >> >> Clearly, the scope of the "prefix" statement used with an "import" statement is limited to the module where it is imported and does not impact the imported module. As such, and because it is a SHOULD and not a MUST, this is a "nice to have" without conflicts, but one would not be wrong using a different prefix from the one defined in the imported module. Add to this, most tools, e.g. pyang or yanglint do not complain if you do define a different prefix when there are no conflicts. I have not seen a problem in the implementation of the module when the prefix is different. >> >> RFC 8407 confuses this whole situation by saying: >> >> The proper module prefix MUST be used for all identifiers imported >> from other modules. >> >> which as written is true for identifiers (but not for other types of imports??). Besides, it does not define what is "proper module prefix". In the absence of a proper definition, one should follow what RFC 7950 says. >> >> Comments? >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> > >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Mar 19 02:23:22 2021 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 640A53A0902 for ; Fri, 19 Mar 2021 02:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxKIbm_NLHlF for ; Fri, 19 Mar 2021 02:23:09 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00116.outbound.protection.outlook.com [40.107.0.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565CD3A086E for ; Fri, 19 Mar 2021 02:23:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lkca8HPcdNbDhXgXEi57uVkaggIYnmIKHIaVl9dR6sQFZ0G7vXvC1azq4OiVt+EJSegq5xv0lgdBKBCHSxqeYY/lMUT7iXqGZSysG0e89/DmHFax15nb1IFqQ/GCCIJuLPgjrUlMQqMLUkrOZ1szgepirCnPKTyf7X3jWogkuGk0p8fw1WwLIvtIIgFw/cU0EivTKV1ykryZ+nCUao4ojlK62xsjTvXqMiRR43fQNqkk4RP73OYQzUDqZAOsjNQbJnGJUB+6Fi/j7ChnGASAV68TarU4Xt/QbEwJ6IfLYDKBxFjMuc0PwClZPiGkILZVu6X0sRruiGlkF2LrUlhq6w== 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=qFroCTRa+6w4ob+6/25FEPNEakInKxAKkc80bF0nv4o=; b=MJtFtQCcGtxz4sp19zFF62FROZ7zikCj1DTmZnmmv/9++yEu4MbdGklpREKB95dqD8OgLaYMsi5Jm3yymUAiuX+SZXyq7ykRWR61vtD+GGZ2ee2X+b81yUdir2HzETh2IPfVvsyJ1ze5CFtU7OCLBAVAqBQ5aIbYm7fGkxqExrWLBISajaKALfBQU1ZO7TrANw4XLMAbuZSM823l4EqALi9hmxZAfwnVW7+H8zfjmKzhwyoRlPhQEhDFd7nkkhnaLM0pI5q5vX98bdQOCUYcbcMuEH0VnAmpm0N4IM+suN3BbbACSd82hyEQF3InRwOZFtAJuEZmLWfVmHIauTkh2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qFroCTRa+6w4ob+6/25FEPNEakInKxAKkc80bF0nv4o=; b=RXvCY0riNdXnfq1us+KcejOUOCwytQ0wqazr5QJO8M65aB30GXqX6R6h1PcI7pVhpc8cJrlgLs2gg4P6g/QqUQ5prpsrqsKmZP7peP+hkCfl50czwOn1964YgMD8g3v7zWGghT2o4UMw5wWImexj5Ky+Jwm2ghJWPV+B61vGWEA= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR0702MB3799.eurprd07.prod.outlook.com (2603:10a6:209:e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.10; Fri, 19 Mar 2021 09:23:06 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3955.023; Fri, 19 Mar 2021 09:23:06 +0000 From: tom petch To: Andy Bierman CC: Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Use of prefixes in YANG models Thread-Index: AQHXG4oeNuzkx0+3DEiWrin2IABkWaqJY72AgAA85lKAAFp/gIAABHSAgAAFPoCAAAXFAIAA/tMb Date: Fri, 19 Mar 2021 09:23:06 +0000 Message-ID: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0579a12-1f75-44a6-3c0f-08d8eab89ae3 x-ms-traffictypediagnostic: AM6PR0702MB3799: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fOzP0XmVurq/USM8XszdTLipYbXmluoWqYeoV0mEGDDUYXHrY2MDa8C1PEBt70qxHBA2j+NEKiZhd//8trxYMT0hDXm+/oHYPBRrXXbZR4gTUp3Wj2Wm5G3jk4Y6pKiCZy0vT38qzUg2OV/NFNMkg4IoTcTquyFBDku2smXfktaLq6csEAld6N9YnH1R5f0LD1yFYYICqEHeqUEfx3VGQnA81oq3v3RY1hXZCrNYAT59yjfWZ5lnXpxEe1T1UWtTzzO6xKm8tVQ/7wwyDd7lM8MYq8WrZjd66y8zZ8XyI74nKXgwR//MBxoslXCuYgJkKXHnWTCRph6I2EXFHW3D7qgdUJ7PacZkn/j+q8s+XOa0N3vvXFCVqsFZet/Ch6R0Bm6VfFIvGUC9K4l7Hn620uPJ9smEiBNu5b3SBUty4y1tpZOtcDirJC/RpyLoRilsxcXG/7HgfUninS7g8ISLlFU8vfkp4LcWdbAiE3IxxgN2s0dG46xnFaR26flN7K5YoO6DRonqZQqScHMqgYQzOxSjSxjDmmGZ8Qwhn5OWGj5Y9evSe8h2E9Risct7wi/tK3SD7M7VZlzKoHnuZ33bMhM0EVSlD5bPvNHNTpGOyWSlQMzONvICTTXwWEWpqF58J2xHolQUQARnMiiQEI4eovp3T4A42rOiRKGT7IYR5SBMEiYRJu+Gb4dlUoF3Wb8nr45ycJ3qg7owQIRBcysFa0gcEgSjjFFlKpW17+/OHvfbkovcT9eBn3IjB3xYp2/yUQ/jR9sDCqwcDUKRymYnsg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(376002)(39860400002)(136003)(366004)(2906002)(9686003)(52536014)(86362001)(26005)(4326008)(5660300002)(53546011)(54906003)(6506007)(83380400001)(966005)(66476007)(64756008)(55016002)(66446008)(6916009)(33656002)(66556008)(186003)(8936002)(316002)(8676002)(478600001)(71200400001)(76116006)(91956017)(66946007)(7696005)(38100700001)(170073001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?SWlNbkRsZ1VybFNEZ2Rka1NIcGdrTmtIczJiL25RdWtwdUprb20wZFFjUkZy?= =?utf-8?B?NU9SeVdraEFvTUNyRm12YkhJU0FPZFZIV05aSm1MelI0SWdxYk1Ed3NiRHVU?= =?utf-8?B?ZndrZ0pnSFJJV1djVzZIR2xwemlWWm45UEdqeXZMeXh6N01QSU1Ld043T1dj?= =?utf-8?B?V0hIeTFJZi9sQ1JYVis3QTBZdGlPQVNTN1Y0VXN1UUZ1ZWlBVGlKdHlrV2Nm?= =?utf-8?B?RFpKMEhJTE5JT3JNNzI0cjRQM1ZhaUFCSlE5dE41bGhBZytsTlJ2ZlAzc3Zp?= =?utf-8?B?NWlzWFJSYjVIMnBnRkcxeTNFSHUvTTRxalFPRkQyYnY5ajVMNHJOaWhDNXpr?= =?utf-8?B?bVZMdHNrVUkvU2gvWVBLaHIvb0EyQU1MeStHNDF3Q21NSXZub1dCNmZRbjlW?= =?utf-8?B?RTJUdTJMZzFoRldWcnV5amgxWEtUaUlYTlB5L0VKY25ZbFBBRDBYTlFjTGNz?= =?utf-8?B?alBRL0t3T2R0MkhucStDVENjY3R3a0t2VUFoN0hTVVJkeGROTGxRelBhRGlQ?= =?utf-8?B?L1VLT1FRaks0RHF4S3lhRmZtckZVY2dZcWQ2R01XQVNEZzdUbmhTY3JsZmFE?= =?utf-8?B?OG9oSmRwcndVSVJLUm9RMjRxaGo3WUtFYWxwbUFGaSttV2EwYUFhVktOZ2xQ?= =?utf-8?B?Z3RBWDhkR2JPV0ViellCeUhLQ1ZidVBFOTgwL1gvdWpuV2ZtNWVXMlpMK2tp?= =?utf-8?B?ZnZ2VnhGa29odXhSUStZYm5NSGxiRmQ5ZjZPbEM4VTg5KzlGV1NnZHRkVnFN?= =?utf-8?B?ZUJyYUNNQjFWUm1mVkxlT2R5ZUtTTXJYSzlFZldsOVJJUlpqRldWdTdlMFIz?= =?utf-8?B?WDZVYVZ6N05Obm9zeXhyblRiUVRKSUF1VEdWeTZRSkpDNnZkT1N0aWRHZENl?= =?utf-8?B?L2JrcnJvQUI4THhZZDZPcGNBeUM2bzloemFEM2xueEtOZVN6MU9vQmVNZEJI?= =?utf-8?B?ODZiaXpOa0tJd3BTdmNZT3BxdHFKVmtTNThOTDZzM1o2OVhXWDdrYzJIWGtX?= =?utf-8?B?UWZ4OFh6MzNSWitzYm5xVE51S1hIaDhkazFLbDN6a3pyM3kyMmRFSnkwaldJ?= =?utf-8?B?U3dTWi9QSkQvRWNFWmZJa1FXbzVGNzJPU2dPVWl5YWg0UDJoM1hJRzFiR1dY?= =?utf-8?B?YjFXanltMmZKTk50MVIrbExSenNFYUUvWlNpQVhxZWRBd3RkVXdNWHc5QXky?= =?utf-8?B?SklyL21GQWU5cTcvVEloM2FTd3VqL0UzemVXQmxHVE1hZ1ovd3dNVkI0T2xY?= =?utf-8?B?V3ZwTkJ3TTZERVJlakp3dFhpdGZObzVLVGx2VmpwUFZBQnpBUTVTRE00OTlY?= =?utf-8?B?cXRmSWlZbTd6UFVzU3NqK2NwUktnREd0V0UrYm1ZUWtONXJsSzR1SVdrN0FC?= =?utf-8?B?RXo3WldkdmkyVlNxVTcwbFpJU0hMTVBaM0t4RVRrOHE1UUhHQ1Z1UWRid2FU?= =?utf-8?B?U0FnOEd0THJPSk5VQy9lZ2NGRVRYRUFaWEhCaGYzTmF0d2hWWThTckhWR3N5?= =?utf-8?B?OG94ekk5emRobVF2WHFZbzBxZFowa09JSXVoU2dmWmNxUXdHSDFxR1pNeUc0?= =?utf-8?B?T1E5VlFPRnFneWZ6WEUrTGpOZkd2T1hTVC9oUUxOeWlZbjZMV0tyQ1UxRFZ2?= =?utf-8?B?b3VkNDBBNHlkbFJxZE13NzhkbEw2cU1JeTlDTUxKT2M1NlFEczR0ZUFqUHVV?= =?utf-8?B?V3VvSUM4MndiWlJjckxtM0ZMbGNybVlwQWZMY0lPQWhlV0kvVlRSZXEreUtz?= =?utf-8?Q?M4eB/dqZXlCuzYn++pTd3QbYqfeMfF41dp1gI59?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0579a12-1f75-44a6-3c0f-08d8eab89ae3 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 09:23:06.5355 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ejXlm48Nz4UylDoOug7NILUr59/ueeqEn872YbCdbLFELqiEYsRZLvT4ej2Fn2lByV2zs+A4rO5Z1mc+FR8B/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3799 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 09:23:16 -0000 RnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+ClNlbnQ6IDE4IE1hcmNoIDIw MjEgMTg6MDIKCk9uIFRodSwgTWFyIDE4LCAyMDIxIGF0IDEwOjQxIEFNIERvbiBGZWR5ayA8ZGZl ZHlrQGxhYm4ubmV0PG1haWx0bzpkZmVkeWtAbGFibi5uZXQ+PiB3cm90ZToKU28geW91IGFyZSBz YXlpbmcgSSBzaG91bGQgYmVhdCB1cCBvbiB0aGUgdG9vbCBjaGFpbiBwZW9wbGUgdGhhdCBoYXZl IG5vdCBmb2xsb3dlZCB0aGUgc3BlYy4gSSB0cmllZCB0aGF0IGFscmVhZHkg8J+YiiAsIGJ1dCBz aW5jZSBJIGNhbiByZWRlZmluZSB0aGUgcHJlZml4ZXMgbG9jYWxseSBhcyBhIHdvcmthcm91bmQs IGFuZCBJIGNvdWxkbuKAmXQgY29udmluY2UgdGhlbSBpdCB3YXMgYW4gaXNzdWUsIGl0IGZlbGwg YnkgdGhlIHdheXNpZGUgd2l0aCBvbmUgdG9vbCBzbyBmYXIuCgpJZiAgdGhlIHNwZWMgd2FzIG1v cmUgcHJlY2lzZSBpdCB3b3VsZCBzZXR0bGUgdGhlIGFyZ3VtZW50cy4KCkkgdGhpbmsgaXQgaXMg dW5mb3J0dW5hdGUgdGhhdCB0aGUgSUVURiB3YW50ZWQgc28gbWFueSBjbGV2ZXIgbGl0dGxlIHJ1 bGVzIGZvciB0aGUgY3JlYXRpb24gb2YgWUFORyBtb2R1bGVzLgpBbHNvIHVuZm9ydHVuYXRlIHRo YXQgUkZDIDIxMTkgdGVybXMgaW4gdGhlIHN0eWxlIGd1aWRlIGdldCBjb25mdXNlZCB3aXRoIHNp bWlsYXIgdGVybXMgaW4gdGhlIFlBTkcgUkZDLgoKUkZDIDg0MDcgaXMgbm9ybWF0aXZlIGZvciBJ RVRGIFlBTkcgbW9kdWxlIGF1dGhvcnMuClJGQyA3OTUwIGlzIGZvciBZQU5HIG1vZHVsZSB0b29s LW1ha2Vycy4KUGVvcGxlIHNob3VsZCBrbm93IHRoZSBkaWZmZXJlbmNlLCBlc3BlY2lhbGx5IHNp bmNlIDg0MDcgb25seSBhcHBsaWVzIHRvIHRoZSBJRVRGLCBub3Qgb3RoZXIgb3JnYW5pemF0aW9u cy4KCjx0cD4KQXBvbG9naWVzIGZvciB0aGUgdXNlbGVzcyBxdW90aW5nIHRoYXQgbXkgd2VibWFp bCBpbXBvc2VzIG9uIG1lOi0oCgpBbmR5CgpPZiBjb3Vyc2UgdG9vbCBjaGFpbnMgc2hvdWxkIGFs bG93IGZvciBhIGNoYW5nZSBvZiBwcmVmaXggYnV0IHlvdSBkaWQgd3JpdGUsIGluIFJGQzg0MDcs CiIgICBvICBUaGUgcHJvcGVyIG1vZHVsZSBwcmVmaXggTVVTVCBiZSB1c2VkIGZvciBhbGwgaWRl bnRpZmllcnMgaW1wb3J0ZWQKICAgICAgZnJvbSBvdGhlciBtb2R1bGVzLgoiCmFuZCB0aGlzIGRp c2N1c3Npb24gc3RhcnRlZCB3aXRoIHRoZSBtZWFuaW5nIG9mICdwcm9wZXInIGhlcmUuICBJIHRh a2UgaXQgdG8gbWVhbiB0aGUgcHJlZml4IGRlZmluZWQgYnkgdGhlIGF1dGhvciBvZiB0aGUgaW1w b3J0ZWQgbW9kdWxlLiAgSSBtYXkgaGF2ZSBhIGJyaWxsaWFudCBpZGVhIHRoYXQgaXMgYSBtYXNz aXZlIGltcHJvdmVtZW50IG9uIHdoYXQgdGhlIGF1dGhvciBvZiB0aGUgaW1wb3J0ZWQgbW9kdWxl IGNob3NlLCBidXQgdG9vIGxhdGUuICBJZiB0aGlzIGlzIGFuIFJGQywgdGhlbiBJIGNhbiBvbmx5 IGNhdXNlIGNvbmZ1c2lvbiBieSB1c2luZyBhIGRpZmZlcmVudCBwcmVmaXggaW4gbXkgbW9kdWxl IGFuZCB0aGF0IHdvdWxkIGJlIGltcHJvcGVyLgoKSXMgdGhpcyB3aGF0IHlvdSBpbnRlbmRlZD8K ClRvbSBQZXRjaAoKUmVnYXJkcywKRG9uCgoKQW5keQoKCkZyb206IEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PgpTZW50OiBUaHVyc2Rh eSwgTWFyY2ggMTgsIDIwMjEgMToyMyBQTQpUbzogRG9uIEZlZHlrIDxkZmVkeWtAbGFibi5uZXQ8 bWFpbHRvOmRmZWR5a0BsYWJuLm5ldD4+CkNjOiB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5j b208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+PjsgTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpl dGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj47IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PjsgbmV0bW9kQGll dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBVc2Ug b2YgcHJlZml4ZXMgaW4gWUFORyBtb2RlbHMKCgoKT24gVGh1LCBNYXIgMTgsIDIwMjEgYXQgMTA6 MDcgQU0gRG9uIEZlZHlrIDxkZmVkeWtAbGFibi5uZXQ8bWFpbHRvOmRmZWR5a0BsYWJuLm5ldD4+ IHdyb3RlOgpDbGFyaXR5IGFuZCBjb25zaXN0ZW5jeSB3b3VsZCBoZWxwLgoKTWFueSBvZiB0aGUg c3VwcG9ydGluZyB0b29sIGNoYWlucyBhcmUgcGlja3kgYWJvdXQgcHJlZml4ZXMuIElFIHRoZXkg bXVzdCBiZSB0aGUgc2FtZSBhcyBpbiB0aGUgZGVmaW5pdGlvbiBmaWxlLiAgSSBoYXZlIGEgY2Fz ZSB3aGVyZSB5YW5nbGludCB3YW50cyAibG9jYWwgcHJlZml4ZXMgb3IgZGVyaXZlZC1mcm9tKC1v ci1zZWxmKSBjb25zdHJ1Y3QiIGZvciBhbiBsb2NhbCBpZGVudGl0eSBpbiBhbiB4cGF0aCBzdGF0 ZW1lbnQuIChlaXRoZXIgcmVtZWR5IHNlZW1zIHRvIHdvcmsuKSBJIGFyZ3VlZCBmb3IgdGhlIHBy ZWZpeGVzIGluIGJ1dCBvdGhlcnMgYXJndWUgdGhleSBhcmUgbm90IG5lY2Vzc2FyeSBidXQgSSBj YW5ub3QgdmFsaWRhdGUgd2l0aG91dCB0aGVtLgoKClRoZSB0b29sIG1ha2VycyBzaG91bGQgdW5k ZXJzdGFuZCB0aGF0IFlBTkcgcHJlZml4ZXMgYXJlIG5vdCByZXF1aXJlZCB0byBiZSB1bmlxdWUu Ckl0IGlzIHVuZGVyc3Rvb2QgdGhhdCBzaG9ydCBjaGFyYWN0ZXIgc2VxdWVuY2VzIGhhdmUgYSBo aWdoIHByb2JhYmlsaXR5IG9mIGR1cGxpY2F0aW9uLgpTbyB3aGF0IGlmIHRoZSBzZXJ2ZXIgd2Fu dHMgdG8gc3VwcG9ydCAyIG1vZHVsZXMgd2l0aCB0aGUgc2FtZSBwcmVmaXggZGVmaW5lZCBpbiB0 aGUgWUFORyBtb2R1bGU/CklzIGl0IG5vdCBjbGVhciB0aGF0IHRoZSBFTlRJUkUgcG9pbnQgb2Yg aGF2aW5nIHRoZSBwcmVmaXgtc3RtdCBpbiB0aGUgaW1wb3J0LXN0bXQgaXMKYmVjYXVzZSB0aGUg aW1wb3J0ZWQgbW9kdWxlcyBtYXkgaGF2ZSBwcmVmaXhlcyB0aGF0IGNvbGxpZGU/CgoKCkFuZHkK CiJub3QoZGVyaXZlZC1mcm9tKC4uLy4uL2JyaWRnZS10eXBlLCd0d28tcG9ydC1tYWMtcmVsYXkt YnJpZGdlJykpIiB3b3JrcyAocHJlZml4L25vIHByZWZpeCkKQnV0ICIuLi8uLi9icmlkZ2UtdHlw ZSAhPSAnZG90MXE6dHdvLXBvcnQtbWFjLXJlbGF5LWJyaWRnZScgICAgICB3b3JrcyB0b28uCgpU aGFua3MKRG9uCgoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZyb206IG5ldG1vZCA8bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gT24g QmVoYWxmIE9mIHRvbSBwZXRjaApTZW50OiBUaHVyc2RheSwgTWFyY2ggMTgsIDIwMjEgNzo1MCBB TQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj47IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU+PgpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBVc2Ugb2YgcHJlZml4ZXMgaW4gWUFORyBtb2Rl bHMKCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJA amFjb2JzLXVuaXZlcnNpdHkuZGU+PgpTZW50OiAxOCBNYXJjaCAyMDIxIDA4OjA1CgpXZSBvZnRl biBkbyBub3QgZG8gYSBnb29kIGpvYiBpbiBkaXN0aW5ndWlzaGluZyB0ZWNobmljYWwgcmVxdWly ZW1lbnRzIGZyb20gdXNhZ2UgZ3VpZGVsaW5lcy4gKEFuZCBSRkMgMjExOSBrZXl3b3JkcyBtYWtl IHRoaW5ncyB3b3JzZS4pCgpBcyBmYXIgYXMgSSByZWNhbGwsIHRoZSBpbnRlbnQgb2YgdGhlIFJG QyA4NDA3IHRleHQgd2FzIHRvIHNheSB0aGF0IGl0IGlzIGhlbHBmdWwgZm9yIF9odW1hbnNfIHRv IGFsd2F5cyB1c2UgJ2lmOm5hbWUnIHdoZW4geW91IHJlZmVyIHRvIHRoZSBsZWFmICduYW1lJyBk ZWZpbmVkIGluICdpZXRmLWludGVyZmFjZXMnIG9yICd5YW5nOmRhdGUtYW5kLXRpbWUnIHdoZW4g eW91IHJlZmVyIHRvICdkYXRlLWFuZC10aW1lJyBkZWZpbmVkIGluICdpZXRmLXlhbmctdHlwZXMn LgoKSSBiZWxpZXZlIHdlIGFncmVlZCB0aGF0IG1vZHVsZSBhdXRob3JzIGFzc2lnbmluZyBhIHBy ZWZpeCBkaWZmZXJlbnQgZnJvbSB0aGUgZGVmYXVsdCBwcmVmaXggZHVyaW5nIGFuIGltcG9ydCBz aG91bGQgaGF2ZSBlaXRoZXIgdGVjaG5pY2FsIHJlYXNvbnMgZm9yIGRvaW5nIHNvIChyZXNvbHZp bmcgcHJlZml4ZXMgY2xhc2hlcykgb3Igc29tZSBvdGhlciBnb29kIHJlYXNvbiB0byBkZXBhcnQg ZnJvbSB0aGUgZ2VuZXJhbCBndWlkZWxpbmUgYWltaW5nIHRvIHJlZHVjZSBodW1hbiBjb25mdXNp b24uCgo8dHA+ClRvIG1ha2UgYW4gYWJzdHJhY3QgY29uY2VwdCBjb25jcmV0ZSwgZHJhZnQtaWV0 Zi1iYWJlbC15YW5nLW1vZGVsIGltcG9ydHMgeWFuZyB0eXBlcyBmcm9tIFJGQzY5OTEgYW5kIGdp dmVzIGl0IHRoZSBwcmVmaXggeXQ6IGFzIGluIHl0OmRhdGUtYW5kLXRpbWUgb3IgeXQ6Y291bnRl cjMyLiAgQW4gZWFybHkgWUFORyBEb2N0b3IgcmV2aWV3IGJ5IFJhZGVrIGRpZCBub3QgY29tbWVu dCBvbiB0aGlzIGFzcGVjdCBvZiB0aGUgSS1ELiAgTW9yZSByZWNlbnRseSwgSSBoYXZlLgoKVG9t IFBldGNoCgoKCi9qcyAod2hvIHN0b3BwZWQgYmVsaWV2aW5nIHRoYXQgUkZDIDIxMTkga2V5d29y ZHMgYXJlIGhlbHBmdWwgeWVhcnMgYWdvKQoKT24gV2VkLCBNYXIgMTcsIDIwMjEgYXQgMDU6MDM6 MTFQTSAtMDcwMCwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToKPiBJIGhhdmUgc2VlbiB0aGUg ZGViYXRlIG9uIHRoZSB1c2Ugb2YgcHJlZml4ZXMgaW4gWUFORyBtb2RlbHMsIHNwZWNpYWxseSBh cyBpdCByZWxhdGVzIHRvIHRoZWlyIHVzZSB3aGVuIGltcG9ydGluZyBhIG1vZGVsLiBJIHRoaW5r IGl0IHdvdWxkIG5pY2UgdG8gYmUgY2xlYXIgb24gd2hhdCBpcyByZXF1aXJlZCwgd2hhdCBpcyBu aWNlLCBhbmQgd2hhdCBpcyBub3Qgb2sgdG8gZG8uIEkgZG8gbm90IHdhbnQgdG8gY29uZnVzZSB0 aGlzIGRpc2N1c3Npb24gd2l0aCB0aGUgbGVuZ3RoIG9mIHRoZSBwcmVmaXgsIHdoaWNoIEkgYmVs aWV2ZSBpcyBzb21ld2hhdCByZWxhdGVkIGJ1dCBub3QgdGhlIHNhbWUgZGlzY3Vzc2lvbi4KPgo+ IFJGQyA3OTUwIHNheXM6Cj4KPiAgICBBbGwgcHJlZml4ZXMsIGluY2x1ZGluZyB0aGUgcHJlZml4 IGZvciB0aGUgbW9kdWxlIGl0c2VsZiwgTVVTVCBiZQo+ICAgIHVuaXF1ZSB3aXRoaW4gdGhlIG1v ZHVsZSBvciBzdWJtb2R1bGUuCj4KPiBUaGlzIGlzIGEgcmVxdWlyZW1lbnQsIGFzIGlzIGNsZWFy IGJ5IHRoZSBNVVNULgo+Cj4gVGhlbiBSRkMgNzk1MCBzYXlzOgo+Cj4gICAgVG8KPiAgICBpbXBy b3ZlIHJlYWRhYmlsaXR5IG9mIFlBTkcgbW9kdWxlcywgdGhlIHByZWZpeCBkZWZpbmVkIGJ5IGEg bW9kdWxlCj4gICAgU0hPVUxEIGJlIHVzZWQgd2hlbiB0aGUgbW9kdWxlIGlzIGltcG9ydGVkLCB1 bmxlc3MgdGhlcmUgaXMgYQo+ICAgIGNvbmZsaWN0Lgo+Cj4gSXQgYWxzbyBzYXlzOgo+Cj4gICAg V2hlbiB1c2VkIGluc2lkZSB0aGUgImltcG9ydCIgc3RhdGVtZW50LCB0aGUgInByZWZpeCIgc3Rh dGVtZW50Cj4gICAgZGVmaW5lcyB0aGUgcHJlZml4IHRvIGJlIHVzZWQgd2hlbiBhY2Nlc3Npbmcg ZGVmaW5pdGlvbnMgaW5zaWRlIHRoZQo+ICAgIGltcG9ydGVkIG1vZHVsZS4KPgo+IENsZWFybHks IHRoZSBzY29wZSBvZiB0aGUgInByZWZpeCIgc3RhdGVtZW50IHVzZWQgd2l0aCBhbiAiaW1wb3J0 IiBzdGF0ZW1lbnQgaXMgbGltaXRlZCB0byB0aGUgbW9kdWxlIHdoZXJlIGl0IGlzIGltcG9ydGVk IGFuZCBkb2VzIG5vdCBpbXBhY3QgdGhlIGltcG9ydGVkIG1vZHVsZS4gQXMgc3VjaCwgYW5kIGJl Y2F1c2UgaXQgaXMgYSBTSE9VTEQgYW5kIG5vdCBhIE1VU1QsIHRoaXMgaXMgYSAibmljZSB0byBo YXZlIiAgd2l0aG91dCBjb25mbGljdHMsIGJ1dCBvbmUgd291bGQgbm90IGJlIHdyb25nIHVzaW5n IGEgZGlmZmVyZW50IHByZWZpeCBmcm9tIHRoZSBvbmUgZGVmaW5lZCBpbiB0aGUgaW1wb3J0ZWQg bW9kdWxlLiBBZGQgdG8gdGhpcywgbW9zdCB0b29scywgZS5nLiBweWFuZyBvciB5YW5nbGludCBk byBub3QgY29tcGxhaW4gaWYgeW91IGRvIGRlZmluZSBhIGRpZmZlcmVudCBwcmVmaXggd2hlbiB0 aGVyZSBhcmUgbm8gY29uZmxpY3RzLiBJIGhhdmUgbm90IHNlZW4gYSBwcm9ibGVtIGluIHRoZSBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgbW9kdWxlIHdoZW4gdGhlIHByZWZpeCBpcyBkaWZmZXJlbnQu Cj4KPiBSRkMgODQwNyBjb25mdXNlcyB0aGlzIHdob2xlIHNpdHVhdGlvbiBieSBzYXlpbmc6Cj4K PiAgICAgICBUaGUgcHJvcGVyIG1vZHVsZSBwcmVmaXggTVVTVCBiZSB1c2VkIGZvciBhbGwgaWRl bnRpZmllcnMgaW1wb3J0ZWQKPiAgICAgICBmcm9tIG90aGVyIG1vZHVsZXMuCj4KPiB3aGljaCBh cyB3cml0dGVuIGlzIHRydWUgZm9yIGlkZW50aWZpZXJzIChidXQgbm90IGZvciBvdGhlciB0eXBl cyBvZiBpbXBvcnRzPz8pLiBCZXNpZGVzLCBpdCBkb2VzIG5vdCBkZWZpbmUgd2hhdCBpcyAicHJv cGVyIG1vZHVsZSBwcmVmaXgiLiBJbiB0aGUgYWJzZW5jZSBvZiBhIHByb3BlciBkZWZpbml0aW9u LCBvbmUgc2hvdWxkIGZvbGxvdyB3aGF0IFJGQyA3OTUwIHNheXMuCj4KPiBDb21tZW50cz8KPgo+ IE1haGVzaCBKZXRoYW5hbmRhbmkKPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20+Cj4KPgo+Cj4KPgoKPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+IG5ldG1vZCBtYWlsaW5nIGxpc3QKPiBuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZAoKCi0tCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIClBob25lOiArNDkgNDIxIDIwMCAzNTg3 ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkKRmF4OiAgICs0 OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv PgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9k IG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5nIGxpc3QKbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Cmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPgpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZAo= From nobody Fri Mar 19 03:46:25 2021 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 7D8CE3A0D92 for ; Fri, 19 Mar 2021 03:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_xlbP2J7goE for ; Fri, 19 Mar 2021 03:46:21 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2051.outbound.protection.outlook.com [40.107.21.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE4D3A0D8C for ; Fri, 19 Mar 2021 03:46:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RcuqrlhNDc88X3RiLrwPq3RNYJdZEieuymF0QlHsxSAVr16Gw0h5ww+/Zhzpxgd8+8Tc5sPHIE52qmTGTnt6jcJfV0LfK5HcaDaBC75BCXCKAGu/tg4uY8gUD6fZslqpNYvLV99vOqctYLnvagRbYKKlQWj9eVRU9dU+gkZrRCjbHPR73VOPpOZFukC2ykGl9E8NMCdPVK0m2hjmRUmNed3csWa9cJjsikbPp5VyHjiHGNf2k2d+ZVsM5wsIZmR9nuakCYSc9TN1xvp3vMla/5Sdp1Kp92c0/0aG/qbK1vOXy1JbwcTxEq/+FsxeKfTnUB5lja1bYA4KkWfzeoxDwQ== 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=x+wQm8PaOB21nOKOX1uIdvR3OyVlBe+8IM/mtxnVBpo=; b=S36684Of3vF2oB/4VoaJ42iJgOMJ+0LV79aEnXGxayIJxbhNZvZLlln0YrnjdeaT2ZPYZ+B7DtANLEaEQU4wRx1csHM0qAfOg3CagkT8dnVbtHtWPHSUOx8Blql8mJmV/Np4TNuOZBxM3ZdQAcC2o68XoF7aoORvXDOyZ2d/miqte3iROTHYDGmCTQseiBe13qeF2ex5jLTf1j0+XkAiA+CVa/CFeMXj9fdn7xcC9xPu3fevGOpESjVfLTkKdNPRML51RO8+1u6EpTnhRyLHF14YKnvR7MJSHFrBq1d3s2IRY8O8mUN6EgAabaINIX8qi9x88hIfmA7eiuq08ddBrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x+wQm8PaOB21nOKOX1uIdvR3OyVlBe+8IM/mtxnVBpo=; b=DrXkHneCQ+RFtpnaWGBHpAJekmj+XFWJrsIfriUqTxCngd2OVRP1wUS0DtoobPk6JOaoPDATX/TGhRdDUXSZCG8jRYgyNxS52dPf1Dk+sJJkYCrm6KA3Qy6PsZTmSffNgN3N/sYuXIOS2p6ETGJqlrRsHrWIZH37KbTg1L0b59c= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0852.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1c4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Fri, 19 Mar 2021 10:46:19 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3955.018; Fri, 19 Mar 2021 10:46:19 +0000 Date: Fri, 19 Mar 2021 11:46:17 +0100 From: Juergen Schoenwaelder To: "netmod@ietf.org" Message-ID: <20210319104617.hqhcxhnyfujfqoow@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "netmod@ietf.org" References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR02CA0171.eurprd02.prod.outlook.com (2603:10a6:20b:28e::8) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR02CA0171.eurprd02.prod.outlook.com (2603:10a6:20b:28e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Fri, 19 Mar 2021 10:46:18 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cb168fcd-54a3-4ed5-58d7-08d8eac43a6e X-MS-TrafficTypeDiagnostic: AM8P190MB0852: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vPMPhNwgjZYuSkWr1mhdJ4eSevwSvJKm2oguxLj67+xMxKx33Z8WTL2t39ksgiQ2M3BfZFgls8AADk9nBgh6IVczl0b5SD1ig+iQiqqAlACZHc5hX5kWd6IIfDdFR5oKS7TV2LB+AYqm5axu3aCC3lOB73DK5y6MaKBRqdNO2x+zGY4x3TpVSBUdUGpBTs7enBTRTalmWG9jSQhvexSHdnf3xN60tJfAKdINCeg9R8w2hJFu7gcEBp7xngS4X3cEWLDDVu/Obq4m2nLNv5AtQRjadtiPmpgjAMKRPrWbZ2Kg3ixSxe6ALfMFWS6EpTfomgOUljFuzSPClpe9yFt68jxxvBiBnCmqt1n71rHCdrcNmmebrgOBmKmZE4ZOSiBOOqI1YsnURckUfsZEVbwTDoYgByDhTrU/0bqRfSeXdo0kSiubzsOQjMFLcgFAtj5v9sMsXP0gZ3pBLv9OVeiTeZZ1i7LL10KbgLbE+erqu5Q9VVmthy+RVOqvGMMA6O5nFEyxwycVePzR9E5CKjAtD6dAfTAnRRw2ADHdMAF0IhZaEQi9fFxH3pFFCBySQ+ofcTktw3/WZ7QdzORoNtydgxX8UXfpsQE+fQ5dO5LH0cyKRoMnMchJIE2dLuNUZEGxNRaunuE3gd4fILkb5el2jG5pPuoshKYK7KExZi05zSDB0MjXjPy8t98vSyT9ZXf6aoBu1rOXIR549qIC7f9wfwH9plLvdf5ODDAnh8P2a3QAtHeKmGZkVE+tVwtvFo1u4j/0/2rt67rt1umzR/1Gjg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(396003)(136003)(366004)(346002)(376002)(83380400001)(1076003)(8676002)(3450700001)(6486002)(3716004)(6916009)(52116002)(6496006)(5660300002)(86362001)(8936002)(956004)(66946007)(38100700001)(478600001)(786003)(16526019)(2906002)(186003)(316002)(26005)(66556008)(66476007)(170073001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?pgzLLNH0XYtegSplGJsougXAub90Yea42vqykB5oqkVqEDasQsJXPo1JeACM?= =?us-ascii?Q?8yvZ7ZRsIMIcIymo9eMqATUNYyrMdHfvjCBmbgvt6qi4G5TTuhgjouVNAppJ?= =?us-ascii?Q?ty1tn/kHaUj6GQTqWbjR9FF5hZcZJjYabEwQzte9i2nWIAZy9+LwK+Lzv5eZ?= =?us-ascii?Q?riojBQGVWjWthwHTDiIAF9vlQdPqQaino8C+ghJFiHCUQyFS2+xW3xI/qmSm?= =?us-ascii?Q?5kAYgHUzbkRy4EEAFkXTpvuOj+O9OS2pQr2vV7i5jvndznYs0p4GKJSRIJEH?= =?us-ascii?Q?8lfltfUkHSM6wJuFqpp2+qskjfocLJC7xmhQi9eR/hBRWmgSyLfHOhbyCcX+?= =?us-ascii?Q?sCA27dBCvgyRNgKYOdIAW5v2wDmOrqkCWrF9NwBWBItb2VKBcoi12ITV/CBw?= =?us-ascii?Q?FvqFVsHTE3DZgRSscktVGspJ0j5q/n3XENkWHY3qPwS46PUQmrkU8HuPFvv9?= =?us-ascii?Q?uTbRjm43fWE7nQhZDsHYFy0R+wZtx1aDCJu3DikZP/xJ2TAONZXPADTyG2bY?= =?us-ascii?Q?iDiit6nlOtLG2om6YsmWBj3Bj1kYtzx/rIsAHA9W5X+d960akUs4BglYno5o?= =?us-ascii?Q?hLOmPEFCsanNTYue6ZVH8cNcZP+2YeMh8dqNW8uu6mkHF3Gn0TwmACpvOLv5?= =?us-ascii?Q?6QCaCs8kjK/9AEC/f+7G5z8WhMOtjlLOyF4+XIDQG5QkwLUmw5J0NM+9bVZv?= =?us-ascii?Q?rqqXDFqm+gxHNk471XXzZDSafy00HEvbokeLcSvExm09UmQXIUjmc/eV6ucx?= =?us-ascii?Q?87CtD2UzsnhsjTO+r7EWywSzy1BS0b8CLsDMpLcs4BcyJCsuAUosvI8qAxqh?= =?us-ascii?Q?8eQZIBljchqmstQqJyfNgBZBGkwBFXrlFrOKMAs8kEjIdaTEqUo6x5r4GLoP?= =?us-ascii?Q?Xee4bScb5qkPcG8wU3rGrLcwrVdc9ZBp7D6TQGPckJx91gPKvencOEh39WVK?= =?us-ascii?Q?B8mzPYz6RIICT4Wwjb+sidJtLmPj+EpZAvO8hA2KMwneXWyzyq/QsOEpuJst?= =?us-ascii?Q?hwxf58j4xk8+TqJWq4LAcF0wI2ehPjczIyffW6uFaGbHwLeeqoP/Vzi88q+d?= =?us-ascii?Q?EPXOo/KfZT8j4t1tzZLnuuZou857FyCO9oK6IOehuMuS/o7fY998pNZOYeLZ?= =?us-ascii?Q?xoakXCuy3WEluBnUxrf3aM+s6J91pUwj+rXCW6Qzv9qKDzXxVVHd9xr9e68P?= =?us-ascii?Q?py/DNfrKHmnGNd8D5i+rpRB5HJzcpEay6PwUGplHXtIfhMTNlESfgnOPP+/9?= =?us-ascii?Q?KbRGY5elosIbHJTAA4pQAsxwQ1HBdEReV1CyLKjj4nwA59+Hd2PYixA4hNZ7?= =?us-ascii?Q?3jZitrGFYQbmZHRVJR6kWDSO?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: cb168fcd-54a3-4ed5-58d7-08d8eac43a6e X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2021 10:46:18.9248 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6X+Eocz9VIA8/z+vAMR9wEaYA1kVYI+EKna4ivy/TMExdqRY2XkHOiGka8nFngxtSL7N9ss9LrjFbOm1VfeISbPfLoQAgB5gdR1+EpF7Las= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0852 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 10:46:24 -0000 On Fri, Mar 19, 2021 at 09:23:06AM +0000, tom petch wrote: > > If the spec was more precise it would settle the arguments. > RFC 7950 says that tools must support a prefix statement inside an import statement, which overrides the prefix defined in the imported module. A tool that does not support this is not implementing RFC 7950 correctly. RFC 8407 provides additional rules for authors writing IETF YANG modules. Implementations may generate warnings (perhaps even errors, may be implementation specific) if these rules are violated by modules to which the RFC 8407 rules apply. (This implies that a tool needs to know whether RFC 8407 rules apply or not.) It is true that RFC 8407 is not very explicit to which YANG modules the rules apply but given the many IETF specific rules, it is kind of implicit that the rules may not apply 1:1 to YANG modules published by other organizations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 19 04:56:00 2021 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 845AA3A109C for ; Fri, 19 Mar 2021 04:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4OlsTdR44-i for ; Fri, 19 Mar 2021 04:55:55 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213C23A108F for ; Fri, 19 Mar 2021 04:55:55 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id f16so11665939ljm.1 for ; Fri, 19 Mar 2021 04:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KPwnAWUeCLNQ7USonBzAPVOPc9sX+lJlN+1r7AN8SYA=; b=ntJvwgd3PC0N4TQXFX6pn2+QCGgGDAhr9/m/NY4yhSBfcLg11+hwL8ID3S8HK7mwlc eEi0autcFEnfEhsX2WQwF6Qm+aEHoQIU1miRtFAzmtUXKCrHaqmfY5T0wTLbOtiA0NRs 5YiLR3FbfAGAUA/iufJJpgqZuJYnPl6u0DL7na1wAz4bVrB8LEhauimklN8KIeWdCS5T Js7SCAA4o+K3sR7CcR/u8jr6W3lm3aT7nrb4zxI7FgPky3SQdP/BPP1UQWhReeHliQcZ lSiQ3U+6fw0FgpgyBlsyJyogx1KoQZvNhkV7RWX+IhK8d44R3wq+nyiYGIf+nJyp7DWM 8NAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KPwnAWUeCLNQ7USonBzAPVOPc9sX+lJlN+1r7AN8SYA=; b=qlD4+Ec5OUs7aUseU/d1QQFo0XtqKpcU4dkVrFV90aF7LSq41GtRbZmMdstks4cKzb KRZVzCwPGhU8cAOOQstDbjJOwm0b3EOWBIqLPcPObdtntpGsgBDe+y2JL0hFGINWuwJa wau3ueh5TbeDpvcb0uQ7vVwqmcdROMrRN8mE/yDZGWFKmbSmLW/PQyDSP0vp6tR4iudO CJzPkD4HQrb0Cy++jaBz0QfsSA7pPPm/7YSUytb8KbIYAP3vadvOixy+WFGL97vIPp// bUpYth1pgH5bjzMXTQHfceG+WPgCGLdBPe1rZ8RXRqgixraXrhgkV+RyxCEwtL1TD/+P /dlw== X-Gm-Message-State: AOAM533B6HWmBm4Ds1icD1ylrbVWI20nWFnkBfuitUxBCECs/anzOFA9 HWt5BwyIcKDVhkWmBj+439mIlycGPHis/UybBPfjiw== X-Google-Smtp-Source: ABdhPJw/QJngBsJ7A0bk6SUSvLzhQVmODJI7VqLJMnp2K5KHteV/7tMvqqTBU+l2Q6wj7P0kW9uSUZY0Y31u+J5HBUM= X-Received: by 2002:a2e:9157:: with SMTP id q23mr711129ljg.298.1616154951957; Fri, 19 Mar 2021 04:55:51 -0700 (PDT) MIME-Version: 1.0 References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Fri, 19 Mar 2021 04:55:41 -0700 Message-ID: To: tom petch Cc: Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d04fd605bde2656f" Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 11:55:59 -0000 --000000000000d04fd605bde2656f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 19, 2021 at 2:23 AM tom petch wrote: > From: Andy Bierman > Sent: 18 March 2021 18:02 > > On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk dfedyk@labn.net>> wrote: > So you are saying I should beat up on the tool chain people that have not > followed the spec. I tried that already =F0=9F=98=8A , but since I can re= define the > prefixes locally as a workaround, and I couldn=E2=80=99t convince them it= was an > issue, it fell by the wayside with one tool so far. > > If the spec was more precise it would settle the arguments. > > I think it is unfortunate that the IETF wanted so many clever little rule= s > for the creation of YANG modules. > Also unfortunate that RFC 2119 terms in the style guide get confused with > similar terms in the YANG RFC. > > RFC 8407 is normative for IETF YANG module authors. > RFC 7950 is for YANG module tool-makers. > People should know the difference, especially since 8407 only applies to > the IETF, not other organizations. > > > Apologies for the useless quoting that my webmail imposes on me:-( > > Andy > > Of course tool chains should allow for a change of prefix but you did > write, in RFC8407, > " o The proper module prefix MUST be used for all identifiers imported > from other modules. > " > and this discussion started with the meaning of 'proper' here. I take it > to mean the prefix defined by the author of the imported module. I may > have a brilliant idea that is a massive improvement on what the author of > the imported module chose, but too late. If this is an RFC, then I can > only cause confusion by using a different prefix in my module and that > would be improper. > > Is this what you intended? > You mean what the WG intended. I believe you are correct. Use the prefix defined in the imported module if it is not already in use amongst the local prefixes within the module. Otherwise pick a different prefix. (No guidelines for picking a replacement prefix are given) > > Tom Petch > > Andy > Regards, > Don > > > Andy > > > From: Andy Bierman > > Sent: Thursday, March 18, 2021 1:23 PM > To: Don Fedyk > > Cc: tom petch >; Mahesh > Jethanandani >; > Juergen Schoenwaelder j.schoenwaelder@jacobs-university.de>>; netmod@ietf.org netmod@ietf.org> > Subject: Re: [netmod] Use of prefixes in YANG models > > > > On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk dfedyk@labn.net>> wrote: > Clarity and consistency would help. > > Many of the supporting tool chains are picky about prefixes. IE they must > be the same as in the definition file. I have a case where yanglint want= s > "local prefixes or derived-from(-or-self) construct" for an local identit= y > in an xpath statement. (either remedy seems to work.) I argued for the > prefixes in but others argue they are not necessary but I cannot validate > without them. > > > The tool makers should understand that YANG prefixes are not required to > be unique. > It is understood that short character sequences have a high probability o= f > duplication. > So what if the server wants to support 2 modules with the same prefix > defined in the YANG module? > Is it not clear that the ENTIRE point of having the prefix-stmt in the > import-stmt is > because the imported modules may have prefixes that collide? > > > > Andy > > "not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works > (prefix/no prefix) > But "../../bridge-type !=3D 'dot1q:two-port-mac-relay-bridge' works = too. > > Thanks > Don > > > > -----Original Message----- > From: netmod > On > Behalf Of tom petch > Sent: Thursday, March 18, 2021 7:50 AM > To: Mahesh Jethanandani mjethanandani@gmail.com>>; Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de j.schoenwaelder@jacobs-university.de>> > Cc: netmod@ietf.org > Subject: Re: [netmod] Use of prefixes in YANG models > > From: netmod > on > behalf of Juergen Schoenwaelder > > Sent: 18 March 2021 08:05 > > We often do not do a good job in distinguishing technical requirements > from usage guidelines. (And RFC 2119 keywords make things worse.) > > As far as I recall, the intent of the RFC 8407 text was to say that it is > helpful for _humans_ to always use 'if:name' when you refer to the leaf > 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refe= r > to 'date-and-time' defined in 'ietf-yang-types'. > > I believe we agreed that module authors assigning a prefix different from > the default prefix during an import should have either technical reasons > for doing so (resolving prefixes clashes) or some other good reason to > depart from the general guideline aiming to reduce human confusion. > > > To make an abstract concept concrete, draft-ietf-babel-yang-model imports > yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-tim= e > or yt:counter32. An early YANG Doctor review by Radek did not comment on > this aspect of the I-D. More recently, I have. > > Tom Petch > > > > /js (who stopped believing that RFC 2119 keywords are helpful years ago) > > On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote: > > I have seen the debate on the use of prefixes in YANG models, specially > as it relates to their use when importing a model. I think it would nice = to > be clear on what is required, what is nice, and what is not ok to do. I d= o > not want to confuse this discussion with the length of the prefix, which = I > believe is somewhat related but not the same discussion. > > > > RFC 7950 says: > > > > All prefixes, including the prefix for the module itself, MUST be > > unique within the module or submodule. > > > > This is a requirement, as is clear by the MUST. > > > > Then RFC 7950 says: > > > > To > > improve readability of YANG modules, the prefix defined by a module > > SHOULD be used when the module is imported, unless there is a > > conflict. > > > > It also says: > > > > When used inside the "import" statement, the "prefix" statement > > defines the prefix to be used when accessing definitions inside the > > imported module. > > > > Clearly, the scope of the "prefix" statement used with an "import" > statement is limited to the module where it is imported and does not impa= ct > the imported module. As such, and because it is a SHOULD and not a MUST, > this is a "nice to have" without conflicts, but one would not be wrong > using a different prefix from the one defined in the imported module. Add > to this, most tools, e.g. pyang or yanglint do not complain if you do > define a different prefix when there are no conflicts. I have not seen a > problem in the implementation of the module when the prefix is different. > > > > RFC 8407 confuses this whole situation by saying: > > > > The proper module prefix MUST be used for all identifiers importe= d > > from other modules. > > > > which as written is true for identifiers (but not for other types of > imports??). Besides, it does not define what is "proper module prefix". I= n > the absence of a proper definition, one should follow what RFC 7950 says. > > > > Comments? > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000d04fd605bde2656f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 19, 2021 at 2:23 AM tom p= etch <ietfc@btconnect.com>= wrote:
From: An= dy Bierman <andy= @yumaworks.com>
Sent: 18 March 2021 18:02

On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>> wrote:
So you are saying I should beat up on the tool chain people that have not f= ollowed the spec. I tried that already =F0=9F=98=8A , but since I can redef= ine the prefixes locally as a workaround, and I couldn=E2=80=99t convince t= hem it was an issue, it fell by the wayside with one tool so far.

If=C2=A0 the spec was more precise it would settle the arguments.

I think it is unfortunate that the IETF wanted so many clever little rules = for the creation of YANG modules.
Also unfortunate that RFC 2119 terms in the style guide get confused with s= imilar terms in the YANG RFC.

RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to th= e IETF, not other organizations.

<tp>
Apologies for the useless quoting that my webmail imposes on me:-(

Andy

Of course tool chains should allow for a change of prefix but you did write= , in RFC8407,
"=C2=A0 =C2=A0o=C2=A0 The proper module prefix MUST be used for all id= entifiers imported
=C2=A0 =C2=A0 =C2=A0 from other modules.
"
and this discussion started with the meaning of 'proper' here.=C2= =A0 I take it to mean the prefix defined by the author of the imported modu= le.=C2=A0 I may have a brilliant idea that is a massive improvement on what= the author of the imported module chose, but too late.=C2=A0 If this is an= RFC, then I can only cause confusion by using a different prefix in my mod= ule and that would be improper.

Is this what you intended?


You mean what the WG intended.
I believe you are correct.

Use the prefix defined in the imported module if it is= not already in use amongst the
local prefixes within the module.= =C2=A0 Otherwise pick a different prefix.
(No guidelines for pick= ing a replacement prefix are given)


=C2=A0

Tom Petch



Andy
=C2=A0
Regards,
Don


Andy


From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk <dfed= yk@labn.net<mailto:dfedyk@labn.net>>
Cc: tom petch <= ietfc@btconnect.com<mailto:ietfc@btconnect.com>>; Mahesh Jethanandani <mjethanandani@gm= ail.com<mailto:mjethanandani@gmail.com>>; Juergen Schoenwaelder <j.sch= oenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-univers= ity.de>>; ne= tmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Use of prefixes in YANG models



On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>> wrote:
Clarity and consistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must b= e the same as in the definition file.=C2=A0 I have a case where yanglint wa= nts "local prefixes or derived-from(-or-self) construct" for an l= ocal identity in an xpath statement. (either remedy seems to work.) I argue= d for the prefixes in but others argue they are not necessary but I cannot = validate without them.


The tool makers should understand that YANG prefixes are not required to be= unique.
It is understood that short character sequences have a high probability of = duplication.
So what if the server wants to support 2 modules with the same prefix defin= ed in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the impo= rt-stmt is
because the imported modules may have prefixes that collide?



Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'= ;))" works (prefix/no prefix)
But "../../bridge-type !=3D 'dot1q:two-port-mac-relay-bridge'= =C2=A0 =C2=A0 =C2=A0 works too.

Thanks
Don



-----Original Message-----
From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of= tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>; = Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto= := j.schoenwaelder@jacobs-university.de>>
Cc: netmod@ietf.org<mailto:netmod@iet= f.org>
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> on behalf of= Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailt= o:j.schoenwaelder@jacobs-university.de>>
Sent: 18 March 2021 08:05

We often do not do a good job in distinguishing technical requirements from= usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is h= elpful for _humans_ to always use 'if:name' when you refer to the l= eaf 'name' defined in 'ietf-interfaces' or 'yang:date-a= nd-time' when you refer to 'date-and-time' defined in 'ietf= -yang-types'.

I believe we agreed that module authors assigning a prefix different from t= he default prefix during an import should have either technical reasons for= doing so (resolving prefixes clashes) or some other good reason to depart = from the general guideline aiming to reduce human confusion.

<tp>
To make an abstract concept concrete, draft-ietf-babel-yang-model imports y= ang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time o= r yt:counter32.=C2=A0 An early YANG Doctor review by Radek did not comment = on this aspect of the I-D.=C2=A0 More recently, I have.

Tom Petch



/js (who stopped believing that RFC 2119 keywords are helpful years ago)
On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> I have seen the debate on the use of prefixes in YANG models, speciall= y as it relates to their use when importing a model. I think it would nice = to be clear on what is required, what is nice, and what is not ok to do. I = do not want to confuse this discussion with the length of the prefix, which= I believe is somewhat related but not the same discussion.
>
> RFC 7950 says:
>
>=C2=A0 =C2=A0 All prefixes, including the prefix for the module itself,= MUST be
>=C2=A0 =C2=A0 unique within the module or submodule.
>
> This is a requirement, as is clear by the MUST.
>
> Then RFC 7950 says:
>
>=C2=A0 =C2=A0 To
>=C2=A0 =C2=A0 improve readability of YANG modules, the prefix defined b= y a module
>=C2=A0 =C2=A0 SHOULD be used when the module is imported, unless there = is a
>=C2=A0 =C2=A0 conflict.
>
> It also says:
>
>=C2=A0 =C2=A0 When used inside the "import" statement, the &q= uot;prefix" statement
>=C2=A0 =C2=A0 defines the prefix to be used when accessing definitions = inside the
>=C2=A0 =C2=A0 imported module.
>
> Clearly, the scope of the "prefix" statement used with an &q= uot;import" statement is limited to the module where it is imported an= d does not impact the imported module. As such, and because it is a SHOULD = and not a MUST, this is a "nice to have"=C2=A0 without conflicts,= but one would not be wrong using a different prefix from the one defined i= n the imported module. Add to this, most tools, e.g. pyang or yanglint do n= ot complain if you do define a different prefix when there are no conflicts= . I have not seen a problem in the implementation of the module when the pr= efix is different.
>
> RFC 8407 confuses this whole situation by saying:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The proper module prefix MUST be used for al= l identifiers imported
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from other modules.
>
> which as written is true for identifiers (but not for other types of i= mports??). Besides, it does not define what is "proper module prefix&q= uot;. In the absence of a proper definition, one should follow what RFC 795= 0 says.
>
> Comments?
>
> Mahesh Jethanandani
> mjethanan= dani@gmail.com<mailto:mjethanandani@gmail.com>
>
>
>
>
>

> _______________________________________________
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ie= tf.org>
> https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org<= ;mailto:netmod@ietf.or= g>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org<= ;mailto:netmod@ietf.or= g>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org<= ;mailto:netmod@ietf.or= g>
https://www.ietf.org/mailman/listinfo/netmod
--000000000000d04fd605bde2656f-- From nobody Fri Mar 19 09:38:25 2021 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 E1D503A19F0 for ; Fri, 19 Mar 2021 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMDTbUAAd3pD for ; Fri, 19 Mar 2021 09:38:21 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80130.outbound.protection.outlook.com [40.107.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916E53A19EF for ; Fri, 19 Mar 2021 09:38:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F20vbgzfFt3bHEN4uN1el2CnE5E7EK2QfDha1vUNtAyIARAyfsDyrMd4WoDFbdIF2klWRGN74xvyW/ZN+qbDo0cVkz8MMb74WWq/QULcCTj5tz92UmJ6wbzt/TnGKbuG0GE7hxqeuPi0eixYegI4LZNd3zdEQRJPznqnpKMrpQtWWBpBQ3zFP5nHF/+51Z6Lhye+/7WwhocaCzxxcBQPG2FDXZYop0ithz2THcF2DnXZuol0L8l2vmIQOe23s4gOUCCty2EjDLORxqtLzgrpl3B7sNVW48jfW9P79eKYqIjl9zC0pxQkeX7hvLP9rCE9X/GYxGkmMj9qwXI7yp7yow== 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=LPzyN2WxPrhZvslFu7iWCj0DCB+qbs4DN0MBCHeQB+c=; b=XdzjvGh97ridsG+g22pdSubY407urT+suehgjUb9LLyB9cvf/+35J/zVvnNqezzIKj3tTVjWLnL7nY3Nb3nCa5RAPvyC9NbeulLgfI2qG28TTBYjMeMyzE6PGPFNEgTy3PJL+zmXKA97n7m+5qWn6FjknXGkYsxFtAd+sZsYMC5hLrzvIpXRnjPsl0U8bl22l8oXI6muUpLdqro1T51j23BEKil9x+ThYvw8H9qVMcNqPlOUqpwRiAs3wVLbmkOy4iaCqTS5hcS9j4r99ssyczpLOnTrzfiZ5m/coxGsZwDlrYpzu9/v/M/4G9td+k+LE8NmCbc1UrZMRrEOzYasKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LPzyN2WxPrhZvslFu7iWCj0DCB+qbs4DN0MBCHeQB+c=; b=Z1NYrITRH2ivd7u5SBAQX4hwFRRUX0wAyaFk5/srY5khc8WFZ8XypWIWflHkdQkVIzkM585JPAmxrEX7fZq81NDWbXSLAQurfnnkJGWPBcadotqu0Mykj2iMDFPJ8jJHhkOAsyUvw72+GVqZomsuGk9beNI7OKW5QKAcj0XmWho= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AS8PR07MB7382.eurprd07.prod.outlook.com (2603:10a6:20b:2af::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.24; Fri, 19 Mar 2021 16:38:11 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3955.023; Fri, 19 Mar 2021 16:38:11 +0000 From: tom petch To: Andy Bierman CC: Mahesh Jethanandani , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Use of prefixes in YANG models Thread-Index: AQHXG4oeNuzkx0+3DEiWrin2IABkWaqJY72AgAA85lKAAFp/gIAABHSAgAAFPoCAAAXFAIAA/tMbgAAtEYCAAE4NPg== Date: Fri, 19 Mar 2021 16:38:11 +0000 Message-ID: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84d4be5f-4f6c-4421-729f-08d8eaf562bd x-ms-traffictypediagnostic: AS8PR07MB7382: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /1vtWj7H6NV0d0PC6JWo/aD2qwK9lQWKl/V4Ct1wT8fX5nV77Y5bWc3i813zIwljvwfnIy4vCOJC0WE04dqFbHUBavW6/kp3dmx8cWy3UyI6FHZjo45dJMS6Z4+QjwWdMvjWA8A3t+EdgljjNYbQ2WCHYLJxcjpb+PQm1+zOzN5XWUkvTQDwS4wvOxOdbrpHo3fWvUTArxTV1wUjR6lvQg9SveLFpYbKS7CYGOcyNBhbd6UNMuKXvRBLncMGqzw7AMn/PLzyGoK4m1TIMBdasj/GPTRw0Q6fwwBltQwOqMEb/X70D7qtPya8R5FfzuHNHIuMMn7RLqPTFRZXhBMaSQhfrqpWK3YPtmTBYeXhg1XpvYHqUBDyZf6hp8aohCSpMVspyEUEEh7qSbjQOqiucDIpvyL01ay6C4kj7UjB7Oou6BjR26Oj/qRJXdW1qENsfCGc6qHlIuog5w7I2nQBfZdZrvZ5x7vyekv8lko0hDTf9D3p6j9wz1Y0sC0JjKZk10Op1vs8wW/1uBFnN7OxK4wjMxuV2DLsFUnc9PXEzc+JUTAoz9OAnYsrWKNXWJqPspxtUIgFSR/uM3fN9eXrSRQl29KakarDcyxiiq4Kou5VzGii95PFY/zqd22MGRSyg+TdqXEyQZFUsi7IKgOOtO3U/1HYxyIYOuLetZjekrM8mF31G1NflmsILDXT/j8GsRXy2fyTCXKr1E9cCL3TmAqL7enoUTZC447tA76lQeFuSySQa3LjArH9Sz0SdMV66i5h4XVBgJfbBFqtqU9zWQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(346002)(39860400002)(136003)(8936002)(8676002)(83380400001)(52536014)(6916009)(316002)(71200400001)(64756008)(5660300002)(38100700001)(66946007)(76116006)(66556008)(66476007)(186003)(55016002)(26005)(9686003)(2906002)(66446008)(91956017)(33656002)(4326008)(54906003)(478600001)(86362001)(6506007)(966005)(53546011)(7696005)(170073001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?ekwvUHNZajg2TlJkLzBBRW1ra1dRVlZBcGVHaHcza0d6UGVrT25ZM0JleGU3?= =?utf-8?B?Y09qaWY4YnFjR0pGeDMwYjJTMFdnb3V6S0QvYm5Neko2RStGek5CTjQ4bFN6?= =?utf-8?B?b09qNnZSN2tweW41TW15Z0pJQVZGOEordnF6aTJkSVFZVE44SkxaS0dWbk4r?= =?utf-8?B?aUlkRllXZWhBZUdRdmhWU0tXZkdPU3lKSmtFbWVIeS9hcjBQZHMrSmo3NTY1?= =?utf-8?B?QUI5RnVodnBZYTlnd0NhYkwvbjYvNjVNNDZjb2YzZXlRTGQ2TFRXT3hWeER3?= =?utf-8?B?eGlNbHlkTkNnUDloVDhsbEFkVFhRSkxzY2toTkhKNnVuUy9kSzRzU2hCTmpk?= =?utf-8?B?L0ZNeEFBWjZqMlB5S2dVdUNHaS8vbW1sQWI4MDcrb0E5THk4cW9EYURUTXVF?= =?utf-8?B?aGRZMy9hem45bTQ0SENWbTFoY3QvVmdHV0dBc0Y1bENVL3Q3UXorMHl4Nktk?= =?utf-8?B?TDFGUDY0UGY1a1kwZ0tuaTNneE12YmZjMGtVMERUaFpIWThybDM5Z0k5bUVF?= =?utf-8?B?S2hENG9vdFFxMGlLWmZJdDZTczFMVjRjTmlPd3JEc3pGQWxTUUZoNzdiRHdE?= =?utf-8?B?eHZjdG5KVkVlcUwwMTJwU1dMd1A3OWRZczd3R2xHZEJYMmo3R0EwTFA3UWZx?= =?utf-8?B?Q0x5N2dSOHlIR2NGa0xTUUYyTWNjK3hsMXoyQmt5SVBOcktpV0VZQVdxT2Y4?= =?utf-8?B?VGFWMVBPQUZpYUVmTGFaUXp0MVhVanh2MEh1VjNlUTJqV21MMFo4elgxdjU4?= =?utf-8?B?dFE4dW8rVFVoT21KY3JGbmM4TFNlYTgxZFhGS09hU2lYcVd2L1hZQXlnMUox?= =?utf-8?B?ZUlURXF2Y2FrOGdtSWpOTDJ3NmNhN3hTVWRva1lqbE5OZnc1TXFyOWo0RmF4?= =?utf-8?B?eG85bld4eVQySFp4Vkl5V2sxbGcwTjBUVUNjL2RXNk1GaFJXemF4d0laMyt1?= =?utf-8?B?ZEhrOEc0NzVySzF3MXArczNDdzNMdnJtNk9KcFBURGg1Rk9XU2VVN0p5R0M4?= =?utf-8?B?NFFIdVNjTTMvOWprMEZaWCs3NUVSWkVWSUU0ci9PY00wSXltYWlpdHBMWTZH?= =?utf-8?B?d1JYdTVKUktxc3NCKzBJNVdIcDlrOXZuVlU2UHVkVTlZL2R6dzFrMTBja2Mv?= =?utf-8?B?KzkvN1NxTDhNK012UUhGYWdHeEJtNWlpbXcrWmFtMW1kTG5QQjdGK2Q0M3BS?= =?utf-8?B?UFBrM255cGxhQ3hMWUQwclRqUUxTeVR5M1ZPRUV6VWRNWVc2VlRrcVVucGtt?= =?utf-8?B?REhTVjRVd013N0hNd3V5VEp4NVFNQnVDVXJCTG56UWp2L1hBOUp2MFZ0bmRU?= =?utf-8?B?Lzk0U1hsN2M0eFpnek8rMTNyUTlpVzlXZi9tcHlIeUxYQmh1NHRGenFSMWJB?= =?utf-8?B?bUpuZzlvaTg0QTJVQlZYZE5TcFh1YUZ6dzIrMnBxdit6aGlUU3owZVV1V2pK?= =?utf-8?B?OWQ4OGtoZGpza2RQRFRGWHNLeVI4bmk3UytSU2NHV1pnSi9qQnNxbmk5NUZT?= =?utf-8?B?c1JCa1ZQWkxwSlBuRmdaRWFaTGNxdmQ4bVNvTUFwS3FWSGdYcHBTZkFtck4w?= =?utf-8?B?V0lqK2pmVEhjZllwYzlVRC84YjRjaUkvdHBhMi90NVFQY21rNU82cDFlKzBO?= =?utf-8?B?cVVOMW92Z01iSEErbE5FV1R3QndNeGZvVFBsUHN3d3oyMWV4aGo4UmYvd0NN?= =?utf-8?B?QWFjaVNzSzZDWXpUdjMzSlJJMzlHN3dtY3l2dUcvTG1HV2l2dklKcmtrbVZm?= =?utf-8?Q?xuzbc+qCOHDF53lAFoL7ZKWXP23cSkh4Z9kJM9K?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84d4be5f-4f6c-4421-729f-08d8eaf562bd X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 16:38:11.6160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X6KCPXNXLsSNnfrYyNwVFef6owjoD5Nh8tNu08d1sZZjbz9+u/BhhzEa0b/5Qq8PkwuYUYvKulLSETg2ROrSwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB7382 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 16:38:24 -0000 RnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+ClNlbnQ6IDE5IE1hcmNoIDIw MjEgMTE6NTUKCk9uIEZyaSwgTWFyIDE5LCAyMDIxIGF0IDI6MjMgQU0gdG9tIHBldGNoIDxpZXRm Y0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4gd3JvdGU6CkZyb206 IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20+PgpTZW50OiAxOCBNYXJjaCAyMDIxIDE4OjAyCgpPbiBUaHUsIE1hciAxOCwgMjAyMSBhdCAx MDo0MSBBTSBEb24gRmVkeWsgPGRmZWR5a0BsYWJuLm5ldDxtYWlsdG86ZGZlZHlrQGxhYm4ubmV0 PjxtYWlsdG86ZGZlZHlrQGxhYm4ubmV0PG1haWx0bzpkZmVkeWtAbGFibi5uZXQ+Pj4gd3JvdGU6 ClNvIHlvdSBhcmUgc2F5aW5nIEkgc2hvdWxkIGJlYXQgdXAgb24gdGhlIHRvb2wgY2hhaW4gcGVv cGxlIHRoYXQgaGF2ZSBub3QgZm9sbG93ZWQgdGhlIHNwZWMuIEkgdHJpZWQgdGhhdCBhbHJlYWR5 IPCfmIogLCBidXQgc2luY2UgSSBjYW4gcmVkZWZpbmUgdGhlIHByZWZpeGVzIGxvY2FsbHkgYXMg YSB3b3JrYXJvdW5kLCBhbmQgSSBjb3VsZG7igJl0IGNvbnZpbmNlIHRoZW0gaXQgd2FzIGFuIGlz c3VlLCBpdCBmZWxsIGJ5IHRoZSB3YXlzaWRlIHdpdGggb25lIHRvb2wgc28gZmFyLgoKSWYgIHRo ZSBzcGVjIHdhcyBtb3JlIHByZWNpc2UgaXQgd291bGQgc2V0dGxlIHRoZSBhcmd1bWVudHMuCgpJ IHRoaW5rIGl0IGlzIHVuZm9ydHVuYXRlIHRoYXQgdGhlIElFVEYgd2FudGVkIHNvIG1hbnkgY2xl dmVyIGxpdHRsZSBydWxlcyBmb3IgdGhlIGNyZWF0aW9uIG9mIFlBTkcgbW9kdWxlcy4KQWxzbyB1 bmZvcnR1bmF0ZSB0aGF0IFJGQyAyMTE5IHRlcm1zIGluIHRoZSBzdHlsZSBndWlkZSBnZXQgY29u ZnVzZWQgd2l0aCBzaW1pbGFyIHRlcm1zIGluIHRoZSBZQU5HIFJGQy4KClJGQyA4NDA3IGlzIG5v cm1hdGl2ZSBmb3IgSUVURiBZQU5HIG1vZHVsZSBhdXRob3JzLgpSRkMgNzk1MCBpcyBmb3IgWUFO RyBtb2R1bGUgdG9vbC1tYWtlcnMuClBlb3BsZSBzaG91bGQga25vdyB0aGUgZGlmZmVyZW5jZSwg ZXNwZWNpYWxseSBzaW5jZSA4NDA3IG9ubHkgYXBwbGllcyB0byB0aGUgSUVURiwgbm90IG90aGVy IG9yZ2FuaXphdGlvbnMuCgo8dHA+CkFwb2xvZ2llcyBmb3IgdGhlIHVzZWxlc3MgcXVvdGluZyB0 aGF0IG15IHdlYm1haWwgaW1wb3NlcyBvbiBtZTotKAoKQW5keQoKT2YgY291cnNlIHRvb2wgY2hh aW5zIHNob3VsZCBhbGxvdyBmb3IgYSBjaGFuZ2Ugb2YgcHJlZml4IGJ1dCB5b3UgZGlkIHdyaXRl LCBpbiBSRkM4NDA3LAoiICAgbyAgVGhlIHByb3BlciBtb2R1bGUgcHJlZml4IE1VU1QgYmUgdXNl ZCBmb3IgYWxsIGlkZW50aWZpZXJzIGltcG9ydGVkCiAgICAgIGZyb20gb3RoZXIgbW9kdWxlcy4K IgphbmQgdGhpcyBkaXNjdXNzaW9uIHN0YXJ0ZWQgd2l0aCB0aGUgbWVhbmluZyBvZiAncHJvcGVy JyBoZXJlLiAgSSB0YWtlIGl0IHRvIG1lYW4gdGhlIHByZWZpeCBkZWZpbmVkIGJ5IHRoZSBhdXRo b3Igb2YgdGhlIGltcG9ydGVkIG1vZHVsZS4gIEkgbWF5IGhhdmUgYSBicmlsbGlhbnQgaWRlYSB0 aGF0IGlzIGEgbWFzc2l2ZSBpbXByb3ZlbWVudCBvbiB3aGF0IHRoZSBhdXRob3Igb2YgdGhlIGlt cG9ydGVkIG1vZHVsZSBjaG9zZSwgYnV0IHRvbyBsYXRlLiAgSWYgdGhpcyBpcyBhbiBSRkMsIHRo ZW4gSSBjYW4gb25seSBjYXVzZSBjb25mdXNpb24gYnkgdXNpbmcgYSBkaWZmZXJlbnQgcHJlZml4 IGluIG15IG1vZHVsZSBhbmQgdGhhdCB3b3VsZCBiZSBpbXByb3Blci4KCklzIHRoaXMgd2hhdCB5 b3UgaW50ZW5kZWQ/CgoKWW91IG1lYW4gd2hhdCB0aGUgV0cgaW50ZW5kZWQuCkkgYmVsaWV2ZSB5 b3UgYXJlIGNvcnJlY3QuCgpVc2UgdGhlIHByZWZpeCBkZWZpbmVkIGluIHRoZSBpbXBvcnRlZCBt b2R1bGUgaWYgaXQgaXMgbm90IGFscmVhZHkgaW4gdXNlIGFtb25nc3QgdGhlCmxvY2FsIHByZWZp eGVzIHdpdGhpbiB0aGUgbW9kdWxlLiAgT3RoZXJ3aXNlIHBpY2sgYSBkaWZmZXJlbnQgcHJlZml4 LgooTm8gZ3VpZGVsaW5lcyBmb3IgcGlja2luZyBhIHJlcGxhY2VtZW50IHByZWZpeCBhcmUgZ2l2 ZW4pCgo8dHA+CkFuZHkKClRoYW5rIHlvdSBmb3IgdGhhdDsgeWVzLCBpdCB3YXMgdGhlIGludGVu dCBvZiB0aGUgV0cgdGhhdCBJIHdhcyBsb29raW5nIGZvciBjbGFyaWZpY2F0aW9uIG9mLgoKVG9t IFBldGNoCgoKVG9tIFBldGNoCgoKCkFuZHkKClJlZ2FyZHMsCkRvbgoKCkFuZHkKCgpGcm9tOiBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29t PjxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+Pj4K U2VudDogVGh1cnNkYXksIE1hcmNoIDE4LCAyMDIxIDE6MjMgUE0KVG86IERvbiBGZWR5ayA8ZGZl ZHlrQGxhYm4ubmV0PG1haWx0bzpkZmVkeWtAbGFibi5uZXQ+PG1haWx0bzpkZmVkeWtAbGFibi5u ZXQ8bWFpbHRvOmRmZWR5a0BsYWJuLm5ldD4+PgpDYzogdG9tIHBldGNoIDxpZXRmY0BidGNvbm5l Y3QuY29tPG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPjxtYWlsdG86aWV0ZmNAYnRjb25uZWN0 LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+PjsgTWFoZXNoIEpldGhhbmFuZGFuaSA8 bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPjxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPj4+OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjxt YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+Pj47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+PgpTdWJqZWN0OiBSZTogW25ldG1vZF0gVXNlIG9mIHByZWZpeGVzIGluIFlBTkcgbW9k ZWxzCgoKCk9uIFRodSwgTWFyIDE4LCAyMDIxIGF0IDEwOjA3IEFNIERvbiBGZWR5ayA8ZGZlZHlr QGxhYm4ubmV0PG1haWx0bzpkZmVkeWtAbGFibi5uZXQ+PG1haWx0bzpkZmVkeWtAbGFibi5uZXQ8 bWFpbHRvOmRmZWR5a0BsYWJuLm5ldD4+PiB3cm90ZToKQ2xhcml0eSBhbmQgY29uc2lzdGVuY3kg d291bGQgaGVscC4KCk1hbnkgb2YgdGhlIHN1cHBvcnRpbmcgdG9vbCBjaGFpbnMgYXJlIHBpY2t5 IGFib3V0IHByZWZpeGVzLiBJRSB0aGV5IG11c3QgYmUgdGhlIHNhbWUgYXMgaW4gdGhlIGRlZmlu aXRpb24gZmlsZS4gIEkgaGF2ZSBhIGNhc2Ugd2hlcmUgeWFuZ2xpbnQgd2FudHMgImxvY2FsIHBy ZWZpeGVzIG9yIGRlcml2ZWQtZnJvbSgtb3Itc2VsZikgY29uc3RydWN0IiBmb3IgYW4gbG9jYWwg aWRlbnRpdHkgaW4gYW4geHBhdGggc3RhdGVtZW50LiAoZWl0aGVyIHJlbWVkeSBzZWVtcyB0byB3 b3JrLikgSSBhcmd1ZWQgZm9yIHRoZSBwcmVmaXhlcyBpbiBidXQgb3RoZXJzIGFyZ3VlIHRoZXkg YXJlIG5vdCBuZWNlc3NhcnkgYnV0IEkgY2Fubm90IHZhbGlkYXRlIHdpdGhvdXQgdGhlbS4KCgpU aGUgdG9vbCBtYWtlcnMgc2hvdWxkIHVuZGVyc3RhbmQgdGhhdCBZQU5HIHByZWZpeGVzIGFyZSBu b3QgcmVxdWlyZWQgdG8gYmUgdW5pcXVlLgpJdCBpcyB1bmRlcnN0b29kIHRoYXQgc2hvcnQgY2hh cmFjdGVyIHNlcXVlbmNlcyBoYXZlIGEgaGlnaCBwcm9iYWJpbGl0eSBvZiBkdXBsaWNhdGlvbi4K U28gd2hhdCBpZiB0aGUgc2VydmVyIHdhbnRzIHRvIHN1cHBvcnQgMiBtb2R1bGVzIHdpdGggdGhl IHNhbWUgcHJlZml4IGRlZmluZWQgaW4gdGhlIFlBTkcgbW9kdWxlPwpJcyBpdCBub3QgY2xlYXIg dGhhdCB0aGUgRU5USVJFIHBvaW50IG9mIGhhdmluZyB0aGUgcHJlZml4LXN0bXQgaW4gdGhlIGlt cG9ydC1zdG10IGlzCmJlY2F1c2UgdGhlIGltcG9ydGVkIG1vZHVsZXMgbWF5IGhhdmUgcHJlZml4 ZXMgdGhhdCBjb2xsaWRlPwoKCgpBbmR5Cgoibm90KGRlcml2ZWQtZnJvbSguLi8uLi9icmlkZ2Ut dHlwZSwndHdvLXBvcnQtbWFjLXJlbGF5LWJyaWRnZScpKSIgd29ya3MgKHByZWZpeC9ubyBwcmVm aXgpCkJ1dCAiLi4vLi4vYnJpZGdlLXR5cGUgIT0gJ2RvdDFxOnR3by1wb3J0LW1hYy1yZWxheS1i cmlkZ2UnICAgICAgd29ya3MgdG9vLgoKVGhhbmtzCkRvbgoKCgotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRt b2QtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+PiBPbiBCZWhhbGYgT2YgdG9tIHBldGNoClNlbnQ6 IFRodXJzZGF5LCBNYXJjaCAxOCwgMjAyMSA3OjUwIEFNClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5p IDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+ PG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb20+Pj47IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+ PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+PgpDYzogbmV0bW9kQGlldGYub3JnPG1h aWx0bzpuZXRtb2RAaWV0Zi5vcmc+PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v ZEBpZXRmLm9yZz4+ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBVc2Ugb2YgcHJlZml4ZXMgaW4gWUFO RyBtb2RlbHMKCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4+IG9uIGJlaGFsZiBvZiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjxtYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+Pj4KU2VudDogMTggTWFyY2ggMjAyMSAwODowNQoKV2Ugb2Z0ZW4gZG8gbm90IGRv IGEgZ29vZCBqb2IgaW4gZGlzdGluZ3Vpc2hpbmcgdGVjaG5pY2FsIHJlcXVpcmVtZW50cyBmcm9t IHVzYWdlIGd1aWRlbGluZXMuIChBbmQgUkZDIDIxMTkga2V5d29yZHMgbWFrZSB0aGluZ3Mgd29y c2UuKQoKQXMgZmFyIGFzIEkgcmVjYWxsLCB0aGUgaW50ZW50IG9mIHRoZSBSRkMgODQwNyB0ZXh0 IHdhcyB0byBzYXkgdGhhdCBpdCBpcyBoZWxwZnVsIGZvciBfaHVtYW5zXyB0byBhbHdheXMgdXNl ICdpZjpuYW1lJyB3aGVuIHlvdSByZWZlciB0byB0aGUgbGVhZiAnbmFtZScgZGVmaW5lZCBpbiAn aWV0Zi1pbnRlcmZhY2VzJyBvciAneWFuZzpkYXRlLWFuZC10aW1lJyB3aGVuIHlvdSByZWZlciB0 byAnZGF0ZS1hbmQtdGltZScgZGVmaW5lZCBpbiAnaWV0Zi15YW5nLXR5cGVzJy4KCkkgYmVsaWV2 ZSB3ZSBhZ3JlZWQgdGhhdCBtb2R1bGUgYXV0aG9ycyBhc3NpZ25pbmcgYSBwcmVmaXggZGlmZmVy ZW50IGZyb20gdGhlIGRlZmF1bHQgcHJlZml4IGR1cmluZyBhbiBpbXBvcnQgc2hvdWxkIGhhdmUg ZWl0aGVyIHRlY2huaWNhbCByZWFzb25zIGZvciBkb2luZyBzbyAocmVzb2x2aW5nIHByZWZpeGVz IGNsYXNoZXMpIG9yIHNvbWUgb3RoZXIgZ29vZCByZWFzb24gdG8gZGVwYXJ0IGZyb20gdGhlIGdl bmVyYWwgZ3VpZGVsaW5lIGFpbWluZyB0byByZWR1Y2UgaHVtYW4gY29uZnVzaW9uLgoKPHRwPgpU byBtYWtlIGFuIGFic3RyYWN0IGNvbmNlcHQgY29uY3JldGUsIGRyYWZ0LWlldGYtYmFiZWwteWFu Zy1tb2RlbCBpbXBvcnRzIHlhbmcgdHlwZXMgZnJvbSBSRkM2OTkxIGFuZCBnaXZlcyBpdCB0aGUg cHJlZml4IHl0OiBhcyBpbiB5dDpkYXRlLWFuZC10aW1lIG9yIHl0OmNvdW50ZXIzMi4gIEFuIGVh cmx5IFlBTkcgRG9jdG9yIHJldmlldyBieSBSYWRlayBkaWQgbm90IGNvbW1lbnQgb24gdGhpcyBh c3BlY3Qgb2YgdGhlIEktRC4gIE1vcmUgcmVjZW50bHksIEkgaGF2ZS4KClRvbSBQZXRjaAoKCgov anMgKHdobyBzdG9wcGVkIGJlbGlldmluZyB0aGF0IFJGQyAyMTE5IGtleXdvcmRzIGFyZSBoZWxw ZnVsIHllYXJzIGFnbykKCk9uIFdlZCwgTWFyIDE3LCAyMDIxIGF0IDA1OjAzOjExUE0gLTA3MDAs IE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6Cj4gSSBoYXZlIHNlZW4gdGhlIGRlYmF0ZSBvbiB0 aGUgdXNlIG9mIHByZWZpeGVzIGluIFlBTkcgbW9kZWxzLCBzcGVjaWFsbHkgYXMgaXQgcmVsYXRl cyB0byB0aGVpciB1c2Ugd2hlbiBpbXBvcnRpbmcgYSBtb2RlbC4gSSB0aGluayBpdCB3b3VsZCBu aWNlIHRvIGJlIGNsZWFyIG9uIHdoYXQgaXMgcmVxdWlyZWQsIHdoYXQgaXMgbmljZSwgYW5kIHdo YXQgaXMgbm90IG9rIHRvIGRvLiBJIGRvIG5vdCB3YW50IHRvIGNvbmZ1c2UgdGhpcyBkaXNjdXNz aW9uIHdpdGggdGhlIGxlbmd0aCBvZiB0aGUgcHJlZml4LCB3aGljaCBJIGJlbGlldmUgaXMgc29t ZXdoYXQgcmVsYXRlZCBidXQgbm90IHRoZSBzYW1lIGRpc2N1c3Npb24uCj4KPiBSRkMgNzk1MCBz YXlzOgo+Cj4gICAgQWxsIHByZWZpeGVzLCBpbmNsdWRpbmcgdGhlIHByZWZpeCBmb3IgdGhlIG1v ZHVsZSBpdHNlbGYsIE1VU1QgYmUKPiAgICB1bmlxdWUgd2l0aGluIHRoZSBtb2R1bGUgb3Igc3Vi bW9kdWxlLgo+Cj4gVGhpcyBpcyBhIHJlcXVpcmVtZW50LCBhcyBpcyBjbGVhciBieSB0aGUgTVVT VC4KPgo+IFRoZW4gUkZDIDc5NTAgc2F5czoKPgo+ICAgIFRvCj4gICAgaW1wcm92ZSByZWFkYWJp bGl0eSBvZiBZQU5HIG1vZHVsZXMsIHRoZSBwcmVmaXggZGVmaW5lZCBieSBhIG1vZHVsZQo+ICAg IFNIT1VMRCBiZSB1c2VkIHdoZW4gdGhlIG1vZHVsZSBpcyBpbXBvcnRlZCwgdW5sZXNzIHRoZXJl IGlzIGEKPiAgICBjb25mbGljdC4KPgo+IEl0IGFsc28gc2F5czoKPgo+ICAgIFdoZW4gdXNlZCBp bnNpZGUgdGhlICJpbXBvcnQiIHN0YXRlbWVudCwgdGhlICJwcmVmaXgiIHN0YXRlbWVudAo+ICAg IGRlZmluZXMgdGhlIHByZWZpeCB0byBiZSB1c2VkIHdoZW4gYWNjZXNzaW5nIGRlZmluaXRpb25z IGluc2lkZSB0aGUKPiAgICBpbXBvcnRlZCBtb2R1bGUuCj4KPiBDbGVhcmx5LCB0aGUgc2NvcGUg b2YgdGhlICJwcmVmaXgiIHN0YXRlbWVudCB1c2VkIHdpdGggYW4gImltcG9ydCIgc3RhdGVtZW50 IGlzIGxpbWl0ZWQgdG8gdGhlIG1vZHVsZSB3aGVyZSBpdCBpcyBpbXBvcnRlZCBhbmQgZG9lcyBu b3QgaW1wYWN0IHRoZSBpbXBvcnRlZCBtb2R1bGUuIEFzIHN1Y2gsIGFuZCBiZWNhdXNlIGl0IGlz IGEgU0hPVUxEIGFuZCBub3QgYSBNVVNULCB0aGlzIGlzIGEgIm5pY2UgdG8gaGF2ZSIgIHdpdGhv dXQgY29uZmxpY3RzLCBidXQgb25lIHdvdWxkIG5vdCBiZSB3cm9uZyB1c2luZyBhIGRpZmZlcmVu dCBwcmVmaXggZnJvbSB0aGUgb25lIGRlZmluZWQgaW4gdGhlIGltcG9ydGVkIG1vZHVsZS4gQWRk IHRvIHRoaXMsIG1vc3QgdG9vbHMsIGUuZy4gcHlhbmcgb3IgeWFuZ2xpbnQgZG8gbm90IGNvbXBs YWluIGlmIHlvdSBkbyBkZWZpbmUgYSBkaWZmZXJlbnQgcHJlZml4IHdoZW4gdGhlcmUgYXJlIG5v IGNvbmZsaWN0cy4gSSBoYXZlIG5vdCBzZWVuIGEgcHJvYmxlbSBpbiB0aGUgaW1wbGVtZW50YXRp b24gb2YgdGhlIG1vZHVsZSB3aGVuIHRoZSBwcmVmaXggaXMgZGlmZmVyZW50Lgo+Cj4gUkZDIDg0 MDcgY29uZnVzZXMgdGhpcyB3aG9sZSBzaXR1YXRpb24gYnkgc2F5aW5nOgo+Cj4gICAgICAgVGhl IHByb3BlciBtb2R1bGUgcHJlZml4IE1VU1QgYmUgdXNlZCBmb3IgYWxsIGlkZW50aWZpZXJzIGlt cG9ydGVkCj4gICAgICAgZnJvbSBvdGhlciBtb2R1bGVzLgo+Cj4gd2hpY2ggYXMgd3JpdHRlbiBp cyB0cnVlIGZvciBpZGVudGlmaWVycyAoYnV0IG5vdCBmb3Igb3RoZXIgdHlwZXMgb2YgaW1wb3J0 cz8/KS4gQmVzaWRlcywgaXQgZG9lcyBub3QgZGVmaW5lIHdoYXQgaXMgInByb3BlciBtb2R1bGUg cHJlZml4Ii4gSW4gdGhlIGFic2VuY2Ugb2YgYSBwcm9wZXIgZGVmaW5pdGlvbiwgb25lIHNob3Vs ZCBmb2xsb3cgd2hhdCBSRkMgNzk1MCBzYXlzLgo+Cj4gQ29tbWVudHM/Cj4KPiBNYWhlc2ggSmV0 aGFuYW5kYW5pCj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPjxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPj4KPgo+Cj4KPgo+Cgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+Pgo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCgoKLS0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p dmVyc2l0eSBCcmVtZW4gZ0dtYkgKUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1w dXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+CgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0 Cm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGll dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+PgpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz48bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPj4KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5n IGxpc3QKbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+PG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+Cmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kCg== From nobody Fri Mar 19 10:54:17 2021 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 3FE383A1B4B for ; Fri, 19 Mar 2021 10:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l22XI0pZt0sd for ; Fri, 19 Mar 2021 10:54:13 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00059.outbound.protection.outlook.com [40.107.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144D43A1B48 for ; Fri, 19 Mar 2021 10:54:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H6edTRwsxcBdmG7RCrYkAkh2SRikD7bf7zof8b5VQS5UkFNWc9zMBMcdDaQrWn3sCQ/1SZ06kTgX0qr96YkijxZum2z1I91//uLwazxNA7qqSLIR7WOab46wr94F866B4ak90i5g/UHLgI6oNSPF6M80STaxadTap286iEhReYg+90vupLggegKv+5BlwpY/RbeiZoszAL7u399t1rNSlDDxyEgRt/UEgrAnWtn7FcCFbR24Z6yr/O4uMs/uTWgfQyP1Gh7KQczsTMfkiUJbO3/GHC7V3al5zFzUwo4cOe/yRqZ3uXjMSe/+JgTQWqy9RfUxXE5tgc9za68bHPZd/A== 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=jfA5E5ffrt5zBg/YIRUUmzReK9jVY5FEKrgYY/6XqFk=; b=QOU0dJtNEfSS8VWnYtTJCVFQY16QkPQSXAmq9rILxfaxbfeJmGoyHVmP4oxpAp6MyMLE/6aelsvMXVKDaLADMM+icfA8to1dKpi1Ch49x2CAm+gYRKDWGd3XCs+uXQADmvTc1AyXHv5mwhoC1q+Rw46eQ5e7fBr9p/83EJRTJLApdLwdkXUj1PUlHYp7zpSLXdXVYMh/Jv851K6ZFGiqBTh8W/r7sioRXiMR/ojIsbhUnMOTGOIolea/JvxgQoTgrR/B/uS+TxOK5CA/67MW2LGV0cjp6S+22XXAJHy5jc9CixVpy0qtiBIJbcZlu9QnCuFcfCkiLYzsoXrW4NiaBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jfA5E5ffrt5zBg/YIRUUmzReK9jVY5FEKrgYY/6XqFk=; b=THMk3SklbjgvRqXVl0fuDtABcWeAljc7X4g7l5rme2XMDNADXzSmJRPl1HqbS/nSclmNox1iEyeo/0a1EtkEAO452Rh/7njAziymZulQw1gmC+jQjZ1EmEDOIbnxpl8I8hh/rfnM0aFBSKnvfRhrkwkCwPUuamHsT9oU1QMRZYo= Authentication-Results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0852.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1c4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Fri, 19 Mar 2021 17:54:10 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3955.018; Fri, 19 Mar 2021 17:54:10 +0000 Date: Fri, 19 Mar 2021 18:54:09 +0100 From: Juergen Schoenwaelder To: tom petch Cc: Andy Bierman , Mahesh Jethanandani , "netmod@ietf.org" Message-ID: <20210319175409.yulul4tqdfaaesr6@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , Andy Bierman , Mahesh Jethanandani , "netmod@ietf.org" References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR10CA0132.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::49) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR10CA0132.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Fri, 19 Mar 2021 17:54:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 867cd2cb-5301-4bef-fa14-08d8eaffffbe X-MS-TrafficTypeDiagnostic: AM8P190MB0852: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: d8chm1bbyRYLytn60Bf9EDB3rJz3FcrSuraYE/Tby8batU8klNUIq6egMEVSvvwK37ulKhBR6YsJhaVmSFX6xaHBR26PYdcPXTkXRPuDQDhyU8vkHGe+7KffH0E4G6HClVskVAA1440tkuMYHatmdSBJpn3wGTVenWH+x565rgcItuS3EaCN2aYWkrAy4j8WZ0tRxliWqPALG/V371xnW6XXOzDwleadCBsiPcqB525T/JwF/KRXRIgb33Q/tPjPLZ+NSunWkBspsRz37ybeAp9286CDgsLSmteZpWaLVo920B3wZ0zDRhCh2MHOnMenyHZq1bIQEOB2mNDowLpd36WygMGOqr8iVChD/pEb24g+Yn+ZmsJRd/3lroBA3sV/B9C7ghD89ECtNR+dNZnNyFysl18ebsBbmY1q1m+sbbAG1YL6w/LPPBtnoxEG1VoE3xLIuIJwOpL36v9R8iNnf7WEJgx5ZSjtNQxfyf59DxCbpudR+UawiYuOiFSnoUQTydJReFmrJVQQj0fWw6YKl3tlAjK00MnBJB3wM4ns6DFRCbW9TVD15E8pn+U0CGszuKkf9a6JdTdJM1idBWMWVWehKHXWd1VYbWxeKaVlzrUzL5i+oX0s0L56xj5lGwU9BWOSaeiFkqghhwQR0y/aLaf2qE6JnxQsmM6AoOQOXpRZ3pXgx6pXtTcmhYcx5RGGquI5hTtq2mGYHiWloKACMNNBPH/R1RfDySRw1hM4S1b5CGW0Xu2fOOv84P4cPnN8HjkRzigO0zvKvYffjGY8GA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(136003)(39850400004)(366004)(376002)(346002)(83380400001)(4744005)(1076003)(8676002)(54906003)(3450700001)(6916009)(52116002)(6496006)(6486002)(5660300002)(86362001)(956004)(8936002)(4326008)(66946007)(38100700001)(296002)(786003)(316002)(478600001)(16526019)(186003)(66476007)(2906002)(26005)(66556008)(170073001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?e9x+rN52YFCEZrXyZgN819btDymrzQ9TMPsMe0+dDJ8lw2V3Resg8Lzq6EE7?= =?us-ascii?Q?eiywlPFMbqhgfmvji1GlLmbvizod0l7MXoFKYMLX2zjjtS8uJe2qnWpVByLA?= =?us-ascii?Q?keuuA4fUpE1JFHVH38STNt9dHwLfsZJE4LorKMlHRsc/QVF+qYzTV+M9bn1p?= =?us-ascii?Q?JG0eSv0BO5vqrkknxZUPPldR+DjNkyDdx47U93oA/oqZFmsxKeITOp96VUUA?= =?us-ascii?Q?8mNe4e9kVOwj7CMSwtnWbyNzrSoCUkmBNAXOUy5P5Tde4MsncXlQ6ij2+u24?= =?us-ascii?Q?6IpPoeKdhs4lh0namM/TW2ug4AlD582RgwEgqQTmWVMv7PsgXz+hWtaELLOe?= =?us-ascii?Q?QA6hPWcNvqTN7AFnaalDrE3cOpX6D2clRem5IpkOvZyYd6LbLAupO5aLp28d?= =?us-ascii?Q?KxHWWJzSl1A+nj00FeN3N2xpDHovfHZfdCbomxdKAC3d0OTDwlhoxS+iuCvq?= =?us-ascii?Q?FRnxZH82jQLHuJQVnGMFJ6i7BW0DEajDbM+ok8xGc0muaBNaOFVSlKvvCIRU?= =?us-ascii?Q?giy9n06taKYNjK7NH3fRwQM4Dr8guRCHZdvt0Zcj/mVwqEUmtYGxekI5ljjt?= =?us-ascii?Q?je85JCPm4LrqIn5F2V1mFF25IVA9o0zUnN9Kg8iXjQySXrXW9tnKBJwQnxlr?= =?us-ascii?Q?T4ld78WAFxith24iAjQ5ysWvpXylD11XM0n6PrBQfT34ZeHaYXX55YkiXXVv?= =?us-ascii?Q?Pf08CPnPIySmitVB+TpvVZafXchE/2EbjbaJwDjnw8wfLFlKEzMzUy8JXjwA?= =?us-ascii?Q?aPiT0fctXsimCHoJebJ70wF6nU5Q2frugBpT3S5pV+EOKpmJ5wlDmtahXNh0?= =?us-ascii?Q?M1VWmKjLG+Lkp+JDPoC/6vaZFvp0fbiEUdtCFOg+eYP4u+aJHBzaWkM3jOwn?= =?us-ascii?Q?kY2YOy4bYA8t4hoyW7i759WG0coIBaEaxBrfef4cGnRnCXm1ChZIhn51yzje?= =?us-ascii?Q?CxW1ImPNCDpIXLRK7lDCGrxwi10rslLlmqLcxPthQGDvuS4Ahe7ul8I+ozXh?= =?us-ascii?Q?8fh+OZ1ZebhzAGW99K5W7qPeHerrmTGHkXDkUfcOtMMV9InjvCKKZd2gvQiE?= =?us-ascii?Q?+oq2A8qslx/jJzPyi3szdnL3bPi2QgVmkUGuOKtk/56QZtHcmKcrrCVwcw6/?= =?us-ascii?Q?PL52abHEcGoBhVgAGmp8D0u6aokzPTlELcmsK+BX9p+BwCRZ9v6KtcQzPEZi?= =?us-ascii?Q?FyqusD+XzW/BE5g94yNHVNiXIA/NO4Rd02DzMXc6xJibyiJBEhqL3xkVVGbS?= =?us-ascii?Q?CSaK/gjic74wAWpGB5JGZCb0dsAB9qP/4S/m2LN2hJ0gByRu2KQs4ivI0SVb?= =?us-ascii?Q?CEIsZ1R5PpZi2PgHemtTV30v?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 867cd2cb-5301-4bef-fa14-08d8eaffffbe X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Mar 2021 17:54:10.2674 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Oyj17R4W6pKFM0PzCOw/oAnAMXT3oP2ptZmxzMO3/Ms5z9LrlzzQcvKHanU2RRoXnaXiG4CcLVjhahbv+6jyEy/jhTfZXN7bqYnP4EnOR20= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0852 Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 17:54:15 -0000 On Fri, Mar 19, 2021 at 04:38:11PM +0000, tom petch wrote: > > > Apologies for the useless quoting that my webmail imposes on me:-( > Your webmail does not allow to edit the quoted text? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Mar 19 13:30:37 2021 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 183843A0E74 for ; Fri, 19 Mar 2021 13:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoiUL_3HNmzj for ; Fri, 19 Mar 2021 13:30:34 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5041E3A0E73 for ; Fri, 19 Mar 2021 13:30:34 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id l23-20020a05683004b7b02901b529d1a2fdso9727981otd.8 for ; Fri, 19 Mar 2021 13:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BpE1FhhcsbQeW2ELXSUZWOHXX0DySzih5h06ezafweY=; b=ZkGJ//+nbl95zGWjC9k1wb887c+aPkTm5kSrbse65Onq9iST7dKrzVxcFx4LVJrWRg XODNkzjfCCRxRkiPmlUZqs8r9OFOfclf9Bt3bubTQBr2nc9BXRx7R32yGn/oZ9Vp5A6n LYBV2sKZMPzgkFmce8VySXrT4L7nL7gfmAsZAnhV9eYKrvGmY73us+CGE+WDfVUsXY3E qUSbKAKr3LyzfdYqTrIlDSAZqQoLwos+fLD+j9N3lBuKcetQefhmeKGQg4IKWu5iacHD JHPKgmqYz4WH/V3h3xPhf0yrahE6/orBfMO0W2BptZ3N6N4y74wEm1sOspLkoesDtKp0 43VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BpE1FhhcsbQeW2ELXSUZWOHXX0DySzih5h06ezafweY=; b=aVXBQKFBfB9o911u0SB0gaoBFiMDV9F8S/TDOFGQkIbqEOKMHnevyT8WYnSmDxTcnO zulMXo/ZAbdegcDz+98IAvu4tY6c+Jj+Mt9qqDlu9J7sYCa06uWSHzYAsWXC6PS0aZNj jElIW4TopyMnq6mfH7YW+N3LyYkCw0foHH9qXPICE1bNDXIRh3XFj1DyRpJBjw5qdMl2 cCVOvNDK+qdryX9NkF2yvbQNI4zjJqffyldjAKCZvVmltyNsHk/UwqFROR25decptcXL 7GOyrv8vzEiZvI59VQh/JxilTxYoUjxF/LrydB2AsPjh7eSHUn/toM3DlLn0b/A6kNbJ SLFA== X-Gm-Message-State: AOAM530/FHTzwYihTpSxqM3KKE8n8DTkSOgaR+4l3EcxwBOIeK5TlQ9r C8n7Gahutc653Jp1xivsJqY= X-Google-Smtp-Source: ABdhPJwdxp5o4XlPckCMj8tCbMvplUDqNLZCdTXZPXVDWmMD9f78+56cW0cTqaAuyhvkDF0KPbxaBA== X-Received: by 2002:a05:6830:57a:: with SMTP id f26mr2512540otc.70.1616185831784; Fri, 19 Mar 2021 13:30:31 -0700 (PDT) Received: from 2603-800c-2303-9100-ad6b-dc86-b47a-2f9e.res6.spectrum.com (2603-800c-2303-9100-ad6b-dc86-b47a-2f9e.res6.spectrum.com. [2603:800c:2303:9100:ad6b:dc86:b47a:2f9e]) by smtp.gmail.com with ESMTPSA id a5sm673059oiy.15.2021.03.19.13.30.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Mar 2021 13:30:30 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E5D9368B-D19F-410D-863C-21A422EF7388" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Mar 2021 10:30:27 -1000 In-Reply-To: <20210319104617.hqhcxhnyfujfqoow@anna.jacobs.jacobs-university.de> Cc: "netmod@ietf.org" To: Juergen Schoenwaelder References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> <20210319104617.hqhcxhnyfujfqoow@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netmod] Use of prefixes in YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 20:30:36 -0000 --Apple-Mail=_E5D9368B-D19F-410D-863C-21A422EF7388 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2021, at 12:46 AM, Juergen Schoenwaelder = wrote: >=20 > On Fri, Mar 19, 2021 at 09:23:06AM +0000, tom petch wrote: >>=20 >> If the spec was more precise it would settle the arguments. >>=20 >=20 > RFC 7950 says that tools must support a prefix statement inside an > import statement, which overrides the prefix defined in the imported > module. A tool that does not support this is not implementing RFC 7950 > correctly. >=20 > RFC 8407 provides additional rules for authors writing IETF YANG > modules. Implementations may generate warnings (perhaps even errors, > may be implementation specific) if these rules are violated by modules > to which the RFC 8407 rules apply. (This implies that a tool needs to > know whether RFC 8407 rules apply or not.) I believe support by tools for the additional rules imposed by RFC 8407 = would be helpful. There are several ways to recognize that the module in = question is an IETF module, e.g. namespace, or by a more direct option = on the tool CLI, e.g. =E2=80=94ietf option in pyang. The tools can print = a warning if the prefix of the imported module is not used. >=20 > It is true that RFC 8407 is not very explicit to which YANG modules > the rules apply but given the many IETF specific rules, it is kind of > implicit that the rules may not apply 1:1 to YANG modules published by > other organizations. Additionally, RFC 8407 is a BCP. It does not update RFC 7950. However, = it is changing the prefix requirement for import in RFC 7950, from a = SHOULD to a MUST. Aren=E2=80=99t languages supposed to be consistent in = how its rules are meant to be interpreted? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E5D9368B-D19F-410D-863C-21A422EF7388 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 19, 2021, at 12:46 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On = Fri, Mar 19, 2021 at 09:23:06AM +0000, tom petch wrote:

If =  the spec was more precise it would settle the arguments.


RFC 7950 says that = tools must support a prefix statement inside an
import = statement, which overrides the prefix defined in the imported
module. A tool that does not support this is not implementing = RFC 7950
correctly.

RFC 8407 = provides additional rules for authors writing IETF YANG
modules. Implementations may generate warnings (perhaps even = errors,
may be implementation specific) if these rules are = violated by modules
to which the RFC 8407 rules apply. = (This implies that a tool needs to
know whether RFC 8407 = rules apply or not.)

I believe support by tools for the additional rules = imposed by RFC 8407 would be helpful. There are several ways to = recognize that the module in question is an IETF module, e.g. namespace, = or by a more direct option on the tool CLI, e.g. =E2=80=94ietf option in = pyang. The tools can print a warning if the prefix of the imported = module is not used.


It is true = that RFC 8407 is not very explicit to which YANG modules
the= rules apply but given the many IETF specific rules, it is kind of
implicit that the rules may not apply 1:1 to YANG modules = published by
other organizations.

Additionally, RFC 8407 is a BCP. It does not update RFC = 7950. However, it is changing the prefix requirement for import in RFC = 7950, from a SHOULD to a MUST. Aren=E2=80=99t languages supposed to be = consistent in how its rules are meant to be interpreted?


/js

--
Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_E5D9368B-D19F-410D-863C-21A422EF7388-- From nobody Sat Mar 20 04:49:19 2021 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 080ED3A209B for ; Sat, 20 Mar 2021 04:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH0aVOZzcdWg for ; Sat, 20 Mar 2021 04:49:15 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80135.outbound.protection.outlook.com [40.107.8.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A0E3A209A for ; Sat, 20 Mar 2021 04:49:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wqsddad++tpH+gBGWwnKPPdhS68rdcmgpWFfb2ak6auWaVty5Cc6nsa+ShyIxCiaKO2bwcGj8vm3HSbk1PiOGQZcYugSrazf8BVIUcAi2cRVwNjipQRyrDWs9Go7BbIcx3RBt4ReKCE5bUH8pZVSttkUWg20DrraH70JIF7Vfxue/eOZhSwq6aK6RUS9kK+e4LvpYUKoNy4aFmlaQrfDT0jrxJO/NUk/WnZY0k5kIsvzpSfX9+XRh33OF/It5QTvgOvYcwWDM9Da5U0ooKEsrgx9iVQmEzFU9uMB8ubXv8pc8oc7O41aALM/W7qgx84YfhmlbIdNS/8yZPm5DWlk1g== 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=KS+Ya1GsNCVIKoB2XmB8ZJ/kp92yOyG5QwZ180GIqoY=; b=IzpGfqa9Y1cGgEBi+rnj+fhbDRcdUmcz3lfvNsETFOBrWKNyYcvLulWVY8JoabqKV+9+bZq5/urf3tLjv5z8UOSgs+fNa5IsG8sDQPY6XgcwoCeR0mNqyk1hdXPWRsKzwClurL4GvWrwYj5lrZkmVbZ/EcosEXEChB0X9zxpc2DO4b775xadXdIdL6OSzfP8RMS5dq9Bijb1Nw1JgYAAQsqzyoyJa7kO9fb154h41Q/0UJCpeQ+VJBOzogYMeUx+Y/3/QdTBng7v/NEo+x7EcOEvq3evlgODMitXOYNHECYN1rmKRyQ5JC6Ew1H+KxE7sCwafG9FNSmGLe2OzG0pfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KS+Ya1GsNCVIKoB2XmB8ZJ/kp92yOyG5QwZ180GIqoY=; b=BJ0pODaE4KvO3wCWnASa47DvQcm2uNxmTIKKnlNnL44b8DUqsFDcyCvCTIVxubJMqyUXhBZHvvmLXiQ7zJ5MXqOZbOABUT1jeBIypDQWSw9+OONnVtOX3v6kYJyjzFMVs8WLkD1bPakSznAmZqy21bmym51Nh+CbrZlFkLKVvFE= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM5PR0701MB2291.eurprd07.prod.outlook.com (2603:10a6:203:c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.10; Sat, 20 Mar 2021 11:49:09 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3955.023; Sat, 20 Mar 2021 11:49:09 +0000 From: tom petch To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] The Uselessness of webmail Thread-Index: AQHXHX8JKToMNBZ75EG3IfYeT4sQWg== Date: Sat, 20 Mar 2021 11:49:09 +0000 Message-ID: References: <1C71E9E9-784E-4432-A689-0CF4A4171BD1@gmail.com> <20210318080507.xx7ip46mgozl4qcm@anna.jacobs.jacobs-university.de> , <20210319175409.yulul4tqdfaaesr6@anna.jacobs.jacobs-university.de> In-Reply-To: <20210319175409.yulul4tqdfaaesr6@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e118a32-93f2-41cb-be95-08d8eb962c2d x-ms-traffictypediagnostic: AM5PR0701MB2291: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1maC9ybX/dkhtwp4fnsJ9UZDikmJD46zUbB6fj6dS9xDXaK8iAsnObhB+cjTPf8h2DOMwgOsAjfYqErA9pm0FV2i/8LvWWz1rdZZJhJKvub1FVYWWM7Muoksr+8RK2SI5knbSzsx5kxzHMd3hLMZDgxsKON5BupvbLGzW8VZEZB5VBpk+KNZMqsD0o5/89F/Cn0RBCuCWWpt4weCxGcOqSxNCMsG9JkiuBWHUp/ulP4ntiS5r8FQ9as4Bt9K5JxlHcAWux/JSpPVeLttb9qLOxKcK9WLzuLeOS2Zs5mlV7hC7fzTQIi2VDglTEsGARA5ghA7kfaC2PjlJICCg2EZLbxPzmyd1PFYcFl58ANb1pOc9224C2xAH4q72jAkhL/hI9qQ5eZYl6MYe1t5AFFNx2TNlj12b3EwrX/IsP82balZoLeMeFcc94nU6+X2yHhB4lvEXNJT6Nhz6+VTGGaASpvMexc6S3B2IGGMUtbCYJ1fAHrxO3/+LLUXHD9DTnYPICbHXEbj1zmCmVZKFbvDz8A+FuzIzOKb/uIMA0JHhOTCpoE10P8V7awm3/OcLJJiiXzJeLCg2APlG+Bzq5jlJW7pqVdMZLoVEjbNl91EkFh7TeJzcST1s5JSVWS/VFm0pN5JeaTHzNBIOx3Lqyi/vHRmpRYVTdpLiSCJrOYwrn+jRajHdpXP8P1lgVTAsus5x4kTRJK+Myh5pufFIeY8Hw2Jet+VMwnq8jP4o1+zoVlM+N9+vL2cnhGNXdf/sw9g x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(136003)(376002)(366004)(396003)(2906002)(5660300002)(6916009)(478600001)(64756008)(316002)(66476007)(66556008)(76116006)(91956017)(66946007)(66446008)(71200400001)(33656002)(8676002)(38100700001)(52536014)(83380400001)(4326008)(9686003)(186003)(55016002)(26005)(86362001)(8936002)(6506007)(4743002)(7696005)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?f/DJDqtAaMU9qW9CTkjf0Fut+riYTpaNX+3rnMeXYAX977THXIQJ8gtSYV?= =?iso-8859-1?Q?0mTmktawFkzIaDCMRrQJX0WB84FjqYUemifcJ/jYBS8RuXqDjl82FJwBCu?= =?iso-8859-1?Q?0z6pscHXZvr/XCuSceDZOPx7H2JP9udOfiMvPkDcVHiI++0BNbmqz3J7Kh?= =?iso-8859-1?Q?k1FeruRi2IIcFdYcUQ5kotrzJcQ9/Qre5aIXFVv5oCuC4mtSiLO6T3ovN4?= =?iso-8859-1?Q?R6fF04phs5md5ElAJyGuBNmtFP1FkMJ/q5VDhdMhsJnFnN68iHodPKakcU?= =?iso-8859-1?Q?iLcIcYfPdbi8wgu79twNweuPiSRVHvL9ARsIrq8J/GYL+yfUmDApe2VUWW?= =?iso-8859-1?Q?4OGGP8iCJgXpWWTVy+c4g64DMxaZW7kI1NHwP+AXEMsovmuXFqRfxmOlXu?= =?iso-8859-1?Q?Opc2f9qZSfgXLkeYUL3RDVxqgROwjwww54l1bNSJtBnE0dp1QtUveK0p63?= =?iso-8859-1?Q?YnhYruPcJWqWi4CO0lRS6l71uNb105hBQPooFNxiQFhrT+MHSG6EVJqBKH?= =?iso-8859-1?Q?W6jr9s2jSXDhlIhRqTZ0bk3T1yUiKtAF/H3ocTYEsCyFDzAXT+CoUsoZLs?= =?iso-8859-1?Q?vrFsPs7+5FLUTodn+TFkLm2Yhp+hjwoH9JfOtDuyDR6OJKsQIfE/sX6fTV?= =?iso-8859-1?Q?761R4IP8+WYfVg+VF7N7BRNo3/zUmkzCDA5xJpj9xm/4n/xCcRAKVa9ilo?= =?iso-8859-1?Q?/1FgmK1htMwg3l1JRoPWfNI/KH/ujkg29rz1bDyQoOq26JhYEIFpVZLOHo?= =?iso-8859-1?Q?y12nKFde7wA5pQY622HIPdClG7IMzVQR+OQ/ss9SQRNPSIixrwy/FzwyJ6?= =?iso-8859-1?Q?Nuh6qS18gA8tealCmd3gHGilKpqhoyPsdyBcjwxuo82tDExzUstCCwgJ/K?= =?iso-8859-1?Q?6/p3A1WaNsM0z4GzQ5PgN6dpTicZLnp2GtLKBdozFBGTg9hunLZtrmczFr?= =?iso-8859-1?Q?3lG/q4tbI90bWk+UFXeiiWc+gIZo58q/g5O98Z7WvkDUUDZBHxuWvoDwF0?= =?iso-8859-1?Q?cTFwp8MvaFnsNrUFRL7FTbkZKQj3WdY2mzZZXqjevRyBkiJFYnY0hIpwbq?= =?iso-8859-1?Q?IzD72U9ldqGsxbPgaGLHo38OD+h8a4zyhjN5gCFQQw42GQqaESg5LZF0VI?= =?iso-8859-1?Q?RkanSe0DaFFrIn3Q+hBaIQtchuy0jdQIf1ufhAAGIJnxlz5JXuzjoD9IdM?= =?iso-8859-1?Q?eQIn6Is9apnEJs0XG1yKg4xXXVbp3+XiUFcxJIo89re/CdN99tAMvl7pCN?= =?iso-8859-1?Q?nBbAkPvHR4E2GJV0RkpRzQ8UBFFxJIXHSsrYoeEipXXsv+2VM7aNgJyoZ3?= =?iso-8859-1?Q?KphxYeq/lzQmjnU05f4HkjTqK61rZMvztbYsR4WFsIXF8Cd5inS7N2oh8G?= =?iso-8859-1?Q?g0UwBV4LbX?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e118a32-93f2-41cb-be95-08d8eb962c2d X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2021 11:49:09.1055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vYsCIFUmG05zYE6uRTO0/BhNeIn/WVNmNt6nyDit3KZhbTz3H2Xj/IEQ7Wup6BeCrR6uFQI8fWttOPFATmGcsw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2291 Archived-At: Subject: Re: [netmod] The Uselessness of webmail X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 11:49:18 -0000 From: Juergen Schoenwaelder =0A= Sent: 19 March 2021 17:54=0A= =0A= Subject: Re: [netmod] Use of prefixes in YANG models=0A= =0A= On Fri, Mar 19, 2021 at 04:38:11PM +0000, tom petch wrote:=0A= >=0A= > =0A= > Apologies for the useless quoting that my webmail imposes on me:-(=0A= >=0A= =0A= Your webmail does not allow to edit the quoted text?=0A= =0A= It has no replace function so I would have to insert a > character in front= of every line by hand. And, often, the original e-mail as displayed has a= series of coloured lines down the left hand side which give some indicatio= n as to what the level of quoting is. When composing a reply, those lines = have vanished so I would have to go back to the original e-mail to see what= the level of quoting is for any one paragraph and then insert the appropri= ate number of > characters for each line of each paragraph. Life is too s= hort to iron tea towels (as a famous person once said)!=0A= =0A= Tom Petch=0A= =0A= /js=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= From nobody Sat Mar 20 05:15:11 2021 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 31E8C3A20FC for ; Sat, 20 Mar 2021 05:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1Cq3WeteKwZ for ; Sat, 20 Mar 2021 05:15:08 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40087.outbound.protection.outlook.com [40.107.4.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AEB3A20FB for ; Sat, 20 Mar 2021 05:15:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d9UGnwU5kUYZmWEFy2gOn2rODuWpgyxHdZnZCZLRvJV3QlGcLUvQ84MJrVBPFwahUAj9s+Vwcr+Bs6sQZyzmKt0jWTurLj8kWTJVJ8FkV+iBMFJZFNqiNm//2u0/uJ18oYR7Era+WKub7C0uExqI4ew0cmdrdbsuOdp6QBoI5+ceAt7wWlOaPluUtRhrK6dc6Hj20vcQTvEOGWNqJmeUSSFTuCsWjFjeRTWAg+p4/iPIW9Ha+RFJH2BMnJ7h01PS5tyDvQGTDnBfwEk5iTgJkphrBid5UJHPgp4jrNG8jaOrIC3wG1jzRYEmEeu9fQzPfRYnEKOOZD/H5M8yfJ/fug== 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=GySDU0+XsZrjdJoobr8XOZ/Cx6+JSE23Otrsi+Y63zs=; b=AlVnmtm4xf1YmnagBKbyj0qmUZjA5D+CuAFtpvcyTr1w4pL5Al7LtA8aKr6PYaE9Ip4qaA47p+NaMmmVG/k6ECHyfF+7BmIfpye8VIXO5ra7FzbNcHT/dxr6xWg/5EM471OK0gSe0+U9GtqXF44uOHKJ1vkzUsUdalngaJgcKmbsI7/dFydw8wTcT7pchta9wosy+NFbNrjFYMu/yhfTvCg0X0qa1xdUGe5txEdnqu6Ji/UhWvK63SRy+YRasBIuNFXs+oAJ5xHjP7iSjxSJtPhvd0gaCLkHGqO/Z4gP36AF7j6CD/NETmn6DNfIMHk8eZUc5EEaHIsHi3t2sssAhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GySDU0+XsZrjdJoobr8XOZ/Cx6+JSE23Otrsi+Y63zs=; b=IqMtmn3tY0uIO9kGCocMOGtA8pACxEZnQ0bmtF47RqHRWraKgl0my2b8V5+uiYn+EfW9/EqoMc/oD1oC7D8U+Ap9o1BcDPuA9XPf5pCGyQo5H3u2zcEmle2FI+DEqI5ZwgZlSb912p1c3aCTeZshiBMqvlH8uCuLWTuHpSXxkrA= Authentication-Results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0978.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d0::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Sat, 20 Mar 2021 12:15:04 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3955.024; Sat, 20 Mar 2021 12:15:04 +0000 Date: Sat, 20 Mar 2021 13:15:03 +0100 From: Juergen Schoenwaelder To: tom petch Cc: "netmod@ietf.org" Message-ID: <20210320121503.ctveuz7ger7bwwns@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , "netmod@ietf.org" References: <20210319175409.yulul4tqdfaaesr6@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM4PR0302CA0023.eurprd03.prod.outlook.com (2603:10a6:205:2::36) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM4PR0302CA0023.eurprd03.prod.outlook.com (2603:10a6:205:2::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Sat, 20 Mar 2021 12:15:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 742fb266-b3cb-43e9-1538-08d8eb99cacd X-MS-TrafficTypeDiagnostic: AM8P190MB0978: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5dbbgQY3JGea2QAYBCvrTXNRJGgr18++biJGb/PVZS6cwMsEH9FHzMPX503xIilx3JavfRLnHcP4pIlEkXVKEHSvczE60sY9+13wq/X1tBXZ5kxdkUnWIS7IX5HHAJ25I9+8GaMYBYzTXy6hgtklTcWjcaBGqduB4CWYIjD5nQY8oUph0s6c42cHoAjHafrscToRS0YQBdTW1H6u6QqrQ+TVqiDBKrxyO5Q1J4Gf62AKJBR/mHV3kmJmCHrAEMAcLcEgZV5j051S1GGls+nB+D9GIZDlDwiKAd7OYyVTlVWXAbjQezEY+ZGJQ9GyzXpHE8yhlzX1TQfODcCaQa/pOGiLNcqKe8NDAQtk7HkY6ZACkOVAGK5SMMNGqcKhCsYOFNuLutB2lomT0DgafSmN2NHCKi384s6Obj9ud05cK9Or4+FTWG+ocfcGllZjWZWwW0jrHMEM8Xv7XP37KSsVS0twt653hX6Xz5MhgqyBnRP8NswhrgId9eu7B4XZ9kunXjq7an/wthfNx+QUcebZwxJdU6E7sGHI+XRWLlSNaAyIZAQ2VWhQXbNn7/B7oyhu2V8u2t70mlwdULwdRY8aNBire41S5wMPYQt7lEDDDY27pVXBWxtWYYdlQBC39AvJmhmyi+Cqcblx5edBQ9iasAurtAFs3zywb+rm54kxRqcYObO3t2tvyoOq3CtD7SHAiRC0pFn+vBac3JbeBYiYlIa1UrizENre+M8HVBcznxo= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(396003)(346002)(376002)(136003)(366004)(8936002)(52116002)(66946007)(6496006)(6486002)(66476007)(53546011)(83380400001)(1076003)(4326008)(786003)(86362001)(38100700001)(956004)(8676002)(5660300002)(316002)(478600001)(26005)(16526019)(186003)(296002)(6916009)(3450700001)(2906002)(66556008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?7lnrNiELL8f1r9HzT+sjqsF9Lclcnja4brqRrhAi375eCwRVV+3mLHfGPKK8?= =?us-ascii?Q?qXtZ22IivAkj3JzK1pCCP/7Rh0fnWwZpUrc1Qk9SST4u0bKaEEAzM/oQKKgn?= =?us-ascii?Q?RNXlIE2X9UcUKSMxKmOq1YMpGrcKrYjgekNKplB2BXxzKJ9tZekvVxjBdV8z?= =?us-ascii?Q?2EMHeGbon4HpGzIlGp9/e3sTM043mRm8nTWOTb8cnfS5CQode/Euh4+gEolI?= =?us-ascii?Q?YJr1YBm2/prvA78HEyp9Wp3MEtTEyTFdYV3sdlWTbNOJ32AR6dzyjwYxdt9P?= =?us-ascii?Q?vLZQz4XywXVaSEpex4fuDQbWIm2Q1CCaPOEND8ug3CabE7AxfIOLPakeDIs9?= =?us-ascii?Q?eEZ8H3sTuveLLciFd+JwYZPRAfK7xA8FqsKUnWptdpcyHB+gbQfrvRxBzUM7?= =?us-ascii?Q?kZH/kHhrFfV0Q++ndLaEt8VDPzQ5Cb/cEIJJURSpuMuJ0ijIbGRX0FM4xYFQ?= =?us-ascii?Q?C5fZWv9ocQQZCLnBk144orGlrHA0Q69Ia+IQ0fa1y9Q67r3BG1NkVDWSLONI?= =?us-ascii?Q?ihb+paWet2eOqM0sN8whNF9ja+yMmRjZby1aVg3V8PP22xr0A4nZO+Dl8CVU?= =?us-ascii?Q?mcZ4MgQTa8TzDx5HTTtnZsTiQ8AJVPL1Gjx9EQVn8TKL8mnpfYDVWh505UUq?= =?us-ascii?Q?X5hf8adDu0ozaKuKzFm8C7V9QqfdsEBmQjZ/7CwnyEKE/51pOJP0uhxSg59C?= =?us-ascii?Q?/27wc/tnhyfPWelu6ipliIfQgQx8Vgo8LSk/E4KCI1NBYQlx1xOpmvSNDCmn?= =?us-ascii?Q?u4z13ORZVEY3tnDUEp9chPG5DqG5F/HOHPbEZdBIeZkPElpO7YOOzJ69WgYA?= =?us-ascii?Q?FCXm8bUpzFUzenHsIkkZO7hvvUCCeRN/UPh51IW7Ka/Fo5YAkvBtBs2r5oOX?= =?us-ascii?Q?3Uxu9xdwyyxhWa9uY5oi+hxa98uJmjyvYDq5xNfVLoPZMXVuCK1TYPqVz0UH?= =?us-ascii?Q?8QHR25LDoio8ye37Kn6cG3EKQKFPcYbFpJZFktXRbdP6JQaqZ0jL9pDmXDaw?= =?us-ascii?Q?U6JM8IriEmy1P+n2/CkfiWmLmXvG0aY3CWNUk4m/Fc94IB6hCBF36T0T18wB?= =?us-ascii?Q?pvwVQRz0IuYGFuOvORPCSp5cjXhe31xLgaiGIAEuJVoogEmYe/X42GJwKU7F?= =?us-ascii?Q?w6lUU9xQl8PRqZR3dHdMRC8qpGu3FjyccovKsirEjA262sGks1RIuDXUYhNy?= =?us-ascii?Q?Z7Zem710EkNtRWkhSuuRBqmbV5K+w1M5P+bDf7MkaVI7VMvC2uZzEnokPEPo?= =?us-ascii?Q?MizTiFxPKt7xd82jlHQcIyPMhpHpWCCL60uozYnCE4mD4yLEvoEEVE6eBnHR?= =?us-ascii?Q?1FUshLrcLUjHk9+Xn5kbLGJ8?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 742fb266-b3cb-43e9-1538-08d8eb99cacd X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2021 12:15:04.0206 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hBcbZhQAy1ph1Aa9g1xl7gd7KRHLAmjeGBzURuPThQ3e6gQm/GVXOY6fEzCpshMCtDAdvBP6iM/NQajIeJM6/Cd9wxY0zu/XB9+DdDVlkaA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0978 Archived-At: Subject: Re: [netmod] The Uselessness of webmail X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 12:15:10 -0000 On Sat, Mar 20, 2021 at 11:49:09AM +0000, tom petch wrote: > From: Juergen Schoenwaelder > Sent: 19 March 2021 17:54 > > Subject: Re: [netmod] Use of prefixes in YANG models > > On Fri, Mar 19, 2021 at 04:38:11PM +0000, tom petch wrote: > > > > > > Apologies for the useless quoting that my webmail imposes on me:-( > > > > Your webmail does not allow to edit the quoted text? > > It has no replace function so I would have to insert a > character in front of every line by hand. And, often, the original e-mail as displayed has a series of coloured lines down the left hand side which give some indication as to what the level of quoting is. When composing a reply, those lines have vanished so I would have to go back to the original e-mail to see what the level of quoting is for any one paragraph and then insert the appropriate number of > characters for each line of each paragraph. Life is too short to iron tea towels (as a famous person once said)! > I do not know what forces you to use this webclient but there is always a readers vs. writers or who pays the price aspect. I do occasionally press 'delete' on emails requiring extra time or special tools to identify the contribution (and given that I am of the dying species reading emails in plain text, I accept that the world is moving on and I am just stuck in the 20th century). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Mar 20 05:19:32 2021 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 BD1873A2105 for ; Sat, 20 Mar 2021 05:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bbikK6pVsqkG for ; Sat, 20 Mar 2021 05:19:29 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAD43A2101 for ; Sat, 20 Mar 2021 05:19:29 -0700 (PDT) Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4F2fvd5WGyzyQH; Sat, 20 Mar 2021 13:19:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20210320121503.ctveuz7ger7bwwns@anna.jacobs.jacobs-university.de> Date: Sat, 20 Mar 2021 13:19:25 +0100 Cc: "netmod@ietf.org" X-Mao-Original-Outgoing-Id: 637935565.203432-c68d5000ca0f562ff525108333abaf00 Content-Transfer-Encoding: quoted-printable Message-Id: <5B017471-D5B1-4C68-BF3A-171D4835E091@tzi.org> References: <20210319175409.yulul4tqdfaaesr6@anna.jacobs.jacobs-university.de> <20210320121503.ctveuz7ger7bwwns@anna.jacobs.jacobs-university.de> To: tom petch X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netmod] The Uselessness of webmail X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 12:19:32 -0000 On 2021-03-20, at 13:15, Juergen Schoenwaelder = wrote: >=20 > On Sat, Mar 20, 2021 at 11:49:09AM +0000, tom petch wrote: >> From: Juergen Schoenwaelder >> Sent: 19 March 2021 17:54 >>=20 >> Subject: Re: [netmod] Use of prefixes in YANG models >>=20 >> On Fri, Mar 19, 2021 at 04:38:11PM +0000, tom petch wrote: >>>=20 >>> >>> Apologies for the useless quoting that my webmail imposes on me:-( >>>=20 >>=20 >> Your webmail does not allow to edit the quoted text? >>=20 >> It has no replace function so I would have to insert a > character in = front of every line by hand. And, often, the original e-mail as = displayed has a series of coloured lines down the left hand side which = give some indication as to what the level of quoting is. When composing = a reply, those lines have vanished so I would have to go back to the = original e-mail to see what the level of quoting is for any one = paragraph and then insert the appropriate number of > characters for = each line of each paragraph. Life is too short to iron tea towels (as a = famous person once said)! >>=20 >=20 > I do not know what forces you to use this webclient but there is > always a readers vs. writers or who pays the price aspect. I do > occasionally press 'delete' on emails requiring extra time or special > tools to identify the contribution (and given that I am of the dying > species reading emails in plain text, I accept that the world is > moving on and I am just stuck in the 20th century). +1. Further to that, let me point out that getting emails that were = mishandled like this makes many readers think the sender suffers of a = serious disregard for their readers. That may not be the signal that = you want to send to a large professional community of peers. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 23 07:00:24 2021 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 6F7DF3A0DBC for ; Tue, 23 Mar 2021 07:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9lOaSdbBNwH for ; Tue, 23 Mar 2021 07:00:18 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2098.outbound.protection.outlook.com [40.107.244.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E403A0DB3 for ; Tue, 23 Mar 2021 07:00:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bo8TJr96CJKj2wATIgEWy8YFmc+dDM0MV/BPTCZ3adgJCkrt9S17faWVXKibGxqGvcqgwl9CabgDl8QX1RMVCoLdNUNfT/XEf+x1PU9QLv9fmUEEGpbYMsCkC8Dfz/6JO46qv/viVS9oam1gguV5cc592MGJGhZ9k+vok68BM9odGH7g01lF0RjUmfr48ggD/vs66gXK4OOhVkSQgPx3eozE98ySDrf80KRBPMz1pVC0HZQwE4XceMSchZPMmkBy8ZfRcBqCfRwBOOgA2HAwVaouSRCVjhw2eyQIkbxYShJqbVz8Q8tKh653kkR3avyU2/6llEfRcu6NJmFWlzQtZg== 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=BKqHhu58C7Bs+cb4XfDmfQmkNkOJV5CNQlIQM3jrvFA=; b=iZboODBNREoQaLVbDGzLRT67psifZjPNugR3YEkAVfL4dco1qtg6P53HEObkiVea4nTZbVchB24YicngLnYrrSRZbk1nD2rAF8h0wpY3x3zcENmXYricsHg75gsIl9nXGFq5AZG/LLMrkUTKAfphryJPCuXOdS/NRwxBKNh2VEuFM+jwcxc4aFt82XVpmL/ivD/uLrfiCMdEeqq+BF6qi1Njev8KBbC60gDuX8V7Bai8ZOKC/MYmg2e2pHBnkiseHHyUSDI7Bdb73V/QW9+ilL8uj6F9SS2A9efWd/O+eLRAOoN6pmrXvocUrvr9m1rG8X2INKmqvbHsaWCk1QPleQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BKqHhu58C7Bs+cb4XfDmfQmkNkOJV5CNQlIQM3jrvFA=; b=IoN2LNRHOTVcUTsBZuPzMi3NKRMrhb0NWCAFJHaFxFdUmQQA0+ODzdIE6Z7dUwZGxUdsuuGEFDFSHP6MuSYYtZrOJCWE4Sl3wb93eFcU0i12HxKBEuZcnRcbDw4XN8pDv44OFx4BVCpF8bK2sP8mBRgpl7+3Jmr2x/IOvV5Gaq8= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6313.namprd08.prod.outlook.com (2603:10b6:5:1ea::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Tue, 23 Mar 2021 14:00:16 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3955.025; Tue, 23 Mar 2021 14:00:16 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-03-23 Thread-Index: Adcf7Lvv78TtJ0pxS8e2MW4aRoVTQA== Date: Tue, 23 Mar 2021 14:00:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2607:fea8:e325:b00:251a:9391:f7d:f3c4] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ce1d2b85-6c26-49db-bce1-08d8ee03fcd5 x-ms-traffictypediagnostic: DM6PR08MB6313: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HJ6i6C3JpmCkYEFdV2S4WnXsTv8ZZSWYwOrbqOpo/Sah5Z/XLXpoqnedjAoduT0FOhxz5tXjZvVDX//m2fRZhoy+PDwb80KNqjT495dkwD/AQkBfSBrorhya6JpcVsEqbI56LYlk67lBAU+6obCMXbHpJwh63LbUSrnDo3ZzOHQzSMtA9gkErn06iOBF5rtKz7sZxR4a4pKUsDh9tT0xyzYXzpld1oYaCNqbuvDZXslM9J06eKvPTiTbHwZgM5zANM0rltXMVg8z4Geqb9tgbKEN1Y4GlOhAjKOa8MgGr3wx4/CvdON59C+ZBxW+t5OUlvxYvt61lkb6NHYQQsbYPCox7RgUT/sLvxRBV1FS+t5Hzdkbhm4cG4Pi59+QZu3diE7AFCBVGwVD4wN7T372v1ss9uAtVFNn1vfsnN+WiU6DBee4N/Ayl74YplDZLhS3kB62hPW4uH95uzrCb7YL3mZwytQ0RVZKsTRiQUfmX3V51Ng7FeoJWF/mSfTVZ8CPaYILzi7eH+9GTz1qdva68gl/JEovbc2mkry0Zj3KFSUYDLfb6Ct35UndgXdgE9XP7qnYPp4/8DWwl84vtTCWwDFRlxCqrlm6THf1QcJTol11FTDwDdTbZ7uCdkF/b0tZp62sjB5Vz+ha0udTUs6VBWNFy74Fyp5UzCdng410gelwtYCBiXUYdzCW5oust0WMP40j+G4JR+P0GzjImyNZtnflElD0/IVhPwJV66rap/jLWw8P8IXBoFspXPOEbLcP x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39850400004)(376002)(366004)(346002)(9686003)(2906002)(66446008)(64756008)(66556008)(66476007)(55016002)(66946007)(76116006)(33656002)(16799955002)(83380400001)(86362001)(8936002)(316002)(6506007)(8676002)(7696005)(186003)(6916009)(478600001)(38100700001)(71200400001)(5660300002)(52536014)(966005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?o2aAA+N7TLFHs2oeQycMCZBs/aYETqTmI4s/w+KcIcRdSTqKl1KAZU8eS+CN?= =?us-ascii?Q?KTCGyK742sD2FA0NVX4gxKCS7mnoxnzIMhPR+vKTCpdGNwDK69NOAZAj15nl?= =?us-ascii?Q?gHN/JDySI1pvew63E2xhmwqypguAkCPM33B4o4GvJFUiZRQQVJ0u3dUjglBF?= =?us-ascii?Q?9ez3k8s1hiCvmbOSZ2V62mQX5jp0mctLxoKPdumZhQPkEdBmu/jBNryEd25g?= =?us-ascii?Q?CpT7crwykuCjwFZbjYMOqB6VvLV6mJkvhTrOWh3n0DIXGree8nTGUedMB/ju?= =?us-ascii?Q?HCJ7G8KDJgmTTtFQu3Qy10pQIaHREkw3nvrP4MSNCZNDnB9wwvHNRUIu8z7M?= =?us-ascii?Q?PfHCd+KoZ7MrR7cEWbR4MvPGXdIJguL7juCktZUdLMt5ww/GaZHsBHggwYIk?= =?us-ascii?Q?AjiPIcLoGeY/bWe0Ygkh7U1H9TKgb5FSCp55a2dtdg1MiCb9eqZNNk1+5mDx?= =?us-ascii?Q?S/8rvsAkc9lXImwZQrGW/cYl9igdyKLCrb9++lfyBnGefd/K9sckH+S5x6tP?= =?us-ascii?Q?NRHwVH0NrSM5azJjWaImCqqTKVektqHJX3eaj4gx0dxXXyAtUSdnomkk7TQh?= =?us-ascii?Q?kl+GJ1mA15U1RMdnT7noP6gy5GeFOgnFR5J576w7U+fiqJx+o2ccejqdTVV6?= =?us-ascii?Q?KnJmajyZIIXfeD+Cd2g/qRgypkHpQ2H01/syUUqVLipibKSz8f2vrgViPa4Y?= =?us-ascii?Q?9uAA2hksKxz8LS0dbbo/bA0aDN05UtwP/opTE69mX9VE6MzfVGbAGLVuxSW9?= =?us-ascii?Q?3tUpcFfRmAlGYopLO8H1uJUV+tyCGzDNBA+Dbv/uD4YEhLnpxeq13UDPvFrP?= =?us-ascii?Q?SrjLbl9YV9dlORUgojuP6VJX+FQ3KYNyqsbZdWIWfCWDtiWgJzywU1/zwnUA?= =?us-ascii?Q?+itc8LwSV2zcbdkgnLq4W5CHthQVvqlNPySk4O1sa2fIy1NO7/lWus6fC/rU?= =?us-ascii?Q?/3r2k6q2tkCQoMYcJENIteN58rsObHnjSfslC/R+Yk4aVbDCGSkz3aNqmvas?= =?us-ascii?Q?13U/Hpf5p6PnPX0L9lOjuEJXyzS1LxkYLxF8j0xdCX7LW98li6/QNnyqm3wi?= =?us-ascii?Q?QNa8Ijf4oe9gjo/yonfJ4uMuwt4hHTF9/d49Q8/UWMcwOHMqpYfIJGaws9kb?= =?us-ascii?Q?rGYSRd2y2nN41MYnp8RHIX3QPPoUqmiMbmcs/mDrltzDDDBRuMQ/KfcBG614?= =?us-ascii?Q?uCy61c0+o4f0byFRLRb1xgVYe/BVrQQiapPTOrUd2Op23HzZJjJ6qCtynmDD?= =?us-ascii?Q?Fei+YJnTemH4RJ8bqKcVB+C2SdzQDV2CYm2Wp6wlUG1NLchcOaL9zSqeAmb/?= =?us-ascii?Q?4UmZBGNY6KgpcBvNKhPUyMOwoFS4CeKX3iaT/mR8YU1ZpbgGV+tijaLtgOz4?= =?us-ascii?Q?7FWkYhTslcF71ly4WHQrKouW3NtS?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB508484E20184679272AD6E9C9B649DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce1d2b85-6c26-49db-bce1-08d8ee03fcd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2021 14:00:16.5604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WvkRF2NhWWsu9Ic7QkP57bbgge9PFXei243Uljd95VlEhapePe4CA8Bqf0jWwqu8v2DBNavu/4D410OAE0EQ9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6313 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-03-23 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2021 14:00:23 -0000 --_000_DM6PR08MB508484E20184679272AD6E9C9B649DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-03-23 Try to focus on a smaller number of issues in parallel and drive them to 10= 0% completion (text in draft). Agenda bashing: - recap of feedback received for issues presented in IETF110 Actions: - review draft text for state BC/NBC rules Whitespace: Add to 3.1 (Reshad): As per RFC 7950, all published revisions of a module are given a new unique= revision date. This applies even for module revisions containing only cha= nges to any whitespace, formatting, comments or line endings (e.g. DOS vs U= NIX). In 3.3 add the word "file" here: A specific revision-label identifies a specific revision (variant) of the module. If two YANG modules contain the same module name and the same revision-label (and hence also the same revision-date) in their latest revision statement, then the *file* contents of the two modules, including the revision history, MUST be identical. --------------------------------------- Module with history that has a mix of revision-labels and nothing. - i.e. not every version must have a revision-label (there MUST be only be = a single scheme, 3.3.1) - current text in Module Versioning draft 3.3 is good enough (it says "MAY"= have a revision-label) --------------------------------------- Update the first parapgraph of 3.3.1 as follows: The OPTIONAL "rev:revision-label-scheme" extension statement is used to indicate which revision-label scheme a module or submodule uses. There = MUST NOT be more than one revision label scheme in a module or submodule. The mandatory argument to this extension statement: ----------------------------------- YANG module: clarify that only a single revision label scheme statement can= exist in a module or submodule. There may be 0 or 1 revision label scheme= statements. The statement MUST only be a substatement to the YANG module or submo= dule statement. Y1: Zero or one rev:revision-label-scheme statements per module or sub= module is allowed. Y2: There MUST be zero or one rev:revision-label-scheme statement= s per module or submodule Y3: There MUST be at most one rev:revision-label-scheme statement= s in a module or submodule. Y4: Zero or one rev:revision-label-scheme statements are allowed per m= odule or submodule. Decision: Y3 A next step: see if there are Github issues that can just be closed now. ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB508484E20184679272AD6E9C9B649DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-03-23

 

Try to focus on a smaller number of issues in parall= el and drive them to 100% completion (text in draft).

 

Agenda bashing:

- recap of feedback received for issues presented in= IETF110

 

Actions:

- review draft text for state BC/NBC rules

 

Whitespace:

 

Add to 3.1 (Reshad):

 

As per RFC 7950, all published revisions of a module= are given a new unique revision date.  This applies even for module r= evisions containing only changes to any whitespace, formatting, comments or= line endings (e.g. DOS vs UNIX).

 

In 3.3 add the word "file" here:

 

   A specific revision-label identifies a = specific revision (variant) of

   the module.  If two YANG modules c= ontain the same module name and the

   same revision-label (and hence also the= same revision-date) in their

   latest revision statement, then the *fi= le* contents of the two modules,

   including the revision history, MUST be= identical.

  

---------------------------------------

 

Module with history that has a mix of revision-label= s and nothing.

- i.e. not every version must have a revision-label = (there MUST be only be a single scheme, 3.3.1)

- current text in Module Versioning draft 3.3 is goo= d enough (it says "MAY" have a revision-label)

 

---------------------------------------

 

Update the first parapgraph of 3.3.1 as follows:

 

   The OPTIONAL "rev:revision-label-s= cheme" extension statement is used to

   indicate which revision-label scheme a = module or submodule uses.  There MUST NOT be more than one revision la= bel scheme in a module or submodule.

   

   The mandatory argument to this ext= ension statement:

 

-----------------------------------

 

YANG module: clarify that only a single revision lab= el scheme statement can exist in a module or submodule.  There may be = 0 or 1 revision label scheme statements.

      The statement MUST on= ly be a substatement to the YANG module or submodule statement.<= /p>

Y1:      Zero or one rev:re= vision-label-scheme statements per module or submodule is allowed.

        &nbs= p;        

Y2:         =  There MUST be zero or one rev:revision-label-scheme statements per m= odule or submodule

        &nbs= p;        

Y3:         =  There MUST be at most one rev:revision-label-scheme statements in a = module or submodule.

 

Y4:      Zero or one rev:re= vision-label-scheme statements are allowed per module or submodule.

 

Decision: Y3

 

A next step: see if there are Github issues that can= just be closed now.

 

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB508484E20184679272AD6E9C9B649DM6PR08MB5084namp_-- From nobody Mon Mar 29 07:26:32 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C907F3A1624; Mon, 29 Mar 2021 07:26:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <161702799076.21853.9308801908403135437@ietfa.amsl.com> Date: Mon, 29 Mar 2021 07:26:30 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 14:26:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-13.txt Pages : 28 Date : 2021-03-29 Abstract: There is a need to document data defined in YANG models when a live server is unavailable. Data is often needed at design or implementation time or needed when a live running server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-13 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 29 07:28:58 2021 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 7A5EC3A1626 for ; Mon, 29 Mar 2021 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 096u0mbCRVQI for ; Mon, 29 Mar 2021 07:28:51 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2074.outbound.protection.outlook.com [40.107.20.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8303A162E for ; Mon, 29 Mar 2021 07:28:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YWSW8ycqCD4UDct0+8lHM1j1BDWfatpfS/lgw1NzEKSaUnjEG1OW6XU+ud8W/1J846QdkRMJUeQIl8x5nOv0I3V5NHN9XsWxLv4krdk7sANdVFLRysVvYnf64c3KMkhXDb5AmKdl9gg3ExnH0DpAZBHnMQ1ZpkZVr65D1JDrK2sNzfarJwZOX77NrFIMfX5RRGIk/Y7t63jJbQqXWNuVawN5I2N7oWtYTA5RmhLsgxwCQi7przY+7uizrHiUFxLe14OqF40hxzOYu5zJrGL0aFCwGO53cGYCWGsvpVZNY6cMvn1TxuxygiQSeoOHEujiGkgGIAfLjk1rxPfvdxW/ew== 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=lgHXjhFav24T8dQDnsgjrgbJ6NsY6BYPpchheEzofHk=; b=GeftTD8nF+Q7GfMM/vUpshuSEDuiB6RPuEMk5MguffH3OzLE8tFdGaB2u3VMLdDraXWKTth4c63KVyjyZgK6pGMktxiGC+ik0r9sQ5FX+vdqIjJq0n+t8I1plaFvOTGqqrKZm5Du7AJ53zA+XthbaVRxGKkF+8agFOdTJ4tb4j/NTeO+u9RNtjmMrWFiM2pl6Ajel52fezXPHSaXOLK0nnQrB/IAL9bWNrSkqCZHfH+WeK4vi1unSEJJn3iftmiEGtls4I3WVue8CEE3/q2kuVvFdq3xtid70+ep8AQOuIwDv2YrHMXNV59I9s52Fhx5upN7Ck1b+y5+PX9QtK1oHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lgHXjhFav24T8dQDnsgjrgbJ6NsY6BYPpchheEzofHk=; b=SJqRwSfGV5at94b0P9KUjB1AGhRxEi/ps9RMQ+l1tGfzVaI2/Q849Vuyn+pkKxuF8wamX6S4EBoGCnN/CozXiab72/5UiNdQfV1zBtkjvuFAKUGHvdUZ33FgHIQFk44h+Su2YTwqcYzu+iJthqOQiSK/jJx4vJ25Ip02Oqahg0A= Received: from AM6PR0702MB3557.eurprd07.prod.outlook.com (2603:10a6:209:d::21) by AM6PR07MB5608.eurprd07.prod.outlook.com (2603:10a6:20b:6f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.16; Mon, 29 Mar 2021 14:28:44 +0000 Received: from AM6PR0702MB3557.eurprd07.prod.outlook.com ([fe80::a40f:d3d5:854a:c673]) by AM6PR0702MB3557.eurprd07.prod.outlook.com ([fe80::a40f:d3d5:854a:c673%5]) with mapi id 15.20.3999.021; Mon, 29 Mar 2021 14:28:44 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "'netmod@ietf.org'" Thread-Topic: New Version Notification for draft-ietf-netmod-yang-instance-file-format-13.txt Thread-Index: AQHXJKeHBbqiTjvX/kCioZzgKC9IpKqbBgDA Date: Mon, 29 Mar 2021 14:28:44 +0000 Message-ID: References: <161702799097.21853.7196559456194029360@ietfa.amsl.com> In-Reply-To: <161702799097.21853.7196559456194029360@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.248.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c26344f-8071-4d8a-6071-08d8f2bef540 x-ms-traffictypediagnostic: AM6PR07MB5608: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /7NBXmVmVJB5qWkmw8c0F31h9MAul3ddRVfv67B+JiiH73dMZaWJ05IzPcZXvNtmVT/F18T3n+fvpqoa/4Qc9tNfrOIMFYdY5hY7CrflWpy59WYHCyvVJnhBV4yFZp6qBMBvZFAgWHpZYrS88c6eyRm/BVX1SNnFivE8aTnJC78HDIv+QQbgyISvRenNW3fmDcp4/9tTuP0OnPqhH3USpUkLQCkh4S9k94to/repGXOLot6v+3iJIrpLDKi3DDyJkKL5MCwV0guFouh4UwoX7CiKnRa8Xs+8ckQwF6+lb6E5OYD2zFjQ3KDiFogxhCVmtgtVmF84TXwj3JIuXoDwbISsJFeJnUxx29NHVormZBtG3zJw/Z55kueEGxBKNFLiRyeFXJFSvTxwQTzA7Ekj0xBcDLsdYOsiu5yy1HuWvT1YphUPwxvremnjlN/b7WTwC6Lpu6L7+BaCb3eIjTzMNpVehBMV9Ax3jWpriPecclwKono2i+QA+d0YUwiiPcY8+MYriKEQ7IrCJMC4HTiueZfz1/73tP9z0HEHiMRiLrTzMfMXDZ0HTsO0fe2cYDqXiVa/qmFDfgRAd+qxPdAkkCt1SvPPfnIs9k8OhXdFtFK4vfLccItDqHAeSvNtQM7JMI/YdD/94lxYPx8s2y4cYr0HbbUMCRYoHvjn6Ctl1ijLtLRZFrOqupBdac0cD3Sq2ExGfTcGtfe9weL13FUYhWlobk+Ri+qUbYh2L9rGDDnkuvbVv995twZrkBafu0+K x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR0702MB3557.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(366004)(376002)(39860400002)(6916009)(64756008)(186003)(52536014)(85202003)(8676002)(15650500001)(26005)(316002)(8936002)(66476007)(85182001)(33656002)(966005)(6506007)(5660300002)(66946007)(66616009)(478600001)(86362001)(53546011)(66574015)(66556008)(55016002)(9686003)(99936003)(71200400001)(83380400001)(38100700001)(2906002)(76116006)(66446008)(7696005)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NzFGM09OMXhIRmFlSjJldGk2akRpMW1LY3FxYmNGaE96U0wxQWxacFB5Q3Bl?= =?utf-8?B?Sm5uTms1UE1tZHFQSVR2STVBODFBa2JFaWRtWEZFN3hJMWJCbmZEVVQ3WDZw?= =?utf-8?B?azgvUTJwbHN3MGhMdFJrenc0NVJPUW5UNXNrbko3bU5QdXIyOHlJSjcvYnhW?= =?utf-8?B?U2VuUDRmbURVdnpoSXE3OWdJZS9sSjdRUmxlRnEvSnU0aS9oVzVZT1BwQ29t?= =?utf-8?B?UjlOMk1aME9BbEdqc1RWMmlzMEhuZFJSS0htU25PRkQ0bzBzQUFwUGExdzA5?= =?utf-8?B?ZEtSc2FQT3FKYWQrYmR2TFR1VlhISTB6bzlsdTFtQVd1Vkp3SUU3dGVqWDZt?= =?utf-8?B?QVVDUHdDRXN2MWpJT3oyNzBmMHpvY0x4WXdRQmR6K2ZLUGVqa2FmaDhrenBi?= =?utf-8?B?dnppRVFzUk5HTHpRYW5CWEhMblIzZkdiVCtLUnovZmovbWE3M0NuU290OGQr?= =?utf-8?B?VDhYSkZrNjhESHU2Q0NraUdnQ0RGMXJYc1JxY01aNXNlMVRDdXlBd3dNeDFo?= =?utf-8?B?dHpDRXJ0S1A2ekNYZGJoVzYrdEZIb3JLWVdWZWRuTGxnb25qdWZScTljSW5h?= =?utf-8?B?UXJ1dlZqdlF3ZWhGK2xsU3U0ZmJpQ1FtZ2VrZUszeVFaUDVFNzBlcXFadUgv?= =?utf-8?B?MWNTeUlqa1ZPUHl5U29peEZCZHhybEVMR3d0NzViQzROTk8zMmp2THlZSlht?= =?utf-8?B?emZtNHZad0JqbG9FMDZRT0k4eXJuMUhaOEFESlE2TEJBWld1R2RZZ3hlNm0v?= =?utf-8?B?ZVVBdCtZYVYyNFp6ZG1SY05sQkRDdE0vYklEZzhqVEEvTit1bzh0V0YyK0Zn?= =?utf-8?B?TU16TURHblFkcUdWVXc4QXkrdUVKVjVORDVTTndvd1hvdzBBQ2srbGhQTXMy?= =?utf-8?B?WlRsdlJtdS9LaFlzZk8vU05Rd2loaUhULzN6eHpsZDVxd1lVNVFpMWRzZWJM?= =?utf-8?B?aHY3MS9DVFMyTU82alZUaWV0a2VnSkVIbW8rTXk1MkloUWdBdE8zYUVoK2tO?= =?utf-8?B?blRWdFZNWU5uWWFPTWgwS1hnUWZ2ZTkyQVJ2VzhER0NwV3VFTUZJTVU3ZDQw?= =?utf-8?B?Z2lzOEMxMk5ZYyt2S2NmbVg3NmNmY2p5eTdjdlM1dEJURmswc3paZHdkQllx?= =?utf-8?B?L1Z3WlFWZ0Rud0Zud3lJWmV2WC94UXdjZ3hJWUw1QVRiRG00Sk1xY2Flc3FQ?= =?utf-8?B?MC9oMXVSRGFJVnprQ2NJZjZWYVBPZkh5RUx3MHB4R2JOc1pZUTlBRGloQ3BU?= =?utf-8?B?bU1rbE1SZHBLU045aEl5LzZoSnpRQWpjUGs2ZmtlRE4vOWx3VFZWcVlkMWx0?= =?utf-8?B?SkRPRjdoT1B5U3VZQlIvMWhJTTByVGM3aHRSWmhKSDBYNXRwZWZsRnp4OGxo?= =?utf-8?B?WEs3UkwrZ2dFck14UzVBYW9IWXpPb2dZSjlaaFNacWt2YWdIU1R2RkVCanE1?= =?utf-8?B?S0cwM01aRXIxNXZDcXVOdkFtaFdLa24zNVFrUkxjWVBvR08xakdaYjRhUS83?= =?utf-8?B?YVZiaDlYWFhCRjg1RWM1VmdxNjRROWpueXl2N2RaN1ptaXdiaWxKM2dCUjdO?= =?utf-8?B?a1BXbS9XZEZSR3doZmlkYjFlZmt6eUNVUitncHpuWTA0NWNaWmxheFFkN01t?= =?utf-8?B?MWp6Q1BjTXlpMkZHRFQrTldYWno1a216dHgydzFpVFlTL0R5NDR2UkQxSXg4?= =?utf-8?B?dzFVcE0xQzRhQUR3THl6emFvTDByRk1SUDdqaWprbzRWUmhFTzNaUzBoR3dL?= =?utf-8?Q?TVJ1aiXz08+Dkx3cW8BtCNknQfZgToCYgRKRGSB?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_017F_01D724B8.9575D9B0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR0702MB3557.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c26344f-8071-4d8a-6071-08d8f2bef540 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2021 14:28:44.4530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k3E3nMhRongUmBxqRVKbJXeQHLDqUOzH8ocB/Lmx0kVNzRbjHKyIsOjuk64jtUW4wJ2yqzolSRKYNUAF/UYq2I+TIhkxEu9VQKK5bASz6HE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5608 Archived-At: Subject: [netmod] FW: New Version Notification for draft-ietf-netmod-yang-instance-file-format-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 14:28:56 -0000 ------=_NextPart_000_017F_01D724B8.9575D9B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Updated according to shepherd's review. Regards Balazs -----Original Message----- From: internet-drafts@ietf.org =20 Sent: 2021. m=C3=A1rcius 29., h=C3=A9tf=C5=91 16:27 To: Bal=C3=A1zs Lengyel ; Benoit Claise = Subject: New Version Notification for = draft-ietf-netmod-yang-instance-file-format-13.txt A new version of I-D, draft-ietf-netmod-yang-instance-file-format-13.txt has been successfully submitted by Balazs Lengyel and posted to the IETF = repository. Name: draft-ietf-netmod-yang-instance-file-format Revision: 13 Title: YANG Instance Data File Format Document date: 2021-03-29 Group: netmod Pages: 28 URL: = https://www.ietf.org/archive/id/draft-ietf-netmod-yang-instance-file-form= at-13.txt Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-for= mat/ Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-fil= e-format Htmlized: = https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-1= 3 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-instance-file-= format-13 Abstract: There is a need to document data defined in YANG models when a live server is unavailable. Data is often needed at design or implementation time or needed when a live running server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat ------=_NextPart_000_017F_01D724B8.9575D9B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVWzCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF7DCCA9SgAwIBAgIP AXUc1ROE7L9MPfu7eEiGMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIx MjQyMDVaFw0yMzEwMTMxMjQyMDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzD oXpzIExlbmd5ZWwxKjAoBgkqhkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COf eak4TXgZkHPCY+wATiveaId4y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWH PSC+NN8IeyErzZNIrZli3vpUV236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZm I9xyaQ+RRJyaWTQKOkEeaa6V2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJO BL4j7Op8BvNmLBmKdnlK0Vj+nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xo I1kCAwEAAaOCAcEwggG9MB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQW BBQQoIERhKwaNK1dOsySWsLFygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEE AYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29u ZXJhLmNvbS9DUFMwJgYDVR0RBB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1Ud HwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlk dWFsY2F2My5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2 MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKG PGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYz LmNlcjANBgkqhkiG9w0BAQsFAAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kN AFNreHI3yY6folHuWMrIeE7pad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPo h5QKBYNYf+evBhITv16N4N8BeU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERs nNzVbp3Bv4/SbLB9TP+YZPKmBw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYc WDOQ2snUXq/FlMxj4oJ0EbHYmzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dl S5fORnKXbAPdEHk9558SJcQpI9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIO eWwxtTiSWGYLckpTlmw1PapzVlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujq Rte5NBVcysJPvxFjTThhOaA6JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDy laeibvqo0MLFtvx+RguycgnCsJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A5 1mjoJvqHA2xCMKb5SzxywsBt70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0G CSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVy YSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvU w0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQw l3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumD pjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o 7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRae MyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrN DZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4d S+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5G L0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuR TVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEF BQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBL BggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEE AYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29u ZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29u ZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNV HSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Qu q1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SB brVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxud rLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz1 1DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8H DZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW 0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2 bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/Ct gWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0M hBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIB ATBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDMyOTE0Mjg0M1owIwYJKoZI hvcNAQkEMRYEFPE7CpLUHPuiypYEpa5DMubpWfW9MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFs IENBIHYzAg8BdRzVE4Tsv0w9+7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAF3TQx2Nu0I51wl7i8snNM4/NtE3a0mmrKrLjmuEjtMbeuYreCQW80zQ JyRmeQWdYaZajrA2btTl6m4nkMS/e2CCgnY/R3xdxET+BoYUuLMxdoJtH9RbPJe6qvN/iv4mWW0U z6Fjuw1WGS7FA+KdZJBrvX8DZRb63QmbFww1NTXSnhtQvMUPe0gFLGXx1K8Ux1jh5zeWmL5Dsf59 P/X+SRmpskPtW3H3SbGaYmHNuCdM5i4anulGgUl1nm7AzL05b08vEENcfVOAeMrBBPnwZMxoYJzT NT519kP+ZroG9E4coSJiz61Ozy9E9/+GGPcqMcNu5iXYYhbetKAVdw31kfwAAAAAAAA= ------=_NextPart_000_017F_01D724B8.9575D9B0-- From nobody Mon Mar 29 18:55:29 2021 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 7498E3A2928 for ; Mon, 29 Mar 2021 18:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeA4nW8waOPb for ; Mon, 29 Mar 2021 18:55:21 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2128.outbound.protection.outlook.com [40.107.236.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8F23A292A for ; Mon, 29 Mar 2021 18:55:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iz66+fk+xygKJDXwhKYQ3h4rI0vjth6560NQ+9J+WuHFVLnTXY/4YL2j4pyEIw8mrygXU/1WYlixJ4Wf2sN/ZaWFkQvJNn7JnbhS1oa9ODE58ISCgaO/pqweDGzoGcl+IPGbD5I36an8Y1BPRXGslHw6v7B7f3dHQyD9VxwldDFl0a4MdZMPrMlCdkOrWgNti0W7Jwbw+/ftrgasZvYatMde6rNKVQ35Gef2H+tVoOQlDQ4JdoCtY7AyHZlE7lY54FFtvhrnprfOzulOC/JKhJFULzetnIpDs37AuODJ9DDWPJxuPW1r0HJJXtM0mO+X9d4ZL1GDUzgUKokUPyQJDA== 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=W/tLtV18U2SClfBBTWnVEqDzXnFH3RTFfXH53tKZ3xs=; b=VwKfwrDUxG8/dyErN/vKI8qIdtCRtrsljpNVCHbF/NIU1km3A59M2Ru4qxxGYi7/uM0guHmm+7Uic6MCMXDFXU41EtlMpbKvqFojmP9S2kPoNRGZ0fApfHeptK7A0W8PUxAlWMwuaWMwB1ufIiTZChoiRhX6OqfMYoD2uqTqKucUgOIKCccfbyJwAKiWbgu6DYoPQC6zcy+8JbEM4+HkQbBUXVEzrHbusOYI5dpfkjEAowWA+DEpvzs4oKUPmLr75E7P8zVsmGUZc7id3a8ldu92jGlJNKZczveIRWdCDVd84MKxroUbxNDQJgjCW8VVY+G1wUhUtdCE5eemWx512Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/tLtV18U2SClfBBTWnVEqDzXnFH3RTFfXH53tKZ3xs=; b=GqCFizjrWTKZQZ7VbKYpfjSzgI90xwNNR3BEWy/Ervgts4T7kPzlGSCBAy0M2V/JdbLY0y7XVh1cpIUYwU6Blscm1ycKHFOLM7SoiGeeHgBw0eu8iNz4kipVwq7IWdeV2QIBPVm7VhL04kS5yAQo+wn6EVIdWn/CRlh+nisA9DE= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB4155.namprd08.prod.outlook.com (2603:10b6:5:8b::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Tue, 30 Mar 2021 01:55:18 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 01:55:18 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: review of state NBC rules in yang-module-versioning-02 Thread-Index: AdclBSWWxB5xRC8HQSW7x602ImvvWA== Date: Tue, 30 Mar 2021 01:55:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [174.112.3.120] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1f3ccc97-ebc5-4530-b4f1-08d8f31eded6 x-ms-traffictypediagnostic: DM6PR08MB4155: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UeeHPZcDG72eCDi/6Nq8KlByojAWnIWOPsLWm90hdyOKvNKrQbwWgiVjdxQW2E3wYNyQVqFElrdRWBQxfqG6nMwcB/kM+ObuMtuzxoLp1LiAmQTkB9wLRhPjoQHSB2h0wNcTjSRqHGAjMEayRYj4TG+e/quTzw+ZiqvslCLQPkyiN6wPkp+IRtyb6W1ZcCDixBBbSUpJFBMIpu5DqGcM9bsLabGuwCbsRFsotb59HwUZ4JqY8y7v2SqusVnrXiSNQhhRfPiStHNeOdgVCRW1cdlhTn+vcgk1Xcf8ImCRg0nHShebNcJQ0BLPn2M6x8/8f7gDPz6+qkp/dVT5uHUYWUO3CTPryBP3VeBHLi7H3OBIX7zqQvtNAS1Pyf6RNAQk9pEz2oRj/ptamYM3kZz88jtjSUuREhAkrou+0bexqmsPzk5Fa2Ix+IlSptCgBqUpgz86/AjoogFAh4snaLXnR2am3/azTvHmbrMIYXOTfOlhcjm04i8ukehS8Zk1Dw+Q1Dgx4RCGZBL4+t/9Zp4mkEC/hgwLtmEr6gdhwGp9jq5aNm/pdVrLMRw3wQY4tyB3TSuEAxUoAVcb2i0weqrug8ZUbqG6WuQlmG5MWNXNGlsBZ4mNr5BoDiKPl7DeM45doxqF5dcqst9J2it3bOUKKPyq25/b3iCTOO390hRhOtmXLneYv5iSLKbh4AIAuVtzmF/sw9zDYP7kLKw8+70dfEB5CECsadbh5lPT/B3ff6I= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(186003)(38100700001)(52536014)(26005)(5660300002)(76116006)(71200400001)(7696005)(6916009)(966005)(2906002)(166002)(66446008)(66946007)(66476007)(86362001)(66556008)(83380400001)(478600001)(33656002)(6506007)(8936002)(64756008)(55016002)(8676002)(9686003)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?GkrO/4Yxzcog4ffnh9c5XOrURT9AKU8XU4lyP2ufR1XQ//EYtL8EMR0+uney?= =?us-ascii?Q?vWYkrpuDFRymCgIGmcuL+LdzRa64pYulM+jNclLx3qwhbnbTNFHPodZ3lS9K?= =?us-ascii?Q?FoYs7GzUeFX/WtPUZDzH5JUFQqcb6YokOPskFdnG1ylrtEytFJYyfAmlj5Io?= =?us-ascii?Q?cV/cfpfRTBnD6AJ04fUwpTIp9zmOXb9GHBxm57YzWb/UseSL8ty19DFRJRcg?= =?us-ascii?Q?E/UwQU/FhnMZN3lpvwfLrZNuu7wIZabj7J9cQIblDKqVu4DO2Sl7qVT2QuoF?= =?us-ascii?Q?KAwt5Gkj7t3vxGd4C2LQVvoVYSCA22Lw5AlGq/Vd2sZ1S8g3bOlymz1mm67a?= =?us-ascii?Q?zLSfRBqA/iH/5cyPUFAPUhbytbQtXeL9rRdiqbko0Z+hIrTcOObAjQUpH4bt?= =?us-ascii?Q?a8kAt8p0rOuGT8y5FpmxkFAsffncAnArJ2GC1zjJ9yuYIg0HXSFCzAl7cWWw?= =?us-ascii?Q?8fUAvensN0Q+MxR5iJZqgGKpSPn4twRQVTFQmDQg3TL4cEF6VzUk5ni6p2Kz?= =?us-ascii?Q?+DeDf7BjXDoj3dB1wgz3L+1m797vn84LQKlO3KnYBgAFbkz/lu3ed3SrwmMW?= =?us-ascii?Q?DX+v80heO+gfaL4hE/lkugFGs5cp3ZmkZVxHpWhBDvm3NHo3HTNehA2ID3WS?= =?us-ascii?Q?57ypXJauvTWZhU8LNM7P6nuJH4NNb3/q6RvL6i4yM+utQRjdInbuq3ewNTf7?= =?us-ascii?Q?kuanMBrUSkEkSXZxemeL/1Y8a5tppLlkxUd8bPTiz07cMxA06IMmCGrSjX0i?= =?us-ascii?Q?u4FpjZIrC8tZQSon8RZQJDycePwEhc309TEDcQAGe33ehW10zCtQAJGVuYlu?= =?us-ascii?Q?0VofTTb2JUz8c7mImXUvZUgsxmYqdCDHbCcZ+JpRCsY61AJV11G4WwsM5xT+?= =?us-ascii?Q?USsJegeFquJlj0uwulJDyoZuwOu21oX0x3r1uAS3WBudeyzeLaUHXBOrcGe+?= =?us-ascii?Q?7AI33BjntcoiuCKKc6C03E9C3UmlobL3tofRFZ6G4RkJjUZicCoqJbd3zPwE?= =?us-ascii?Q?8R04vHzmOEp7CTVwHIGAWiW+0M6J9gbJbqBX3AEAJ5rxWMyprHzD41837WdH?= =?us-ascii?Q?b4coWhLT/uN53Pn6wVHur8sa3w6ha0eQ4QV0nU91f47tjCzonyxV6YxvbAF0?= =?us-ascii?Q?Oq8kRR5F2qt30SrQ7r5Y8NfDRszzUZ1j/jb6c+qcNCoMQpPcGJxjtV/+TL+I?= =?us-ascii?Q?rqPMo2Nh3I3mxQYPeu897t90XKI8UPDb+AnK/4ngHIPR1gV75qvKcx3dKQbH?= =?us-ascii?Q?7c6m7AaO+/Av1JqODxS9GT6a0xR9oVY5G4ZtwTBp5/ibf6c/ecgoQjcLRJSL?= =?us-ascii?Q?d4sQSaV/JGPKcmHi6xEZ8/+y?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB5084362AAED96C0A27D7C6589B7D9DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f3ccc97-ebc5-4530-b4f1-08d8f31eded6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 01:55:18.5337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GYaYeN1x04dOukoufBY9AH7jUilH+fmIHRLBWY2wbQB+FV1oOGj2gm0baDecReDnFsVpWVD/1ouqfyHAw8EVIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4155 Archived-At: Subject: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 01:55:27 -0000 --_000_DM6PR08MB5084362AAED96C0A27D7C6589B7D9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I took a look at section "3.1.2 Backwards-compatibility rules for config fa= lse and output data" of https://tools.ietf.org/html/draft-ietf-netmod-yang-= module-versioning-02. Here are some suggestions (mostly just editorial - I agree with the general= spirit of what's in here). (A) Valuespace Valuespace is defined in module versioning 02: o Valuespace: The valuespace of a leaf or leaf-list is the set of values that the schema node may have according to the type and constraint statements of the YANG model. It seems to be a more complete definition than "value space" in RFC7950 (wh= ich doesn't seem to take into account "range", "pattern", etc statements): o value space: For a data type; the set of values permitted by the data type. For a leaf or leaf-list instance; the value space of its data type. Should we mention that this definition replaces/supercedes that of 7950 (at= least for the scope of the module versioning doc) ? I'd also recommend we call it "value space" rather than "valuespace". (B) replace "an additional state leaf can easily be discarded" with "the presen= ce of an unexpected state leaf is not typically a problem for a client and = can be ignored" (C) replace "config=3Dfalse data" in the 1st paragraph with the following (and = keep the quotes - that is how RFC8342 presents it): "config false" data (D) replace this: o A client SHOULD be able to handle data that is outside the valuespace defined, as long as it is of the same basic type. with this: o A client SHOULD be able to handle instance data that is outside the d= efined value space of a schema node, as long as the data matches the base ty= pe of the schema node. (E) I don't think we should try to exhaustively list (and limit) all the factor= s that can change the value space of a schema node. So instead of this: o Expanding the valuespace of a leaf or leaf-list is BC. Change of the valuespace may be the result of a change to a range, length, pattern, base, enum, bit, require-instance or must statements. how about this: o Expanding the value space of a leaf or leaf-list schema node is BC (f= or example, a change, addition or removal of a range or length statement). (F) replace this: o Changing min-elements to a lower value is NBC (it is like removing mandatory) with this: o Decreasing min-elements is NBC (it is similar to removing a mandatory = statement) (G) There isn't really a "catch all" rule for everything else that isn't mentio= ned in section 3.1.2. Should we have some sort of statement that state rul= es are the same as config rules (section 3.1.1) except where explicitly upd= ated by this section 3.1.2 ? Jason --_000_DM6PR08MB5084362AAED96C0A27D7C6589B7D9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I took a look at section "= 3.1.2 Backwards-compatibility rules for config false and output data" = of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02= . 

 

Here are some suggestions (most= ly just editorial - I agree with the general spirit of what's in here).

 

(A) Valuespace

 

Valuespace is defined in module= versioning 02:

   o = ; Valuespace: The valuespace of a leaf or leaf-list is the set of

   &= nbsp;  values that the schema node may have according to the type and<= o:p>

   &= nbsp;  constraint statements of the YANG model.

 

It seems to be a more complete = definition than "value space" in RFC7950 (which doesn't seem to t= ake into account "range", "pattern", etc statements):

   o  value space: For a da=
ta type; the set of values permitted by the
      data type.&=
nbsp; For a leaf or leaf-list instance; the value space of
      its data ty=
pe.

 

Should we mention that this def= inition replaces/supercedes that of 7950 (at least for the scope of the mod= ule versioning doc) ?

 

I'd also recommend we call it &= quot;value space" rather than "valuespace".

 

(B)

replace "an additional sta= te leaf can easily be discarded" with "the presence of an unexpec= ted state leaf is not typically a problem for a client and can be ignored&q= uot;

 

(C)

replace "config=3Dfalse da= ta" in the 1st paragraph with the following (and keep the q= uotes - that is how RFC8342 presents it):

     &= nbsp;          "config fa= lse" data

 

(D)

replace this:=

   o  A client S= HOULD be able to handle data that is outside the

      = valuespace defined, as long as it is of the same basic type.

with this: 

   o  A client SHOULD be ab=
le to handle instance data that is outside the defined

      value space=
 of a schema node, as long as the data matches the base type of the schema =
node.


 


(E)


I don't think we should try to =
exhaustively list (and limit) all the factors that can change the value spa=
ce of a schema node. So instead of this:


   o  Expanding the valuesp=
ace of a leaf or leaf-list is BC.  Change of


      the valuesp=
ace may be the result of a change to a range, length,

      pattern, ba=
se, enum, bit, require-instance or must statements.


how about this:


   o  Expanding the value s=
pace of a leaf or leaf-list schema node is BC (for example, a change, addit=
ion or removal of a range or length statement).


 


(F)


replace this:


  o  Changing min-elements to a =
lower value is NBC (it is like removing


      mandatory)<=
o:p>


with this:


  o  Decreasing min-elements is =
NBC (it is similar to removing a mandatory statement)

 


(G)


There isn't really a "catch all"=
 rule for everything else that isn't mentioned in section 3.1.2.  Shou=
ld we have some sort of statement that state rules are the same as config r=
ules (section 3.1.1) except where explicitly updated by this section 3.1.2 =
?


 


Jason


 
--_000_DM6PR08MB5084362AAED96C0A27D7C6589B7D9DM6PR08MB5084namp_-- From nobody Mon Mar 29 22:38:10 2021 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 7FC3A3A3D9B for ; Mon, 29 Mar 2021 22:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dutCCXezXPv for ; Mon, 29 Mar 2021 22:38:04 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30073.outbound.protection.outlook.com [40.107.3.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808293A3D9A for ; Mon, 29 Mar 2021 22:38:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LLGiCuytu079OocVtNutFEa22KLM50HpcNAJFt+bFAuWtDfg38Y4XgpE/9B6MeuZfdZ5d4tJwMQAEwtPw587tpZ4c8oEV9FzTwunIl6pcB38tWF6KfPdXF9kyPUZigG7x4eTjuF22Y5pIhEJmENGC0t1pPwBQSzOYMcFF0IC+zf7diSsW50E/gnsCn95nUyKsDhQi9s4je5bAqK2gHJ3VTLe1bKnnT6ouHSyNHg4Ps7VSChv8w+ISuN68iJnidR9dbypTTFe7qun5P2hfShv5EDRLWib4VHavtSiMFIO2Lb9Ta4Cqs6fia0/UFUsljD7X8ggrQwskxGsVWd1ihYAJw== 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=zGHgB2F62VE9d/Nc7xW/Dxewput86YZpi7dYZ0IxyGk=; b=kBWDZZzLhwQPQqmY3zZmViiMwUjNlWqaTIdTlJ9epK8fS6K0RVVvpqZ7Vy+eNHre55h1N+lqU9GkPdSyzd7jQIIXgvooPuG/UWBgMGVsu4UIKFZBY2W5ODYh/AXCSGpmoCm8yuqstdz+JDRXhv1EDvwJmgSsjyynBCPo+M564XvZswuF44jPU2Uv+3e5Klf956qNXi8IqZ++1ndjHN+gRt8f8JGZntHR/ZCNweDKYrhf0ueC1ywtxCbgkcPiVNEiayoHnuDtOoRsdUnvT9Qk8L4WpIntQeHrJTDT3SXwstDn/cKjLPrCsNyYW0j53WkXmzdiVJNQEGyqVffF3f0kiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zGHgB2F62VE9d/Nc7xW/Dxewput86YZpi7dYZ0IxyGk=; b=hKBPR0i9j60sVdNFExTKXuCCy7DIDqndtlS/MkUWGArD+nmS5hgQyOniCtaz8FwUxbQnxfU6GF+9zaglg4amxksizGmMUuUKlQetkxOgNC9RwjMPLI1/58sM1L1/AFSY89RnUAEuVgoiotqIbqAcWGm4eMKL5QEuJGskK/Yc5lE= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1171.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.29; Tue, 30 Mar 2021 05:38:02 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%6]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 05:38:02 +0000 Date: Tue, 30 Mar 2021 07:38:01 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Message-ID: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM3PR07CA0125.eurprd07.prod.outlook.com (2603:10a6:207:8::11) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM3PR07CA0125.eurprd07.prod.outlook.com (2603:10a6:207:8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.17 via Frontend Transport; Tue, 30 Mar 2021 05:38:01 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d6a2303a-85bb-41c8-e2c0-08d8f33dfbde X-MS-TrafficTypeDiagnostic: AM9P190MB1171: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OpPMIK2sGv8WhbwtIhozsqHRcWd8x0Y2gvixsnvn8QZmopuzSJFQ2h2mIUUlt309LUOT9NNMoskUTTolO4oLFa+DO5yo/e/+2vlQ7BLpemaGKB/JTk38YAESJ5FDHKBFFa95J4wecfEaWVNFQ6CaZFFGVh32j5q96pniUZ7ytNBKcqHh/D+uM65zI1tPiJ2o1iy8RpA4JLg0bzUfEHofDem/BjXQEeDTAMv8GsQwDf8nGK61NByu8x330k04CA4ZrNaIH20wbmdcBDXi3X38U4ewxxYpeEdK8ePSCcRKIZoABpXS9VGFMjMmO6WvuPaRAUGtLPZHGG3rDKLS3uN3joCGUc5Sw0l2OTKWYIOpxwhuObKztamo6TlQJ5PfJJxFvo/dXU7MnqRavH4J749eIBVaUjmcxLomiCrdgBE62PzCoTa3l8wWtHSWSmhXD+DOipCv4LSQY1xBigUmPgQMRSqIRxOnuWyQbSFpdwmHHe92VBIU/oLgMiEAdSH7g5a2mEvtOR/ObjCvm9gt3syJrTUTTrnB0fB6dSeVRqEOZ884AUZMnBeyKtGA0i3M6NevaLYaYqvcP2zb+6MKtdfmVfJjZz5CA+b4l9a7hhv3x3VngU0fDgmonVmGE63omnQXSbPkMmWZYtj9XMlhhGQi71smRKXXPVPlcdZcwlYfrbzpv38BI1vRw9UxG8eG3HBBiIao2LTNqvWpgYlS0+h3S9ci0BfFSTHcbNk3B+N2Xwg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(39850400004)(396003)(376002)(38100700001)(296002)(316002)(786003)(66946007)(478600001)(956004)(6496006)(8676002)(8936002)(4326008)(2906002)(5660300002)(6916009)(3450700001)(1076003)(966005)(86362001)(83380400001)(186003)(16526019)(52116002)(6486002)(66476007)(26005)(66556008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?HQ9+MZw7WaQ/5vGaVyHce7FINbamZS5K6hji4xmuVPzoL/7mtskluwL03+AR?= =?us-ascii?Q?gOupCXujR/DMQiwvOelOZa19apJwh6d1j/QA1gbbo0ajE8vAFg5JPQf8X8Dw?= =?us-ascii?Q?fbI9taYGYKIO2LdmDlHeqo/GtFxS+TOR0ehvfeDLIjMgCXp8V31PiaGJB/Ur?= =?us-ascii?Q?N1PYLUABoQG6aZP5QFCxRkZkMPFabbxOY/V/Yw8n7o1XxwNdzm7PcYLUYe6V?= =?us-ascii?Q?YGfmzgs/UEePferh9PuXYm0x/ft5Pm2+JRe5yW+gQ3b6rJe3qwtGlM2Ol+Pv?= =?us-ascii?Q?B9jr0wXZYXV3Q3HhJ4rTpuN2TYks2Dd1oT9hj8Gko4LKcx0Wamo8hb5D2sPt?= =?us-ascii?Q?3M2QQEBLthzeoMhV2JvVsPyEGv0fu2Z7GBAlSFQSJNm7aws9UQ9H7JYJZR+D?= =?us-ascii?Q?YIlidC7xg+fc3juQ8RuM1/wqUN3tdVWQgO/Rb/NEYSqCg880Zc6TFoXWRvi/?= =?us-ascii?Q?z6zBg0C9ZW+3UWHA2i37sTwlRlD4lYqGTf0uQS2DXCzudafJZds20XRMRVB3?= =?us-ascii?Q?rqKZJVFoZBK9NdIqBXs71e6NpsSDhEawRq+UnSS1UGHyj/2ljMDB05foZe7e?= =?us-ascii?Q?K85EyAJlvhFcBm+iPRJnnobu2hxeUA4Jp0O+CQi2mwKdTSy3hp1HSJAx2bag?= =?us-ascii?Q?oEEJBGopU7SkOhvBY8O4CPpU0BZzM43uVc3PtMbAerUU1vRswGkwviz9KgvJ?= =?us-ascii?Q?Qg/Ib7SqZIqcdGITRkcbIMwdwI+4033JocMGV294frMzc2b6lyyuuL/n/7ag?= =?us-ascii?Q?cViG1cQCSGvYWutmJbtmLfvZeUGlbZATtrB41gqLRcMA3AsLBVa1CpbqmKbd?= =?us-ascii?Q?Wo9gz9+IMDRWhChtFxx5+md6eL+H0WULOK0uHsxnwbtiHlFN8YZEhh/sHRzJ?= =?us-ascii?Q?qOFl8a9WBVo4NWRfaEdgEgq8fir8YerH8qHIGma9hm6vMYrutHOYgX9URwSY?= =?us-ascii?Q?RX53FdBzDxt24kQhl0EpyRdm4XcRdf94fqETM51LsYFopdVzoNnPM52SlZxD?= =?us-ascii?Q?mcg1GcUp2VebmEYGAnh2go7gsMAD7gGYCKcjOzVnPUML60m7y8sAv3Y0BIx4?= =?us-ascii?Q?PZgylS6manUYKdUIVvaulgM4W0MJYibhtF3A80lJ6i0fTIMfpOGNpiX+Besm?= =?us-ascii?Q?65WLm2086Q66rTf8jj2+fJtbWpPuf0jbyg+cU0ehn3aRz7XPoS4aHekpv85P?= =?us-ascii?Q?JimDCRKON7CQFRwemBXrnN3Ynfeyl9b6vPT+4g1DJSY2D/0tJQDKA1YGSbdB?= =?us-ascii?Q?/jenOD+wn6lnr6LTp12X/BYrIogAo1C9ZDCqG9h9361828tfL/nPrOYCCcyC?= =?us-ascii?Q?AR4Ov+oFNulD2LuFD1UmKwDw?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: d6a2303a-85bb-41c8-e2c0-08d8f33dfbde X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2021 05:38:01.9338 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 93h3uz/uv/yn5pB1wEtKO2jED9pEqWfHGQYRknzjzd6MEIbd3kGdJSE4FKNQ12tLDpBmxJYhAVlrORP6H3C5fcyM8LX2xHK7ZsK7mf8sc34= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1171 Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 05:38:10 -0000 On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > I took a look at section "3.1.2 Backwards-compatibility rules for config false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. > > Here are some suggestions (mostly just editorial - I agree with the general spirit of what's in here). > > (A) Valuespace > > Valuespace is defined in module versioning 02: > o Valuespace: The valuespace of a leaf or leaf-list is the set of > values that the schema node may have according to the type and > constraint statements of the YANG model. > > It seems to be a more complete definition than "value space" in RFC7950 (which doesn't seem to take into account "range", "pattern", etc statements): > > o value space: For a data type; the set of values permitted by the > > data type. For a leaf or leaf-list instance; the value space of > > its data type. > > Should we mention that this definition replaces/supercedes that of 7950 (at least for the scope of the module versioning doc) ? Please no. RFC 7950 says data type and for me this includes everything that defines a type, including the semantics carried in the type's description statement. We do not need to fix what is not broken. Why do we need a new definition at all? If definitions in RFC 7950 are broken, then we need to fix it in YANG next. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 29 23:10:27 2021 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 232A03A3E66 for ; Mon, 29 Mar 2021 23:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=NHSTWvuT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fju9ZWmB 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 I-9mBIQDKqYW for ; Mon, 29 Mar 2021 23:10:21 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367503A3E65 for ; Mon, 29 Mar 2021 23:10:20 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6D7535C013B; Tue, 30 Mar 2021 02:10:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 30 Mar 2021 02:10:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= 9FJ0a3FzUPISz8h4WNr+0sOVFRJlimDrTjKh5l1ki+U=; b=NHSTWvuTOy2f4VFp +KcBZWbNINy4oKiwddXcTy2XfLQF5bfiu3UB/0Yt8qU9AqzE+yhXe+As4YwhWtiD 6NGFX0wTMp9DAu1om2TIFd7m6Fm7yryvXIuc5F2dARpVNS28K5IlHeMUCSIj9OdA wYV1WK1CI7J21J6fGieWkqeP+flVosovqmK5ruUMlJS4J2Bx//Z+Lp7s3TIA2BZ9 I0CzANCbdRtOCZKxDUUOUx5ahxli0oSALWqPOU8XXstkarsNNapg1MWSNvmxZlxw URlfrFzJKpG1SuMfkA8fo17yzHGCQm51cJwFcH1XxGeG7omtsqNBBq/cGBQXJ8+g b4EB4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=9FJ0a3FzUPISz8h4WNr+0sOVFRJlimDrTjKh5l1ki +U=; b=Fju9ZWmB8ZlIn1Z0eTBT/MtkiaVS42kAyyxJ93OJS/WaNxtsMqKhIhfyD ZDAo6GqapPrtm21fxVSMAqhQFqZcHrlU4/vVFHM9u3FDyKXC1ScSdPrcQOBkd+qu QPJknBt0O3rfQI5EggUt2TLgjGA88YP9WERUyTh5QNToCFHcHYL9NCQCbw5ChPhM /liU5ygPyEj1M6TCmEfjoBq5nVHOsl/5scSkiBywtDs+wmZnxyy48cxMKlT/T52U GrSQR3oOkrqXcSNPshvIHChRTM7LAB+F5v2dZdVvIWG0s5vGlcN7IoUyHNGcq0w6 o5aP6nn+cTfrrIFMFII203siHhJbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehledguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeffhedufffhveelvedvje eiffduffdthedvheethedtteelleekkeffjedthfdtfeenucffohhmrghinhepihgvthhf rdhorhhgpdhjrggtohgsshdquhhnihhvvghrshhithihrdguvgenucfkphepudehkedrud ejgedrgedrvdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 4DAFC240054; Tue, 30 Mar 2021 02:10:17 -0400 (EDT) Date: Tue, 30 Mar 2021 08:10:15 +0200 (CEST) Message-Id: <20210330.081015.471474254972270522.id@4668.se> To: j.schoenwaelder@jacobs-university.de Cc: jason.sterne@nokia.com, netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> References: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 06:10:26 -0000 Juergen Schoenwaelder wrote: > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi all, > > > > I took a look at section "3.1.2 Backwards-compatibility rules for config false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02. > > > > Here are some suggestions (mostly just editorial - I agree with the general spirit of what's in here). > > > > (A) Valuespace > > > > Valuespace is defined in module versioning 02: > > o Valuespace: The valuespace of a leaf or leaf-list is the set of > > values that the schema node may have according to the type and > > constraint statements of the YANG model. > > > > It seems to be a more complete definition than "value space" in RFC7950 (which doesn't seem to take into account "range", "pattern", etc statements): > > > > o value space: For a data type; the set of values permitted by the > > > > data type. For a leaf or leaf-list instance; the value space of > > > > its data type. > > > > Should we mention that this definition replaces/supercedes that of 7950 (at least for the scope of the module versioning doc) ? > > Please no. RFC 7950 says data type and for me this includes everything > that defines a type, including the semantics carried in the type's > description statement. > > We do not need to fix what is not broken. Why do we need a new > definition at all? If definitions in RFC 7950 are broken, then we > need to fix it in YANG next. +1. I don't think the text in RFC 7950 is broken. It is better if the new document refers to the defintion in RFC 7950, rather than providing its own defintion with new words. /martin > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 30 05:13:35 2021 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 4255F3A0E96 for ; Tue, 30 Mar 2021 05:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYVHfi90eJRf for ; Tue, 30 Mar 2021 05:13:22 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2133.outbound.protection.outlook.com [40.107.244.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657BF3A0E97 for ; Tue, 30 Mar 2021 05:13:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Chu7Z2y8k1i4UFJufOYG5eZcRsEq221V/v5HFfxnICOPBi16GFE8AMUcvHw2N4gfZaLXJcmm70mxbNkRAEvXLhBfb3+/AhJxwzOiUyYm966w7/Ki4fN8kwH9ywcG+wkeW7Zl60r2HO28xQb2rcn4HG6LT085a1vmiLqAez1mPSfVw//9K15i1mA+17gHYz1AfGzIxhy0G6Um32jpR349Qu+r5XHqXZYZ85OfadLHeVDO9hhgaY72buqSNdpWUYeDbPHJzd9lenlzsqkZRNCq3qItKS5WLb3ck/Dlt9wIk2cNv1/59lMdQbd+yjn0x9z1b1jKSORHIYtO5b54mx+sGA== 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=KTZwUqTE/y+h/NUZ6hYhKk1rvsaoD6UtJKwtB+lIv+M=; b=LyfC80onbQgyudYt/VQs8LpHXg9jI5xHKHcR4Sy0qhaQ7I7zGOlyPe22FOdTBZjzNKB23OQQWCKw04s3yTO3IDDlwqUA4DAUsP/t9aB1zkZDnwqfGfL+s0ZxbCdgQtRLHRL/qs/NQAxdjUWAy+nM0x69O/OBvCgzayEWVm4k5fAbP1iOnD4JFjLeMwiLAFoIjWYjSZvBqB2Wab3T5P4WVdzdujkpGbWP9c0ucB8ysU3+BLPfZI94/9VP5OYzLf6pQW43e1A1Fd4glPbuRO3fg+Qg68095QCCyQnaZd5DOf2APgzfsc/WY65VfZmfReTN0Zx+d1QIrgiGqB3RO14XJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTZwUqTE/y+h/NUZ6hYhKk1rvsaoD6UtJKwtB+lIv+M=; b=Zh7W6K3bcGy229QoJpbc0N42BvKNHPMbtgL4FhySitbFyuwWKQWrz/8vlzuk6uoj1UvqkTR8Al0ee59taMLgy8voQf6kJB5QHmAnFmEdK0bRuOEGJFCWNrydPBPvcDqEWqN42wQE3z6d6wD59a4ijpFFD+AJuhFN8z2Qe6UQdJo= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB2380.namprd08.prod.outlook.com (2603:10b6:3:71::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.26; Tue, 30 Mar 2021 12:13:18 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 12:13:18 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= , "j.schoenwaelder@jacobs-university.de" CC: "netmod@ietf.org" Thread-Topic: [netmod] review of state NBC rules in yang-module-versioning-02 Thread-Index: AdclBSWWxB5xRC8HQSW7x602ImvvWAAIbNmAAAEgMIAADKXxYA== Date: Tue, 30 Mar 2021 12:13:18 +0000 Message-ID: References: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> <20210330.081015.471474254972270522.id@4668.se> In-Reply-To: <20210330.081015.471474254972270522.id@4668.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=nokia.com; x-originating-ip: [174.112.3.120] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 44e1f509-6eee-40e7-b548-08d8f3753408 x-ms-traffictypediagnostic: DM5PR08MB2380: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vyOxyEPTQb8hK+sBDc+4qond5ix3yOYsHn09OwrzWzvg2XbTatPLea0uvYvGnCR7wDltk9ZwtNiT6BznQE6o7mFfTLPkAWq52ovT8npERlkyUdXp+NoO6mKLnR/8XrnfJOEEhz3EUKrm9eid3pEqPFsiu9T4U1yy0AWQZ8yJxuC3f9SonXLOsfkxGE6YKjMRC/wU2kmrMNDyL3FfxFhfpIGZ/rPOF2KnrgPNtPrKXXPXEZTku232Kzbf8HkQpeqQUmVviK9mdP+x0k8U4ggvCJiiJytlClgBTleGHxXwcVhUrk2avECv94INkPyJu8472UmtOdLC1ojlAzCOGAmVyD0HpTA3RkTD6tJkzngaPojm0tlE2F2HCJ1AaAJv6LYAGzAi79Bns7ygVCm/FEFhAdFVbR4HhiuDkZ+rv18dp55Wl7i6H+TdWaCBTUeFPstKhDKz5sdrxtVmfTxzssOKIEVxW8/+FpEzthI8A0m+tlKB0I2TU/WfkIjxmPi1BbTYzjHUctDfe29j/MGINsdeuyUpwYqmay+8VPjI8XjIdKsIlUXVWGhQ3wt8IIdYzTbJefDpsH6K+OtBR3E94mUzHHdjr3YXxW3rlJ8vkXT29L4XLAIY1dEvs/Kj1go+hbLVTcImazDWrR2WVCSF2sh2FuJv5B25+qY2kYINlnmhoY7+V6Duk/n09Ag2LRoRL0bJYBBUs6jXO0UVhvzCFhMfUzuh5t9gDhfnvCLNBkerHFY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(346002)(39860400002)(396003)(136003)(33656002)(7696005)(186003)(26005)(8936002)(8676002)(64756008)(76116006)(6506007)(53546011)(478600001)(66556008)(55016002)(71200400001)(66946007)(4326008)(66476007)(86362001)(66446008)(966005)(110136005)(83380400001)(2906002)(66574015)(5660300002)(9686003)(38100700001)(316002)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?RaFGuyeBIxRvEHwwZyG1PZkPFa2s07H9gYNBBRQYnRNmBgvUyUjeNpMvTO?= =?iso-8859-1?Q?UbxXHt3Y2IFSRnfRbyzwFbuqcSuaGaHK5in0HMyRhxip/sGqIRKy2sEJJZ?= =?iso-8859-1?Q?gFYEAN2V9usQ2HR/QKYJXDI2l1y9hByWpLJKA/G0OUqlVCiQjFSVQC+tZM?= =?iso-8859-1?Q?CWxKYaKb+8AtKumwesukyIV6S1IJPejPQSX8zUbwAPFBYE4C8ZdxIdzgNm?= =?iso-8859-1?Q?O1UcXA8GqZzvFCoGVn0J3pvCIQU/uZjDpL9VULxsMmeJrffdhs+Bird0AZ?= =?iso-8859-1?Q?FaD+VuxYBIRvH6PZkV4orQE4O51YDeGZenuJBATbMUnjeYu79PfoRgSm5o?= =?iso-8859-1?Q?i9ZMwWOHFDJ1jY0q9uDNjJi7rHp4QRCHDHpHDwWIQ8YjK1hid4+FBFQZGn?= =?iso-8859-1?Q?poBUQEt0CQGSHFwbp7ho6qg7eSAzk73SO/HiHQ6VroEX0GoaFGQn77MQ5F?= =?iso-8859-1?Q?ojEelniGkjFJeab/dCDiyofbLOvEWqyrX2qN1YnN/3KgcEqkJAzGav9cwh?= =?iso-8859-1?Q?M26CdlGdrQtAwdieQY8+4UFpR79X/hRMsmOLYmu+XULwZAWe5BxOpdlqrU?= =?iso-8859-1?Q?jPE5IjdtJ2XhbG4bAAU1fqTikAmv3ECIlsnsQKGErB6kRWiM+DGP8bWGUq?= =?iso-8859-1?Q?sy+mda9+/hoO5fhoVwk+ORU74cr8RTvVHMGmFyuVcuBolwj66cOBUQLMMg?= =?iso-8859-1?Q?Xw1HKL6T5Quc471oQ4IDNeAD+lZUqCcy7BTZb4Z2RQXJUMra6sGpK/sYQQ?= =?iso-8859-1?Q?triLS0pFbm+r5IyIQ/rcbNz84GcSCIyMwJTCfMgsBwrcKGPy5QaARrDvFn?= =?iso-8859-1?Q?tdTDFR3PNPPeWXIaBuVwZyJ8YqnKEA+qXwtpOHXn/8CoPMNrHU90NIm8k1?= =?iso-8859-1?Q?2PFFmKgmAYtpHtn0f64AeeCBAvdkANfzNuwwWjsk2I9BUe03iUqZcbSxtq?= =?iso-8859-1?Q?6TRWRNdUGsvrxCcLawhyhecQgGl1UXmjl45bm3m543qY3GHyD0E+UXyDOa?= =?iso-8859-1?Q?eVhwwBiEvjBPpmVJV5alGC9S/JfyhnJBdIz9xtys1uHmIso1FguTJi5Cwi?= =?iso-8859-1?Q?8NYHukORumBgtwIJIodfjrmWA1ITv4awtU1tdqy4UmQN2WvUuxmDtxfOmH?= =?iso-8859-1?Q?mFb/2rX98M+7QuvO50DxmAI3ZuYAcwQeThbugqlXieS+29X5mioOr7EBWS?= =?iso-8859-1?Q?uQsqZlkGXfxMOGcTsT1ZQV33IrvT+O4e+VlM6NJCM6dOFu3NfAi6C4NwHS?= =?iso-8859-1?Q?4tRt6vtD7FQ6Vb3S+yo1cBUe1oNr0b687ZEUQQvlgeZj8+U5E+clVJOu5+?= =?iso-8859-1?Q?VzhijVYo0hk/QqvBni6/oWrCOJG4qBftJvGnMeoJ7BGgp2XnCup1MQjZ1O?= =?iso-8859-1?Q?5kKnVp6bj+?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44e1f509-6eee-40e7-b548-08d8f3753408 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 12:13:18.1884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ex1tYwPDD9f04kOBAnx1mn0O9CNYPbovN7a0ViEw2sukKsh30k95ovyOQblaAONYptJwmA+BLER6ri+YPbTOow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2380 Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 12:13:27 -0000 Hi guys, The text in 7950 doesn't mention anything about semantics in the descriptio= n. That is part of what made me feel it isn't accurate or complete. It also doesn't mention constraints like range or pattern. It only mentions= the type. Jason > -----Original Message----- > From: Martin Bj=F6rklund > Sent: Tuesday, March 30, 2021 2:10 AM > To: j.schoenwaelder@jacobs-university.de > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > netmod@ietf.org > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning= - > 02 >=20 > Juergen Schoenwaelder wrote: > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - > CA/Ottawa) wrote: > > > Hi all, > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules for con= fig > false and output data" of https://tools.ietf.org/html/draft-ietf-netmod- > yang-module-versioning-02. > > > > > > Here are some suggestions (mostly just editorial - I agree with the > general spirit of what's in here). > > > > > > (A) Valuespace > > > > > > Valuespace is defined in module versioning 02: > > > o Valuespace: The valuespace of a leaf or leaf-list is the set of > > > values that the schema node may have according to the type and > > > constraint statements of the YANG model. > > > > > > It seems to be a more complete definition than "value space" in RFC79= 50 > (which doesn't seem to take into account "range", "pattern", etc > statements): > > > > > > o value space: For a data type; the set of values permitted by th= e > > > > > > data type. For a leaf or leaf-list instance; the value space o= f > > > > > > its data type. > > > > > > Should we mention that this definition replaces/supercedes that of 79= 50 > (at least for the scope of the module versioning doc) ? > > > > Please no. RFC 7950 says data type and for me this includes everything > > that defines a type, including the semantics carried in the type's > > description statement. > > > > We do not need to fix what is not broken. Why do we need a new > > definition at all? If definitions in RFC 7950 are broken, then we > > need to fix it in YANG next. >=20 > +1. I don't think the text in RFC 7950 is broken. It is better if > the new document refers to the defintion in RFC 7950, rather than > providing its own defintion with new words. >=20 >=20 > /martin >=20 >=20 >=20 > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 30 08:51:27 2021 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 D57F53A191B for ; Tue, 30 Mar 2021 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF2mFspcTsAL for ; Tue, 30 Mar 2021 08:51:20 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60093.outbound.protection.outlook.com [40.107.6.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2983A1918 for ; Tue, 30 Mar 2021 08:51:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A1/Lz/G//P3dXMEpEwCsuCBsL8T4dETrsYw6Uab50CpM2oxG6tePrnHNe4ytDmat46e4oh0j0+r0cgZeKJKV7OC3wBlD2mdxkm7BjWJqgwRoT7EaHG1axdPoV6Zu9WItp99a2dJ074ACD7pPG+XZVIaAtvv8QEtjfYTOqJ4Aw7d6OG0yoF4Gi7ZCVfF5j+/lL1dmh4NJqH/Eu3PCVqg35mgIwFCfPsVRS7T8e+hEOsTPYfbWkr17GfnAnnlk31uQc2JLoh9sz5pXLqSnlrAnPJ4OHNFufG3iJOKpiGv0JFBLOQxa/nzxhYImkFHyxbOFXRqOGhGw4vgRBrfR4Chuvg== 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=ndffzaE/YrX+WCfCfHs4sRETJp6M4oErSnb5UVlXef0=; b=aZjURyjWwLBTx9BxBqijCWCUZNnvz4CBebI7stVm1SuZlrgxOJiGGGRiqqSC8EDtJGo5AnKz5iK9tvRHtXPnKSpDjNBujiHCw6LsnFZjL/JDIPmpn6rie+9mtPpvmVRz7cKA6pv9Y4gtFRAQDB/rf5sCrO3YETeQeyGZXhjS19pCSPgAYVnoQNqERHkSk8/6ltiOOmdwe2k2fYzhRPWae8fr11uugovtQuWZ1PJOjDbAo3J9M3qa8ukK9TLcaFvZVzy3a5AEM9a13mg6WjlWoffqSQ3dgz9X1ql3YPKBFGTfr6mYaaoQZlowWqW3kSXsLUzA/yUJ/QFy1wrPql4/vw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ndffzaE/YrX+WCfCfHs4sRETJp6M4oErSnb5UVlXef0=; b=QPhsT41eXiYSjEDU14e67IedUncDwWvfz/+7pjZtE6ENBA4JARMIpC4nZMU3G/q4vo8jen70pa972QpB0sm1KTEjfD7138qLZdutO/+IYreyXYU6wq7WgoTlXbWiW8N+bKjatAF9XSH5Hb5j40PLPaSgPNbBmKDzJ3XTA14AJu0= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5701.eurprd07.prod.outlook.com (2603:10a6:20b:2c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.16; Tue, 30 Mar 2021 15:51:16 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3999.021; Tue, 30 Mar 2021 15:51:15 +0000 From: tom petch To: "Sterne, Jason (Nokia - CA/Ottawa)" , =?iso-8859-1?Q?Martin_Bj=F6rklund?= , "j.schoenwaelder@jacobs-university.de" CC: "netmod@ietf.org" Thread-Topic: [netmod] review of state NBC rules in yang-module-versioning-02 Thread-Index: AdclBSWWxB5xRC8HQSW7x602ImvvWAAIbNmAAAEgMIAADKXxYAAHcRzZ Date: Tue, 30 Mar 2021 15:51:15 +0000 Message-ID: References: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> <20210330.081015.471474254972270522.id@4668.se>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23ad6d4a-79dc-4a62-5ad0-08d8f393a6f6 x-ms-traffictypediagnostic: AM6PR07MB5701: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kte2Rx/+rLCYDxhCGIL7/I6rkdB/KUP+Hhz54RtGd7zH9WwJOY8Yfuv5m5lsDLtunYaHNnc0A1k87gw1rjidM3WbnMHxK2/l7OOlpdk74tkutfpMUChqk7hTyxTsr4FMTm/U/N8eHJhbyr7Xf3A7z4JVebJUBff5NQWdmVjUWo8z+ehUtLqyf4aqMwjleB9JnxgxZVj4fLMb7a5Vh0KNUfbIq/v7l2JvGTaVgd4s5MFXAK+qwFCTrhEZnDrSts7dwOQWOoHfYoF8qGvX1vqr8cviWKa/WrGFykNoSVjPlUX0CoL0AbP4XUGTfUuqlHiAOSw1Zeg/4tBFlGbBzARZxvwRXvfydGyfkabUfdqHPt1JtFc4y+0cZiWfYet8QjttoQG+fl4ZCseLrFHUOilEEZVueXJe9K4NcqONYEBou9Nu1mESZRK8s6tqSlhhaxi0pKYEJ6XoAcArSP4uAEbfWXe5KBfEPin6Ry5CUYqfRtX4y70VQoB34UBKUAcOvX3ShCRZNk+UVJVYQ0Vfrw7xx5Xyoxe1uOwEZInSfuEYOvBkBpRnqoAcjU5N9BMj8AXxi5culpLXJT6IRmryCX9O1PyRuDID6bz/mqDrnns0uwGsot0WI+a7FxpnpgkfcFITWo0Lzq+wdx9eZpG+mC7UL7qDW01IRM0/ytc9jSZJEkSd394aJnZkmMvGH0+r8ZXw4rpDxN3pU7Z48Ao6Y56Mt6/ETi003BB+jPplsaT9Rek= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(39860400002)(346002)(396003)(52536014)(53546011)(66574015)(5660300002)(7696005)(9686003)(55016002)(64756008)(66476007)(83380400001)(110136005)(8676002)(76116006)(91956017)(296002)(71200400001)(66946007)(6506007)(316002)(2906002)(186003)(4326008)(8936002)(26005)(38100700001)(66556008)(966005)(66446008)(478600001)(33656002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?XrzvsrUpIWajj1U8X277Z0JwSFT3ssPzDd5TUqwWufjE6kLeAvZmEs4QQ5?= =?iso-8859-1?Q?ez+34URcsGsI+kLPKp6qBgcT6N1me43GY/UfOz9OJ/s4GY5QlZxvR22Vt0?= =?iso-8859-1?Q?vRmRoEt8di1qPUY3Z8kGk2cvZiLw5DePRFPccSszoMGHaZMem3CWXFIeM7?= =?iso-8859-1?Q?q6EaM6YS7Y3tVqyCXTupeeg+EPoWZxRjLt2UNZCmWfcY1fotFQRmknsiJV?= =?iso-8859-1?Q?UIwGpaGpaCy3R2iEVJh21wBZiBdbV02Etg8myNqFMu+g9FR6nY1+ds5agN?= =?iso-8859-1?Q?hFvX+B583GFFyDOpnUg22IYg0LqJqwzjqAqG+2ZdL6Cco6HJ2a/tXcBMZX?= =?iso-8859-1?Q?mkaJA33yp+PcHko8qmvie1DQvGq0wl3ciMS5gw58aUAHP9mEoEwJgKlZOI?= =?iso-8859-1?Q?6XKBwqtz+ZUU8Ax5TCFQAZtatpgORnn6I+KhJ/27QD2l9wzRtC/T1RNXUd?= =?iso-8859-1?Q?Ec/hsf5dE28qGU2iOBrwxYS+jsy06rQ/1UWVEQ8BuNQnGSw1MDBQ8B23AQ?= =?iso-8859-1?Q?m2vjLlAZFkku9f2r7JptulztgAPvkReKB95tA4F1mJw5ioC9+jmhkbqFpD?= =?iso-8859-1?Q?jY7Vkoz9f207xFCnEhvO19Aadp7R1izxDFdNZnlPnZgmn7VBvNcZPCzHYd?= =?iso-8859-1?Q?tYq6T2qrf34Aaj2x4YRjrJUPf+mBh01Ys2CKdlXcpT3QtVg6lrFVAMXUV3?= =?iso-8859-1?Q?Sf3ulIemMswPnmT6mDga4oDp6BJYTw+k2I6AO0ebfRIFgfQPaPodQC/FrJ?= =?iso-8859-1?Q?VdHMewWAdXc1V651Er/yIip3L606f/6R6uR6norzyDwOL+rFuU02+SZgm+?= =?iso-8859-1?Q?+prETB3hF/Y5W5Sekvp4eKQvIjDoxWmw1mrOL94HWkVo+cddZuPp4p1uZq?= =?iso-8859-1?Q?zLdBIPLYHVkagk/Bg5GNvEZ72i1xGKLb9OMblbnU2PtX5MDF0NP2T5nZ5I?= =?iso-8859-1?Q?//uYn7aNc1oZtPwVsBAW9WSi8vFLOXAZpme81mS24C7rE5XN3047T7hu2I?= =?iso-8859-1?Q?3BVX2I6muFKaUGU3KNQFYhosjyLgRaVmZQEWN99tmegVpI2PRCPrs2l3uY?= =?iso-8859-1?Q?8Pvsey4vCANNrtFVsi39D570Nw/IzfzbdwE9Yvr0GVQTo1ZEx5l70y6A4u?= =?iso-8859-1?Q?WQcrE1+b7WTP384/+rcHBekADjbrBEV8IAnaeP3dfCf6YrnKsJRU4s2PWw?= =?iso-8859-1?Q?qfVdlOsS2j+RShLarP70/npKW4DBtppqQThfz4yEnnN1TpDmIUPs+DPpJT?= =?iso-8859-1?Q?UOED9waLkm4WeTLQ7QBHhEpphIEQ4xrf3U9IVQHpmRn2j6+igSH+hAZGaA?= =?iso-8859-1?Q?XWfYHHmu9aDa2MUm0hG3fVBr5cYQ877xYArO9lyF30L6KK8ft5KUGIVkhT?= =?iso-8859-1?Q?FfGQFLChB/?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23ad6d4a-79dc-4a62-5ad0-08d8f393a6f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 15:51:15.8545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JDkBpt9Hh1ge/QH90KNfl2tjxtPmEBJFCgfhiY017riRuHWsUz2gnuf+hP/B6PN7GBECGb6Ym80QJsPChoHhew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5701 Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 15:51:25 -0000 From: netmod on behalf of Sterne, Jason (Nokia - = CA/Ottawa) =0A= Sent: 30 March 2021 13:13=0A= Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-0= 2=0A= =0A= Hi guys,=0A= =0A= The text in 7950 doesn't mention anything about semantics in the descriptio= n. That is part of what made me feel it isn't accurate or complete.=0A= =0A= It also doesn't mention constraints like range or pattern. It only mentions= the type.=0A= =0A= =0A= I am with Martin and Juergen on this one. You pick on two of the ten subst= atements for type but all are part of the definition of a type and are rele= vant in defining the value space; and elsewhere in the RFC, e.g. decimal64,= there are explicit descriptions of the value space. Whereas if you take, = say, uint32 what more do you need to say to describe the value space?=0A= =0A= Tom Petch=0A= =0A= Jason=0A= =0A= > -----Original Message-----=0A= > From: Martin Bj=F6rklund =0A= > Sent: Tuesday, March 30, 2021 2:10 AM=0A= > To: j.schoenwaelder@jacobs-university.de=0A= > Cc: Sterne, Jason (Nokia - CA/Ottawa) ;=0A= > netmod@ietf.org=0A= > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning= -=0A= > 02=0A= >=0A= > Juergen Schoenwaelder wrote:=0A= > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia -=0A= > CA/Ottawa) wrote:=0A= > > > Hi all,=0A= > > >=0A= > > > I took a look at section "3.1.2 Backwards-compatibility rules for con= fig=0A= > false and output data" of https://tools.ietf.org/html/draft-ietf-netmod-= =0A= > yang-module-versioning-02.=0A= > > >=0A= > > > Here are some suggestions (mostly just editorial - I agree with the= =0A= > general spirit of what's in here).=0A= > > >=0A= > > > (A) Valuespace=0A= > > >=0A= > > > Valuespace is defined in module versioning 02:=0A= > > > o Valuespace: The valuespace of a leaf or leaf-list is the set of= =0A= > > > values that the schema node may have according to the type and= =0A= > > > constraint statements of the YANG model.=0A= > > >=0A= > > > It seems to be a more complete definition than "value space" in RFC79= 50=0A= > (which doesn't seem to take into account "range", "pattern", etc=0A= > statements):=0A= > > >=0A= > > > o value space: For a data type; the set of values permitted by th= e=0A= > > >=0A= > > > data type. For a leaf or leaf-list instance; the value space o= f=0A= > > >=0A= > > > its data type.=0A= > > >=0A= > > > Should we mention that this definition replaces/supercedes that of 79= 50=0A= > (at least for the scope of the module versioning doc) ?=0A= > >=0A= > > Please no. RFC 7950 says data type and for me this includes everything= =0A= > > that defines a type, including the semantics carried in the type's=0A= > > description statement.=0A= > >=0A= > > We do not need to fix what is not broken. Why do we need a new=0A= > > definition at all? If definitions in RFC 7950 are broken, then we=0A= > > need to fix it in YANG next.=0A= >=0A= > +1. I don't think the text in RFC 7950 is broken. It is better if=0A= > the new document refers to the defintion in RFC 7950, rather than=0A= > providing its own defintion with new words.=0A= >=0A= >=0A= > /martin=0A= >=0A= >=0A= >=0A= > >=0A= > > /js=0A= > >=0A= > > --=0A= > > Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany= =0A= > > Fax: +49 421 200 3103 =0A= > >=0A= > > _______________________________________________=0A= > > netmod mailing list=0A= > > netmod@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/netmod=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Tue Mar 30 09:15:48 2021 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 258243A19F4 for ; Tue, 30 Mar 2021 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY77P9Gg0kJi for ; Tue, 30 Mar 2021 09:15:42 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2136.outbound.protection.outlook.com [40.107.223.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3431F3A19F0 for ; Tue, 30 Mar 2021 09:15:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yq7VbFH4OKNDwAv0st1TWoccqj3sTtbFS83Gtgzvjh9P1KTrjoVqeDj3iiZA7gFoZDhhtr7Njr58RMtDPAvsKICcgrVFy1Bkdk+jKk87IC9vV88Dmu6BXI0xth4nOFlUFtilhZqtOoPwLW97Ey9EAzuKdk7L6rbafwMHFDVnE+oIW18Mwoongi6LnQd3etouBB9eD/c3wbwq/zGQTqja2pPBizUmhwaP9ZqScEWlMa1xKU89R1PZTdjxCxgYUmCRiASWMROkUIfbBq5mlcvnS7FY5nxPiDy5tcYTiLE/VFgeTetIa5FabXo0VhD2Ual7FoYE5vXaSDNk/QEdEvOgFA== 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=9LEbipuI5lyKn3xBAdfEIHt/tiQOYX9a6xnPTTYptuo=; b=hUcPZ76Fyl3/+x8F3675zws89OoPmpE+XnGuIGPM/s9EouJL91bZgudetOABKj0vYbHrHc49bxK3peFgyTfPRjpnlZkbpjp2WGR5ACUPyXKY0CHc/vtgwmYo2ylGK1ZFlHRwp+zZV8bPQ/jbOeC5J5ZzGjAVdxrr26cOghSNIHUG3Q+cTiFuf+R8wGtbimZ80bVZ+JCdSzfnC2wL0SVukEoxSqMurYdAGXcB8YXn9cwNz6fCE4NLz3N93RbmLHyCfnFz9kknQSbPB3Rsd1ljvQQMUJxAo3H8VySOlA5OalIrAUBh6esPrngbfOkzqpWqPmZEIFy04P2TSJ0y9QtNMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9LEbipuI5lyKn3xBAdfEIHt/tiQOYX9a6xnPTTYptuo=; b=hychm1mAroNtrxApOMxs3YGws5FRYgADIx1PBBBaW2DLSLyqKL0z1HiZ1F7JmJEbIoO5UQMjxIFgW0MIn1sSoGkLeSMAq+hBAKngozjyJ5SIB8ocNTYapPZkyIMFFkhe6ow1HfQXucCWel2sd557o5IEGjDq0K+6LevDGXULoyU= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB2409.namprd08.prod.outlook.com (2603:10b6:3:71::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.26; Tue, 30 Mar 2021 16:15:40 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 16:15:40 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: tom petch , =?iso-8859-1?Q?Martin_Bj=F6rklund?= , "j.schoenwaelder@jacobs-university.de" CC: "netmod@ietf.org" Thread-Topic: [netmod] review of state NBC rules in yang-module-versioning-02 Thread-Index: AdclBSWWxB5xRC8HQSW7x602ImvvWAAIbNmAAAEgMIAADKXxYAAHcRzZAAC7XuA= Date: Tue, 30 Mar 2021 16:15:40 +0000 Message-ID: References: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> <20210330.081015.471474254972270522.id@4668.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [174.112.3.120] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fba142c9-08bb-4e2f-f834-08d8f3970fdb x-ms-traffictypediagnostic: DM5PR08MB2409: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ++nNT9i2QrF/xvAGoWxpaPp6GgZcvOKN5jv+g2hhChpf2VT2KJ7FVd2zgHL8/mliu8GTC0Ke9JC4csKEstGnBZUHz/p2c38OHoZt/cDh7RhZxO2mK8ab1E4upPjVsGihgQYR8Txbusc2vQFJRSb+nEJ1+38KG1aRDtxhVa1hYYrzEmRMJ648q6YxybuNmvrRNFPM/eQxVjvTtMoH+4tmcdEM7Jd6cu0Lt4LV8J2/00e4GF7IIVvdLmyB3Fk2w5WLJUKpma5eyLi8TrzBYsxUHGo8z5Id+loHQFyQpTafNGFs1+L0kj1i7Kw6/zHegi4LNReUnQlr2eK2vwkOPybn3b1tuFzSteCwGaxB1eznZT4fdRKj4tbUFm/Zd/QAzmEGwfDW8ODpqbxp9tJxLRS3kFnx7lGnAfivV4TtroeSMRD8xCTNFz+Xz8iB2uDavzSHpYb1UEDnlWMSGKZiKUyVvdfx3GpcFnXaLvggKX7adwttcaETbVBL3WdZRK2ARBenUAeVKA6lClrku5AizBZzEFqk0e7VXrrdpg1Z5SR+OxGomW3I0h0aqvvbTJM8fRD1V7esJn2UUc3FGoFzvtbWg5wF5h6ZI+Qu/NRC/SmWVI0gbMDUQ02dQET16Zgjssid2/8z+HrP1Xs20k8vmDNUmaDdkRlRoxzriCPrLdwtTUTCw1EVe2PwR30lrPgXFHLki59RY4MXsbmffoDQKL2HMjEBD8nByiOOrZ3yRr47RH0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(136003)(376002)(39860400002)(396003)(26005)(8676002)(66574015)(5660300002)(71200400001)(66446008)(86362001)(52536014)(478600001)(33656002)(186003)(8936002)(83380400001)(66946007)(64756008)(55016002)(53546011)(4326008)(966005)(2906002)(316002)(66476007)(76116006)(110136005)(7696005)(9686003)(6506007)(296002)(38100700001)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?9HLJ/99i9Hkut/CVl1Yngq/EeYjpLAKZsOSNnst2NRh5oggfnmw49mg8dT?= =?iso-8859-1?Q?Y46BfkXBLAwnoRCqg/bgUkhEml0rEjsRnGE7vCR6L/eENPg1ErZzdX8LGF?= =?iso-8859-1?Q?EDzQKRaE2cSOKWnyIqJeIYJa7FRo+9IqjNBFBfaoFpHxJpiKS91ZP/ypTn?= =?iso-8859-1?Q?uRLi+Wk+N2l7UGXAeCkOfEtbgGuZUuuDsOIEZ+RGITCDw0MhgdKbnraXEe?= =?iso-8859-1?Q?tjmYJoIohgIPwJLG0k0knwGk9hELeAWdui0W+FUWvoD8r5U/YjP/tVhuR/?= =?iso-8859-1?Q?x0I11yfDI3aDfMIMdzM/6Cmip0N492BwPQYXWMOK2LRLCvKuAxeCVGFWcu?= =?iso-8859-1?Q?NOnGwn0zR5QejjJ3E7pHy9O58Z4L5XZSXrCxEVV74ocGokchX0rr4E9CCG?= =?iso-8859-1?Q?O185zhPKqn2xYiS9BjkohVxenbFWbNCTxmb2HxLokpUga+WEu+ElrFINMF?= =?iso-8859-1?Q?7ZfIrdhQVBzTFQbxpixRw3OWL/xL0hZ27+FxLLAQA1XszZk6E9O7tQAacp?= =?iso-8859-1?Q?g2G+8RGnWkxd2L1hHET04yhosGjvUfbg2KUAtuuMed2eRgAeSo+2fmkq4Z?= =?iso-8859-1?Q?yo7EoEt/oDC36Gsv4iobVX6SEXGmfnG5ck3nj4cgRgydhpH2or0C8/Mgny?= =?iso-8859-1?Q?tMeoub8rOHrVy5drumCFDHQdUlotIz98pPT+IsPsSQpBbvnmOLTc9VF0gM?= =?iso-8859-1?Q?ctwb9zhXZCQiuE43Ajs5gvl3Bh55xp6HUAnO7oceN9NKERj35aSuFzz3m6?= =?iso-8859-1?Q?tyql5EkZefvz4ODa3ZzQG46j+TEGleQm4Owa40pbnU6fBqq9gX8VCilI3z?= =?iso-8859-1?Q?66xzXxtHyj6Wizx10fs7gyUxForujda+KNk6xNgX6/ieKcQr2wdJ5cbNCv?= =?iso-8859-1?Q?jc/OUgwxVD+31vEAhuWgJeyoMORIkv2MPzjo/VI2UNJA3d51Cb8ZdWausb?= =?iso-8859-1?Q?NiPJt/i/HmZgOdCWiVzZ6z9p4SemzFKEMuOxGfg7je5bUXR7MNRziAfyBC?= =?iso-8859-1?Q?LoBxGoS/Iz+E8rh8S3DIprQ8EhIIV/1TGCAi2ESwxYKPpRxIiwKkZ745QP?= =?iso-8859-1?Q?CDvQpHbBgaDm0x8uclV8ojV0wr/YbwpksmcqJVQq05Umo7sqJWGnXv5UZm?= =?iso-8859-1?Q?+2k/+FzPIskVNL5ihsVEVhzfI2GR8KXppo9E4eicm4GkqpcUEdAywk226p?= =?iso-8859-1?Q?y+QNt1DlSxQwSqwJnQkMDRTIAfo6My1mYcZCm/69mex0caLJWj+1wxyKhB?= =?iso-8859-1?Q?9lkfKrgIF9LtC5Hvkx0SlyKp4QbepnZbV7izwelQqFPRD7yg9rWVLezgKF?= =?iso-8859-1?Q?RwwIHUQakrghdzADMLEE1e7Qtjw9I/x4gZYEPqg4vv17HE7kKzFB60HWww?= =?iso-8859-1?Q?TRCNOSgsMe?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fba142c9-08bb-4e2f-f834-08d8f3970fdb X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 16:15:40.3161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zviAuJL4uUVgkxPFlW4/7Ea9ynR2foQ2zepFId+etP6HlVL5QfFj1JoK3ESLgLQOI0JlMmtp6CICDSROQmD/9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB2409 Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 16:15:47 -0000 Hi guys, Let's take this model for a leaf (line numbers for reference): 10 leaf foo { 20 type uint8 { 30 range "5..101"; 40 } 50 } When I've been talking about "type" I've only been talking about line 20. = The base type of the leaf. But are you guys considering that the term "type" includes 20 and 30 ? I'm not sure that RFC7950 is terribly clear when it mentions "data type" be= low. Isn't that a bit ambiguous as to whether it includes line 30 or not? In the example above I think the value space is 5..101. Is that correct? But what about a description like this ? 10 leaf bar { 20 type uint8 { 30 range "5..101"; 40 } 50 description "actually only takes values 5..88 in all current suppor= ted implementations"; 60 } That description isn't a substatement of the "type" statement. Is the value= space 5..101 or 5..88 ? Jason > -----Original Message----- > From: tom petch > Sent: Tuesday, March 30, 2021 11:51 AM > To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin > Bj=F6rklund ; j.schoenwaelder@jacobs-university.de > Cc: netmod@ietf.org > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning= - > 02 >=20 > From: netmod on behalf of Sterne, Jason > (Nokia - CA/Ottawa) > Sent: 30 March 2021 13:13 > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning= - > 02 >=20 > Hi guys, >=20 > The text in 7950 doesn't mention anything about semantics in the > description. That is part of what made me feel it isn't accurate or compl= ete. >=20 > It also doesn't mention constraints like range or pattern. It only mentio= ns the > type. >=20 > > I am with Martin and Juergen on this one. You pick on two of the ten > substatements for type but all are part of the definition of a type and a= re > relevant in defining the value space; and elsewhere in the RFC, e.g. > decimal64, there are explicit descriptions of the value space. Whereas i= f you > take, say, uint32 what more do you need to say to describe the value spac= e? >=20 > Tom Petch >=20 > Jason >=20 > > -----Original Message----- > > From: Martin Bj=F6rklund > > Sent: Tuesday, March 30, 2021 2:10 AM > > To: j.schoenwaelder@jacobs-university.de > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > netmod@ietf.org > > Subject: Re: [netmod] review of state NBC rules in yang-module- > versioning- > > 02 > > > > Juergen Schoenwaelder wrote: > > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - > > CA/Ottawa) wrote: > > > > Hi all, > > > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules for c= onfig > > false and output data" of https://tools.ietf.org/html/draft-ietf-netmod= - > > yang-module-versioning-02. > > > > > > > > Here are some suggestions (mostly just editorial - I agree with the > > general spirit of what's in here). > > > > > > > > (A) Valuespace > > > > > > > > Valuespace is defined in module versioning 02: > > > > o Valuespace: The valuespace of a leaf or leaf-list is the set = of > > > > values that the schema node may have according to the type an= d > > > > constraint statements of the YANG model. > > > > > > > > It seems to be a more complete definition than "value space" in > RFC7950 > > (which doesn't seem to take into account "range", "pattern", etc > > statements): > > > > > > > > o value space: For a data type; the set of values permitted by = the > > > > > > > > data type. For a leaf or leaf-list instance; the value space= of > > > > > > > > its data type. > > > > > > > > Should we mention that this definition replaces/supercedes that of > 7950 > > (at least for the scope of the module versioning doc) ? > > > > > > Please no. RFC 7950 says data type and for me this includes everythin= g > > > that defines a type, including the semantics carried in the type's > > > description statement. > > > > > > We do not need to fix what is not broken. Why do we need a new > > > definition at all? If definitions in RFC 7950 are broken, then we > > > need to fix it in YANG next. > > > > +1. I don't think the text in RFC 7950 is broken. It is better if > > the new document refers to the defintion in RFC 7950, rather than > > providing its own defintion with new words. > > > > > > /martin > > > > > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Mar 30 10:22:25 2021 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 5297A3A1BC0 for ; Tue, 30 Mar 2021 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=eF+tDVYf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vS4Y8Jnq 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 5FxbaFVNNF8e for ; Tue, 30 Mar 2021 10:22:18 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203A03A1BBE for ; Tue, 30 Mar 2021 10:22:17 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0227D5C0099; Tue, 30 Mar 2021 13:22:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 30 Mar 2021 13:22:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= XuSb5MuYsMnbLV4Ox4cs2ZjP1rHWMs61scMy3cWb+Zs=; b=eF+tDVYfqpqxKZp6 RbuuT4qsbkMJSODtn6D2zQGUG+ajqcfJQ01H3HoghyqrNHGHMltxVVlHHX7VSOKC lp0zYHEz27r35sN9Y0spK0OvtrPAqByIHdvzzIdmxdHnQdHTU9qL2siJih3JBehk 35VHvmD+mi6GvQ16Vr5/XPHFeHRrdVtnN4pGKQHRwpqG3nbaOfO8ZJjkFgWxFwif wdLsNjFd9KYQIW3cBgaC2H9tl27mdxa26eaEhURkKw9jLTL7xJxiGDYUqzQEVOz+ PndvH+QCwLRhK8KDiHBJifQS230uUV6v+NriBFeJ0r2KNM3/VfyByt4zQzcvJkki DM8ZNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XuSb5MuYsMnbLV4Ox4cs2ZjP1rHWMs61scMy3cWb+ Zs=; b=vS4Y8JnqdJkQ6qXzOtjbkAx2YRVI2k8uR9anEtdCdDmBaHQ7z1L99JrDv EQXDNB0io7f3a8zDmPGkKoiDZwQP3sTJ4DFKs42HB6zD5lwYGDDOCOLnnxyw1Pgn o1mY9ea5Mj+DC1sedE8AS/aKjgUc7GvrLlj4F+DJE6t8Z8x/nvJ2BiMBVDqglhui recoRMFGG1YX9jC+NsgmnWKbg/xEBN5ovGznyNa07KiC8RVcMLc0DeJVOPR3yN6d vNFDuis+cQbSSHsscbFkjbuzl4voz/HWNRClXWlKeI4mT44dAWbzI2smsUzEZ1lb GKoUaeUkd6djqzK24GtVEXJyIrKeQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeitddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth hqredtredtudenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeeitdethfdthfekteelte ekveeifefhudduueekvdefleegtdevgefgteefjefgleenucfkphepudehkedrudejgedr gedrvdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id CB66224005C; Tue, 30 Mar 2021 13:22:12 -0400 (EDT) Date: Tue, 30 Mar 2021 19:22:10 +0200 (CEST) Message-Id: <20210330.192210.52793363388988914.id@4668.se> To: jason.sterne@nokia.com Cc: ietfc@btconnect.com, mbj+ietf@4668.se, j.schoenwaelder@jacobs-university.de, netmod@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 17:22:23 -0000 Hi, "Sterne, Jason (Nokia - CA/Ottawa)" wrote: > Hi guys, > = > Let's take this model for a leaf (line numbers for reference): > = > 10 leaf foo { > 20 type uint8 { > 30 range "5..101"; > 40 } > 50 } > = > When I've been talking about "type" I've only been talking about > line 20. The base type of the leaf. > = > But are you guys considering that the term "type" includes 20 and 30 > ? Yes; the definition in RFC 7950 is: o value space: For a data type; the set of values permitted by the data type. For a leaf or leaf-list instance; the value space of its data type. So line 20 and 30 together defines the set of values permitted byu this type. > I'm not sure that RFC7950 is terribly clear when it mentions "data > type" below. Isn't that a bit ambiguous as to whether it includes > line 30 or not? > = > In the example above I think the value space is 5..101. Is that corre= ct? Yes. > But what about a description like this ? > = > 10 leaf bar { > 20 type uint8 { > 30 range "5..101"; > 40 } > 50 description "actually only takes values 5..88 in all current = supported implementations"; > 60 } > = > That description isn't a substatement of the "type" statement. Is > the value space 5..101 or 5..88 ? Perhaps a better example is inet:uri from RFC 6991, which is defined as: typedef uri { type string; description "The uri type represents a Uniform Resource Identifier (URI) as defined by STD 66. Objects using the uri type MUST be in US-ASCII encoding, and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary percent-encoding is removed, and all case-insensitive characters are set to lowercase except for hexadecimal digits, which are normalized to uppercase as described in Section 6.2.2.1. The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient to provide uniqueness. Two URIs that are textually distinct after this normalization may still be equivalent. Objects using the uri type may restrict the schemes that they permit. For example, 'data:' and 'urn:' schemes might not be appropriate. A zero-length URI is not a valid URI. This can be used to express 'URI absent' where required. In the value set and its semantics, this type is equivalent to the Uri SMIv2 textual convention defined in RFC 5017."; reference "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax RFC 3305: Report from the Joint W3C/IETF URI Planning Interest= Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations RFC 5017: MIB Textual Conventions for Uniform Resource Identifiers (URIs)"; } The value space is all legal URIs, even though there is no pattern defined. An implementation may hook up a standard uri parser to objects of this type. Are we discussing a real problem here? /martin > = > Jason > = > > -----Original Message----- > > From: tom petch > > Sent: Tuesday, March 30, 2021 11:51 AM > > To: Sterne, Jason (Nokia - CA/Ottawa) ; Mar= tin > > Bj=F6rklund ; j.schoenwaelder@jacobs-university.d= e > > Cc: netmod@ietf.org > > Subject: Re: [netmod] review of state NBC rules in yang-module-vers= ioning- > > 02 > > = > > From: netmod on behalf of Sterne, Jason > > (Nokia - CA/Ottawa) > > Sent: 30 March 2021 13:13 > > Subject: Re: [netmod] review of state NBC rules in yang-module-vers= ioning- > > 02 > > = > > Hi guys, > > = > > The text in 7950 doesn't mention anything about semantics in the > > description. That is part of what made me feel it isn't accurate or= complete. > > = > > It also doesn't mention constraints like range or pattern. It only = mentions the > > type. > > = > > > > I am with Martin and Juergen on this one. You pick on two of the t= en > > substatements for type but all are part of the definition of a type= and are > > relevant in defining the value space; and elsewhere in the RFC, e.g= .= > > decimal64, there are explicit descriptions of the value space. Whe= reas if you > > take, say, uint32 what more do you need to say to describe the valu= e space? > > = > > Tom Petch > > = > > Jason > > = > > > -----Original Message----- > > > From: Martin Bj=F6rklund > > > Sent: Tuesday, March 30, 2021 2:10 AM > > > To: j.schoenwaelder@jacobs-university.de > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > > netmod@ietf.org > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > versioning- > > > 02 > > > > > > Juergen Schoenwaelder wrot= e: > > > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia = - > > > CA/Ottawa) wrote: > > > > > Hi all, > > > > > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules= for config > > > false and output data" of https://tools.ietf.org/html/draft-ietf-= netmod- > > > yang-module-versioning-02. > > > > > > > > > > Here are some suggestions (mostly just editorial - I agree wi= th the > > > general spirit of what's in here). > > > > > > > > > > (A) Valuespace > > > > > > > > > > Valuespace is defined in module versioning 02: > > > > > o Valuespace: The valuespace of a leaf or leaf-list is th= e set of > > > > > values that the schema node may have according to the t= ype and > > > > > constraint statements of the YANG model. > > > > > > > > > > It seems to be a more complete definition than "value space" = in > > RFC7950 > > > (which doesn't seem to take into account "range", "pattern", etc > > > statements): > > > > > > > > > > o value space: For a data type; the set of values permitt= ed by the > > > > > > > > > > data type. For a leaf or leaf-list instance; the value= space of > > > > > > > > > > its data type. > > > > > > > > > > Should we mention that this definition replaces/supercedes th= at of > > 7950 > > > (at least for the scope of the module versioning doc) ? > > > > > > > > Please no. RFC 7950 says data type and for me this includes eve= rything > > > > that defines a type, including the semantics carried in the typ= e's > > > > description statement. > > > > > > > > We do not need to fix what is not broken. Why do we need a new > > > > definition at all? If definitions in RFC 7950 are broken, then= we > > > > need to fix it in YANG next. > > > > > > +1. I don't think the text in RFC 7950 is broken. It is better = if > > > the new document refers to the defintion in RFC 7950, rather than= > > > providing its own defintion with new words. > > > > > > > > > /martin > > > > > > > > > > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > > > Fax: +49 421 200 3103 > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > = > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Tue Mar 30 11:47:45 2021 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 1D0063A1CD1 for ; Tue, 30 Mar 2021 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9ywZ8RHZ5nV for ; Tue, 30 Mar 2021 11:47:39 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2108.outbound.protection.outlook.com [40.107.236.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC6D3A1E21 for ; Tue, 30 Mar 2021 11:47:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YbWGAdO3KSrkkv2WGsZgeUyd3IzgdrPm5k8Wl8Ud8r/iMpGdCUFXqQf9B2GtROMcy/+OlBcF+lGh6x17+uBNsOnXRARXjdX1Z0/XVj0ppgD92CvCKTnpae/uahzjccXCHW6kfwJik61QWlKpiIUK/z+AeuwFv0SldyHcAIl+HkamXBK1D6dkO+ITp7zw4O2eGhrHsp1y5vG6LVV9lx7Q947v+Yxh/AEZ8YjGbIPPUAhlJFu99bcEFVbB9aTfum6JKSLuJBtmecM7U9eWEO6KMHA3jgcsFbwpQN71zTOHKCKqYjuOcrYYK64wtcivZG8BXWeg2FX+UpS5j4HWjB7YDQ== 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=d4dNsw/Q/oxdsYi36eqRAlKTZe5BgCdnxKEvMqZvJzg=; b=b7FuPBFKMi8L62kHinM2HrenGK2IwYgeKXY4VA7y/1by0iNGii5duJ0fjc7bgm+rOUq5kjLc5VaHRpslkWq96uxW5Y7qyQCwxxGtxDgcfjAi3kK2dPNnIp850ZNngMWW4WzefyR+M8rPk6lhvau3A01gcZdSK0FgYMt1aLRqO06+1gHKshfDdD8FLb175PfRreyrOEMNuCVHeJUzTFlVBaF4tFGvqYS6Kr97h0ja3rXbnx68y/RPbrYsMNBZbGiaD2ToMIXF4ZAGvuAHwrV3PQyGvjtu4I9fX/2QW3Dx2O34j1+Castioz9RcvRZw4sgy8a8WlA06SwjsrdNfXG6sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d4dNsw/Q/oxdsYi36eqRAlKTZe5BgCdnxKEvMqZvJzg=; b=RFHrxDXggdfwrT/Tt+R5/t3wOzb5jUEP0mOZvL4qAGsEl6c0aBYpBJOGRRd6ZVNIoh96zofokdfINIq1jBZPjNVE021jl4TZeVNmSlWm1nX1IjwgjRbS9mjkZo4LxfsYyQPny0kTazoVcbs9cJpD90G6HcsPr0Fd8cKv0VeoVy8= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM5PR08MB3513.namprd08.prod.outlook.com (2603:10b6:4:68::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.26; Tue, 30 Mar 2021 18:47:35 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::4c19:5c12:5ed6:96df%4]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 18:47:35 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= CC: "ietfc@btconnect.com" , "j.schoenwaelder@jacobs-university.de" , "netmod@ietf.org" Thread-Topic: [netmod] review of state NBC rules in yang-module-versioning-02 Thread-Index: AdclBSWWxB5xRC8HQSW7x602ImvvWAAIbNmAAAEgMIAADKXxYAAHcRzZAAC7XuAAAqT8AAAC08oA Date: Tue, 30 Mar 2021 18:47:35 +0000 Message-ID: References: <20210330.192210.52793363388988914.id@4668.se> In-Reply-To: <20210330.192210.52793363388988914.id@4668.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=nokia.com; x-originating-ip: [174.112.3.120] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6fbdde88-a72b-4c57-5d8b-08d8f3ac48de x-ms-traffictypediagnostic: DM5PR08MB3513: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ztAdPcb2RC0hO14RXxJnhb3NA78fddrnEb80DIHqKsnm0lIkj+Z1JHVw0LLAFff5te+KRtGVmLiWDQWzRzwqn9dFDSm7U4n/yh8Xjss9S8DnmHqJqFO6YxAJz2rMAlUefUzbDKAQfvs3y8f2E4nFhIox1S4a12uCAZlRu+JafwsmRI/c0UsJSiNBx7OeT+dgnjMp06dDyHsaxgC7W7UR80CY5ItkfAZLywWLvx1NsvW5idItI86QFKr5QTIQaLl02mh6pZKLxnY26S0g7PTlNSJw+wM3cxH3xo+Dk4acipGN3FEllJF+ypSD3G+ZbM1NKvPraPqHl8G2uszppXkrcD8nSW/potZ/V3oGbbgZkjH0aMjJs+m3X3HkBTowBg0V0pUiIUvC+HechWLqUeroyY8hwBXEE75r9qBaOMJs8/Yd51vYK0JPbB5iDZiT4guQ7pbvOCTGei06BiMLb3DqxXXX2HeINbJ2MzUE6iFkFsUcsNO2tEr7/ykUcWNWyuReSGrJqbYqL3M1Om9AeGC96WpH9+kjME4ZNGocY/KKS+elbcoWcFFsTnGEK8VeTbXSGAzaT97fnx0GyOk6/4XGYbsqZ2Bd4tc90E/eYBOB8sRVHFfL3qnm0bjgPBd+SkXUQ9KFnbGlO6YTVO+JNqMMsrsTdAWUy9/sQjcAHZSkN6v96yblHKkd5wIZ5qhHXDyrNN0rBUEq1f9/STrqBtaFlhpXONJFnv0T9Y/V5oQaRPs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(136003)(396003)(366004)(346002)(26005)(54906003)(478600001)(8676002)(8936002)(9686003)(66476007)(53546011)(6506007)(55016002)(71200400001)(966005)(4326008)(2906002)(66946007)(83380400001)(52536014)(38100700001)(86362001)(186003)(33656002)(66574015)(5660300002)(76116006)(64756008)(7696005)(66446008)(66556008)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?YDTNlflSsefDOfA0m//RrPP7F9fJG+CLropJSY0f8ZZ0/nmxrHmoXdxCxq?= =?iso-8859-1?Q?RCVw6kNUzGRO3toec2pJUnGDzmdQs5j6x8wj6RjQjMuPUdAjyyxvnd6TMG?= =?iso-8859-1?Q?GIfuj0Y8uuSiiPLJ795JPCgULtgQExDIy2SFxA5eimeuK5akziJEv+Okot?= =?iso-8859-1?Q?ujDVU2SrOK2QWLej+aXQ6kW6I7BbujqEC3X1tIUzCIYRDJrHKquPzA3EHC?= =?iso-8859-1?Q?+1rttAEFsSNqIxV+qkv9vfgRFPQclkzd2Q4W/oieN6vMJ2/xyZhtN1pdlE?= =?iso-8859-1?Q?/7hFzuylOP3PZZMwazxIJqb9ZRDI/grf7ert0SehraSCTd+IvzAB9BSNT8?= =?iso-8859-1?Q?I7q50/wdWfA893DndWYHHyEqJg9eHdksplh9OhHhK4hkKl0ccW9l8GdvXt?= =?iso-8859-1?Q?Q5x9g3yamULw4gwTEj/qi78VYPCr2zjCo6cYhCv+wMzyMfBpeCR2HKdisP?= =?iso-8859-1?Q?fXmVtK4+jYZjvWCWrE+qKrCQ85qQiuLe0r9Iz5T71uBsT0jQR6TsF71YWS?= =?iso-8859-1?Q?y9xhzPnqcVaR6orGBogFu4IXJpyV87+L+Tk5Gj1eRHpnd495q3fxhOsMVa?= =?iso-8859-1?Q?erGhSfQg+gEDP3yIWWpHa3r/DLpKxQ2UacvqG1vy/UhqlAqPDFLAuh/IbB?= =?iso-8859-1?Q?m2rG811+LlFjvRGzk+XDdgk3kGQ9x0/7DGgqfFKbRp2sbIrU9HC3R7wrwg?= =?iso-8859-1?Q?8SmQCa2ecNRoCK/UH1jVOwFL3NkdzT2N5dvcXAsy1ivzkXg+HTCY46zEoG?= =?iso-8859-1?Q?XOCIdKtEJDhPBXhCsRvvyPkN0i5ZskDZ2S9XosvLV2yJvH1WHrgD/VSDMo?= =?iso-8859-1?Q?R3j/Z0AT4+JAOyxXlnYIaoNpVOiyVEE3gT6Dzy7lpaVEaRPAb9nhqBsaNe?= =?iso-8859-1?Q?QIqUC/ukhFE12r+k1bJ9GA3bYkpW7t7OfNKgQUkfQhGX3MRJZWhpNnzPhu?= =?iso-8859-1?Q?5r6ZuHqg7vN19cfRr//LlbJ554Eo3PtemkSjqzJucyMqAa2yci+B5XIkTK?= =?iso-8859-1?Q?dl97axPHvosThejGPveqJ3fW7JK0kO+3G9KZCI5mZgTKONOCPGTsPifoD+?= =?iso-8859-1?Q?OeDLfD3RJUSmZj0ipW8pw9/hSeBZnQF65av2qecVMl2KX1PrwhR7PWjjq0?= =?iso-8859-1?Q?kW5twkh3pEW28woPmNHvTcPW3UGCwK2MGChOd+u8atEwMqTykAGPk6kzXU?= =?iso-8859-1?Q?CnMJKywDCWdpDDkVc12j56wRQpQiHC5L5DcsSx8AxtOTge5nt6ESzQs7HU?= =?iso-8859-1?Q?WACk8f5FF9kKiiYFZpieStqM27A0mrwERaqV7mJF7gENi+gCBAToo8DGcw?= =?iso-8859-1?Q?S4pZA6jvopebkufl0hCuLGoenDppwo+LgJwJzM266qojRVAHl8Y3sxSkDi?= =?iso-8859-1?Q?lhsTRaCAin?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6fbdde88-a72b-4c57-5d8b-08d8f3ac48de X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2021 18:47:35.4392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CXofHSU6jRqDe9xfVH7AukRkx84krtGQhhfAjU7Yb/8nsJaLr6bZiIQX7Xl8BdJsJ1K5nliR+21KcB2ACw2uRg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR08MB3513 Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 18:47:44 -0000 Thanks Martin. Maybe I'm in the minority thinking the definition in RFC7950 is slightly am= biguous. If anyone else thinks it might be, then let us know. Otherwise I'm= fine to just stick with the 7950 definition. That example in 6991 is a typedef which has a description statement. But a = leaf that doesn't use a typedef may have a description for the leaf (not pa= rt of the type) that affects the value space.=20 Jason > -----Original Message----- > From: Martin Bj=F6rklund > Sent: Tuesday, March 30, 2021 1:22 PM > To: Sterne, Jason (Nokia - CA/Ottawa) > Cc: ietfc@btconnect.com; mbj+ietf@4668.se; j.schoenwaelder@jacobs- > university.de; netmod@ietf.org > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning= - > 02 >=20 > Hi, >=20 > "Sterne, Jason (Nokia - CA/Ottawa)" wrote: > > Hi guys, > > > > Let's take this model for a leaf (line numbers for reference): > > > > 10 leaf foo { > > 20 type uint8 { > > 30 range "5..101"; > > 40 } > > 50 } > > > > When I've been talking about "type" I've only been talking about > > line 20. The base type of the leaf. > > > > But are you guys considering that the term "type" includes 20 and 30 > > ? >=20 > Yes; the definition in RFC 7950 is: >=20 > o value space: For a data type; the set of values permitted by the > data type. For a leaf or leaf-list instance; the value space of > its data type. >=20 > So line 20 and 30 together defines the set of values permitted byu > this type. >=20 > > I'm not sure that RFC7950 is terribly clear when it mentions "data > > type" below. Isn't that a bit ambiguous as to whether it includes > > line 30 or not? > > > > In the example above I think the value space is 5..101. Is that correct= ? >=20 > Yes. >=20 > > But what about a description like this ? > > > > 10 leaf bar { > > 20 type uint8 { > > 30 range "5..101"; > > 40 } > > 50 description "actually only takes values 5..88 in all current su= pported > implementations"; > > 60 } > > > > That description isn't a substatement of the "type" statement. Is > > the value space 5..101 or 5..88 ? >=20 > Perhaps a better example is inet:uri from RFC 6991, which is defined > as: >=20 > typedef uri { > type string; > description > "The uri type represents a Uniform Resource Identifier > (URI) as defined by STD 66. >=20 > Objects using the uri type MUST be in US-ASCII encoding, > and MUST be normalized as described by RFC 3986 Sections > 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary > percent-encoding is removed, and all case-insensitive > characters are set to lowercase except for hexadecimal > digits, which are normalized to uppercase as described in > Section 6.2.2.1. >=20 > The purpose of this normalization is to help provide > unique URIs. Note that this normalization is not > sufficient to provide uniqueness. Two URIs that are > textually distinct after this normalization may still be > equivalent. >=20 > Objects using the uri type may restrict the schemes that > they permit. For example, 'data:' and 'urn:' schemes > might not be appropriate. >=20 > A zero-length URI is not a valid URI. This can be used to > express 'URI absent' where required. >=20 > In the value set and its semantics, this type is equivalent > to the Uri SMIv2 textual convention defined in RFC 5017."; > reference > "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax > RFC 3305: Report from the Joint W3C/IETF URI Planning Interest > Group: Uniform Resource Identifiers (URIs), URLs, > and Uniform Resource Names (URNs): Clarifications > and Recommendations > RFC 5017: MIB Textual Conventions for Uniform Resource > Identifiers (URIs)"; > } >=20 > The value space is all legal URIs, even though there is no pattern > defined. An implementation may hook up a standard uri parser to > objects of this type. >=20 > Are we discussing a real problem here? >=20 >=20 >=20 > /martin >=20 >=20 > > > > Jason > > > > > -----Original Message----- > > > From: tom petch > > > Sent: Tuesday, March 30, 2021 11:51 AM > > > To: Sterne, Jason (Nokia - CA/Ottawa) ; > Martin > > > Bj=F6rklund ; j.schoenwaelder@jacobs-university.de > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > versioning- > > > 02 > > > > > > From: netmod on behalf of Sterne, Jason > > > (Nokia - CA/Ottawa) > > > Sent: 30 March 2021 13:13 > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > versioning- > > > 02 > > > > > > Hi guys, > > > > > > The text in 7950 doesn't mention anything about semantics in the > > > description. That is part of what made me feel it isn't accurate or > complete. > > > > > > It also doesn't mention constraints like range or pattern. It only me= ntions > the > > > type. > > > > > > > > > I am with Martin and Juergen on this one. You pick on two of the ten > > > substatements for type but all are part of the definition of a type a= nd are > > > relevant in defining the value space; and elsewhere in the RFC, e.g. > > > decimal64, there are explicit descriptions of the value space. Where= as if > you > > > take, say, uint32 what more do you need to say to describe the value > space? > > > > > > Tom Petch > > > > > > Jason > > > > > > > -----Original Message----- > > > > From: Martin Bj=F6rklund > > > > Sent: Tuesday, March 30, 2021 2:10 AM > > > > To: j.schoenwaelder@jacobs-university.de > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > > > netmod@ietf.org > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > > versioning- > > > > 02 > > > > > > > > Juergen Schoenwaelder > wrote: > > > > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - > > > > CA/Ottawa) wrote: > > > > > > Hi all, > > > > > > > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules f= or > config > > > > false and output data" of https://tools.ietf.org/html/draft-ietf-ne= tmod- > > > > yang-module-versioning-02. > > > > > > > > > > > > Here are some suggestions (mostly just editorial - I agree with= the > > > > general spirit of what's in here). > > > > > > > > > > > > (A) Valuespace > > > > > > > > > > > > Valuespace is defined in module versioning 02: > > > > > > o Valuespace: The valuespace of a leaf or leaf-list is the = set of > > > > > > values that the schema node may have according to the typ= e and > > > > > > constraint statements of the YANG model. > > > > > > > > > > > > It seems to be a more complete definition than "value space" in > > > RFC7950 > > > > (which doesn't seem to take into account "range", "pattern", etc > > > > statements): > > > > > > > > > > > > o value space: For a data type; the set of values permitted= by the > > > > > > > > > > > > data type. For a leaf or leaf-list instance; the value s= pace of > > > > > > > > > > > > its data type. > > > > > > > > > > > > Should we mention that this definition replaces/supercedes that= of > > > 7950 > > > > (at least for the scope of the module versioning doc) ? > > > > > > > > > > Please no. RFC 7950 says data type and for me this includes > everything > > > > > that defines a type, including the semantics carried in the type'= s > > > > > description statement. > > > > > > > > > > We do not need to fix what is not broken. Why do we need a new > > > > > definition at all? If definitions in RFC 7950 are broken, then w= e > > > > > need to fix it in YANG next. > > > > > > > > +1. I don't think the text in RFC 7950 is broken. It is better if > > > > the new document refers to the defintion in RFC 7950, rather than > > > > providing its own defintion with new words. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > Fax: +49 421 200 3103 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Tue Mar 30 12:06:51 2021 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 11B3C3A1EC8 for ; Tue, 30 Mar 2021 12:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwH1DGbCe8eT for ; Tue, 30 Mar 2021 12:06:44 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DF93A1EC5 for ; Tue, 30 Mar 2021 12:06:44 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id n138so25412948lfa.3 for ; Tue, 30 Mar 2021 12:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6qKiSuNK6iJP92LfyCafKm1k4NY3gt2Ju3xURURhb9g=; b=cUKSckoLZbYPrGYVS4+9/8BmRuL3LeMg0ymEB4Snlr4SKFKyFYvB50CbBnzG59jkQF A0Uqg+n9eCKOfmWx8SGjU6462mnSQgsdkcf6uw2d4+f5l2d/vB0f1fGxlcPTpyCZB2V9 YXOCfeP9tX1D8EEKLxSuqYrozkxQLasPsTWkvjOQrvqYUi5OeRd1kK0E15DQk15oYIS+ nbnDkC2JWYiGkFu7f51cqm9VOZXTfnGm0nSkZs1J715cKPr22qcF6ItuvfZXYTHEt3SU Yw+y9BCHfifaBUEpKI6XGZNCrxV5kv/xVQW3AujIngtaKtnIq+Eo0xuU4C6jLEKEfr7g w0jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6qKiSuNK6iJP92LfyCafKm1k4NY3gt2Ju3xURURhb9g=; b=mTGQAhj8/mgRe5mqSy9cMarJPWaevgdollSG287xTjXjyDiJJBUOpF0cmiCRV1V0Zj qxzVC4KxGLv9eS7VDPcRKDhguKTA8DR+bqVjPGDjXDjYqdMSF/SlZIdps7Odpk/y97v5 +P3s2H1y4s/a8P39M9TB9JeBiEF3Y4esUQDayjddx9U1bNwJyn0t83mrxpKkd6V8AM30 lDWhp6o6qH4BCsQy0dNoFV4VMIrck93K4iMIqvNOO9W3x6bRsZhwCI4d1GcCgIuJG2Fz UV6GyxG9tHlsFNeFoVe7ViiiceaxnSUoi5U6YP+M7FHVmejq9ZwxCgfQZXetBXfcbSjf IG1g== X-Gm-Message-State: AOAM5315IMGt+43Lzj3WVulC7kMTiGFFNyoqLNdkaJnYvYRrJBjl22I8 Nm354rU6UA1H2bmR6TgPNUEBn+YW5WfbE3J95x6u3A== X-Google-Smtp-Source: ABdhPJyEBo4N3VUz5ivRnCNNO5i4hPKMmQ+8jx8NopKze3HWlaOVYmVaN/PHHX/aZRaO+Ujpl/8sQTBpnxbWl//NEfA= X-Received: by 2002:ac2:434d:: with SMTP id o13mr20379969lfl.478.1617131201528; Tue, 30 Mar 2021 12:06:41 -0700 (PDT) MIME-Version: 1.0 References: <20210330.192210.52793363388988914.id@4668.se> In-Reply-To: <20210330.192210.52793363388988914.id@4668.se> From: Andy Bierman Date: Tue, 30 Mar 2021 12:06:30 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: "Sterne, Jason (Nokia - CA)" , NetMod WG Content-Type: multipart/alternative; boundary="000000000000d29c3305bec5b27e" Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 19:06:50 -0000 --000000000000d29c3305bec5b27e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2021 at 10:22 AM Martin Bj=C3=B6rklund w= rote: > Hi, > > "Sterne, Jason (Nokia - CA/Ottawa)" wrote: > > Hi guys, > > > > Let's take this model for a leaf (line numbers for reference): > > > > 10 leaf foo { > > 20 type uint8 { > > 30 range "5..101"; > > 40 } > > 50 } > > > > When I've been talking about "type" I've only been talking about > > line 20. The base type of the leaf. > > > > But are you guys considering that the term "type" includes 20 and 30 > > ? > > Yes; the definition in RFC 7950 is: > > o value space: For a data type; the set of values permitted by the > data type. For a leaf or leaf-list instance; the value space of > its data type. > > So line 20 and 30 together defines the set of values permitted byu > this type. > > I think RFC 7950 is clear in this regard. What concerns me is the idea that a "new YANG" can be defined that overrides RFC 7950 (in any way) without actually updating the YANG version number, or without any formal development of a new YANG language version. > I'm not sure that RFC7950 is terribly clear when it mentions "data > > type" below. Isn't that a bit ambiguous as to whether it includes > > line 30 or not? > > > > In the example above I think the value space is 5..101. Is that correct= ? > > Yes. > > > But what about a description like this ? > > > > 10 leaf bar { > > 20 type uint8 { > > 30 range "5..101"; > > 40 } > > 50 description "actually only takes values 5..88 in all current > supported implementations"; > > 60 } > > > > That description isn't a substatement of the "type" statement. Is > > the value space 5..101 or 5..88 ? > > Perhaps a better example is inet:uri from RFC 6991, which is defined > as: > > typedef uri { > type string; > description > "The uri type represents a Uniform Resource Identifier > (URI) as defined by STD 66. > > Objects using the uri type MUST be in US-ASCII encoding, > and MUST be normalized as described by RFC 3986 Sections > 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary > percent-encoding is removed, and all case-insensitive > characters are set to lowercase except for hexadecimal > digits, which are normalized to uppercase as described in > Section 6.2.2.1. > > The purpose of this normalization is to help provide > unique URIs. Note that this normalization is not > sufficient to provide uniqueness. Two URIs that are > textually distinct after this normalization may still be > equivalent. > > Objects using the uri type may restrict the schemes that > they permit. For example, 'data:' and 'urn:' schemes > might not be appropriate. > > A zero-length URI is not a valid URI. This can be used to > express 'URI absent' where required. > > In the value set and its semantics, this type is equivalent > to the Uri SMIv2 textual convention defined in RFC 5017."; > reference > "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax > RFC 3305: Report from the Joint W3C/IETF URI Planning Interest > Group: Uniform Resource Identifiers (URIs), URLs, > and Uniform Resource Names (URNs): Clarifications > and Recommendations > RFC 5017: MIB Textual Conventions for Uniform Resource > Identifiers (URIs)"; > } > > The value space is all legal URIs, even though there is no pattern > defined. An implementation may hook up a standard uri parser to > objects of this type. > > Are we discussing a real problem here? > > No, because it is clear that description-stmt semantics are just as normative as a pattern-stmt semantics or range-stmt semantics, etc. > > /martin > > Andy > > > > > Jason > > > > > -----Original Message----- > > > From: tom petch > > > Sent: Tuesday, March 30, 2021 11:51 AM > > > To: Sterne, Jason (Nokia - CA/Ottawa) ; Marti= n > > > Bj=C3=B6rklund ; j.schoenwaelder@jacobs-university.= de > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] review of state NBC rules in > yang-module-versioning- > > > 02 > > > > > > From: netmod on behalf of Sterne, Jason > > > (Nokia - CA/Ottawa) > > > Sent: 30 March 2021 13:13 > > > Subject: Re: [netmod] review of state NBC rules in > yang-module-versioning- > > > 02 > > > > > > Hi guys, > > > > > > The text in 7950 doesn't mention anything about semantics in the > > > description. That is part of what made me feel it isn't accurate or > complete. > > > > > > It also doesn't mention constraints like range or pattern. It only > mentions the > > > type. > > > > > > > > > I am with Martin and Juergen on this one. You pick on two of the ten > > > substatements for type but all are part of the definition of a type > and are > > > relevant in defining the value space; and elsewhere in the RFC, e.g. > > > decimal64, there are explicit descriptions of the value space. > Whereas if you > > > take, say, uint32 what more do you need to say to describe the value > space? > > > > > > Tom Petch > > > > > > Jason > > > > > > > -----Original Message----- > > > > From: Martin Bj=C3=B6rklund > > > > Sent: Tuesday, March 30, 2021 2:10 AM > > > > To: j.schoenwaelder@jacobs-university.de > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > > > netmod@ietf.org > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > > versioning- > > > > 02 > > > > > > > > Juergen Schoenwaelder wrote: > > > > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - > > > > CA/Ottawa) wrote: > > > > > > Hi all, > > > > > > > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules > for config > > > > false and output data" of > https://tools.ietf.org/html/draft-ietf-netmod- > > > > yang-module-versioning-02. > > > > > > > > > > > > Here are some suggestions (mostly just editorial - I agree with > the > > > > general spirit of what's in here). > > > > > > > > > > > > (A) Valuespace > > > > > > > > > > > > Valuespace is defined in module versioning 02: > > > > > > o Valuespace: The valuespace of a leaf or leaf-list is the > set of > > > > > > values that the schema node may have according to the typ= e > and > > > > > > constraint statements of the YANG model. > > > > > > > > > > > > It seems to be a more complete definition than "value space" in > > > RFC7950 > > > > (which doesn't seem to take into account "range", "pattern", etc > > > > statements): > > > > > > > > > > > > o value space: For a data type; the set of values permitted > by the > > > > > > > > > > > > data type. For a leaf or leaf-list instance; the value > space of > > > > > > > > > > > > its data type. > > > > > > > > > > > > Should we mention that this definition replaces/supercedes that > of > > > 7950 > > > > (at least for the scope of the module versioning doc) ? > > > > > > > > > > Please no. RFC 7950 says data type and for me this includes > everything > > > > > that defines a type, including the semantics carried in the type'= s > > > > > description statement. > > > > > > > > > > We do not need to fix what is not broken. Why do we need a new > > > > > definition at all? If definitions in RFC 7950 are broken, then w= e > > > > > need to fix it in YANG next. > > > > > > > > +1. I don't think the text in RFC 7950 is broken. It is better if > > > > the new document refers to the defintion in RFC 7950, rather than > > > > providing its own defintion with new words. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000d29c3305bec5b27e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 30, 2021 at 10:22 AM Mart= in Bj=C3=B6rklund <mbj+ietf@4668.s= e> wrote:
Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> wrote: > Hi guys,
>
> Let's take this model for a leaf (line numbers for reference):
>
> 10 leaf foo {
> 20=C2=A0 =C2=A0 =C2=A0 type uint8 {
> 30=C2=A0 =C2=A0 =C2=A0 =C2=A0 range "5..101";
> 40=C2=A0 =C2=A0 =C2=A0 }
> 50 }
>
> When I've been talking about "type" I've only been t= alking about
> line 20.=C2=A0 The base type of the leaf.
>
> But are you guys considering that the term "type" includes 2= 0 and 30
> ?

Yes; the definition in RFC 7950 is:

=C2=A0 =C2=A0o=C2=A0 value space: For a data type; the set of values permit= ted by the
=C2=A0 =C2=A0 =C2=A0 data type.=C2=A0 For a leaf or leaf-list instance; the= value space of
=C2=A0 =C2=A0 =C2=A0 its data type.

So line 20 and 30 together defines the set of values permitted byu
this type.



I think RFC 7950 is cle= ar in this regard.

What concerns me is the idea th= at a "new YANG" can be defined that
overrides RFC 7950= =C2=A0 (in any way) without actually updating the YANG
version nu= mber, or without any formal development of a new YANG language version.


> I'm not sure that RFC7950 is terribly clear when it mentions "= ;data
> type" below. Isn't that a bit ambiguous as to whether it incl= udes
> line 30 or not?
>
> In the example above I think the value space is 5..101. Is that correc= t?

Yes.

> But what about a description like this ?
>
> 10 leaf bar {
> 20=C2=A0 =C2=A0 =C2=A0 type uint8 {
> 30=C2=A0 =C2=A0 =C2=A0 =C2=A0 range "5..101";
> 40=C2=A0 =C2=A0 =C2=A0 }
> 50=C2=A0 =C2=A0 =C2=A0 description "actually only takes values 5.= .88 in all current supported implementations";
> 60 }
>
> That description isn't a substatement of the "type" stat= ement. Is
> the value space 5..101 or 5..88 ?

Perhaps a better example is inet:uri from RFC 6991, which is defined
as:

=C2=A0 =C2=A0 =C2=A0typedef uri {
=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "The uri type represents a Uniform Resourc= e Identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(URI) as defined by STD 66.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Objects using the uri type MUST be in US-= ASCII encoding,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and MUST be normalized as described by RF= C 3986 Sections
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06.2.1, 6.2.2.1, and 6.2.2.2.=C2=A0 All un= necessary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0percent-encoding is removed, and all case= -insensitive
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0characters are set to lowercase except fo= r hexadecimal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0digits, which are normalized to uppercase= as described in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 6.2.2.1.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The purpose of this normalization is to h= elp provide
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unique URIs.=C2=A0 Note that this normali= zation is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sufficient to provide uniqueness.=C2=A0 T= wo URIs that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0textually distinct after this normalizati= on may still be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equivalent.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Objects using the uri type may restrict t= he schemes that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they permit.=C2=A0 For example, 'data= :' and 'urn:' schemes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0might not be appropriate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A zero-length URI is not a valid URI.=C2= =A0 This can be used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0express 'URI absent' where requir= ed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the value set and its semantics, this = type is equivalent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the Uri SMIv2 textual convention defin= ed in RFC 5017.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "RFC 3986: Uniform Resource Identifier (UR= I): Generic Syntax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 3305: Report from the Joint W3C/IETF = URI Planning Interest
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:= Uniform Resource Identifiers (URIs), URLs,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Un= iform Resource Names (URNs): Clarifications
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Re= commendations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5017: MIB Textual Conventions for Uni= form Resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Identi= fiers (URIs)";
=C2=A0 =C2=A0 =C2=A0}

The value space is all legal URIs, even though there is no pattern
defined.=C2=A0 An implementation may hook up a standard uri parser to
objects of this type.

Are we discussing a real problem here?



No, because it is clear= that description-stmt semantics are just as normative
as a patte= rn-stmt semantics or range-stmt semantics, etc.



/martin



Andy
=C2=A0

>
> Jason
>
> > -----Original Message-----
> > From: tom petch <ietfc@btconnect.com>
> > Sent: Tuesday, March 30, 2021 11:51 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; Martin=
> > Bj=C3=B6rklund <mbj+ietf@4668.se>; j.schoenwaelder@jacobs-university.de
> > Cc: netmod@i= etf.org
> > Subject: Re: [netmod] review of state NBC rules in yang-module-ve= rsioning-
> > 02
> >
> > From: netmod <netmod-bounces@ietf.org> on behalf of Sterne, Jason
> > (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> > Sent: 30 March 2021 13:13
> > Subject: Re: [netmod] review of state NBC rules in yang-module-ve= rsioning-
> > 02
> >
> > Hi guys,
> >
> > The text in 7950 doesn't mention anything about semantics in = the
> > description. That is part of what made me feel it isn't accur= ate or complete.
> >
> > It also doesn't mention constraints like range or pattern. It= only mentions the
> > type.
> >
> > <tp>
> > I am with Martin and Juergen on this one.=C2=A0 You pick on two o= f the ten
> > substatements for type but all are part of the definition of a ty= pe and are
> > relevant in defining the value space; and elsewhere in the RFC, e= .g.
> > decimal64, there are explicit descriptions of the value space.=C2= =A0 Whereas if you
> > take, say, uint32 what more do you need to say to describe the va= lue space?
> >
> > Tom Petch
> >
> > Jason
> >
> > > -----Original Message-----
> > > From: Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
> > > Sent: Tuesday, March 30, 2021 2:10 AM
> > > To: j.schoenwaelder@jacobs-university.de
> > > Cc: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; > > > netmod@= ietf.org
> > > Subject: Re: [netmod] review of state NBC rules in yang-modu= le-
> > versioning-
> > > 02
> > >
> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.d= e> wrote:
> > > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason= (Nokia -
> > > CA/Ottawa) wrote:
> > > > > Hi all,
> > > > >
> > > > > I took a look at section "3.1.2 Backwards-com= patibility rules for config
> > > false and output data" of https://= tools.ietf.org/html/draft-ietf-netmod-
> > > yang-module-versioning-02.
> > > > >
> > > > > Here are some suggestions (mostly just editorial -= I agree with the
> > > general spirit of what's in here).
> > > > >
> > > > > (A) Valuespace
> > > > >
> > > > > Valuespace is defined in module versioning 02:
> > > > >=C2=A0 =C2=A0 o=C2=A0 Valuespace: The valuespace of= a leaf or leaf-list is the set of
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0values that the schema n= ode may have according to the type and
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0constraint statements of= the YANG model.
> > > > >
> > > > > It seems to be a more complete definition than &qu= ot;value space" in
> > RFC7950
> > > (which doesn't seem to take into account "range&quo= t;, "pattern", etc
> > > statements):
> > > > >
> > > > >=C2=A0 =C2=A0 o=C2=A0 value space: For a data type;= the set of values permitted by the
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0data type.=C2=A0 For a l= eaf or leaf-list instance; the value space of
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0its data type.
> > > > >
> > > > > Should we mention that this definition replaces/su= percedes that of
> > 7950
> > > (at least for the scope of the module versioning doc) ?
> > > >
> > > > Please no. RFC 7950 says data type and for me this incl= udes everything
> > > > that defines a type, including the semantics carried in= the type's
> > > > description statement.
> > > >
> > > > We do not need to fix what is not broken. Why do we nee= d a new
> > > > definition at all?=C2=A0 If definitions in RFC 7950 are= broken, then we
> > > > need to fix it in YANG next.
> > >
> > > +1.=C2=A0 I don't think the text in RFC 7950 is broken.= =C2=A0 It is better if
> > > the new document refers to the defintion in RFC 7950, rather= than
> > > providing its own defintion with new words.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > /js
> > > >
> > > > --
> > > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Jacobs University Bremen gGmbH
> > > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<https://www.jacobs-university.de/>
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > ne= tmod@ietf.org
> > > > https://www.ietf.org/mailman/listinf= o/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.= org
> > https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000d29c3305bec5b27e-- From nobody Tue Mar 30 12:20:53 2021 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 1D7413A1F26 for ; Tue, 30 Mar 2021 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1T9p6DKlaocj for ; Tue, 30 Mar 2021 12:20:50 -0700 (PDT) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE483A1F25 for ; Tue, 30 Mar 2021 12:20:49 -0700 (PDT) Received: by mail-pj1-f51.google.com with SMTP id q6-20020a17090a4306b02900c42a012202so8171254pjg.5 for ; Tue, 30 Mar 2021 12:20:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ii29EqUoPvEnbU5mD+IxMGgC/z7vExK38VM0gnVS2gY=; b=HMdhiqHnPR1VZTa/vCaIPVHgZGNoEyCcPw/hrMMFCpfAW9kjtSEKcHFQzaUuDKGPs/ 9vBQrEWOdDF6NegD4HxG+ZaLk3xPR9TGhD+tK1R3SuUECj2I12bHai+SQU+S4f/bnE8B kfgoU82GThXni3Vc4oAdH44SOfJxPfVyUER6NsnIHfXTw+mHy+PZOb2xXEJIhPPaYdHY UbK7WZ+OOVuWG3dtnwMnAufW2D6GXnC6oGa9RTBwFgZMX9FoxYLQQAuz4FKxU7V8IdN3 wWY1XiN1pYESWVCh6B095Xu5WSObSJBfOBaSyUlQjg4KnzYa6IHFmOJAecCQeOSfrUWQ 96Jg== X-Gm-Message-State: AOAM532SQ5Z67ujFDWm413c97iZtSt/nkHWgu7HSPKWTc+z6wDUFPonF UPLwjuQjdETK1GGLkc/rcESmEiLu7iUx2Q== X-Google-Smtp-Source: ABdhPJw0CxLBzof5gSerSfYht5M5L8+rtKlDBWG0P8RNge2blPEWH+ojWtj0LQ0jmRW74EXgDXM6qQ== X-Received: by 2002:a17:902:b68b:b029:e6:cda9:39d with SMTP id c11-20020a170902b68bb02900e6cda9039dmr35329229pls.63.1617132048949; Tue, 30 Mar 2021 12:20:48 -0700 (PDT) Received: from ?IPv6:2601:646:9300:791:84c5:467d:1af:3a7e? ([2601:646:9300:791:84c5:467d:1af:3a7e]) by smtp.gmail.com with ESMTPSA id b19sm20855113pfo.7.2021.03.30.12.20.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Mar 2021 12:20:48 -0700 (PDT) To: netmod@ietf.org References: <20210330053801.fjgw26jgnolk3to5@anna.jacobs.jacobs-university.de> <20210330.081015.471474254972270522.id@4668.se> From: Randy Presuhn Message-ID: <273e9035-06de-30eb-9063-8babf1b4a4c8@alumni.stanford.edu> Date: Tue, 30 Mar 2021 12:20:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 19:20:51 -0000 Hi - On 2021-03-30 9:15 AM, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi guys, > > Let's take this model for a leaf (line numbers for reference): > > 10 leaf foo { > 20 type uint8 { > 30 range "5..101"; > 40 } > 50 } > > When I've been talking about "type" I've only been talking about line 20. The base type of the leaf. > > But are you guys considering that the term "type" includes 20 and 30 ? Like others, I'm in the "20 and 30" camp. But it's worth noting that this was an area that frequently caused problems for modelers new to GDMO. GDMO had very strict rules about subclassing / subtyping and compatibility, and the unwary would inadvertently overspecify base classes' attributes, putting in ranges that would be narrower than those eventually needed for future versions of products, and preventing what would otherwise be great opportunities for reuse and "automatic" interoperability. It feels like an analogous situation may underlie the concerns here. Randy From nobody Tue Mar 30 12:39:44 2021 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 EFAA93A1FA7 for ; Tue, 30 Mar 2021 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQdUTW-7hVMT for ; Tue, 30 Mar 2021 12:39:38 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2088.outbound.protection.outlook.com [40.107.20.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CCAF3A1FA2 for ; Tue, 30 Mar 2021 12:39:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UdZ4iMD+HGD+/APfXRr/m6KvjxOsuuUBpz+lRXK3Xo4uaN1vxQrCgrJjWU1IT1/shYZMcOu4pfaaITdFAjA1nb5UexJHlg5+oqQLgxR6ch2kMg9LX7/YaTlV4U6ELQU0yUjuEpHccFQPuZKExzF4y78yGyd56isE+smjv8h4BVdR1/DvlxZ+pnf4PrLjP0NXuoS5rLj67A3qqh/i6/OIBkLn8r+OV88/4dEiVgnNUomamFWzXRD1tKBPMbIcN6iZT/bTdoaoGmz3blXLn28TFIv4dxwzRBUx3JykuHF+8bZNHV243vQjWCx+Ghr4xe1lHksW2yzKJMTopc6AFEs3aQ== 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=Ex/KhLf+NFbVh2Z/kR93YX0OnVEStXqlabZ1Ds4sS9w=; b=a6thh+018ysTZZWWQKcexklI6Oit4aXKpg8cUGR+eBCQekODm2+s1dY/LcTArsxAJzWVrBF0xF8x6bgdo+SSHWVGYTtsDMo7pedyckeWL1+QfJ7F0qUU2T+qVk85IAC+QGHI9Rh9/WR6C6kjhILO0q4URV0gUJLJt+LypYyuM5NFrV6G1xRy+WcyzsquDij0h0bd8y1VNID/q86+zNm3lmyLNjn8oC2FOivjmPRTpmnkXDL45YKEPRwB06dL3UCe3QHe2UvtrcnfFgEWl/EU1rpixZgu/VleD9liz8F+X9cdyabbXDm8QyjY3kqH6tWpEHHGYfPhOjGv9iG5VE4Jog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ex/KhLf+NFbVh2Z/kR93YX0OnVEStXqlabZ1Ds4sS9w=; b=pHDdeNUlZvTlMZxRfOOxfWs7f5I/b5VGetI/BgoS0u5RJLiBoAqqKMGPvEzMVSfslD8sqMU79JJbcHID1rsWT6oIxa+wfu0cGzv46XCCaYw9+n3oLjsy0ewW0eg4isqGIsiHJWuxa7iWvzXiy4vPf/ZA+3UR8jyY90BU7NPSRSc= Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0769.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.29; Tue, 30 Mar 2021 19:39:35 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%6]) with mapi id 15.20.3977.033; Tue, 30 Mar 2021 19:39:34 +0000 Date: Tue, 30 Mar 2021 21:39:33 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA/Ottawa)" Cc: "netmod@ietf.org" Message-ID: <20210330193933.vyic4gyc5xmqyqo5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: <20210330.192210.52793363388988914.id@4668.se> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: FRYP281CA0018.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::28) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FRYP281CA0018.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.16 via Frontend Transport; Tue, 30 Mar 2021 19:39:34 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fbf43367-354b-422a-8f1c-08d8f3b38c17 X-MS-TrafficTypeDiagnostic: AM0P190MB0769: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZDj5rZX0izSpz3dyCv6Uk0APq2puseHCNFwd4mmCOGZ4livPfZBoG0aqA8dD+qPhaDpln69zWFUPAYU4cmhwa5Ig59OG3Wak5KOZEI7au1TtEzKLteFELMuv5f3CxZmVQ/yFtB+ATEnAoTzZawnsAT/atcjCOJhJ/1jum8H29j6rB0dgTS/koTbAkcKHNl3jpB9xfiZ0dsV2ZXX4PnlwMhqJbo5O+lg12CDgsIpZ1wWabU6nccsK5K59AFMa7lAkOjji7byakvTxeSH5jIA6FVX6ndU8P2YGEazrp7AdpkGy8IZb6xG/8ViXcAb/KV8gNnW6+11w9aCNSrY5KOy3F0d7FTOK6raYoE63iTa86RBqzxAojo8OOWXtezLgM4+tYuSrY+oanyMnKPA3/vbrxOaPzMpgrNqj0AExKN90FVkQcUQiuaLwpr7ky+WXbapJ+Xw7a99EOEfH2jHccUq/eWgEyAJp7s/OB9YJwn1KegI2lwlw2lSWvAF5id5wkOmw1CwLshE/tA9eYIx0Clf3FAQsJqbrYUklP1mKyJ5PaC+iVF5qgW03AFY11XbYnJo81TDWLTqrVNBzS8GyUzPCnZ+RI/n+YCbOkU22tUUIhakh0NqlTlEP4zq0OCc7j0maOwQTHpk5WRWGRPfyo+5oHuIJsUj6Hg+S3hoxXeF0MZHCgyeQLDv/gcVyJu6f1RdsmFkul1+LgIxWbrrFT/jUx0GpkcSLPhUmSYT7SsGq/as= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(39850400004)(376002)(346002)(366004)(396003)(8676002)(5660300002)(4326008)(86362001)(38100700001)(1076003)(296002)(6916009)(786003)(8936002)(3450700001)(956004)(316002)(6496006)(26005)(478600001)(966005)(6486002)(2906002)(186003)(83380400001)(66556008)(66574015)(16526019)(66476007)(52116002)(53546011)(66946007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?TzI3diV6gRjtW5uPTN4ocxPrOYJUlvGcRTUqSsxGgc/SuGA+/XvYPHO+NA?= =?iso-8859-1?Q?3OGvxLAbi99gCegEhOpe+ijlsgMKT5o+u30k87ZI8LzAQ13WLGWGA4J7an?= =?iso-8859-1?Q?GsATEPz/tZF62urWxLloSJnLcqyN4+rxKbf9C2ktQJUDB/o/bQDQJnDsI+?= =?iso-8859-1?Q?YDONGDgmR1y1141AVoI7xJ/Otdd34X2roeNZ7EM1c4eGzkSD8ir0UZS5MF?= =?iso-8859-1?Q?kAmIkk3okNU4cGSp08A3IsPvYDufSld2KjfcIDI2cIVhfUf6Z5F0mThlc5?= =?iso-8859-1?Q?pzYxNeXqg1oI/kthA1AdDbCBsAV7FNlt+bus1IKYPNz9F7bDks0BCa6Ctg?= =?iso-8859-1?Q?9XLRChbmU5k9Q1CNFm3qc2l7nTspgFg+zPc33QeN78QtgZ5O1/XR4rjDdH?= =?iso-8859-1?Q?qpTHf3XfEoxR+vSjr+/tAFQYdng82AKDQ+wyEtzzpwVc9tBMLPP5d8n90h?= =?iso-8859-1?Q?SghHsycNJY0Rxhz/529fJklZCjaYYmRDM2VpHDcKo3Q3cDJWf2dwW8S+T4?= =?iso-8859-1?Q?ozfkoDF3Yw5nlAZNHXzsuDrkhBemL0eClblu92eVGwMu8tk2WAuMprM3UN?= =?iso-8859-1?Q?cPZYih9OZFqcK/oMvtkZwDMo4tUV3Tq7AL8GYVvVb3ghNaNtbD4qmI1dVJ?= =?iso-8859-1?Q?aG8b589qMNcuyopg9WRUfjrxNVGzKHtJ6C+4yLD08dvqln4TOIdo+r1GC+?= =?iso-8859-1?Q?wXKcaevJPe6pWGST2RPz/Z4zyf06LgCbLmUxhulvNagwDTnZ8YJ4IV1/Ww?= =?iso-8859-1?Q?MLkk9kML0N25gPxHX8cZUmI2blJDNbtSj+pX+LYy8x5/MPHZ7nKm7g2j9D?= =?iso-8859-1?Q?LDCU6btxUbvln2UpZDh1+psnLCx6p+GIdocUDpizwGK8mS5s6PVijogHB/?= =?iso-8859-1?Q?F8Bk0t92MUTFQPEFbK1FnJO0jaO9KvSh8pcpeHwp7+PQw+Qje4sbwbvo6Q?= =?iso-8859-1?Q?6k8Fkho/n3/7mHxJjuO9af3nagWgl4l/Lrs+/fR8pGm4pmdTK60f2ubpaQ?= =?iso-8859-1?Q?CcW8NqOyRkM5ecRxwOi+X1YI0VqNsu5KasPoiryz7ChS3KiDBCbEyXsK7E?= =?iso-8859-1?Q?fg+zfruK6V5N2QuX5OX8qEyS1IXy5/ckx9pT9bKMVTn1WxIrnDs5W7dG26?= =?iso-8859-1?Q?7u+5NLaJfflEpsOqjZRa8oreKfANKYVSVC2aRt6rMrvnINyjInxthu4N4o?= =?iso-8859-1?Q?N3AUVur97nZrJGqxMVqqIM3xn1tDgGUenADGs26aHcfR3GfLnORXUJKtgQ?= =?iso-8859-1?Q?P6P+5+mZ7O1bK9SOY1LdZPfztUq7GUjtBUSyP9TJgXt/ryMTDTeHIdYApY?= =?iso-8859-1?Q?RvInNv60gBmNI5xUz6wx+5ES5Vi9VaRiCiZQ5zE5EbRpEvND6fysx6hnyS?= =?iso-8859-1?Q?mQJM04IuRE?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: fbf43367-354b-422a-8f1c-08d8f3b38c17 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2021 19:39:34.9229 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Rb1k3nUPsEChGKKcYIVobtwSU1TEBd0b63JdmvQqFqgBgQmaIlA/jm0xRnVL1DHOpEcnVMsr3FBv8jwHGTA8pR26L6KRqmOO0sBC7et4qUs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0769 Archived-At: Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 19:39:43 -0000 Jason, the type defined below has a value space that consists of the set of prime numbers in the range 0 to 4294967295. typedef prime { type uint32; description "The set of prime numbers that can be represented in the uint32 range".; } People are way too focused on machine readable constructs but these constructs often only capture a small part of the story. Yes, I can inline this into a leaf definition, but this does not change the value space of the (unnamed) type used by the leaf. leaf prime { type uint32; description "This leaf holds a prime number in the uint32 range"; } /js On Tue, Mar 30, 2021 at 06:47:35PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Thanks Martin. > > Maybe I'm in the minority thinking the definition in RFC7950 is slightly ambiguous. If anyone else thinks it might be, then let us know. Otherwise I'm fine to just stick with the 7950 definition. > > That example in 6991 is a typedef which has a description statement. But a leaf that doesn't use a typedef may have a description for the leaf (not part of the type) that affects the value space. > > Jason > > > -----Original Message----- > > From: Martin Björklund > > Sent: Tuesday, March 30, 2021 1:22 PM > > To: Sterne, Jason (Nokia - CA/Ottawa) > > Cc: ietfc@btconnect.com; mbj+ietf@4668.se; j.schoenwaelder@jacobs- > > university.de; netmod@ietf.org > > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning- > > 02 > > > > Hi, > > > > "Sterne, Jason (Nokia - CA/Ottawa)" wrote: > > > Hi guys, > > > > > > Let's take this model for a leaf (line numbers for reference): > > > > > > 10 leaf foo { > > > 20 type uint8 { > > > 30 range "5..101"; > > > 40 } > > > 50 } > > > > > > When I've been talking about "type" I've only been talking about > > > line 20. The base type of the leaf. > > > > > > But are you guys considering that the term "type" includes 20 and 30 > > > ? > > > > Yes; the definition in RFC 7950 is: > > > > o value space: For a data type; the set of values permitted by the > > data type. For a leaf or leaf-list instance; the value space of > > its data type. > > > > So line 20 and 30 together defines the set of values permitted byu > > this type. > > > > > I'm not sure that RFC7950 is terribly clear when it mentions "data > > > type" below. Isn't that a bit ambiguous as to whether it includes > > > line 30 or not? > > > > > > In the example above I think the value space is 5..101. Is that correct? > > > > Yes. > > > > > But what about a description like this ? > > > > > > 10 leaf bar { > > > 20 type uint8 { > > > 30 range "5..101"; > > > 40 } > > > 50 description "actually only takes values 5..88 in all current supported > > implementations"; > > > 60 } > > > > > > That description isn't a substatement of the "type" statement. Is > > > the value space 5..101 or 5..88 ? > > > > Perhaps a better example is inet:uri from RFC 6991, which is defined > > as: > > > > typedef uri { > > type string; > > description > > "The uri type represents a Uniform Resource Identifier > > (URI) as defined by STD 66. > > > > Objects using the uri type MUST be in US-ASCII encoding, > > and MUST be normalized as described by RFC 3986 Sections > > 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary > > percent-encoding is removed, and all case-insensitive > > characters are set to lowercase except for hexadecimal > > digits, which are normalized to uppercase as described in > > Section 6.2.2.1. > > > > The purpose of this normalization is to help provide > > unique URIs. Note that this normalization is not > > sufficient to provide uniqueness. Two URIs that are > > textually distinct after this normalization may still be > > equivalent. > > > > Objects using the uri type may restrict the schemes that > > they permit. For example, 'data:' and 'urn:' schemes > > might not be appropriate. > > > > A zero-length URI is not a valid URI. This can be used to > > express 'URI absent' where required. > > > > In the value set and its semantics, this type is equivalent > > to the Uri SMIv2 textual convention defined in RFC 5017."; > > reference > > "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax > > RFC 3305: Report from the Joint W3C/IETF URI Planning Interest > > Group: Uniform Resource Identifiers (URIs), URLs, > > and Uniform Resource Names (URNs): Clarifications > > and Recommendations > > RFC 5017: MIB Textual Conventions for Uniform Resource > > Identifiers (URIs)"; > > } > > > > The value space is all legal URIs, even though there is no pattern > > defined. An implementation may hook up a standard uri parser to > > objects of this type. > > > > Are we discussing a real problem here? > > > > > > > > /martin > > > > > > > > > > Jason > > > > > > > -----Original Message----- > > > > From: tom petch > > > > Sent: Tuesday, March 30, 2021 11:51 AM > > > > To: Sterne, Jason (Nokia - CA/Ottawa) ; > > Martin > > > > Björklund ; j.schoenwaelder@jacobs-university.de > > > > Cc: netmod@ietf.org > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > versioning- > > > > 02 > > > > > > > > From: netmod on behalf of Sterne, Jason > > > > (Nokia - CA/Ottawa) > > > > Sent: 30 March 2021 13:13 > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > versioning- > > > > 02 > > > > > > > > Hi guys, > > > > > > > > The text in 7950 doesn't mention anything about semantics in the > > > > description. That is part of what made me feel it isn't accurate or > > complete. > > > > > > > > It also doesn't mention constraints like range or pattern. It only mentions > > the > > > > type. > > > > > > > > > > > > I am with Martin and Juergen on this one. You pick on two of the ten > > > > substatements for type but all are part of the definition of a type and are > > > > relevant in defining the value space; and elsewhere in the RFC, e.g. > > > > decimal64, there are explicit descriptions of the value space. Whereas if > > you > > > > take, say, uint32 what more do you need to say to describe the value > > space? > > > > > > > > Tom Petch > > > > > > > > Jason > > > > > > > > > -----Original Message----- > > > > > From: Martin Björklund > > > > > Sent: Tuesday, March 30, 2021 2:10 AM > > > > > To: j.schoenwaelder@jacobs-university.de > > > > > Cc: Sterne, Jason (Nokia - CA/Ottawa) ; > > > > > netmod@ietf.org > > > > > Subject: Re: [netmod] review of state NBC rules in yang-module- > > > > versioning- > > > > > 02 > > > > > > > > > > Juergen Schoenwaelder > > wrote: > > > > > > On Tue, Mar 30, 2021 at 01:55:18AM +0000, Sterne, Jason (Nokia - > > > > > CA/Ottawa) wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I took a look at section "3.1.2 Backwards-compatibility rules for > > config > > > > > false and output data" of https://tools.ietf.org/html/draft-ietf-netmod- > > > > > yang-module-versioning-02. > > > > > > > > > > > > > > Here are some suggestions (mostly just editorial - I agree with the > > > > > general spirit of what's in here). > > > > > > > > > > > > > > (A) Valuespace > > > > > > > > > > > > > > Valuespace is defined in module versioning 02: > > > > > > > o Valuespace: The valuespace of a leaf or leaf-list is the set of > > > > > > > values that the schema node may have according to the type and > > > > > > > constraint statements of the YANG model. > > > > > > > > > > > > > > It seems to be a more complete definition than "value space" in > > > > RFC7950 > > > > > (which doesn't seem to take into account "range", "pattern", etc > > > > > statements): > > > > > > > > > > > > > > o value space: For a data type; the set of values permitted by the > > > > > > > > > > > > > > data type. For a leaf or leaf-list instance; the value space of > > > > > > > > > > > > > > its data type. > > > > > > > > > > > > > > Should we mention that this definition replaces/supercedes that of > > > > 7950 > > > > > (at least for the scope of the module versioning doc) ? > > > > > > > > > > > > Please no. RFC 7950 says data type and for me this includes > > everything > > > > > > that defines a type, including the semantics carried in the type's > > > > > > description statement. > > > > > > > > > > > > We do not need to fix what is not broken. Why do we need a new > > > > > > definition at all? If definitions in RFC 7950 are broken, then we > > > > > > need to fix it in YANG next. > > > > > > > > > > +1. I don't think the text in RFC 7950 is broken. It is better if > > > > > the new document refers to the defintion in RFC 7950, rather than > > > > > providing its own defintion with new words. > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 31 04:07:21 2021 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 AD1A23A247A for ; Wed, 31 Mar 2021 04:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-TOlQjX1bpY for ; Wed, 31 Mar 2021 04:07:14 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2114.outbound.protection.outlook.com [40.107.21.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3B03A2477 for ; Wed, 31 Mar 2021 04:07:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LnfAHvLraMR440J0A039NQ9flrGGsnhJ4LdQKzoSd7YMlthT2MQ6nVvtdejCO3I2rTM6Cyhx0wrD3wlus176fobDEm8OatJe1qfbJH8A3tuDEPMjBD0Yulca0Jrq4LMYTkK8kcJPmt2rnmAvyHSKOICV1vZwGFDUU23hm1U2ZuzwPn7QXWqdSMEViwikz7sJZp9i82C8Jqtyml3JDhLYWU6NcXFCMZUt+yXVHyYXO2zAR+0MsXADHNeTYNPDv1Pmm3e7AM2x8v39kOlCwzaiUgYl96htQrn82kSFG2w0yZTYZ/+xfhBFk7iKsUteZAqXloIkCFr570PSt9uYxo3Evg== 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=RQNgxXO0WMDMpu11v1gfLOJ5u3mos00VOyrZISyvAhk=; b=Bf4zMoL06F86CcdylKObliaFFmc4RM4D55jbRgAuqzOM9CcvLFwJtL6Yrf3Deo0dGEkcHfqVd3OMsd5MbQB/GH1q8XzSg768GlLJU6cZIVEavJp+xUU5Tyl81vh3YY6SthXu2XXRhW9iCzevvTJspbSSby6irb6dlNq/7qD9hRDi23/ekCLBSiOy+j4UMDrJVLaB8lyFcCwecC4zTXjnJthChiAryzVHnMqZT8GbidvhkfSUjAKOOO1haFX7dQPAzJMDwl8q2R7rKAOOdwRwIHvesEG3vNt5dpaculwXQphQC2YiXgFMsNMB+pmBMRYxpXvt/cmFkGtRN9+z0RZpIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RQNgxXO0WMDMpu11v1gfLOJ5u3mos00VOyrZISyvAhk=; b=f2TYvH0vZeClglm7JP//d1R+mBaQoH6ECWvZYAUxxMpQuC3NKH4TIPvqKrUKYfvJx0nDbDfycsXUFmMG8v2ZXGYVF/MeutnHf7VdzF+sodUFNR/ZSfeTh2AwetuoBqFzlswM5a0q1qSt20r0GjtZohb9bhaTdvkUJkvLuV2OJCA= Received: from PAXPR06MB7872.eurprd06.prod.outlook.com (2603:10a6:102:1a3::9) by PR3PR06MB6908.eurprd06.prod.outlook.com (2603:10a6:102:8b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25; Wed, 31 Mar 2021 11:07:08 +0000 Received: from PAXPR06MB7872.eurprd06.prod.outlook.com ([fe80::35e1:a3ee:4530:78f2]) by PAXPR06MB7872.eurprd06.prod.outlook.com ([fe80::35e1:a3ee:4530:78f2%7]) with mapi id 15.20.3977.033; Wed, 31 Mar 2021 11:07:08 +0000 From: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= To: "Aseem Choudhary (asechoud)" , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match Thread-Index: AdcbGExc8OTG49eVSoeJejnhX1jHZwAENNWA///CiICAAHf9AP//j5kA/+nm8rA= Date: Wed, 31 Mar 2021 11:07:08 +0000 Message-ID: References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> <20210317155834.nz6cv4mefwxrjgmq@anna.jacobs.jacobs-university.de> <4BBA1D6B-F2CC-4099-A640-88F003327529@cisco.com> In-Reply-To: <4BBA1D6B-F2CC-4099-A640-88F003327529@cisco.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=telefonica.com; x-originating-ip: [79.152.139.53] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 630825a4-5ace-4355-4748-08d8f4352085 x-ms-traffictypediagnostic: PR3PR06MB6908: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bG533iBXX1/dwCpjMBHdtRPJWnTo7615OQOXlUlnfutcFdKcYeUVMXtL35YUwqWSwodOAVNpNbqCmBi+agMBwl5HRGsc9HPT3tp330EnChun6BNQWcsCSi9+xXzbO//y7AORazPkY4UTjQvXEMAngA1U1uNKXflMoNZGpQCnboAPWi5VtHG5MDoA54uG9o932mGn+1AjEG1sbVjSRXQeaYMwIJbvVsjQ0akvc5RYiQ214ZN3LaI2fLr1AxJf+6U0BkXBMraYeLbZQD98t/uneshoM4J8kis7GF/a3jgIi0/ImUYwSX4UZRpUri8ad0LbC/X0NA4Lpp93kYz36iSpvoh6ltp8X/6vJ9qcqjjBCLojPoRrCrClSViX2lx9ZkIEM/OwhXqXNtztANOJOUnI8zECi6DDsny0CkOCpwc9aAShxUumWregwpKnJq13H16I83gtDEqBygEE0BHIqCFdR+rPP1YqVnXx/J2mTOJ2hhR7+iFj0VqEUoafMzZ81+PwWThCWyOihlme/awqewk9U3kmS4F/wA6AlLiXpL3SuH+JI7Kiaue1nifRG6jFlB5TBVdccW3PoWIcIR9Aze3Im0GUAR/NNqO6B4pQ12dVNaDy300XhXFw/95p1k+O4ySotVaeQZwQahguiFAFDIulkEYSlhpiRKRR/NkNpJl0+iFDIep3r42539lZcZAt2RXYGmUsRE70EiFztIP22SVDCAABw9aMYi9pdB7ccUqg93L1yZCMsCTZDJg+1SfL1m4rnF03imcW8xSAU213HuHkdA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAXPR06MB7872.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(366004)(376002)(346002)(2906002)(55016002)(186003)(9686003)(66574015)(478600001)(52536014)(85202003)(64756008)(86362001)(71200400001)(66446008)(66556008)(33656002)(26005)(85182001)(8936002)(4326008)(53546011)(6506007)(8676002)(38100700001)(316002)(5660300002)(83380400001)(966005)(76116006)(7696005)(786003)(110136005)(66946007)(66476007)(9010500006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?VmlWOGh4czlZOTJLRWJiOGNjYWRDMkp1cHFLSThtQ2NOSlVIZ1dxUGdOTVdF?= =?utf-8?B?c253MktGaUNoM3R3c2JacFBKY3ZvZDYwcXFPTXpPZkI5L3BDMlVJL01lUUdm?= =?utf-8?B?Y2QyVWhPbzh3MStxaWVIY1dCclR2NGdzMGdra0hYTmdCSUhDK09IM28wR09R?= =?utf-8?B?eXZ4UFc3WE9SS09mY1RoUXdQODM1K2JydHMyZnVGWEQvZGxrSkJoYjZvYXY5?= =?utf-8?B?OUw4eEJsNVVPNitTMFpuVmlscmlNc3psd1AzamhDSzBRM0VwYnZGT0lBbXUy?= =?utf-8?B?VlQrZXRjQlIvZENEay9veGJNTmI2WGsrRjc2T2tXZGxqTHNxc2lIU3h5S2J0?= =?utf-8?B?YTNsQWlneURZTElBOWRzeUk4elVNMXFQTFF3alYwd2RyaTYyTElqVU40YjFF?= =?utf-8?B?NkdwY3FWTmNnaUlhQTVBSGdjbjlua20rV2wvRS9kS0o4SjZzT1RsZFZKVnpM?= =?utf-8?B?ZVE1UUJWb2RRaSt2SUZTSzM5SllMUWNhbW04OG1ySUJpb25MVDRQSGZ3THRF?= =?utf-8?B?aXZrUzNWcVZXNHpKVHgzaXJiRXE0UzRwa3pQWjBtYVlLVlczWXVmREZTYXN0?= =?utf-8?B?VkRnSEpENkVORjdVVDJ1N3paejg3aUh4Ull6NWZWK0hPalp2U2RpVGcyU3VB?= =?utf-8?B?L2tWN3M1OS9rbmVUWUtIUUQ2S0RwbTZ4NU9pcjFMaFNHUVphYVoybEcrZkJC?= =?utf-8?B?YzkvVllTajEvcDZzSnZpUVB2eVVBV21ZclJSZDljVy96UWpUdElxbUpnZks1?= =?utf-8?B?TWVZQ3QvK0ZmUUdqbnVDN3pzQ2Y3S055RzY4YmlIVjk0ajJSc1I2dGxDL1hB?= =?utf-8?B?YU9DOFBkQUVPTVpLQUN2bThNMjJOMS9zS05qeFBWSnhvOGhUVllnVktIdEhJ?= =?utf-8?B?dlMwVVY5b093d2RUOGdqZ1dVZm5OT2FVeS9KNDg3aUo3aklUWHhINE9oSHMz?= =?utf-8?B?NENEU0QxWVI0a0pTWEpBUWgveHltUStPMUU5SWNicHl3USt5TWR1Wjg3UFlT?= =?utf-8?B?bDlxY2NSb21XbzdKZkdmcGRocGRxbjVvcmFKdVE2TW1ZQ3NOMU5vODZZeHNs?= =?utf-8?B?OXJ2clJBcFpsNlpvVHJHcUs4eFdwUmZjMS8yamFIM1NBdndwTkZvZlg5aVRx?= =?utf-8?B?bEsrZ0d4UzRCL3p4enJaU1RiNk85NEZDL01TKzVjSllsdmlVdG1xR0xJMUFn?= =?utf-8?B?dWNLZWN0d1FIWW9MN0NVdkluT1VOOFh0Nis4UC9nMVJLVlh4Vy9MdzVsbmhX?= =?utf-8?B?NmZFMjdIYk1XMVNqcDlhMEZrNmhFRi9YN1pMZWpjdzkzbjFyeGVOOVFuaVdV?= =?utf-8?B?ZjhPTFhsMmIrcE90MkFWdk1mNUlYSGxsZUlJM2ZLalJHRUVyeGF6L3pOYXVz?= =?utf-8?B?a2VKUFVXUU4zc3dwNEVITk1xSThqMHNRa0paaTNCandXZDNHa1dOemU1S3Qx?= =?utf-8?B?V2pzSHhQQUlBd3ZvOTZWaXZqY29nZUg2dmpDWEZCUVFNaGdlNzNEWk9CTjdt?= =?utf-8?B?NGZFdEtDaHFkMUFCUGhzdWxicTl6bHFMcFEvMFZBbVVnMHdXMlZsd1BSUTlq?= =?utf-8?B?RWtDTmRRMC9xZDZEZlBjMTAwWWNvZ0JrblV1Vng2czJTbjA2VW9SbFdCc3No?= =?utf-8?B?UTc3SFdmZFV4bndrRllsS2lxQmdSbHhKTnhxdldYcC94elM0dWVSYWNMNHgx?= =?utf-8?B?cHNDU0VkaUVEdmZuQWZFS0pDbGp3NmtFWU1BdkRxV1pUNUlnRkVNR0phNDRy?= =?utf-8?Q?kAmDH4MqRiiF3WjJFKkBaWZr/GN+JWLcIfna0Ef?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAXPR06MB7872.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 630825a4-5ace-4355-4748-08d8f4352085 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2021 11:07:08.7441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4lj2fEIK+obQ08atv5xLJww+NkKrVUBgdl7M5dR9779L0sIOa+42R+WKlyE5QcE/5t+OZp71EsFn7qf4CtR+C7x9uRkIS2k3NpjEfcsXvtKsh6ORUDxQsH+wVtmG1iAN X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR06MB6908 Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 11:07:20 -0000 QWdyZWUgdG9vLA0KDQpJdCBtYWtlcyBzZW5zZSB0byAiZ2VuZXJhbGl6ZSIgdGhlIGNvbmNlcHQg b2Ygc2V0cyB0aGF0IGNhbiBiZSBzaGFyZWQgYmV0d2VlbiBBQ0xzLCBzbyB0aGV5IGNhbiBiZSB1 c2VkIHdpdGggb3RoZXIgZmllbGRzIGJleW9uZCB0aG9zZSBhbHJlYWR5IGlkZW50aWZpZWQgd2l0 aCBvdXIgdXNlIGNhc2VzIChwcmVmaXhlcyBhbmQgcG9ydHMvcG9ydCByYW5nZXMpIC4NCg0KU28s IHF1ZXN0aW9uIGZvciBOZXRtb2QgV0cgY2hhaXJzLCB3aGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1 cmUgdG8gaW5jbHVkZSBzdWNoIGZlYXR1cmUgaW4gdGhlIEFDTCBtb2R1bGUsIGdpdmVuIHRoYXQg aXQgaXMgZGVmaW5lZCBpbiAgYW4gYWxyZWFkeSBwdWJsaXNoZWQgUkZDPyBJcyBpdCB2aWEgYSBu ZXcgZHJhZnQgZGVzY3JpYmluZyBqdXN0IHRoZSBleHRlbnNpb24gYW5kIHJlZmVyZW5jaW5nIHRo ZSBvcmlnaW5hbCBSRkMgYW5kIGluY2x1ZGluZyB0aGUgdXBkYXRlZCB5YW5nPyBPciBpdCBpcyBh biB1cGRhdGUgb2YgdGhlIGV4aXN0aW5nIFJGQyBhZGRpbmcgdGhlIG5ldyBmdW5jdGlvbmFsaXR5 IChmdWxsIGRlc2NyaXB0aW9uIGFuZCBmdWxsIHlhbmcpPyBJIGFtIGFzc3VtaW5nIHRoZSB3b3Jr IGltcGxpZXMgY3JlYXRpbmcgYSBuZXcgcmV2aXNpb24gb2YgdGhlIG1vZHVsZS4NCg0KQmVzdCBS ZWdhcmRzLA0KDQpPc2Nhcg0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IEFzZWVt IENob3VkaGFyeSAoYXNlY2hvdWQpIDxhc2VjaG91ZEBjaXNjby5jb20+DQpFbnZpYWRvIGVsOiBt acOpcmNvbGVzLCAxNyBkZSBtYXJ6byBkZSAyMDIxIDE3OjE2DQpQYXJhOiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCkNDOiBPc2Nh ciBHb256w6FsZXogZGUgRGlvcyA8b3NjYXIuZ29uemFsZXpkZWRpb3NAdGVsZWZvbmljYS5jb20+ OyBuZXRtb2RAaWV0Zi5vcmcNCkFzdW50bzogUmU6IFtuZXRtb2RdIFJlcXVlc3QgZm9yIGltcHJv dmVtZW50IGluIEFDTCBZQU5HIE1vZGVsOiBhZGQgcHJlZml4LWxpc3QgdG8gdGhlIG1hdGNoDQoN CkkgYWdyZWUsIGEgdGVtcGxhdGUgYmFzZWQgYXBwcm9hY2ggd29ya3Mgd2VsbCBhcyBpdCBoZWxw cyB0byBzaGFyZSB0aGUgc2V0IG9mIGZpZWxkcyBiZXR3ZWVuIEFDTHMuDQoNCi10aGFua3MsDQpB c2VlbQ0KDQrvu79PbiAzLzE3LzIxLCA4OjU4IEFNLCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KICAgIEkgbm93 IHVuZGVyc3RhbmQgdGhhdCB0aGUgb3JpZ2luYWwgcmVxdWVzdCB3YXMgYWJvdXQgdHdvIHRoaW5n czoNCg0KICAgIC0gYWxsb3dpbmcgc2V0cyBvZiBwcmVmaXhlcyBpbiBhbiBBQ0wgKGluc3RlYWQg b2YganVzdCBhIHNpbmdsZSkNCiAgICAtIHNoYXJpbmcgb2Ygc2V0cyBvZiBwcmVmaXhlcyBiZXR3 ZWVuIEFDTHMNCg0KICAgIEFuZCB5ZXMsIGlmIHRoZSBXRyBnb2VzIHRoZXJlLCB0aGVuIG9mIGNv dXJzZSB0aGUgc2FtZSBxdWVzdGlvbnMgd2lsbA0KICAgIGNvbWUgdXAgZm9yIGFsbCB0aGUgb3Ro ZXIgcG9zc2libGUgaGVhZGVyIGZpZWxkcy4uLg0KDQogICAgLSBhbGxvd2luZyBzZXRzIG9mIHBv cnRzL3BvcnQgcmFuZ2VzDQogICAgLSBzaGFyaW5nIG9mIHNldHMgb2YgcG9ydHMvcG9ydCByYW5n ZXMgYmV0d2VlbiBBQ0xzDQoNCiAgICBbLi4uXQ0KDQogICAgL2pzDQoNCiAgICBPbiBXZWQsIE1h ciAxNywgMjAyMSBhdCAwMzo0OToxMVBNICswMDAwLCBBc2VlbSBDaG91ZGhhcnkgKGFzZWNob3Vk KSB3cm90ZToNCiAgICA+IEhpLA0KICAgID4NCiAgICA+IFNpbWlsYXJseSwgdGhlcmUgaXMgTnhN IGlzc3VlIHdoZW4gdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgc291cmNlIGFuZCBkZXN0aW5hdGlv biBwb3J0L3BvcnQgcmFuZ2VzLg0KICAgID4NCiAgICA+IC10aGFua3MsDQogICAgPiBBc2VlbQ0K ICAgID4NCiAgICA+IE9uIDMvMTcvMjEsIDU6MjkgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KICAgID4NCiAg ICA+ICAgICBIaSwNCiAgICA+DQogICAgPiAgICAgbGV0IG1lIGNoZWNrIHdoZXRoZXIgSSB1bmRl cnN0YW5kIHlvdXIgcmVxdWVzdCBjb3JyZWN0bHk6IEkgaGVhcmQgeW91DQogICAgPiAgICAgc2F5 aW5nIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gaGF2ZQ0KICAgID4NCiAgICA+ICAgICAgICAgICAg IGxlYWYtbGlzdCBkZXN0aW5hdGlvbi1pcHY2LW5ldHdvcmsgew0KICAgID4gICAgICAgICAgICAg ICB0eXBlIGluZXQ6aXB2Ni1wcmVmaXg7DQogICAgPiAgICAgICAgICAgICAgIGRlc2NyaXB0aW9u DQogICAgPiAgICAgICAgICAgICAgICAgIkRlc3RpbmF0aW9uIElQdjYgYWRkcmVzcyBwcmVmaXgu IjsNCiAgICA+ICAgICAgICAgICAgIH0NCiAgICA+DQogICAgPiAgICAgaW5zdGVhZCBvZiBqdXN0 DQogICAgPg0KICAgID4gICAgICAgICAgICAgbGVhZiBkZXN0aW5hdGlvbi1pcHY2LW5ldHdvcmsg ew0KICAgID4gICAgICAgICAgICAgICB0eXBlIGluZXQ6aXB2Ni1wcmVmaXg7DQogICAgPiAgICAg ICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgPiAgICAgICAgICAgICAgICAgIkRlc3RpbmF0aW9u IElQdjYgYWRkcmVzcyBwcmVmaXguIjsNCiAgICA+ICAgICAgICAgICAgIH0NCiAgICA+DQogICAg PiAgICAgKGFuZCBzaW1pbGFyIGNoYW5nZXMgZm9yIHRoZSBvdGhlciBJUCBwcmVmaXggcmVsYXRl ZCBsZWFmcykuDQogICAgPg0KICAgID4gICAgIFdoaWxlIHN1Y2ggYSBkaXJlY3QgY2hhbmdlIG1h eSBiZSBkaWZmaWN1bHQsIGdpdmVuIHRoYXQgdGhlIGhlYWRlcg0KICAgID4gICAgIGZpZWxkcyBh cmUgZGVmaW5lZCBpbiBhIGNob2ljZSwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFkZA0KICAg ID4gICAgIGFkZGl0aW9uYWwgY2hvaWNlcyBmb3Igc2V0cyBvZiBwcmVmaXhlcy4gU28gZnJvbSB0 aGUgWUFORyBzaWRlLCB0aGlzDQogICAgPiAgICAgc2VlbXMgdG8gYmUgc29tZXRoaW5nIHBvc3Np YmxlIHRvIGFkZHJlc3Mgd2l0aG91dCB0b28gbXVjaCB0cm91YmxlLg0KICAgID4NCiAgICA+ICAg ICBXaGV0aGVyIGltcGxlbWVudG9ycyBhcmUgaGFwcHkgd2l0aCBzdXBwb3J0aW5nIHN1Y2ggYSBj aGFuZ2UgaXMNCiAgICA+ICAgICBzb21ldGhpbmcgb3RoZXJzIGhhdmUgdG8gY29tbWVudCBvbi4N CiAgICA+DQogICAgPiAgICAgL2pzDQogICAgPg0KICAgID4gICAgIE9uIFdlZCwgTWFyIDE3LCAy MDIxIGF0IDEwOjMxOjEwQU0gKzAwMDAsIE9zY2FyIEdvbnrDoWxleiBkZSBEaW9zIHdyb3RlOg0K ICAgID4gICAgID4gRGVhciBuZXRtb2Qgd2cgY29sbGVhZ3VlcywNCiAgICA+ICAgICA+DQogICAg PiAgICAgPiAgICAgICAgICAgICAgICAgVGhlIGlldGYtYWNsIFlBTkcgbW9kZWwgZGVmaW5lZCBp biBSRkMgODUxOSBhbGxvd3MgdG8gY3JlYXRlIHJ1bGVzLCBhbmQgZm9yIGVhY2ggYSBydWxlLCBp biBjYXNlIG9mIElQdjQvSVB2NiB5b3UgY2FuIHNwZWNpZnkgaW4gdGhlIG1hdGNoIHRoZSBzb3Vy Y2UtbmV0d29yayBhbmQgZGVzdGluYXRpb24tbmV0d29yay4gVGhlIHNvdXJjZS1uZXR3b3JrIChv ciBlcXVhbGx5IHRoZSBkZXN0aW5hdGlvbiBuZXR3b3JrKSBpcyBpbiB0aGUgbW9kZWwgYW4gYWRk cmVzcyBwcmVmaXguIEluIG91ciB1c2UgY2FzZSBpbiBUZWxlZm9uaWNhIHdlIGFyZSBzcGVjaWZ5 aW5nIGEgcHJlZml4LWxpc3QgZm9yIHNvdXJjZSBuZXR3b3JrIGFuZCBhbm90aGVyIHByZWZpeCBs aXN0IGZvciBkZXN0aW5hdGlvbiBuZXR3b3JrLiBJZiB5b3UgaGFkIHRvIGNyZWF0ZSB0aGlzIGJl aGF2aW9yIHVzaW5nIHRoZSBBQ0wgbW9kZWwsIHlvdSB3b3VsZCBuZWVkIHRvIGNyZWF0ZSBOeE0g cnVsZXMuIEJlc2lkZXMsIHRoZSBtYW5hZ2VtZW50IG9mIHRob3NlIHJ1bGVzIHdvdWxkIGJlIG1v cmUgY29tcGxleC4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgICAgICAgICAgICAgVGhl IHJvdXRpbmcgcG9saWN5IG1vZGVsIGhhcyB0aGUgY29uY2VwdCBvZiBwcmVmaXgtc2V0cywgYnV0 IGlzIGEgc2VwYXJhdGUgbW9kZWwgKGFuZCBhIGRpZmZlcmVudCB1c2UgY2FzZSkuDQogICAgPiAg ICAgPg0KICAgID4gICAgID4gICAgICAgICAgICAgICAgIFRoZSBmdW5jdGlvbmFsaXR5IG9mIHNw ZWNpZnlpbmcgYSBwcmVmaXggbGlzdCBmb3Igc291cmNlIGFuZCBkZXN0aW5hdGlvbiBpbiBhY2Nl c3MgY29udHJvbCBsaXN0cyBpcyBhdmFpbGFibGUgaW4gbW9zdCB2ZW5kb3JzIHRoYXQgSSBhbSBh d2FyZSB0b2RheS4gSGVuY2UsIGl0J3MgYSBwcmV0dHkgc3RhbmRhcmQgZnVuY3Rpb25hbGl0eS4N CiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICAgICAgICAgICAgICAgRG8geW91IHRoaW5rIGl0 IGlzIHVzZWZ1bCB0byBhZGQgdGhpcyBmdW5jdGlvbmFsaXR5IHRvIHRoZSBBQ0wgWUFORyBtb2Rl bD8gSWYgeWVzLCB3aGF0IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmUsIGdpdmVuIHRoYXQgQUNMIGlz IGFscmVhZHkgZGVmaW5lZCBpbiBhbiBleGlzdGluZyBSRkM/DQogICAgPiAgICAgPg0KICAgID4g ICAgID4gICAgICAgICAgICAgICAgIEJlc3QgUmVnYXJkcywNCiAgICA+ICAgICA+DQogICAgPiAg ICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3NjYXINCiAgICA+ICAgICA+DQog ICAgPiAgICAgPg0KICAgID4gICAgID4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPg0KICAgID4g ICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICA+DQogICAg PiAgICAgPiBFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFt ZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZp bGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJz b25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlv IGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nD s24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIg cHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVj aWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVu aXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRl c3RydWNjacOzbi4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlh bCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVu aWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVs eSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5p Y2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCiAgICA+ICAgICA+DQogICAgPiAg ICAgPiBFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50 ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVn aWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91 IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5h dMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6 YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBl c3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNl YmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlx dWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3Ry dWnDp8Ojbw0KICAgID4NCiAgICA+ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgPiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAg PiAgICAgPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgPg0KICAgID4NCiAgICA+ICAgICAtLQ0KICAg ID4gICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIDQogICAgPiAgICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBD YW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgID4gICAgIEZheDogICAr NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl Lz4NCiAgICA+DQogICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICA+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiAgICAgbmV0 bW9kQGlldGYub3JnDQogICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCiAgICA+DQoNCiAgICAtLQ0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAg ICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQogICAgUGhvbmU6ICs0OSA0 MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFu eQ0KICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29i cy11bml2ZXJzaXR5LmRlLz4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFk YSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8g ZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGlj YWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRp dnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGli aWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8g ZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBp bm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNj acOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBp cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRo ZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRp b24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5v dCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxl dGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2 YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJp dmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNz b2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRl c3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1 dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBw b2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNl IHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNv bXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEg ZGVzdHJ1acOnw6NvDQo= From nobody Wed Mar 31 09:02:20 2021 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 F0A993A2D6E for ; Wed, 31 Mar 2021 09:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYgFXJL2lmD7 for ; Wed, 31 Mar 2021 09:02:07 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F4C3A2CBF for ; Wed, 31 Mar 2021 09:02:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ce9jJipSdWWAntzUw42IofGel+sFPrx5vbi3UL2vLKmxT3o4akHyEt0qYpvPHyMfNxu5ZqWnTWvGIt8AfVpn3MY8rp9jg/GJJVELBRzurD6trKQz7MHwIQGIBmimH+YqCO9dj9x4X5nUig8rtLEIVFIEYO5DmGzZmABuzbMoP5Bf/vSa0jCC2DO6f9bhb2QLMrABaJDpFMrP0rw9Qfa0kFXWNqRUVUbltd2K/vDgyIkn0N3OYerKKrBLC/xZ79rlIb/8UnVXq8fgaDsvyJIL7YA5DSCVpM0jM2DGlMGSIWQ/dPJEiyNPVnbxSbsX5kysDjf67WzT92/1X3fo/mJX1Q== 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=rbE8shsKVtkzBucT2jJjVDKqEFLb7Nx9U6lZCdRXh/4=; b=ISUqmksyXmrJkCIwtgI0XTXbqsazRTks49k5rHiLqlVlZVJYS9wJsWbWRT7XvMYab4oeU8XBcIVkqU4kO35CK5yfFBtW+mcHhyGSYTdZKrmasVBiEx175ffOD0S0ZpyMLisCTKlR8Js8s7YpdDR4CFwe377cd2q/IS22Gz2ZXVrsVev2GPs/DSqXKREUfgovbr2fQdzf6C28pp9bROKd7yAa2YwXQXo2JVDxJOtWCvwqImjbZjSCtnGuIe8Qopix1MJZ+Rb8KJZpE3EPHnO2qEYclcw4F7KBq5zdhKLrraMuLhBztiQZxvHyOFTmvoF0eybQAyWE3Vqli5TUJ4JEZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rbE8shsKVtkzBucT2jJjVDKqEFLb7Nx9U6lZCdRXh/4=; b=JOqSnTWn4wv4PblHHgeodvAeGZMMCWHer6XZ1URXl7AJW4gPH2B4acnVYT8jWlDH8IbNMsqhzFkocaFTidT0McXa6A0PLh4tM/CMhO1kcsMMc76bGmj6tAKs3NTYGE6sZn4+vH1J9O2VjzUZ37Nak7ZK0fCYTs6TFItKmGKSWPQ= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5702.eurprd07.prod.outlook.com (2603:10a6:20b:9d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.16; Wed, 31 Mar 2021 16:01:58 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3999.027; Wed, 31 Mar 2021 16:01:58 +0000 From: tom petch To: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= , "Aseem Choudhary (asechoud)" , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match Thread-Index: AdcbGExc8OTG49eVSoeJejnhX1jHZwAENNWA///CiICAAHf9AP//j5kA/+nm8rCALIiQbA== Date: Wed, 31 Mar 2021 16:01:58 +0000 Message-ID: References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> <20210317155834.nz6cv4mefwxrjgmq@anna.jacobs.jacobs-university.de> <4BBA1D6B-F2CC-4099-A640-88F003327529@cisco.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telefonica.com; dkim=none (message not signed) header.d=none;telefonica.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f69e4c94-8f4e-44a8-650d-08d8f45e5063 x-ms-traffictypediagnostic: AM6PR07MB5702: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gXOAQ2W+UfyGrGxvT/cgo/rNuuoWo9z/FX/YmZKB3L0osbh9xprnr46uVLzzLmTqUOidFWrjBQoXKHUgT1rFaHyogcankyfNccAOIrlIajaeotkU4SD9YNo0DnKvBtnzoZeEJXX7FXt1SdipGrUpc4CZ9erYzq6KeGm+toNhp/0OfNvTRpsq1Plo8WvjvQ2rg7CL6B8+IT8RRoAlXlnRUVeHC6TQGl+HTulV4SBDQVYk+L/F/EVU+wQ/FN8s1vpApxjSfGJSVH6JZMmO4RRphSL+U/S7rV1nuQ4DI+MDgtXWdqB4kHCW6rEDZ6n7fTCXJSIGNo2hOU6UFOQbxURpHeag463ptwQH+Gr2Bhsb20Jjrb28Uu0t63wrt/SIrpCX00UCt3by0VaD4A/tNTJGnnTrVUVsYk9rDovvGGmsRJz03LecSVeweuUoLvoNZIobFH/EF6MKLTVSpzC2fVy9q/R3G1+fzqauWDwFaL6p9cSdxMOS5fOScBEwbRxtPdx9lX5wLuWgg8FMTFvm5uvPXPHgcFNZjnH1PhFhkbbEIRgM0CcIrA+tajnLioXcSSrBJ8pfKcEypHt4Hp5xvZENH9p+1OsfVOT3cZYHCmatriu266mqL9Cfgf85U16VERW2hS0yaJvBmWn2M53RZFG9ie5T4gWMgStJ/Mp9XYgnyzE375l+s0YOwrSuxjlrw1P0YojqBrc2iOWyia7dgbAB4//SJCFI1wU3nERJpNmSJfM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(39860400002)(396003)(136003)(376002)(4326008)(55016002)(9686003)(38100700001)(83380400001)(66946007)(64756008)(26005)(66574015)(33656002)(186003)(66446008)(66556008)(296002)(316002)(478600001)(110136005)(52536014)(53546011)(6506007)(71200400001)(5660300002)(966005)(86362001)(8936002)(2906002)(76116006)(91956017)(66476007)(8676002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?NEJIc1BhWTdsc3R3V0k0NS9IcWIxWVgzTFBwL1lWTURiVDV4TDZBdlNHZmU4?= =?utf-8?B?ZUc0L1Uva2ROOUZwSFJPNnR6M3pwelVLWFhqb1lqb0hlanI0SXhaK1Z4QUxq?= =?utf-8?B?VmNBaWxUcXhQZGRzejg0VkJ2cEwxYmJXM1B2UkZKVVlCQlVUSjhxMjRGZmlU?= =?utf-8?B?Mkp6ZFhhaDVCamRYV2d1YmxQYzdwVkVwK0JEVXVBT1grMVdFZkNhYUIvcE5s?= =?utf-8?B?a0dtNkRLVjc2c0VldkVyR0kwYWlWUjM3bjh2T1dqbjFSK0xMYWtmVys1Rm5z?= =?utf-8?B?WWFyRW81MVNLbVdlS29iQy9nUlpRNW13c1FXM29CMm9YdS9JZ0ovY0VJNzRG?= =?utf-8?B?Q0loQVRUOFduSE1iVUhZRnhWUFd2TGQ3Y0pwSEtLWkVqSDNVbEl0UWp5NzBH?= =?utf-8?B?NG1wSDZ1allDcjZNTWdtK0RUamwyZkxTVWdxZC9GVFdvbWY4azlkY0NUM0cx?= =?utf-8?B?TlR3YnJZa25pS1dhWFR4cS8weUN4dXV3Qlc2VndLRW5adWNMSExFRmFuekZv?= =?utf-8?B?cEkxekpodStjdFhKZzdPbkszZTdEN0lKbi9KL1cwNnQ0VTdpeE9Wb0Ridk9h?= =?utf-8?B?VWNpTEROQlplMlRidGVhWFVGQWxiWWNUVlhpS3ZEbGlzR0g2ZWhieldmc1Rx?= =?utf-8?B?eHEySHR0VkxmbDVuMGp3bnZHaDVhZXU4a1c5ODJrUE9TYjkxTFJ1MlA2RW00?= =?utf-8?B?aWpMWDJuL0pVZFZibUl6ajhGODBFZzNGUkowbDd4QWcrZTV1akJSaWF0QkY2?= =?utf-8?B?bDR1Zm5lb3lRMWJaaHVZNFlDWUVFN2cyVHBtQWl1RlZ5MDNFbGtiT1NQODY1?= =?utf-8?B?OXRNbjV6Y0F2WHp4S0I3RVFWUXBuRGNFQVJ3bDVLMkhqWS9ZUWpZenZvMy9K?= =?utf-8?B?M0hWRnhBSUhweW0rZ0ZQNFRIU1JZdWNmaHdmdThwUXlzRHRHR1RJMEZZcHAy?= =?utf-8?B?ZWxYU0pvWFltSWhQRFJMVkRjeXNlNlVFMFl5bTNMbVRvOGVVVzdoRW9PV1RX?= =?utf-8?B?S0UxQW5SOFZsdDhlSWo5K1ZtRkV0VVpDN1R0SVZWNVNwQU5SUGJWTnV2R0k0?= =?utf-8?B?NHpCaXROcXc5TzN0ZzQ5WUFZODdpMzRrU1FYN3BpTklIQVZmNE4xRjBnc21y?= =?utf-8?B?MFViYW84bHM4RE9JVHhmMExISTYwSVF5NUpEQ29IWkhsOWlQcTBnb3VZNkJh?= =?utf-8?B?a0tyVXdQb0NFekk4TkY2ekNuMWVzL2VUUm51bjB5UlFTVENib2hyVS8rWDAx?= =?utf-8?B?MkdzZEttZHN6T0d2VHRoVUJGSWVrZW5JRkV5SFg5V1ZXbDI2QmIxZ2RVS3Zr?= =?utf-8?B?RHE4VDB1VjFMQWxkaTVBSW9Kc0VXSjVlRTBxODl1MUZSUmIzc1RodWI3MmZB?= =?utf-8?B?UTRGaURwclNVUDkzTGpOR1RQeStpWlYvNm9rN25XZGpkcHFFa2tieVpHbmVW?= =?utf-8?B?eXNWTnljbDl2Yk1wMVJHdG5vWktodWppbUxldEhGNkltNFJjRHQrY1ZGUHU2?= =?utf-8?B?Z1ErSGVpaUFOem9kSU5RTzJmR09BbC9kS2YyS1BhZUFIM0laZ0M3aHBpdEJL?= =?utf-8?B?VzRoQ1cySzE3Yy9BbVdrbFNZejNDTVdvejY1ejFPa2hXZGtCR1RMQlVuM3Q5?= =?utf-8?B?bHJPM0NramlGRm1ZVXd1MjZDckZpbHNIeGwzTlptVy9mSW1lRlVyeFlCaVZF?= =?utf-8?B?c0NUVXdvZkpPcDNxeXdsRkhTKzdIamxFcktCQ3p3ZFFCWmZhaVB3Nm9aeitT?= =?utf-8?Q?sbPwuOzlubr0j6hxn0=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f69e4c94-8f4e-44a8-650d-08d8f45e5063 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2021 16:01:58.4355 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: er9tY68KsX7fbcS7+voa9G50f9PQ4HddWwzxF2SgZtQIyO/LixO18QZFb6Fr1r6rAbdAFxcsku3jKME2cYcv4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5702 Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 16:02:19 -0000 RnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE9zY2Fy IEdvbnrDoWxleiBkZSBEaW9zIDxvc2Nhci5nb256YWxlemRlZGlvc0B0ZWxlZm9uaWNhLmNvbT4K U2VudDogMzEgTWFyY2ggMjAyMSAxMjowNwoKQWdyZWUgdG9vLAoKSXQgbWFrZXMgc2Vuc2UgdG8g ImdlbmVyYWxpemUiIHRoZSBjb25jZXB0IG9mIHNldHMgdGhhdCBjYW4gYmUgc2hhcmVkIGJldHdl ZW4gQUNMcywgc28gdGhleSBjYW4gYmUgdXNlZCB3aXRoIG90aGVyIGZpZWxkcyBiZXlvbmQgdGhv c2UgYWxyZWFkeSBpZGVudGlmaWVkIHdpdGggb3VyIHVzZSBjYXNlcyAocHJlZml4ZXMgYW5kIHBv cnRzL3BvcnQgcmFuZ2VzKSAuCgpTbywgcXVlc3Rpb24gZm9yIE5ldG1vZCBXRyBjaGFpcnMsIHdo YXQgd291bGQgYmUgdGhlIHByb2NlZHVyZSB0byBpbmNsdWRlIHN1Y2ggZmVhdHVyZSBpbiB0aGUg QUNMIG1vZHVsZSwgZ2l2ZW4gdGhhdCBpdCBpcyBkZWZpbmVkIGluICBhbiBhbHJlYWR5IHB1Ymxp c2hlZCBSRkM/IElzIGl0IHZpYSBhIG5ldyBkcmFmdCBkZXNjcmliaW5nIGp1c3QgdGhlIGV4dGVu c2lvbiBhbmQgcmVmZXJlbmNpbmcgdGhlIG9yaWdpbmFsIFJGQyBhbmQgaW5jbHVkaW5nIHRoZSB1 cGRhdGVkIHlhbmc/IE9yIGl0IGlzIGFuIHVwZGF0ZSBvZiB0aGUgZXhpc3RpbmcgUkZDIGFkZGlu ZyB0aGUgbmV3IGZ1bmN0aW9uYWxpdHkgKGZ1bGwgZGVzY3JpcHRpb24gYW5kIGZ1bGwgeWFuZyk/ IEkgYW0gYXNzdW1pbmcgdGhlIHdvcmsgaW1wbGllcyBjcmVhdGluZyBhIG5ldyByZXZpc2lvbiBv ZiB0aGUgbW9kdWxlLgoKPHRwLgpOZXcgcmV2aXNpb24gb3IgbmV3IG1vZHVsZT8gIFJGQzc5NTAg bGF5cyBkb3duIHdoYXQgY2FuIGJlIGNoYW5nZWQgaW4gYSBuZXcgcmV2aXNpb24gb2YgYSBtb2R1 bGUgYW5kIGl0IHdvdWxkIGJlIGdvb2QgdG8gc2VlIGluIHN1bW1hcnkgd2hhdCB5b3VyIHJldmlz ZWQgWUFORyB3b3VsZCBsb29rIGxpa2UuICBJIHN1c3BlY3QgdGhhdCBpdCB3b3VsZCBnbyBiZXlv bmQgd2hhdCBpcyBwZXJtaXR0ZWQgaW4gYSByZXZpc2lvbiBpZSB5b3UgYXJlIHByb3Bvc2luZyBh IG5ldyBtb2R1bGUsIG5ldyBuYW1lIChidXQgSSBjb3VsZCBiZSB3cm9uZzotKC4KCkVpdGhlciB3 YXksIGl0IGlzIGFuIFJGQy4gSWYgdGhlIGNoYW5nZXMgZmFsbCB3aXRoaW4gdGhvc2UgcGVybWl0 dGVkIHRoZW4gSSB3b3VsZCBzdGlsbCBleHBlY3QgYSByZXBsYWNlbWVudCBSRkMsIGFzIGhhcyBo YXBwZW5lZCB3aXRoIGEgbnVtYmVyIG9mIFlBTkcgbW9kdWxlcywgZS5nLiB0aG9zZSB0cmlnZ2Vy ZWQgYnkgTk1EQS4KClRoZSBjaGFpcnMgY2FuIGd1aWRlIHlvdSBvbiBwcm9jZWR1cmUgYnV0IGl0 IGlzIHRoZSBXRyBtZW1iZXJzLCB5b3UsIG1lIGFuZCBldmVyeW9uZSBlbHNlIHdobyBoYXZlIHRv IGRvIHRoZSB3b3JrIGFuZCBzbyBkZWNsYXJlIHRoZWlyIHdpbGxpbmduZXNzLCBvciBub3QsIHRv IHRha2UgdXAgdGhlIHdvcmsgd2hpY2ggdGhlIGNoYWlycyB0aGVuIHVzZSB0byBkZWNpZGUgd2hl dGhlciBvciBub3QgdGhlIHdvcmsgc2hvdWxkIGhhcHBlbiBpbiB0aGUgV0cuCgpUb20gUGV0Y2gu CgpCZXN0IFJlZ2FyZHMsCgpPc2NhcgoKLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0KRGU6IEFz ZWVtIENob3VkaGFyeSAoYXNlY2hvdWQpIDxhc2VjaG91ZEBjaXNjby5jb20+CkVudmlhZG8gZWw6 IG1pw6lyY29sZXMsIDE3IGRlIG1hcnpvIGRlIDIwMjEgMTc6MTYKUGFyYTogSnVlcmdlbiBTY2hv ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+CkNDOiBPc2Nh ciBHb256w6FsZXogZGUgRGlvcyA8b3NjYXIuZ29uemFsZXpkZWRpb3NAdGVsZWZvbmljYS5jb20+ OyBuZXRtb2RAaWV0Zi5vcmcKQXN1bnRvOiBSZTogW25ldG1vZF0gUmVxdWVzdCBmb3IgaW1wcm92 ZW1lbnQgaW4gQUNMIFlBTkcgTW9kZWw6IGFkZCBwcmVmaXgtbGlzdCB0byB0aGUgbWF0Y2gKCkkg YWdyZWUsIGEgdGVtcGxhdGUgYmFzZWQgYXBwcm9hY2ggd29ya3Mgd2VsbCBhcyBpdCBoZWxwcyB0 byBzaGFyZSB0aGUgc2V0IG9mIGZpZWxkcyBiZXR3ZWVuIEFDTHMuCgotdGhhbmtzLApBc2VlbQoK 77u/T24gMy8xNy8yMSwgODo1OCBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6CgogICAgSSBub3cgdW5kZXJzdGFu ZCB0aGF0IHRoZSBvcmlnaW5hbCByZXF1ZXN0IHdhcyBhYm91dCB0d28gdGhpbmdzOgoKICAgIC0g YWxsb3dpbmcgc2V0cyBvZiBwcmVmaXhlcyBpbiBhbiBBQ0wgKGluc3RlYWQgb2YganVzdCBhIHNp bmdsZSkKICAgIC0gc2hhcmluZyBvZiBzZXRzIG9mIHByZWZpeGVzIGJldHdlZW4gQUNMcwoKICAg IEFuZCB5ZXMsIGlmIHRoZSBXRyBnb2VzIHRoZXJlLCB0aGVuIG9mIGNvdXJzZSB0aGUgc2FtZSBx dWVzdGlvbnMgd2lsbAogICAgY29tZSB1cCBmb3IgYWxsIHRoZSBvdGhlciBwb3NzaWJsZSBoZWFk ZXIgZmllbGRzLi4uCgogICAgLSBhbGxvd2luZyBzZXRzIG9mIHBvcnRzL3BvcnQgcmFuZ2VzCiAg ICAtIHNoYXJpbmcgb2Ygc2V0cyBvZiBwb3J0cy9wb3J0IHJhbmdlcyBiZXR3ZWVuIEFDTHMKCiAg ICBbLi4uXQoKICAgIC9qcwoKICAgIE9uIFdlZCwgTWFyIDE3LCAyMDIxIGF0IDAzOjQ5OjExUE0g KzAwMDAsIEFzZWVtIENob3VkaGFyeSAoYXNlY2hvdWQpIHdyb3RlOgogICAgPiBIaSwKICAgID4K ICAgID4gU2ltaWxhcmx5LCB0aGVyZSBpcyBOeE0gaXNzdWUgd2hlbiB0aGVyZSBhcmUgbW9yZSB0 aGFuIG9uZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIHBvcnQvcG9ydCByYW5nZXMuCiAgICA+CiAg ICA+IC10aGFua3MsCiAgICA+IEFzZWVtCiAgICA+CiAgICA+IE9uIDMvMTcvMjEsIDU6MjkgQU0s ICJuZXRtb2Qgb24gYmVoYWxmIG9mIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU+IHdyb3RlOgogICAgPgogICAgPiAgICAgSGksCiAgICA+CiAgICA+ICAgICBsZXQgbWUg Y2hlY2sgd2hldGhlciBJIHVuZGVyc3RhbmQgeW91ciByZXF1ZXN0IGNvcnJlY3RseTogSSBoZWFy ZCB5b3UKICAgID4gICAgIHNheWluZyB0aGF0IHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUKICAgID4K ICAgID4gICAgICAgICAgICAgbGVhZi1saXN0IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yayB7CiAg ICA+ICAgICAgICAgICAgICAgdHlwZSBpbmV0OmlwdjYtcHJlZml4OwogICAgPiAgICAgICAgICAg ICAgIGRlc2NyaXB0aW9uCiAgICA+ICAgICAgICAgICAgICAgICAiRGVzdGluYXRpb24gSVB2NiBh ZGRyZXNzIHByZWZpeC4iOwogICAgPiAgICAgICAgICAgICB9CiAgICA+CiAgICA+ICAgICBpbnN0 ZWFkIG9mIGp1c3QKICAgID4KICAgID4gICAgICAgICAgICAgbGVhZiBkZXN0aW5hdGlvbi1pcHY2 LW5ldHdvcmsgewogICAgPiAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcHY2LXByZWZpeDsKICAg ID4gICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgPiAgICAgICAgICAgICAgICAgIkRlc3Rp bmF0aW9uIElQdjYgYWRkcmVzcyBwcmVmaXguIjsKICAgID4gICAgICAgICAgICAgfQogICAgPgog ICAgPiAgICAgKGFuZCBzaW1pbGFyIGNoYW5nZXMgZm9yIHRoZSBvdGhlciBJUCBwcmVmaXggcmVs YXRlZCBsZWFmcykuCiAgICA+CiAgICA+ICAgICBXaGlsZSBzdWNoIGEgZGlyZWN0IGNoYW5nZSBt YXkgYmUgZGlmZmljdWx0LCBnaXZlbiB0aGF0IHRoZSBoZWFkZXIKICAgID4gICAgIGZpZWxkcyBh cmUgZGVmaW5lZCBpbiBhIGNob2ljZSwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFkZAogICAg PiAgICAgYWRkaXRpb25hbCBjaG9pY2VzIGZvciBzZXRzIG9mIHByZWZpeGVzLiBTbyBmcm9tIHRo ZSBZQU5HIHNpZGUsIHRoaXMKICAgID4gICAgIHNlZW1zIHRvIGJlIHNvbWV0aGluZyBwb3NzaWJs ZSB0byBhZGRyZXNzIHdpdGhvdXQgdG9vIG11Y2ggdHJvdWJsZS4KICAgID4KICAgID4gICAgIFdo ZXRoZXIgaW1wbGVtZW50b3JzIGFyZSBoYXBweSB3aXRoIHN1cHBvcnRpbmcgc3VjaCBhIGNoYW5n ZSBpcwogICAgPiAgICAgc29tZXRoaW5nIG90aGVycyBoYXZlIHRvIGNvbW1lbnQgb24uCiAgICA+ CiAgICA+ICAgICAvanMKICAgID4KICAgID4gICAgIE9uIFdlZCwgTWFyIDE3LCAyMDIxIGF0IDEw OjMxOjEwQU0gKzAwMDAsIE9zY2FyIEdvbnrDoWxleiBkZSBEaW9zIHdyb3RlOgogICAgPiAgICAg PiBEZWFyIG5ldG1vZCB3ZyBjb2xsZWFndWVzLAogICAgPiAgICAgPgogICAgPiAgICAgPiAgICAg ICAgICAgICAgICAgVGhlIGlldGYtYWNsIFlBTkcgbW9kZWwgZGVmaW5lZCBpbiBSRkMgODUxOSBh bGxvd3MgdG8gY3JlYXRlIHJ1bGVzLCBhbmQgZm9yIGVhY2ggYSBydWxlLCBpbiBjYXNlIG9mIElQ djQvSVB2NiB5b3UgY2FuIHNwZWNpZnkgaW4gdGhlIG1hdGNoIHRoZSBzb3VyY2UtbmV0d29yayBh bmQgZGVzdGluYXRpb24tbmV0d29yay4gVGhlIHNvdXJjZS1uZXR3b3JrIChvciBlcXVhbGx5IHRo ZSBkZXN0aW5hdGlvbiBuZXR3b3JrKSBpcyBpbiB0aGUgbW9kZWwgYW4gYWRkcmVzcyBwcmVmaXgu IEluIG91ciB1c2UgY2FzZSBpbiBUZWxlZm9uaWNhIHdlIGFyZSBzcGVjaWZ5aW5nIGEgcHJlZml4 LWxpc3QgZm9yIHNvdXJjZSBuZXR3b3JrIGFuZCBhbm90aGVyIHByZWZpeCBsaXN0IGZvciBkZXN0 aW5hdGlvbiBuZXR3b3JrLiBJZiB5b3UgaGFkIHRvIGNyZWF0ZSB0aGlzIGJlaGF2aW9yIHVzaW5n IHRoZSBBQ0wgbW9kZWwsIHlvdSB3b3VsZCBuZWVkIHRvIGNyZWF0ZSBOeE0gcnVsZXMuIEJlc2lk ZXMsIHRoZSBtYW5hZ2VtZW50IG9mIHRob3NlIHJ1bGVzIHdvdWxkIGJlIG1vcmUgY29tcGxleC4K ICAgID4gICAgID4KICAgID4gICAgID4gICAgICAgICAgICAgICAgIFRoZSByb3V0aW5nIHBvbGlj eSBtb2RlbCBoYXMgdGhlIGNvbmNlcHQgb2YgcHJlZml4LXNldHMsIGJ1dCBpcyBhIHNlcGFyYXRl IG1vZGVsIChhbmQgYSBkaWZmZXJlbnQgdXNlIGNhc2UpLgogICAgPiAgICAgPgogICAgPiAgICAg PiAgICAgICAgICAgICAgICAgVGhlIGZ1bmN0aW9uYWxpdHkgb2Ygc3BlY2lmeWluZyBhIHByZWZp eCBsaXN0IGZvciBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGluIGFjY2VzcyBjb250cm9sIGxpc3Rz IGlzIGF2YWlsYWJsZSBpbiBtb3N0IHZlbmRvcnMgdGhhdCBJIGFtIGF3YXJlIHRvZGF5LiBIZW5j ZSwgaXQncyBhIHByZXR0eSBzdGFuZGFyZCBmdW5jdGlvbmFsaXR5LgogICAgPiAgICAgPgogICAg PiAgICAgPiAgICAgICAgICAgICAgICAgRG8geW91IHRoaW5rIGl0IGlzIHVzZWZ1bCB0byBhZGQg dGhpcyBmdW5jdGlvbmFsaXR5IHRvIHRoZSBBQ0wgWUFORyBtb2RlbD8gSWYgeWVzLCB3aGF0IHdv dWxkIGJlIHRoZSBwcm9jZWR1cmUsIGdpdmVuIHRoYXQgQUNMIGlzIGFscmVhZHkgZGVmaW5lZCBp biBhbiBleGlzdGluZyBSRkM/CiAgICA+ICAgICA+CiAgICA+ICAgICA+ICAgICAgICAgICAgICAg ICBCZXN0IFJlZ2FyZHMsCiAgICA+ICAgICA+CiAgICA+ICAgICA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBPc2NhcgogICAgPiAgICAgPgogICAgPiAgICAgPgogICAgPiAgICAgPgog ICAgPiAgICAgPgogICAgPiAgICAgPgogICAgPiAgICAgPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwogICAgPiAgICAgPgogICAgPiAgICAgPiBFc3RlIG1lbnNhamUgeSBzdXMgYWRq dW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUg Y29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBh cmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBu byBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRl IHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2lu IGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdp c2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwg bGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBt aXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4KICAgID4gICAgID4KICAgID4g ICAgID4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBw cml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSBy ZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCBy ZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUg aXQuCiAgICA+ICAgICA+CiAgICA+ICAgICA+IEVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBz ZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRl ciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNv IGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2 b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBk ZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBz ZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNs YcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1v cy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZp YSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvCiAgICA+CiAgICA+ICAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiAgICA+ICAgICA+IG5ldG1v ZCBtYWlsaW5nIGxpc3QKICAgID4gICAgID4gbmV0bW9kQGlldGYub3JnCiAgICA+ICAgICA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCiAgICA+CiAgICA+CiAg ICA+ICAgICAtLQogICAgPiAgICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgKICAgID4gICAgIFBob25lOiArNDkgNDIxIDIwMCAz NTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkKICAgID4g ICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLz4KICAgID4KICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCiAgICA+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0CiAgICA+ ICAgICBuZXRtb2RAaWV0Zi5vcmcKICAgID4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kCiAgICA+CgogICAgLS0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJICiAgICBQaG9uZTogKzQ5 IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt YW55CiAgICBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNv YnMtdW5pdmVyc2l0eS5kZS8+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkVz dGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8g Y29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRp ZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8s IHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxn YWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEg ZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3Rl IG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVk aWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7Nu LgoKVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2 aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFk ZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3Ig Y29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFk IGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQu CgpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBh byBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFk YSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVu dGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOh cmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOn w6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3Rh ciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1 IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUg aW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnD p8OjbwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRt b2QgbWFpbGluZyBsaXN0Cm5ldG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZAo=
  augment<= span style=3D"background-color:white;"> "ex:example" {
    <= font color=3D"#C586C0">leaf<= /font> bar {
     &n= bsp;= type empty;
     &n= bsp;= description
     &n= bsp;  "When present, the default value = for foo is 10.";
    }=
  }
}
 
 
In this case, when the leaf foo is not configured but the leaf bar is = present, the value of foo in the operational datastore should be 10 (rather= than 0).
 
In this case, I think that it would be better/cleaner if the origin is= marked as system.
 
Maybe a better YANG description for bar could be: “When present,= the system overrides the default value of foo to 10.”
 
What is your and/or WG opinion?
 
Thanks again
 
Italo
 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: mercoled=EC 20 gennaio 2021 17:05
> To: Italo Busi <Italo.Busi@huawei.com>
> Cc: 'netmod@ietf.org' <netmod@ietf.org>
> Subject: Re: [netmod] Questions about how to assign default value= s with
> YANG
>
> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote:
> >
> > What about the case the leaf is not conditional (but still m= andatory false
> since a YANG default statement is defined)?
> >
> > May the server still decide not to use/implement this leaf i= n the operational
> datastore?
> >
> > For example, in appendix C.1 of RFC8342, auto-negotiation is= enabled by
> default.
> > What should be the behavior of a system which does not imple= ment auto-
> negotiation?
> > Return the value false or no value (in the operational datas= tore)?
> >
>
> Here are some of the rules I personally like:
>
> - <operational> is the ground truth about what a system ha= s and does
> - do not implement leafs that do not apply
>
> Hence, interfaces supporting auto-negotiation have either auto-
> negotiation/enabled =3D true or auto-negotiation/enabled =3D fals= e in
> <operational>. And interfaces not supporting auto-negotiati= on have nothing
> to report about auto-negotiation. Yes, I do not want to see auto-=
> negotiation/enabled =3D false on a loopback interface.
>
> My historic Ethernet interface from the last century would also n= ot report
> auto-negotiation/enabled in <operational>. You may hit appl= ications that love
> to have auto-negotiation/enabled available on all Ethernet interf= aces and then
> you end in a debate where the application developers tell you tha= t no
> information in <operational> may have many reasons (instrum= entation not
> implemented, access control rules, whatever and by reporting enab= led=3Dfalse
> you do them a favor) but the true answer in such a debate is ofte= n that
> modeling things as a boolean is simplistic since there are often = more than
> exactly two states (in this case, enabled, disabled, failed, not-= available, ...).
> So you settle on blaming the model writer. ;-)
>
> /js
>
> --
> Juergen Schoenwaelder       &n= bsp;   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587      &n= bsp;  Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103    &nbs= p;    <http= s://www.jacobs-university.de/>
 
 --_000_521a9ccd02e14d178a6e62971b4809eahuaweicom_-- From nobody Mon Mar 8 12:23:40 2021 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 67CE33A16BB for ; Mon, 8 Mar 2021 12:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 R3nZHgVmYWCB for ; Mon, 8 Mar 2021 12:23:36 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A345E3A16BA for ; Mon, 8 Mar 2021 12:23:36 -0800 (PST) Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DvV5062l4z67qS3 for ; Tue, 9 Mar 2021 04:17:40 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Mar 2021 21:23:35 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Mon, 8 Mar 2021 21:23:34 +0100 From: Italo Busi To: "'netmod@ietf.org'" Thread-Topic: Question about validation of the running datastore Thread-Index: AdcUWKEL4642SwgUTmapkFU2qHpl/g== Date: Mon, 8 Mar 2021 20:23:34 +0000 Message-ID: <05f29409f0344549aa0de1da574cd9ad@huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.24.210] Content-Type: multipart/alternative; boundary="_000_05f29409f0344549aa0de1da574cd9adhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Question about validation of the running datastore X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 20:23:38 -0000 --_000_05f29409f0344549aa0de1da574cd9adhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have a doubt about how and when the configured data in the running datast= ore can be validated. According to section 5.1.3 of RFC8342: MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]. In some cases, there are some complex semantic validation rules which canno= t be encoded in the rules defined in Section 8.1 of [RFC7950]. In this case the configuration is, from a semantic perspective, invalid and= cannot be applied, even if the configuration data tree is valid as defined= in Section 8.1 of [RFC7950]. It is not clear to me what is the expected behavior of the system when the = client provides such a configuration. One possible option is that the system accepts that configuration but it do= es not apply it. In this case, the configuration is written in the datastore, but never applied in the datastore. Another possible option is that the system accepts that configuration, it d= oes not apply it but returns to the client a warning message. Also in this = case, the configuration is written in the datastore, but never ap= plied in the datastore. A third option is that the system rejects that configuration and returns to= the client an error message. In this case, the configuration is not writte= n in the datastore and thus never applied in the da= tastore. I am wondering whether all these implementation options are allowed or whet= her there are some standard requirements/restrictions on some of them. Thanks, Italo --_000_05f29409f0344549aa0de1da574cd9adhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have a doubt about how and when the configured dat= a in the running datastore can be validated.

 

According to section 5.1.3 of RFC8342:

 

   <running> MUST always be a valid = configuration data tree, as defined

   in Section 8.1 of [RFC7950].=

 

In some cases, there are some complex semantic valid= ation rules which cannot be encoded in the rules defined in Section 8.1 of = [RFC7950].

 

In this case the configuration is, from a semantic p= erspective, invalid and cannot be applied, even if the configuration data t= ree is valid as defined in Section 8.1 of [RFC7950].

 

It is not clear to me what is the expected behavior = of the system when the client provides such a configuration.

 

One possible option is that the system accepts that = configuration but it does not apply it. In this case, the configuration is = written in the <running> datastore, but never applied in the <oper= ational> datastore.

 

Another possible option is that the system accepts t= hat configuration, it does not apply it but returns to the client a warning= message. Also in this case, the configuration is written in the <runnin= g> datastore, but never applied in the <operational> datastore.

 

A third option is that the system rejects that confi= guration and returns to the client an error message. In this case, the conf= iguration is not written in the <running> datastore and thus never ap= plied in the <operational> datastore.

 

I am wondering whether all these implementation opti= ons are allowed or whether there are some standard requirements/restriction= s on some of them.

 

Thanks, Italo

 

--_000_05f29409f0344549aa0de1da574cd9adhuaweicom_-- From nobody Mon Mar 8 20:07:54 2021 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 3AEC43A0E32; Mon, 8 Mar 2021 20:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7yBgcBqKMFMT; Mon, 8 Mar 2021 20:07:47 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2803A0E30; Mon, 8 Mar 2021 20:07:47 -0800 (PST) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DvhNW5MxFz67wws; Tue, 9 Mar 2021 12:01:47 +0800 (CST) Received: from fraeml702-chm.china.huawei.com (10.206.15.51) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Tue, 9 Mar 2021 05:07:42 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Tue, 9 Mar 2021 05:07:42 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.181]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0513.000; Tue, 9 Mar 2021 12:05:25 +0800 From: Qin Wu To: "pauljeong@skku.edu" , "i2nsf@ietf.org" , "netmod@ietf.org" , "draft-ietf-i2nsf-capability-data-model@ietf.org" , "draft-ietf-netmod-eca-policy@ietf.org" Thread-Topic: ECA Policy: Relationship with I2NSF YANG capability-data-model Thread-Index: AdcUmOrGLG+NBoqATgansS8BtVSEKw== Date: Tue, 9 Mar 2021 04:05:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] ECA Policy: Relationship with I2NSF YANG capability-data-model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 04:07:49 -0000 SGksIA0KT25lIG9mIGlzc3VlcyByYWlzZWQgb24gZHJhZnQtaWV0Zi1uZXRtb2QtZWNhLXBvbGlj eS0wMCBkdXJpbmcgYWRvcHRpb24gY2FsbCBpcyBSZWxhdGlvbnNoaXAgd2l0aCBJMk5TRiBZQU5H IGNhcGFiaWxpdHktZGF0YS1tb2RlbC4NCkkgYmVsaWV2ZSB0d28gd29yayBpbiBJMk5TRiBXRyBh cmUgcmVsYXRlZCB0byBkcmFmdC1pZXRmLW5ldG1vZC1lY2EtcG9saWN5IChodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtZWNhLXBvbGljeS0wMSkuIA0KMS4gUkZD ODMyOSwgd2hpY2ggZGVmaW5lIEVDQSBhcyBJbXBlcmF0aXZlIHBhcmFkaWdtIHJlbGF0ZWQgdG8g ZGF0YSBwYWNrZXQgb3IgZGF0YSBmbG93IHRyZWF0bWVudCwgdGhyZWUgY2xhdXNlIGFyZSBkZWZp bmVkDQogYS4gQW4gRXZlbnQgY2xhdXNlIGlzIHVzZWQgdG8gdHJpZ2dlciB0aGUgZXZhbHVhdGlv biBvZiB0aGUgQ29uZGl0aW9uIGNsYXVzZSBvZiB0aGUgSTJOU0YgUG9saWN5IFJ1bGUuIA0KIGIu IEEgQ29uZGl0aW9uIGNsYXVzZSBpcyB1c2VkIHRvIGRldGVybWluZSB3aGV0aGVyIG9yIG5vdCB0 aGUgc2V0IG9mIEFjdGlvbnMgaW4gdGhlIEkyTlNGIFBvbGljeSBSdWxlIGNhbiBiZSBleGVjdXRl ZCBvciBub3QuIA0KIGMuIEFuIEFjdGlvbiBjbGF1c2UgZGVmaW5lcyB0aGUgdHlwZSBvZiBvcGVy YXRpb25zIHRoYXQgbWF5IGJlIHBlcmZvcm1lZCBvbiB0aGlzIHBhY2tldCBvciBmbG93Lg0KSSB0 aGluayB0aGlzIEVDQSBwYXJhZGlnbSBpcyBhbHNvIHNlY3VyaXR5IHBvbGljeSBzcGVjaWZpYywg bm90IGdlbmVyaWMgZW5vdWdoDQoNCjIuIGRyYWZ0LWlldGYtaTJuc2YtY2FwYWJpbGl0eS1kYXRh LW1vZGVsLCB3aGljaCB1c2UgUkZDODUyOSBhcyBiYXNpcyBmb3IgdGhlIGRlc2lnbiBvZiB0aGUg Y2FwYWJpbGl0eSBtb2RlbCBpbiBkcmFmdC1pZXRmLWkybnNmLWNhcGFiaWxpdHktZGF0YS1tb2Rl bDsNCg0KSGVyZSBpcyB0aGUgRUNBIGRlZmluaXRpb24gd2UgcHJvcG9zZWQgaW4gZHJhZnQtaWV0 Zi1uZXRtb2QtZWNhLXBvbGljeQ0KIGEuIFRoZSBldmVudCBpcyBkZWZpbmVkIGFzIG9uZSByZWxh dGVkIHRvIGRhdGFzdG9yZSBzdWJzY3JpcHRpb24gb3IgZXZlbnQgc3RyZWFtIHN1YnNjcmlwdGlv bi4NCiBiLiBDb25kaXRpb246IENvbmRpdGlvbiBjYW4gYmUgc2VlbiBhcyBhIGxvZ2ljYWwgdGVz dCB0aGF0LCBpZiBzYXRpc2ZpZWQgb3IgZXZhbHVhdGVkIHRvIGJlIHRydWUsIGNhdXNlcyB0aGUg YWN0aW9uIHRvIGJlIGNhcnJpZWQgb3V0LiANCiBjLiBBY3Rpb246IFVwZGF0ZSBvciBpbnZvY2F0 aW9uIG9uIGxvY2FsIG1hbmFnZWQgb2JqZWN0IGF0dHJpYnV0ZXMuDQpBcyB5b3UgY2FuIHNlZSBF Q0EgaXMgbm90IHRpZWQgdG8gc3BlY2lmaWMgdGVjaG5vbG9neSwgdG8gY2xhcmlmeSB0aGUgcmVs YXRpb25zaGlwIHdpdGggSTJOU0YgWUFORyBjYXBhYmlsaXR5LWRhdGEtbW9kZWwsIHdlIHRoaW5r DQpOU0YgY2FuIGJlIGFuIGV4YW1wbGUgdXNlIGNhc2UgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWVj YS1wb2xpY3kuIA0KTGV0IHVzIGtub3cgaWYgdGhpcyBwcm9wb3NhbCBtYWtlIHNlbnNlIHRvIHlv dS4gVGhhbmtzIQ0KDQotUWluIChvbiBiZWhhbGYgb2YgYXV0aG9ycykNCi0tLS0t08q8/tStvP4t LS0tLQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBRaW4gV3UNCreiy83KsbzkOiAyMDIwxOoxMtTCMjPI1SAyMjozMA0KytW8/sjLOiB0b20gcGV0 Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb20+OyBEaHJ1diBEaG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5j b20+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0Ks63LzTogTmV0TW9kIFdHIENoYWly cyA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz47IE5FVE1PRCBHcm91cCA8bmV0bW9kQGlldGYub3Jn Pg0K1vfM4jogUmU6IFtuZXRtb2RdIEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXd3eC1uZXRtb2Qt ZXZlbnQteWFuZy0xMA0KDQpIaSwgVG9tOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5l dG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIHRvbSBwZXRjaA0Kt6LL zcqxvOQ6IDIwMjDE6jEy1MIyM8jVIDE5OjE0DQrK1bz+yMs6IERocnV2IERob2R5IDxkaHJ1di5p ZXRmQGdtYWlsLmNvbT47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQqzrcvNOiBOZXRN b2QgV0cgQ2hhaXJzIDxuZXRtb2QtY2hhaXJzQGlldGYub3JnPjsgTkVUTU9EIEdyb3VwIDxuZXRt b2RAaWV0Zi5vcmc+DQrW98ziOiBSZTogW25ldG1vZF0gQWRvcHRpb24gcG9sbCBmb3IgZHJhZnQt d3d4LW5ldG1vZC1ldmVudC15YW5nLTEwDQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEaHJ1diBEaG9keSA8ZGhydXYuaWV0ZkBnbWFpbC5jb20+ DQpTZW50OiAyMSBEZWNlbWJlciAyMDIwIDE3OjEyDQoNCkhpIExvdSwgV0csDQoNCkkgZmluZCB0 aGUgbW90aXZhdGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uIHRvIGJlIGZvY3VzZWQgb24gRUNBIGF0 IHRoZSBuZXR3b3JrIGRldmljZXMgKHdpdGggYWxsIHRoZSB0YWxrIGFib3V0IGlzc3VlcyB3aXRo IENlbnRyYWxpemVkIG5ldHdvcmsgbWFuYWdlbWVudCkuDQoNCkkgc2VlIHRoZSB2YWx1ZSBvZiBF Q0Egb24gdGhlIGNvbnRyb2xsZXIgYXMgd2VsbCwgc2F5IGEgY3VzdG9tZXIgbmV0d29yayBjb250 cm9sbGVyIG9yIGFuIG9yY2hlc3RyYXRvciBjYW4gc2V0IHRoZSBFQ0Egb24gYSBjZW50cmFsIGNv bnRyb2xsZXIgKHJlZmVyZW5jZSBBQ1ROIGluIFRFQVMgV0cpLiBQZXJoYXBzIHlvdSB3b3VsZCBj b25zaWRlciBhZGRpbmcgYSBzZW50ZW5jZSB0byBkZXNjcmliZSB0aGlzIGFzIHdlbGwuIFRoZSBj bGllbnQtc2VydmVyIHRlcm1pbm9sb2d5IGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCBjb3Zl cnMgaXQgYWxyZWFkeS4NCg0KQW5kIEkgZG8gc2VlIHZhbHVlIGluIHRoaXMgYW5kIHN1cHBvcnQg YWRvcHRpb24uDQoNCjx0cD4NCk15IHRha2UgaXMgdGhhdCB0aGUgSS1EIGlzIHVuY2xlYXIgb24g d2hhdCBFQ0EgaXMuDQoNCltRaW5dOiBUaGFua3MgVG9tLCBBZHJpYW4gcmFpc2VkIHRoZSBzaW1p bGFyIGlzc3VlIGFib3V0IHRoZSBhYnN0cmFjdCBpbXByb3ZlbWVudCBhbmQgd2Ugd2lsbCBhZGRy ZXNzIHRoaXMgaW4gdi0wMS4NCg0KRUNBIGhhcyBiZWVuIHdvcmtlZCBvbiBpbiBhdCBsZWFzdCB0 d28gSUVURiBXRyBBRkFJQ1QuICBJdCBjcm9wcGVkIHVwIGluIEkyUlMgYnV0IGFzIEkgcmVjYWxs LCBpdCB3YXMgYWxvbmcgdGhlIGxpbmVzIG9mICdUaGlzIGlzIEVDQScgICdObyBJdCBpcyBub3Qn ICAnWWVzIGl0IGlzJyB3aGljaCBnYXZlIG1lIHRoZSBpbXByZXNzaW9uIHRoYXQgRUNBIGlzIG5v dCBhIHdlbGwtZGVmaW5lZCwgb3Igd2VsbC11bmRlcnN0b29kLCB0ZXJtLg0KDQpNb3JlIHJlY2Vu dGx5LCBJMk5TRiBoYXZlIHByb2R1Y2VkIGEgWUFORyBjYXBhYmlsaXR5LWRhdGEtbW9kZWwgd2hp Y2ggaXMgNTUgcGFnZXMgb2YgRUNBLiAgTGFja2luZyBhIGRlZmluaXRpb24gaW4gdGhpcyBuZXRt b2QgSS1ELCBJIGFtIHVuY2xlYXIgd2hhdCB0aGUgcmVsYXRpb25zaGlwIGlzIGJldHdlZW4gdGhl IEkyTlNGIEktRCBhbmQgdGhlIG5ldG1vZCBJLUQsIHdoZXRoZXIgb3Igbm90IHRoZXkgYXJlIHVz aW5nIEVDQSBpbiB0aGUgc2FtZSBzZW5zZS4NCltRaW5dOiBJIGhhdmVuJ3QgZm9sbG93ZWQgY2xv c2VseSBvbiB3aGF0IGhhZCBiZWVuIGRvbmUgaW4gSTJOU0YuICBCdXQgSSBkaWQgdGFsayB3aXRo IHR3byBvZiBJMk5TRiBwcm9wb25lbnRzIGluIHRoaXMgeWVhci4gVGhleSB0ZW5kIHRvIGFncmVl IHRoZSBtb2RlbCBwcm9wb3NlZCBpbiBkcmFmdC13d3ggd2lsbCBzZXJ2ZSBhcyB0aGUgYmFzaXMg Zm9yIEkyTlNGIHNlY3VyaXR5IHBvbGljeSBtb2RlbCBvciBOU0YgZmFjaW5nIGludGVyZmFjZSBE TS4gVW5mb3J0dW5hdGVseSBJIGhhdmVuJ3Qgc2VlbiB0aGVpciB1cGRhdGUgdG8gZG8gdGhlIGFs aWdubWVudC4gSSBtaXNzZWQgdGhlaXIgSTJOU0YgcmVjaGFydGVyIGRpc2N1c3Npb24gbWVldGlu Zy4gQnV0IEkgd291bGQgYWxzbyBoaWdobHkgcmVjb21tZW5kIHRoZXkgaW1wb3J0IHRoZSBtb2Rl bCBpbiBkcmFmdC13d3ggYW5kIHJldXNlIHNvbWUgb2YgdGhlc2UgYnVpbGRpbmcgYmxvY2suIEkg cGxhbiB0byByYWlzZSB0aGlzIGlzc3VlIGxhdGVyIG9uLg0KRm9yIEkyUlMgbW9kZWwsIGl0IHdh cyBwYWNrZXQgZm9yd2FyZGluZyBwb2xpY3kgbW9kZWwsIHdoaWNoIGhhcyBiZWVuIGV4cGlyZWQg Zm9yIG1hbnkgeWVhcnMuIElmIHRoYXQgZHJhZnQgbmVlZHMgdG8gYmUgcmV2aXZlZCwgSSB0aGlu ayB3ZSBjYW4gZm9sbG93IHRoZSBzaW1pbGFyIGFwcHJvYWNoIGZvciBJMk5TRiBzZWN1cml0eSBw b2xpY3kgbW9kZWwuDQoNClRoYW5rcyENCkRocnV2DQoNCk9uIFR1ZSwgRGVjIDgsIDIwMjAgYXQg Mzo1OSBBTSBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4NCj4gVGhpcyBl bWFpbCBiZWdpbnMgYSAyLXdlZWsgYWRvcHRpb24gcG9sbCBmb3I6DQo+DQo+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13d3gtbmV0bW9kLWV2ZW50LXlhbmctMTANCj4NCj4gUGxl YXNlIHZvaWNlIHlvdXIgc3VwcG9ydCBvciB0ZWNobmljYWwgb2JqZWN0aW9ucyBvbiBsaXN0IGJl Zm9yZSB0aGUgDQo+IGVuZCBvZiBEZWNlbWJlciAyMSwgYW55IHRpbWUgem9uZS4NCj4NCj4gVGhh bmsgeW91IQ0KPg0KPiBOZXRtb2QgQ2hhaXJzDQo+DQo+IFBTIE5vdGUgdGhlIElQUiBwb2xsIGlz IHJ1bm5pbmcgY29uY3VycmVudGx5IGFzIHRoZSBwcml2YXRlIHJlc3BvbnNlIA0KPiBhbGwgaW5k aWNhdGVkIHRoYXQgbm8gSVBSIGV4aXN0cy4gIFRoZSBkcmFmdCB3aWxsIG5vdCBiZSBmb3JtYWxs eSANCj4gYWRvcHRlZCB1bnRpbCBib3RoIHRoZSBJUFIgYW5kIFdHIHBvbGxzIGFyZSBjb21wbGV0 ZS4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1v ZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1v ZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Tue Mar 9 08:46:50 2021 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 5A80D3A137B for ; Tue, 9 Mar 2021 08:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 E3DVKuT-HRjO for ; Tue, 9 Mar 2021 08:46:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F103A0F09 for ; Tue, 9 Mar 2021 08:46:46 -0800 (PST) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 004F114098F; Tue, 9 Mar 2021 17:46:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1615308404; bh=J/T4u8DszKzGUtwkft+m42l6Hiz8fokUiAreYfDCz4Q=; h=From:To:Date; b=kDsGoh3Ir8Mw0BwZCw5YlwOOeZv9oKk+BeNtc8BpJeYn4xMBWaKZqWdpKi+DMsjGP YisIwiW2rkoHyk6OQS/8MbyPfXZiovDAughw1hW+RE+pFhkn8pgaZV8kbOzsYWxFO9 No+88mNI06O4oElrCOaHo2/YEgeDHuQmLlFEMsPY= From: Ladislav Lhotka To: Italo Busi , 'Juergen Schoenwaelder' Cc: "'netmod@ietf.org'" In-Reply-To: <521a9ccd02e14d178a6e62971b4809ea@huawei.com> References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> Mail-Followup-To: Italo Busi , 'Juergen Schoenwaelder' , "'netmod@ietf.org'" Date: Tue, 09 Mar 2021 17:46:43 +0100 Message-ID: <87sg54cm18.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 16:46:49 -0000 Italo Busi writes: > Hi Juergen, > > Thanks again for your clear explanation on this topic > > I have found a similar but slightly different issue. In this case, a YANG= default statement exists in the base module but the intention with the aug= mentation is to "overwrite" the default value on the basis of another attri= bute, defined in the module which augments the base module. > > For example, I am wondering whether such a code is valid: Yes, this is valid, I'd just suggest: - remove the default statement for "foo", as it may be confusing to both hu= mans and tools - specify the default (both cases) in the description of "foo" A similar example is in the module ietf-ipv6-router-advertisements, e.g. le= af "min-rtr-adv-interval": https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1 Lada > > module example-base { > container example { > leaf foo { > type uint8; > default 0; > } > } > } > > module example-augment { > import example { > prefix ex; > } > > augment "ex:example" { > leaf bar { > type empty; > description > "When present, the default value for foo is 10."; > } > } > } > > > In this case, when the leaf foo is not configured but the leaf bar is pre= sent, the value of foo in the operational datastore should be 10 (rather th= an 0). > > In this case, I think that it would be better/cleaner if the origin is ma= rked as system. > > Maybe a better YANG description for bar could be: "When present, the syst= em overrides the default value of foo to 10." > > What is your and/or WG opinion? > > Thanks again > > Italo > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: mercoled=C3=AC 20 gennaio 2021 17:05 >> To: Italo Busi >> Cc: 'netmod@ietf.org' >> Subject: Re: [netmod] Questions about how to assign default values with >> YANG >> >> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: >> > >> > What about the case the leaf is not conditional (but still mandatory f= alse >> since a YANG default statement is defined)? >> > >> > May the server still decide not to use/implement this leaf in the oper= ational >> datastore? >> > >> > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by >> default. >> > What should be the behavior of a system which does not implement auto- >> negotiation? >> > Return the value false or no value (in the operational datastore)? >> > >> >> Here are some of the rules I personally like: >> >> - is the ground truth about what a system has and does >> - do not implement leafs that do not apply >> >> Hence, interfaces supporting auto-negotiation have either auto- >> negotiation/enabled =3D true or auto-negotiation/enabled =3D false in >> . And interfaces not supporting auto-negotiation have nothi= ng >> to report about auto-negotiation. Yes, I do not want to see auto- >> negotiation/enabled =3D false on a loopback interface. >> >> My historic Ethernet interface from the last century would also not repo= rt >> auto-negotiation/enabled in . You may hit applications that= love >> to have auto-negotiation/enabled available on all Ethernet interfaces an= d then >> you end in a debate where the application developers tell you that no >> information in may have many reasons (instrumentation not >> implemented, access control rules, whatever and by reporting enabled=3Df= alse >> you do them a favor) but the true answer in such a debate is often that >> modeling things as a boolean is simplistic since there are often more th= an >> exactly two states (in this case, enabled, disabled, failed, not-availab= le, ...). >> So you settle on blaming the model writer. ;-) >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 9 08:58:37 2021 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 1614E3A13EE for ; Tue, 9 Mar 2021 08:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLS8XVNufrUe for ; Tue, 9 Mar 2021 08:58:31 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7E23A13BA for ; Tue, 9 Mar 2021 08:58:31 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id p21so28159910lfu.11 for ; Tue, 09 Mar 2021 08:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FG8VPQTJ+6ymaBy8yESi6jDbhty9ekcit0tZsvMJx3M=; b=J5WANVQp7ft38tv77EvBNhfvxRi0iXEs5ZwDp5h5zosmKUpXPRQC1kYxxoTNV/5Pxm lwb5hzh8/60KhW1G8yOc2epB0dcJ/aojSqSUgTrwdyhCX4xmIwLC7YsF3CBhhat+lSnI YiOhEc400BTAGj1w7Ox8/qe00Ptv++bZ0TrXmI+0D/8qsoiKZwkLM7J2ucXIGZumTtYf qJBAy6M6nWAp5BLeg7r7B7nEa6t7NXz1003AmA/qdyaEhl1tsOFd107nSlqSl3wWO7/A ikEqnGOQU+gL51Ar8QvpCNy8ybF47q7mHc87p5c8kC8NE4Eqs8YQO04B3bflVJCZoTZ2 H96g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FG8VPQTJ+6ymaBy8yESi6jDbhty9ekcit0tZsvMJx3M=; b=d/4Kvn7yKvULcCyxPlx5osWeeh2diKkvB0qyJbsdOLWnwL5s6EBd1omoDxjYZpjLHE 945vueUpwJIEVCfDKmO4I9vwBJKUDcAB80CaX7TN4IckFHMjLryelkyxWaHp/Lmv4X7D hdrRHDUcFNQm5Qs0mX8HJW4PlJZ4pBWkKpYdBK7FCVwfH5/9esshsidDzF54xnqfV/QE iUyIO0/3Fap9ljjMCqkH14Qtsc7FGas8TBTtl/NoawN0in2yvfh9b7XV3h9VI5XloqS7 rFxcXMVHTysVjfzfKza/+rPSdlmkCjmKpA5VqgHEfNpZcly0o0UooWdZfg9NWGgNmhge baMA== X-Gm-Message-State: AOAM531B+gs4StsRwqWj+dPPF3ouqSwqLWG4BSseZBbJ8jlgXV2w7mBW Nbwv8POSe/QM3sUqyD6CyswbTbRjVEo4iKPtlFvtgA== X-Google-Smtp-Source: ABdhPJzezpeJSAYjEsaVCE5vNiQ7KxTi/VxyQtRg2V2ZXj6tnleoBSmRp+hCsbakCCFo0b7hUsSnU6hjYRteruhKhd4= X-Received: by 2002:a19:6d07:: with SMTP id i7mr5602288lfc.568.1615309107977; Tue, 09 Mar 2021 08:58:27 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <87sg54cm18.fsf@nic.cz> In-Reply-To: <87sg54cm18.fsf@nic.cz> From: Andy Bierman Date: Tue, 9 Mar 2021 08:58:17 -0800 Message-ID: To: Italo Busi , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095736805bd1d75e1" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 16:58:36 -0000 --00000000000095736805bd1d75e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka wrote: > Italo Busi writes: > > > Hi Juergen, > > > > Thanks again for your clear explanation on this topic > > > > I have found a similar but slightly different issue. In this case, a > YANG default statement exists in the base module but the intention with t= he > augmentation is to "overwrite" the default value on the basis of another > attribute, defined in the module which augments the base module. > > > > For example, I am wondering whether such a code is valid: > > Yes, this is valid, I'd just suggest: > > I do not agree. I do not see how the description-stmt for /foo can change the default leaf processing for /bar > - remove the default statement for "foo", as it may be confusing to both > humans and tools > sec 7.3.4: If the base type has a default value and the new derived type does not specify a new default value, the base type's default value is also the default value of the new derived type. sec 7.6.1 The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1 ): o If no such ancestor exists in the schema tree, the default value MUST be used. o Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree or the case node is the choice's default case, and if no nodes from any other case exist in the data tree. o Otherwise, the default value MUST be used if the ancestor node exists in the data tree. > - specify the default (both cases) in the description of "foo" > > A similar example is in the module ietf-ipv6-router-advertisements, e.g. > leaf "min-rtr-adv-interval": > > https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1 > > Lada > Andy > > > > > module example-base { > > container example { > > leaf foo { > > type uint8; > > default 0; > > } > > } > > } > > > > module example-augment { > > import example { > > prefix ex; > > } > > > > augment "ex:example" { > > leaf bar { > > type empty; > > description > > "When present, the default value for foo is 10."; > > } > > } > > } > > > > > > In this case, when the leaf foo is not configured but the leaf bar is > present, the value of foo in the operational datastore should be 10 (rath= er > than 0). > > > > In this case, I think that it would be better/cleaner if the origin is > marked as system. > > > > Maybe a better YANG description for bar could be: "When present, the > system overrides the default value of foo to 10." > > > > What is your and/or WG opinion? > > > > Thanks again > > > > Italo > > > >> -----Original Message----- > >> From: Juergen Schoenwaelder [mailto: > j.schoenwaelder@jacobs-university.de] > >> Sent: mercoled=C3=AC 20 gennaio 2021 17:05 > >> To: Italo Busi > >> Cc: 'netmod@ietf.org' > >> Subject: Re: [netmod] Questions about how to assign default values wit= h > >> YANG > >> > >> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > >> > > >> > What about the case the leaf is not conditional (but still mandatory > false > >> since a YANG default statement is defined)? > >> > > >> > May the server still decide not to use/implement this leaf in the > operational > >> datastore? > >> > > >> > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled > by > >> default. > >> > What should be the behavior of a system which does not implement aut= o- > >> negotiation? > >> > Return the value false or no value (in the operational datastore)? > >> > > >> > >> Here are some of the rules I personally like: > >> > >> - is the ground truth about what a system has and does > >> - do not implement leafs that do not apply > >> > >> Hence, interfaces supporting auto-negotiation have either auto- > >> negotiation/enabled =3D true or auto-negotiation/enabled =3D false in > >> . And interfaces not supporting auto-negotiation have > nothing > >> to report about auto-negotiation. Yes, I do not want to see auto- > >> negotiation/enabled =3D false on a loopback interface. > >> > >> My historic Ethernet interface from the last century would also not > report > >> auto-negotiation/enabled in . You may hit applications > that love > >> to have auto-negotiation/enabled available on all Ethernet interfaces > and then > >> you end in a debate where the application developers tell you that no > >> information in may have many reasons (instrumentation no= t > >> implemented, access control rules, whatever and by reporting > enabled=3Dfalse > >> you do them a favor) but the true answer in such a debate is often tha= t > >> modeling things as a boolean is simplistic since there are often more > than > >> exactly two states (in this case, enabled, disabled, failed, > not-available, ...). > >> So you settle on blaming the model writer. ;-) > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000095736805bd1d75e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 9, 2021 at 8:46 AM Ladisl= av Lhotka <ladislav.lhotka@nic= .cz> wrote:
Italo Busi <Italo.Busi@huawei.com> writes:

> Hi Juergen,
>
> Thanks again for your clear explanation on this topic
>
> I have found a similar but slightly different issue. In this case, a Y= ANG default statement exists in the base module but the intention with the = augmentation is to "overwrite" the default value on the basis of = another attribute, defined in the module which augments the base module. >
> For example, I am wondering whether such a code is valid:

Yes, this is valid, I'd just suggest:


I do not agree.
I do not see= how the description-stmt for /foo can change the default leaf processing f= or /bar


=C2=A0
- remove the default statement for "foo", as it may be confusing = to both humans and tools

sec 7.3.4:

   If =
the base type has a default value and the new derived type does
   not specify a new default value, the base type's default value is
   also the default value of the new derived type.


sec 7.6.1
<=
br>
   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.  The usage of the default value
   depends on the leaf's closest ancestor node in the schema tree that
   is not a non-presence container (see Section 7.5.1):

   o  If no such ancestor exists in the schema tree, the default value
      MUST be used.

   o  Otherwise, if this ancestor is a case node, the default value MUST
      be used if any node from the case exists in the data tree or the
      case node is the choice's default case, and if no nodes from any
      other case exist in the data tree.

   o  Otherwise, the default value MUST be used if the ancestor node
      exists in the data tree.



- specify the default (both cases) in the description of "foo"
A similar example is in the module ietf-ipv6-router-advertisements, e.g. le= af "min-rtr-adv-interval":

https://www.rfc-editor.org/rfc/rfc8349.html#s= ection-9.1

Lada


Andy
=C2= =A0

>
> module example-base {
>=C2=A0 =C2=A0container example {
>=C2=A0 =C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> module example-augment {
>=C2=A0 =C2=A0import example {
>=C2=A0 =C2=A0 =C2=A0prefix ex;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0augment "ex:example" {
>=C2=A0 =C2=A0 =C2=A0leaf bar {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When present, the default value= for foo is 10.";
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
>
> In this case, when the leaf foo is not configured but the leaf bar is = present, the value of foo in the operational datastore should be 10 (rather= than 0).
>
> In this case, I think that it would be better/cleaner if the origin is= marked as system.
>
> Maybe a better YANG description for bar could be: "When present, = the system overrides the default value of foo to 10."
>
> What is your and/or WG opinion?
>
> Thanks again
>
> Italo
>
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-universi= ty.de]
>> Sent: mercoled=C3=AC 20 gennaio 2021 17:05
>> To: Italo Busi <Italo.Busi@huawei.com>
>> Cc: 'netm= od@ietf.org' <netmod@ietf.org>
>> Subject: Re: [netmod] Questions about how to assign default values= with
>> YANG
>>
>> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote:
>> >
>> > What about the case the leaf is not conditional (but still ma= ndatory false
>> since a YANG default statement is defined)?
>> >
>> > May the server still decide not to use/implement this leaf in= the operational
>> datastore?
>> >
>> > For example, in appendix C.1 of RFC8342, auto-negotiation is = enabled by
>> default.
>> > What should be the behavior of a system which does not implem= ent auto-
>> negotiation?
>> > Return the value false or no value (in the operational datast= ore)?
>> >
>>
>> Here are some of the rules I personally like:
>>
>>=C2=A0 - <operational> is the ground truth about what a syste= m has and does
>>=C2=A0 - do not implement leafs that do not apply
>>
>> Hence, interfaces supporting auto-negotiation have either auto- >> negotiation/enabled =3D true or auto-negotiation/enabled =3D false= in
>> <operational>. And interfaces not supporting auto-negotiatio= n have nothing
>> to report about auto-negotiation. Yes, I do not want to see auto-<= br> >> negotiation/enabled =3D false on a loopback interface.
>>
>> My historic Ethernet interface from the last century would also no= t report
>> auto-negotiation/enabled in <operational>. You may hit appli= cations that love
>> to have auto-negotiation/enabled available on all Ethernet interfa= ces and then
>> you end in a debate where the application developers tell you that= no
>> information in <operational> may have many reasons (instrume= ntation not
>> implemented, access control rules, whatever and by reporting enabl= ed=3Dfalse
>> you do them a favor) but the true answer in such a debate is often= that
>> modeling things as a boolean is simplistic since there are often m= ore than
>> exactly two states (in this case, enabled, disabled, failed, not-a= vailable, ...).
>> So you settle on blaming the model writer. ;-)
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000095736805bd1d75e1-- From nobody Tue Mar 9 09:32:34 2021 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 B4BD73A147B for ; Tue, 9 Mar 2021 09:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 Wn1sjZXkFDWc for ; Tue, 9 Mar 2021 09:32:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61E73A147A for ; Tue, 9 Mar 2021 09:32:27 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8] (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id AEC34140A8B; Tue, 9 Mar 2021 18:32:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1615311144; bh=yC9lxZ9zOTAXP3BBAwhkRlXvRTBFVITDRFfmckpP7tc=; h=To:From:Date; b=GQfiUurtk/8aSo9uUZfCdRPjhzQ2ejGSZvP4OyU29b/i6mwkQCuy0Mpci63mIbetF 7qTln/qNuAUKiDwG5yRretgrMV5ro0Te+tbIeozPv5yKRZfOQ2dehxLJDaH0pFEtd0 PehnBX7eYUzcTUb7IIPdSXiWkwGJzMslgv5tfc5c= To: Andy Bierman , Italo Busi , Juergen Schoenwaelder , "netmod@ietf.org" References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <87sg54cm18.fsf@nic.cz> From: Ladislav Lhotka Organization: CZ.NIC Message-ID: Date: Tue, 9 Mar 2021 18:32:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 17:32:33 -0000 On 09. 03. 21 17:58, Andy Bierman wrote: > > > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka > wrote: > > Italo Busi > > writes: > > > Hi Juergen, > > > > Thanks again for your clear explanation on this topic > > > > I have found a similar but slightly different issue. In this case, > a YANG default statement exists in the base module but the intention > with the augmentation is to "overwrite" the default value on the > basis of another attribute, defined in the module which augments the > base module. > > > > For example, I am wondering whether such a code is valid: > > Yes, this is valid, I'd just suggest: > > > I do not agree. > I do not see how the description-stmt for /foo can change the default > leaf processing for /bar > Are you saying that the (computed) default values specified in description strings (as in ietf-ipv6-router-advertisements) are illegal? Lada > >   > > - remove the default statement for "foo", as it may be confusing to > both humans and tools > > > sec 7.3.4: > > If the base type has a default value and the new derived type does > not specify a new default value, the base type's default value is > also the default value of the new derived type. > > > > sec 7.6.1 > > > The default value of a leaf is the value that the server uses if the > leaf does not exist in the data tree. The usage of the default value > depends on the leaf's closest ancestor node in the schema tree that > is not a non-presence container (see Section 7.5.1 ): > > o If no such ancestor exists in the schema tree, the default value > MUST be used. > > o Otherwise, if this ancestor is a case node, the default value MUST > be used if any node from the case exists in the data tree or the > case node is the choice's default case, and if no nodes from any > other case exist in the data tree. > > o Otherwise, the default value MUST be used if the ancestor node > exists in the data tree. > > > > > - specify the default (both cases) in the description of "foo" > > A similar example is in the module ietf-ipv6-router-advertisements, > e.g. leaf "min-rtr-adv-interval": > > https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1 > > > Lada > > > > Andy >   > > > > > > module example-base { > >   container example { > >     leaf foo { > >       type uint8; > >       default 0; > >     } > >   } > > } > > > > module example-augment { > >   import example { > >     prefix ex; > >   } > > > >   augment "ex:example" { > >     leaf bar { > >       type empty; > >       description > >         "When present, the default value for foo is 10."; > >     } > >   } > > } > > > > > > In this case, when the leaf foo is not configured but the leaf bar > is present, the value of foo in the operational datastore should be > 10 (rather than 0). > > > > In this case, I think that it would be better/cleaner if the > origin is marked as system. > > > > Maybe a better YANG description for bar could be: "When present, > the system overrides the default value of foo to 10." > > > > What is your and/or WG opinion? > > > > Thanks again > > > > Italo > > > >> -----Original Message----- > >> From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de > ] > >> Sent: mercoledì 20 gennaio 2021 17:05 > >> To: Italo Busi > > >> Cc: 'netmod@ietf.org ' > > >> Subject: Re: [netmod] Questions about how to assign default > values with > >> YANG > >> > >> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > >> > > >> > What about the case the leaf is not conditional (but still > mandatory false > >> since a YANG default statement is defined)? > >> > > >> > May the server still decide not to use/implement this leaf in > the operational > >> datastore? > >> > > >> > For example, in appendix C.1 of RFC8342, auto-negotiation is > enabled by > >> default. > >> > What should be the behavior of a system which does not > implement auto- > >> negotiation? > >> > Return the value false or no value (in the operational datastore)? > >> > > >> > >> Here are some of the rules I personally like: > >> > >>  - is the ground truth about what a system has and does > >>  - do not implement leafs that do not apply > >> > >> Hence, interfaces supporting auto-negotiation have either auto- > >> negotiation/enabled = true or auto-negotiation/enabled = false in > >> . And interfaces not supporting auto-negotiation > have nothing > >> to report about auto-negotiation. Yes, I do not want to see auto- > >> negotiation/enabled = false on a loopback interface. > >> > >> My historic Ethernet interface from the last century would also > not report > >> auto-negotiation/enabled in . You may hit > applications that love > >> to have auto-negotiation/enabled available on all Ethernet > interfaces and then > >> you end in a debate where the application developers tell you that no > >> information in may have many reasons > (instrumentation not > >> implemented, access control rules, whatever and by reporting > enabled=false > >> you do them a favor) but the true answer in such a debate is > often that > >> modeling things as a boolean is simplistic since there are often > more than > >> exactly two states (in this case, enabled, disabled, failed, > not-available, ...). > >> So you settle on blaming the model writer. ;-) > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | > Germany > >> Fax:   +49 421 200 3103        >  > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 9 09:55:40 2021 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 877B63A14B3 for ; Tue, 9 Mar 2021 09:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8To3r3nW4td for ; Tue, 9 Mar 2021 09:55:36 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C2E3A14B2 for ; Tue, 9 Mar 2021 09:55:35 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id d3so28481005lfg.10 for ; Tue, 09 Mar 2021 09:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ytXs12rVFa2v2C3C+t7zjYHNy6OosMYnZZaWpQa/xII=; b=KGcA1nn7hqbUZFN8bgiRPklI0PdyCR4gMcdmbS6R3TtRt7OvO5Qo9yrrmiumJl2FOu 7LVmb8dlq1okZlcMAHkK8s5oBxHm0S4z4YuRr04Zb4pkgJp8J3qjsOstK+nHhjzCrOvi LS7xYc13wJvX48j9NC8mlO/sn/rtydMRP4FBJSJrNHUjuZXtDkQDE27BewH0NEWr6UAT GMiIALCunwMIXqHvfUDTfzXGklDBo/1nSO6kzzwxLXJUnwSkwxE071zFpjXGMsnzRiHZ wHGvvYHHF3LDsNu+HDw8nM/UCJWVWmwgp8Hwq0gF+4H5QLzNJgN6edEx/wy40VoqqsIm r/bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ytXs12rVFa2v2C3C+t7zjYHNy6OosMYnZZaWpQa/xII=; b=KlSyEWZZu5Nmeq2o+ElvZlHj0oKIkqVTz5PLsJHVsQX+nwvoyaTANQzAnZFycynZYH PNzXiTHJSEE2r0qS7Y0JXUwmhLMEQIdid37gbeJKOuS6B3yS0UY60fl9nIk3cZ8Ip+8y jYZE2aFUqgSgY6cCsFhtsjgXuS1IiW0qh536mHdXq1dGFh26GPzjKyPzxxpMYHHiSGkE SduYpvhzg8iV3MieRxdbtkOvGQNVk/YV9uxzR1XEeRQwuz1vDctaPaZ2AnZ7mDi+DIkn zFXig81zuCVl6MOK12gGQRe0Vmu5qHNqarrg52YWjWJ4NFgC806U34DsRCWZIWy8rRcs 766w== X-Gm-Message-State: AOAM533IjtiQqRrYGYHrTnDRPOs+w/bHlsdV9giWCNFv5y2mIF0ibf3D sqlzzjEwSiiTHU2zL8T/p5iGmwCcZMqa828IuKQMeg== X-Google-Smtp-Source: ABdhPJxqYTDQU7aUh9Dq9GUfuchy8UtH+odzA+kLlGxVUV15dMv6IVxzNHSm6Q9VP1ICurqK8EA+V7t8fuQUyDg5XNU= X-Received: by 2002:a05:6512:1195:: with SMTP id g21mr17633647lfr.512.1615312532615; Tue, 09 Mar 2021 09:55:32 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <87sg54cm18.fsf@nic.cz> In-Reply-To: From: Andy Bierman Date: Tue, 9 Mar 2021 09:55:21 -0800 Message-ID: To: Ladislav Lhotka Cc: Italo Busi , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b5466005bd1e41cb" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 17:55:39 -0000 --000000000000b5466005bd1e41cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka wrote: > On 09. 03. 21 17:58, Andy Bierman wrote: > > > > > > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka > > wrote: > > > > Italo Busi > > > writes: > > > > > Hi Juergen, > > > > > > Thanks again for your clear explanation on this topic > > > > > > I have found a similar but slightly different issue. In this case= , > > a YANG default statement exists in the base module but the intentio= n > > with the augmentation is to "overwrite" the default value on the > > basis of another attribute, defined in the module which augments th= e > > base module. > > > > > > For example, I am wondering whether such a code is valid: > > > > Yes, this is valid, I'd just suggest: > > > > > > I do not agree. > > I do not see how the description-stmt for /foo can change the default > > leaf processing for /bar > > > > Are you saying that the (computed) default values specified in > description strings (as in ietf-ipv6-router-advertisements) are illegal? > > Of course not. In this case there MUST NOT be a YANG default-stmt in use for the leaf or leaf-list. If the leaf or leaf-list does have a YANG default-stmt that MUST be used, then no description-stmt can undo the requirements in 7.6.1 > Lada > > Andy > > > > > > > > - remove the default statement for "foo", as it may be confusing to > > both humans and tools > > > > > > sec 7.3.4: > > > > If the base type has a default value and the new derived type does > > not specify a new default value, the base type's default value is > > also the default value of the new derived type. > > > > > > > > sec 7.6.1 > > > > > > The default value of a leaf is the value that the server uses if the > > leaf does not exist in the data tree. The usage of the default valu= e > > depends on the leaf's closest ancestor node in the schema tree that > > is not a non-presence container (see Section 7.5.1 < > https://tools.ietf.org/html/rfc7950#section-7.5.1>): > > > > o If no such ancestor exists in the schema tree, the default value > > MUST be used. > > > > o Otherwise, if this ancestor is a case node, the default value MUS= T > > be used if any node from the case exists in the data tree or the > > case node is the choice's default case, and if no nodes from any > > other case exist in the data tree. > > > > o Otherwise, the default value MUST be used if the ancestor node > > exists in the data tree. > > > > > > > > > > - specify the default (both cases) in the description of "foo" > > > > A similar example is in the module ietf-ipv6-router-advertisements, > > e.g. leaf "min-rtr-adv-interval": > > > > https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1 > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > > > module example-base { > > > container example { > > > leaf foo { > > > type uint8; > > > default 0; > > > } > > > } > > > } > > > > > > module example-augment { > > > import example { > > > prefix ex; > > > } > > > > > > augment "ex:example" { > > > leaf bar { > > > type empty; > > > description > > > "When present, the default value for foo is 10."; > > > } > > > } > > > } > > > > > > > > > In this case, when the leaf foo is not configured but the leaf ba= r > > is present, the value of foo in the operational datastore should be > > 10 (rather than 0). > > > > > > In this case, I think that it would be better/cleaner if the > > origin is marked as system. > > > > > > Maybe a better YANG description for bar could be: "When present, > > the system overrides the default value of foo to 10." > > > > > > What is your and/or WG opinion? > > > > > > Thanks again > > > > > > Italo > > > > > >> -----Original Message----- > > >> From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de > > ] > > >> Sent: mercoled=C3=AC 20 gennaio 2021 17:05 > > >> To: Italo Busi Italo.Busi@huawei.com>> > > >> Cc: 'netmod@ietf.org ' > > > > >> Subject: Re: [netmod] Questions about how to assign default > > values with > > >> YANG > > >> > > >> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > >> > > > >> > What about the case the leaf is not conditional (but still > > mandatory false > > >> since a YANG default statement is defined)? > > >> > > > >> > May the server still decide not to use/implement this leaf in > > the operational > > >> datastore? > > >> > > > >> > For example, in appendix C.1 of RFC8342, auto-negotiation is > > enabled by > > >> default. > > >> > What should be the behavior of a system which does not > > implement auto- > > >> negotiation? > > >> > Return the value false or no value (in the operational > datastore)? > > >> > > > >> > > >> Here are some of the rules I personally like: > > >> > > >> - is the ground truth about what a system has and > does > > >> - do not implement leafs that do not apply > > >> > > >> Hence, interfaces supporting auto-negotiation have either auto- > > >> negotiation/enabled =3D true or auto-negotiation/enabled =3D fal= se in > > >> . And interfaces not supporting auto-negotiation > > have nothing > > >> to report about auto-negotiation. Yes, I do not want to see auto= - > > >> negotiation/enabled =3D false on a loopback interface. > > >> > > >> My historic Ethernet interface from the last century would also > > not report > > >> auto-negotiation/enabled in . You may hit > > applications that love > > >> to have auto-negotiation/enabled available on all Ethernet > > interfaces and then > > >> you end in a debate where the application developers tell you > that no > > >> information in may have many reasons > > (instrumentation not > > >> implemented, access control rules, whatever and by reporting > > enabled=3Dfalse > > >> you do them a favor) but the true answer in such a debate is > > often that > > >> modeling things as a boolean is simplistic since there are often > > more than > > >> exactly two states (in this case, enabled, disabled, failed, > > not-available, ...). > > >> So you settle on blaming the model writer. ;-) > > >> > > >> /js > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > >> Fax: +49 421 200 3103 > > https://www.jacobs-university.de/>> > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --000000000000b5466005bd1e41cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 9, 2021 at 9:32 AM Ladisl= av Lhotka <ladislav.lhotka@nic= .cz> wrote:
On 09. 03. 21 17:58, Andy Bierman wrote:
>
>
> On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka <ladislav.lhotka@nic.cz
> <mailto:ladislav.lhotka@nic.cz>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Italo Busi <Italo.Busi@huawei.com <mailto:Italo.Busi@huawei.com>&g= t;
>=C2=A0 =C2=A0 =C2=A0writes:
>
>=C2=A0 =C2=A0 =C2=A0> Hi Juergen,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks again for your clear explanation on thi= s topic
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I have found a similar but slightly different = issue. In this case,
>=C2=A0 =C2=A0 =C2=A0a YANG default statement exists in the base module = but the intention
>=C2=A0 =C2=A0 =C2=A0with the augmentation is to "overwrite" t= he default value on the
>=C2=A0 =C2=A0 =C2=A0basis of another attribute, defined in the module w= hich augments the
>=C2=A0 =C2=A0 =C2=A0base module.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> For example, I am wondering whether such a cod= e is valid:
>
>=C2=A0 =C2=A0 =C2=A0Yes, this is valid, I'd just suggest:
>
>
> I do not agree.
> I do not see how the description-stmt for /foo can change the default<= br> > leaf processing for /bar
>

Are you saying that the (computed) default values specified in
description strings (as in ietf-ipv6-router-advertisements) are illegal?

Of course not.
In this case = there MUST NOT be a YANG default-stmt in use for the leaf or leaf-list.

If the leaf or leaf-list does have a YANG default-stm= t that MUST be used, then
no description-stmt can undo the requir= ements in 7.6.1

=C2=A0
Lada



Andy
=C2=A0
>
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0- remove the default statement for "foo",= as it may be confusing to
>=C2=A0 =C2=A0 =C2=A0both humans and tools
>
>
> sec 7.3.4:
>
>=C2=A0 =C2=A0 If the base type has a default value and the new derived = type does
>=C2=A0 =C2=A0 not specify a new default value, the base type's defa= ult value is
>=C2=A0 =C2=A0 also the default value of the new derived type.
>
>
>
> sec 7.6.1
>
>
>=C2=A0 =C2=A0 The default value of a leaf is the value that the server = uses if the
>=C2=A0 =C2=A0 leaf does not exist in the data tree.=C2=A0 The usage of = the default value
>=C2=A0 =C2=A0 depends on the leaf's closest ancestor node in the sc= hema tree that
>=C2=A0 =C2=A0 is not a non-presence container (see Section 7.5.1 <https://tools.ietf.org/html/rfc7950#section-7.5.1= >):
>
>=C2=A0 =C2=A0 o=C2=A0 If no such ancestor exists in the schema tree, th= e default value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be used.
>
>=C2=A0 =C2=A0 o=C2=A0 Otherwise, if this ancestor is a case node, the d= efault value MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be used if any node from the case exists in = the data tree or the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0case node is the choice's default case, = and if no nodes from any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0other case exist in the data tree.
>
>=C2=A0 =C2=A0 o=C2=A0 Otherwise, the default value MUST be used if the = ancestor node
>=C2=A0 =C2=A0 =C2=A0 =C2=A0exists in the data tree.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0- specify the default (both cases) in the descripti= on of "foo"
>
>=C2=A0 =C2=A0 =C2=A0A similar example is in the module ietf-ipv6-router= -advertisements,
>=C2=A0 =C2=A0 =C2=A0e.g. leaf "min-rtr-adv-interval":
>
>=C2=A0 =C2=A0 =C2=A0https://www.rfc-edito= r.org/rfc/rfc8349.html#section-9.1
>=C2=A0 =C2=A0 =C2=A0<https://www.rfc-e= ditor.org/rfc/rfc8349.html#section-9.1>
>
>=C2=A0 =C2=A0 =C2=A0Lada
>
>
>
> Andy
> =C2=A0
>
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> module example-base {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0container example {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0> }
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> module example-augment {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0import example {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0prefix ex;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0augment "ex:example" { >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0leaf bar {
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When pr= esent, the default value for foo is 10.";
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0> }
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In this case, when the leaf foo is not configu= red but the leaf bar
>=C2=A0 =C2=A0 =C2=A0is present, the value of foo in the operational dat= astore should be
>=C2=A0 =C2=A0 =C2=A010 (rather than 0).
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> In this case, I think that it would be better/= cleaner if the
>=C2=A0 =C2=A0 =C2=A0origin is marked as system.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Maybe a better YANG description for bar could = be: "When present,
>=C2=A0 =C2=A0 =C2=A0the system overrides the default value of foo to 10= ."
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> What is your and/or WG opinion?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks again
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Italo
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0>> From: Juergen Schoenwaelder
>=C2=A0 =C2=A0 =C2=A0[mailto:j.schoenwaelder@jacobs-university.de
>=C2=A0 =C2=A0 =C2=A0<mailto:j.schoenwaelder@jacobs-university.de&= gt;]
>=C2=A0 =C2=A0 =C2=A0>> Sent: mercoled=C3=AC 20 gennaio 2021 17:05=
>=C2=A0 =C2=A0 =C2=A0>> To: Italo Busi <Italo.Busi@huawei.com <mailto:Italo.Busi@huawei.= com>>
>=C2=A0 =C2=A0 =C2=A0>> Cc: 'netmod@ietf.org <mailto:netmod@ietf.org>' <netmod@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:netmod@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>> Subject: Re: [netmod] Questions about how = to assign default
>=C2=A0 =C2=A0 =C2=A0values with
>=C2=A0 =C2=A0 =C2=A0>> YANG
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Wed, Jan 20, 2021 at 02:41:39PM +0000, = Italo Busi wrote:
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > What about the case the leaf is not c= onditional (but still
>=C2=A0 =C2=A0 =C2=A0mandatory false
>=C2=A0 =C2=A0 =C2=A0>> since a YANG default statement is defined)= ?
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > May the server still decide not to us= e/implement this leaf in
>=C2=A0 =C2=A0 =C2=A0the operational
>=C2=A0 =C2=A0 =C2=A0>> datastore?
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > For example, in appendix C.1 of RFC83= 42, auto-negotiation is
>=C2=A0 =C2=A0 =C2=A0enabled by
>=C2=A0 =C2=A0 =C2=A0>> default.
>=C2=A0 =C2=A0 =C2=A0>> > What should be the behavior of a syst= em which does not
>=C2=A0 =C2=A0 =C2=A0implement auto-
>=C2=A0 =C2=A0 =C2=A0>> negotiation?
>=C2=A0 =C2=A0 =C2=A0>> > Return the value false or no value (i= n the operational datastore)?
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Here are some of the rules I personally li= ke:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 - <operational> is the ground = truth about what a system has and does
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 - do not implement leafs that do not= apply
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Hence, interfaces supporting auto-negotiat= ion have either auto-
>=C2=A0 =C2=A0 =C2=A0>> negotiation/enabled =3D true or auto-negot= iation/enabled =3D false in
>=C2=A0 =C2=A0 =C2=A0>> <operational>. And interfaces not su= pporting auto-negotiation
>=C2=A0 =C2=A0 =C2=A0have nothing
>=C2=A0 =C2=A0 =C2=A0>> to report about auto-negotiation. Yes, I d= o not want to see auto-
>=C2=A0 =C2=A0 =C2=A0>> negotiation/enabled =3D false on a loopbac= k interface.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> My historic Ethernet interface from the la= st century would also
>=C2=A0 =C2=A0 =C2=A0not report
>=C2=A0 =C2=A0 =C2=A0>> auto-negotiation/enabled in <operationa= l>. You may hit
>=C2=A0 =C2=A0 =C2=A0applications that love
>=C2=A0 =C2=A0 =C2=A0>> to have auto-negotiation/enabled available= on all Ethernet
>=C2=A0 =C2=A0 =C2=A0interfaces and then
>=C2=A0 =C2=A0 =C2=A0>> you end in a debate where the application = developers tell you that no
>=C2=A0 =C2=A0 =C2=A0>> information in <operational> may hav= e many reasons
>=C2=A0 =C2=A0 =C2=A0(instrumentation not
>=C2=A0 =C2=A0 =C2=A0>> implemented, access control rules, whateve= r and by reporting
>=C2=A0 =C2=A0 =C2=A0enabled=3Dfalse
>=C2=A0 =C2=A0 =C2=A0>> you do them a favor) but the true answer i= n such a debate is
>=C2=A0 =C2=A0 =C2=A0often that
>=C2=A0 =C2=A0 =C2=A0>> modeling things as a boolean is simplistic= since there are often
>=C2=A0 =C2=A0 =C2=A0more than
>=C2=A0 =C2=A0 =C2=A0>> exactly two states (in this case, enabled,= disabled, failed,
>=C2=A0 =C2=A0 =C2=A0not-available, ...).
>=C2=A0 =C2=A0 =C2=A0>> So you settle on blaming the model writer.= ;-)
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> /js
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> --
>=C2=A0 =C2=A0 =C2=A0>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>=C2=A0 =C2=A0 =C2=A0>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |
>=C2=A0 =C2=A0 =C2=A0Germany
>=C2=A0 =C2=A0 =C2=A0>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 = =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0<https://www.jacobs-university.de/= <https://www.jacobs-university.de/>>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0> netmod mailing list
>=C2=A0 =C2=A0 =C2=A0> netmod@ietf.org <mailto:netmod@ietf.org>
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailma= n/listinfo/netmod
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/netmod>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Ladislav Lhotka
>=C2=A0 =C2=A0 =C2=A0Head, CZ.NIC Labs
>=C2=A0 =C2=A0 =C2=A0PGP Key ID: 0xB8F92B08A9F76C67
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0netmod mailing list
>=C2=A0 =C2=A0 =C2=A0netmod@ietf.org <mailto:netmod@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/netmod
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/netmod>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod >

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
--000000000000b5466005bd1e41cb-- From nobody Tue Mar 9 10:01:19 2021 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 5A20A3A14C4 for ; Tue, 9 Mar 2021 10:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 6hdGcGITnaSW for ; Tue, 9 Mar 2021 10:01:15 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1A23A14C3 for ; Tue, 9 Mar 2021 10:01:14 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8] (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id EC7AE140AD8; Tue, 9 Mar 2021 19:01:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1615312870; bh=ReqJ6O9oz+nz/nSbM8oASVCUihpua+EZ4ItrV/2KH2Y=; h=To:From:Date; b=F2RckNKE2HtUz1PC5xfrnS8xMwsfJKco/47LaZ2Ge4IcvTE9tSpE9voe6TjTKU4Xp TtfjCcD23a8e52QYVHW6+Y9qsaBbN9gm7jnFK46l2+K7Y4AffzF+ek/pQB/rdU8HTP mHdYNJks6ThTlEeIYj0esGLn/In3+8vViFdJquSE= To: Andy Bierman Cc: Italo Busi , Juergen Schoenwaelder , "netmod@ietf.org" References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <87sg54cm18.fsf@nic.cz> From: Ladislav Lhotka Organization: CZ.NIC Message-ID: Date: Tue, 9 Mar 2021 19:01:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 18:01:17 -0000 On 09. 03. 21 18:55, Andy Bierman wrote: > > > On Tue, Mar 9, 2021 at 9:32 AM Ladislav Lhotka > wrote: > > On 09. 03. 21 17:58, Andy Bierman wrote: > > > > > > On Tue, Mar 9, 2021 at 8:46 AM Ladislav Lhotka > > > >> > wrote: > > > >     Italo Busi >> > >     writes: > > > >     > Hi Juergen, > >     > > >     > Thanks again for your clear explanation on this topic > >     > > >     > I have found a similar but slightly different issue. In this > case, > >     a YANG default statement exists in the base module but the > intention > >     with the augmentation is to "overwrite" the default value on the > >     basis of another attribute, defined in the module which > augments the > >     base module. > >     > > >     > For example, I am wondering whether such a code is valid: > > > >     Yes, this is valid, I'd just suggest: > > > > > > I do not agree. > > I do not see how the description-stmt for /foo can change the default > > leaf processing for /bar > > > > Are you saying that the (computed) default values specified in > description strings (as in ietf-ipv6-router-advertisements) are illegal? > > > Of course not. > In this case there MUST NOT be a YANG default-stmt in use for the leaf > or leaf-list. > > If the leaf or leaf-list does have a YANG default-stmt that MUST be > used, then > no description-stmt can undo the requirements in 7.6.1 Isn't it exactly what I was suggesting in my two items? Namely: remove the "default" statement for "foo" and write this in the description of "foo": The default value is 10 if the "bar" sibling leaf exist, and zero otherwise. Lada > >   > > Lada > > > > Andy >   > > > > >   > > > >     - remove the default statement for "foo", as it may be > confusing to > >     both humans and tools > > > > > > sec 7.3.4: > > > >    If the base type has a default value and the new derived type does > >    not specify a new default value, the base type's default value is > >    also the default value of the new derived type. > > > > > > > > sec 7.6.1 > > > > > >    The default value of a leaf is the value that the server uses > if the > >    leaf does not exist in the data tree.  The usage of the default > value > >    depends on the leaf's closest ancestor node in the schema tree that > >    is not a non-presence container (see Section 7.5.1 > >): > > > >    o  If no such ancestor exists in the schema tree, the default value > >       MUST be used. > > > >    o  Otherwise, if this ancestor is a case node, the default > value MUST > >       be used if any node from the case exists in the data tree or the > >       case node is the choice's default case, and if no nodes from any > >       other case exist in the data tree. > > > >    o  Otherwise, the default value MUST be used if the ancestor node > >       exists in the data tree. > > > > > > > > > >     - specify the default (both cases) in the description of "foo" > > > >     A similar example is in the module > ietf-ipv6-router-advertisements, > >     e.g. leaf "min-rtr-adv-interval": > > > >     https://www.rfc-editor.org/rfc/rfc8349.html#section-9.1 > > >      > > > > >     Lada > > > > > > > > Andy > >   > > > > > >     > > >     > module example-base { > >     >   container example { > >     >     leaf foo { > >     >       type uint8; > >     >       default 0; > >     >     } > >     >   } > >     > } > >     > > >     > module example-augment { > >     >   import example { > >     >     prefix ex; > >     >   } > >     > > >     >   augment "ex:example" { > >     >     leaf bar { > >     >       type empty; > >     >       description > >     >         "When present, the default value for foo is 10."; > >     >     } > >     >   } > >     > } > >     > > >     > > >     > In this case, when the leaf foo is not configured but the > leaf bar > >     is present, the value of foo in the operational datastore > should be > >     10 (rather than 0). > >     > > >     > In this case, I think that it would be better/cleaner if the > >     origin is marked as system. > >     > > >     > Maybe a better YANG description for bar could be: "When present, > >     the system overrides the default value of foo to 10." > >     > > >     > What is your and/or WG opinion? > >     > > >     > Thanks again > >     > > >     > Italo > >     > > >     >> -----Original Message----- > >     >> From: Juergen Schoenwaelder > >     [mailto:j.schoenwaelder@jacobs-university.de > > >      >] > >     >> Sent: mercoledì 20 gennaio 2021 17:05 > >     >> To: Italo Busi >> > >     >> Cc: 'netmod@ietf.org > >' > >     >> > >     >> Subject: Re: [netmod] Questions about how to assign default > >     values with > >     >> YANG > >     >> > >     >> On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > >     >> > > >     >> > What about the case the leaf is not conditional (but still > >     mandatory false > >     >> since a YANG default statement is defined)? > >     >> > > >     >> > May the server still decide not to use/implement this leaf in > >     the operational > >     >> datastore? > >     >> > > >     >> > For example, in appendix C.1 of RFC8342, auto-negotiation is > >     enabled by > >     >> default. > >     >> > What should be the behavior of a system which does not > >     implement auto- > >     >> negotiation? > >     >> > Return the value false or no value (in the operational > datastore)? > >     >> > > >     >> > >     >> Here are some of the rules I personally like: > >     >> > >     >>  - is the ground truth about what a system > has and does > >     >>  - do not implement leafs that do not apply > >     >> > >     >> Hence, interfaces supporting auto-negotiation have either auto- > >     >> negotiation/enabled = true or auto-negotiation/enabled = > false in > >     >> . And interfaces not supporting auto-negotiation > >     have nothing > >     >> to report about auto-negotiation. Yes, I do not want to see > auto- > >     >> negotiation/enabled = false on a loopback interface. > >     >> > >     >> My historic Ethernet interface from the last century would also > >     not report > >     >> auto-negotiation/enabled in . You may hit > >     applications that love > >     >> to have auto-negotiation/enabled available on all Ethernet > >     interfaces and then > >     >> you end in a debate where the application developers tell > you that no > >     >> information in may have many reasons > >     (instrumentation not > >     >> implemented, access control rules, whatever and by reporting > >     enabled=false > >     >> you do them a favor) but the true answer in such a debate is > >     often that > >     >> modeling things as a boolean is simplistic since there are > often > >     more than > >     >> exactly two states (in this case, enabled, disabled, failed, > >     not-available, ...). > >     >> So you settle on blaming the model writer. ;-) > >     >> > >     >> /js > >     >> > >     >> -- > >     >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH > >     >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | > >     Germany > >     >> Fax:   +49 421 200 3103        > >       > >> > >     > > >     > _______________________________________________ > >     > netmod mailing list > >     > netmod@ietf.org > > > >     > https://www.ietf.org/mailman/listinfo/netmod > > >      > > > > >     -- > >     Ladislav Lhotka > >     Head, CZ.NIC Labs > >     PGP Key ID: 0xB8F92B08A9F76C67 > > > >     _______________________________________________ > >     netmod mailing list > >     netmod@ietf.org > > > >     https://www.ietf.org/mailman/listinfo/netmod > > >      > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Mar 9 10:45:58 2021 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 099643A168C for ; Tue, 9 Mar 2021 10:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0hYrrrKDeFa1 for ; Tue, 9 Mar 2021 10:45:53 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486343A1666 for ; Tue, 9 Mar 2021 10:45:53 -0800 (PST) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Dw3vW6nWLz67xJR; Wed, 10 Mar 2021 02:41:27 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 9 Mar 2021 19:45:50 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Tue, 9 Mar 2021 19:45:50 +0100 From: Italo Busi To: 'Andy Bierman' , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Questions about how to assign default values with YANG Thread-Index: AdbvCmZgzen+a6G4QWicT/glaRAynP///QGA///e3yCAAEHcAP//waGggACHKYD/tcyd8BK128+AAABnaoD//9fDkA== Date: Tue, 9 Mar 2021 18:45:50 +0000 Message-ID: References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <87sg54cm18.fsf@nic.cz> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.24.181] Content-Type: multipart/alternative; boundary="_000_cfec6d0a6e1248a1a35f54b701d2976chuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 18:45:56 -0000 --_000_cfec6d0a6e1248a1a35f54b701d2976chuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGFkYSwgQW5keSwNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrcy4NCg0KSWYgSSB1bmRlcnN0 YW5kIGNvcnJlY3RseSwgaWYgdGhlIGJhc2UgbW9kZWwgYW5kIHRoZSBhdWdtZW50YXRpb24gbW9k ZWwgYXJlIGRlZmluZWQgYXQgdGhlIHNhbWUgdGltZSwgd2UgY2FuIGF2b2lkIGRlZmluaW5nIGFu eSBZQU5HIGRlZmF1bHQgc3RhdGVtZW50IGluIHRoZSBiYXNlIG1vZGVsIGFuZCBwcm92aWRpbmcg YSBwcm9wZXIgZGVzY3JpcHRpb24gb2YgdGhlIGRlc2lyZWQgYmVoYXZpb3IuDQoNCkJhc2VkIG9u IHByZXZpb3VzIGRpc2N1c3Npb24gd2l0aCBKdWVyZ2VuLCBJIGhhdmUgdW5kZXJzdG9vZCB0aGF0 LCBpbiB0aGlzIGNhc2UsIHRoZSBvcmlnaW4gaW4gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBj YW4gYmUgZWl0aGVyIHNldCB0byBkZWZhdWx0IG9yIHRvIHN5c3RlbSAoSnVlcmdlbiBwcmVmZXJz IHRoZSBsYXR0ZXIgYnV0IHRoZSBmb3JtZXIgaXMgYWxsb3dlZCBieSBzZWN0aW9uIDUuMy40IG9m IFJGQzgzNDIpLg0KDQpJIHRoaW5rIHRoaXMgd291bGQgYmUgdGhlIGlkZWFsIHNvbHV0aW9uLCBi dXQgaW4gcHJhY3RpY2UgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRoZSBiYXNlIG1vZGVsIGhhcyBi ZWVuIHdyaXR0ZW4gYmVmb3JlIHRoZSBhdWdtZW50YXRpb24gbW9kZWwgYW5kL29yIHRoZSBhdXRo b3Igb2YgdGhlIGJhc2UgbW9kZWwgaXMgbm90IGF3YXJlIG9mIHRoZSBuZWVkcyBmcm9tIHRoZSBh dXRob3Igb2YgdGhlIGF1Z21lbnRhdGlvbiBtb2RlbC4NCg0KSW4gdGhlc2UgY2FzZXMsIHRoZSBZ QU5HIGRlZmF1bHQgc3RhdGVtZW50IGFscmVhZHkgZXhpc3RzIGluIHRoZSBiYXNlIG1vZGVsLg0K DQpJcyBpdCByZWFsbHkgcmVxdWlyZWQgdG8gY2hhbmdlIHRoZSBiYXNlIG1vZGVsIG9yIGNvdWxk IGEgd29yay1hcm91bmQgYmUgZm91bmQ/DQoNCkluIHByaW5jaXBsZSwgdGhlIHN5c3RlbSBoYXMg ZW5vdWdoIGluZm9ybWF0aW9uIHRvIHVuZGVyc3RhbmQgdGhhdCwgaWYgbm8gdmFsdWUgZm9yIHRo ZSBsZWFmIGZvbyBpcyBwcm92aWRlZCBpbiB0aGUgaW50ZW5kZWQgRFMsIHRoZSB2YWx1ZSBpbiB0 aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIGZvciB0aGUgbGVhZiBmb28gc2hvdWxkIGJlIDEwIHJh dGhlciB0aGFuIHRoZSB2YWx1ZSBkZWZpbmVkIGluIHRoZSBZQU5HIGRlZmF1bHQgc3RhdGVtZW50 IChpLmUuLCAwKS4NCg0KQmFzZWQgeW91ciBjb21tZW50cywgSSB0aGluayB0aGF0IGluIHRoaXMg Y2FzZSwgdGhlIG9yaWdpbiBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIG11c3Qgbm90IGJl IHNldCB0byBkZWZhdWx0LCBidXQgSSBhbSB3b25kZXJpbmcgd2hldGhlciBpdCBjb3VsZCBiZSBz ZXQgdG8gc3lzdGVtIGluc3RlYWQuIEluIG90aGVyIHdvcmRzLCB0aGUgYXBwbGllZCBjb25maWd1 cmF0aW9uIGZvciBmb28gaXMgcHJvdmlkZWQgYnkgdGhlIHN5c3RlbSBvbiB0aGUgYmFzaXMgb2Yg dGhlIHJ1bGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgY29uZmlndXJhdGlvbiBvZiBiYXIuDQoNCklm IHRoaXMgaXMgcG9zc2libGUsIHRoZW4gdGhlIGlzc3VlIGNvdWxkIGJlIHNvbHZlZCB3aXRob3V0 IHRoZSBuZWVkIHRvIHJlcXVlc3QgYSBjaGFuZ2UgdG8gdGhlIGJhc2UgbW9kZWwuDQoNClRoZSBk ZXNjcmlwdGlvbiBpbiB0aGUgYXVnbWVudGVkIG1vZGVsIG5lZWRzIHRvIGJlIGNsZWFuZWQtdXAg c2luY2UgaW4gbXkgaW5pdGlhbCBtYWlsIGl0IHdhcyBtaXNsZWFkaW5nLg0KDQpNYXliZSBhIGJl dHRlciBhbHRlcm5hdGl2ZSBjb3VsZCBiZSBzb21ldGhpbmcgbGlrZSDigJxXaGVuIGJhciBpcyBw cmVzZW50IGFuZCBmb28gaXMgbm90IGNvbmZpZ3VyZWQsIHRoZSBzeXN0ZW0gYXBwbGllcyB0aGUg dmFsdWUgMTAgdG8gZm9vIHJhdGhlciB0aGFuIGl0cyBkZWZhdWx0IHZhbHVlLuKAnSAoaXQgY291 bGQgYmUgZnVydGhlciBpbXByb3ZlZCkuDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpJdGFsbw0K DQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBt YXJ0ZWTDrCA5IG1hcnpvIDIwMjEgMTc6NTgNClRvOiBJdGFsbyBCdXNpIDxJdGFsby5CdXNpQGh1 YXdlaS5jb20+OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZT47IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFF1 ZXN0aW9ucyBhYm91dCBob3cgdG8gYXNzaWduIGRlZmF1bHQgdmFsdWVzIHdpdGggWUFORw0KDQoN Cg0KT24gVHVlLCBNYXIgOSwgMjAyMSBhdCA4OjQ2IEFNIExhZGlzbGF2IExob3RrYSA8bGFkaXNs YXYubGhvdGthQG5pYy5jejxtYWlsdG86bGFkaXNsYXYubGhvdGthQG5pYy5jej4+IHdyb3RlOg0K SXRhbG8gQnVzaSA8SXRhbG8uQnVzaUBodWF3ZWkuY29tPG1haWx0bzpJdGFsby5CdXNpQGh1YXdl aS5jb20+PiB3cml0ZXM6DQoNCj4gSGkgSnVlcmdlbiwNCj4NCj4gVGhhbmtzIGFnYWluIGZvciB5 b3VyIGNsZWFyIGV4cGxhbmF0aW9uIG9uIHRoaXMgdG9waWMNCj4NCj4gSSBoYXZlIGZvdW5kIGEg c2ltaWxhciBidXQgc2xpZ2h0bHkgZGlmZmVyZW50IGlzc3VlLiBJbiB0aGlzIGNhc2UsIGEgWUFO RyBkZWZhdWx0IHN0YXRlbWVudCBleGlzdHMgaW4gdGhlIGJhc2UgbW9kdWxlIGJ1dCB0aGUgaW50 ZW50aW9uIHdpdGggdGhlIGF1Z21lbnRhdGlvbiBpcyB0byAib3ZlcndyaXRlIiB0aGUgZGVmYXVs dCB2YWx1ZSBvbiB0aGUgYmFzaXMgb2YgYW5vdGhlciBhdHRyaWJ1dGUsIGRlZmluZWQgaW4gdGhl IG1vZHVsZSB3aGljaCBhdWdtZW50cyB0aGUgYmFzZSBtb2R1bGUuDQo+DQo+IEZvciBleGFtcGxl LCBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHN1Y2ggYSBjb2RlIGlzIHZhbGlkOg0KDQpZZXMsIHRo aXMgaXMgdmFsaWQsIEknZCBqdXN0IHN1Z2dlc3Q6DQoNCkkgZG8gbm90IGFncmVlLg0KSSBkbyBu b3Qgc2VlIGhvdyB0aGUgZGVzY3JpcHRpb24tc3RtdCBmb3IgL2ZvbyBjYW4gY2hhbmdlIHRoZSBk ZWZhdWx0IGxlYWYgcHJvY2Vzc2luZyBmb3IgL2Jhcg0KDQoNCg0KLSByZW1vdmUgdGhlIGRlZmF1 bHQgc3RhdGVtZW50IGZvciAiZm9vIiwgYXMgaXQgbWF5IGJlIGNvbmZ1c2luZyB0byBib3RoIGh1 bWFucyBhbmQgdG9vbHMNCg0Kc2VjIDcuMy40Og0KDQoNCiAgIElmIHRoZSBiYXNlIHR5cGUgaGFz IGEgZGVmYXVsdCB2YWx1ZSBhbmQgdGhlIG5ldyBkZXJpdmVkIHR5cGUgZG9lcw0KDQogICBub3Qg c3BlY2lmeSBhIG5ldyBkZWZhdWx0IHZhbHVlLCB0aGUgYmFzZSB0eXBlJ3MgZGVmYXVsdCB2YWx1 ZSBpcw0KDQogICBhbHNvIHRoZSBkZWZhdWx0IHZhbHVlIG9mIHRoZSBuZXcgZGVyaXZlZCB0eXBl Lg0KDQoNCg0KDQoNCnNlYyA3LjYuMQ0KDQoNCg0KICAgVGhlIGRlZmF1bHQgdmFsdWUgb2YgYSBs ZWFmIGlzIHRoZSB2YWx1ZSB0aGF0IHRoZSBzZXJ2ZXIgdXNlcyBpZiB0aGUNCg0KICAgbGVhZiBk b2VzIG5vdCBleGlzdCBpbiB0aGUgZGF0YSB0cmVlLiAgVGhlIHVzYWdlIG9mIHRoZSBkZWZhdWx0 IHZhbHVlDQoNCiAgIGRlcGVuZHMgb24gdGhlIGxlYWYncyBjbG9zZXN0IGFuY2VzdG9yIG5vZGUg aW4gdGhlIHNjaGVtYSB0cmVlIHRoYXQNCg0KICAgaXMgbm90IGEgbm9uLXByZXNlbmNlIGNvbnRh aW5lciAoc2VlIFNlY3Rpb24gNy41LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5 NTAjc2VjdGlvbi03LjUuMT4pOg0KDQoNCg0KICAgbyAgSWYgbm8gc3VjaCBhbmNlc3RvciBleGlz dHMgaW4gdGhlIHNjaGVtYSB0cmVlLCB0aGUgZGVmYXVsdCB2YWx1ZQ0KDQogICAgICBNVVNUIGJl IHVzZWQuDQoNCg0KDQogICBvICBPdGhlcndpc2UsIGlmIHRoaXMgYW5jZXN0b3IgaXMgYSBjYXNl IG5vZGUsIHRoZSBkZWZhdWx0IHZhbHVlIE1VU1QNCg0KICAgICAgYmUgdXNlZCBpZiBhbnkgbm9k ZSBmcm9tIHRoZSBjYXNlIGV4aXN0cyBpbiB0aGUgZGF0YSB0cmVlIG9yIHRoZQ0KDQogICAgICBj YXNlIG5vZGUgaXMgdGhlIGNob2ljZSdzIGRlZmF1bHQgY2FzZSwgYW5kIGlmIG5vIG5vZGVzIGZy b20gYW55DQoNCiAgICAgIG90aGVyIGNhc2UgZXhpc3QgaW4gdGhlIGRhdGEgdHJlZS4NCg0KDQoN CiAgIG8gIE90aGVyd2lzZSwgdGhlIGRlZmF1bHQgdmFsdWUgTVVTVCBiZSB1c2VkIGlmIHRoZSBh bmNlc3RvciBub2RlDQoNCiAgICAgIGV4aXN0cyBpbiB0aGUgZGF0YSB0cmVlLg0KDQoNCg0KDQoN Ci0gc3BlY2lmeSB0aGUgZGVmYXVsdCAoYm90aCBjYXNlcykgaW4gdGhlIGRlc2NyaXB0aW9uIG9m ICJmb28iDQoNCkEgc2ltaWxhciBleGFtcGxlIGlzIGluIHRoZSBtb2R1bGUgaWV0Zi1pcHY2LXJv dXRlci1hZHZlcnRpc2VtZW50cywgZS5nLiBsZWFmICJtaW4tcnRyLWFkdi1pbnRlcnZhbCI6DQoN Cmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM4MzQ5Lmh0bWwjc2VjdGlvbi05LjEN Cg0KTGFkYQ0KDQoNCkFuZHkNCg0KDQo+DQo+IG1vZHVsZSBleGFtcGxlLWJhc2Ugew0KPiAgIGNv bnRhaW5lciBleGFtcGxlIHsNCj4gICAgIGxlYWYgZm9vIHsNCj4gICAgICAgdHlwZSB1aW50ODsN Cj4gICAgICAgZGVmYXVsdCAwOw0KPiAgICAgfQ0KPiAgIH0NCj4gfQ0KPg0KPiBtb2R1bGUgZXhh bXBsZS1hdWdtZW50IHsNCj4gICBpbXBvcnQgZXhhbXBsZSB7DQo+ICAgICBwcmVmaXggZXg7DQo+ ICAgfQ0KPg0KPiAgIGF1Z21lbnQgImV4OmV4YW1wbGUiIHsNCj4gICAgIGxlYWYgYmFyIHsNCj4g ICAgICAgdHlwZSBlbXB0eTsNCj4gICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAiV2hlbiBw cmVzZW50LCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgZm9vIGlzIDEwLiI7DQo+ICAgICB9DQo+ICAg fQ0KPiB9DQo+DQo+DQo+IEluIHRoaXMgY2FzZSwgd2hlbiB0aGUgbGVhZiBmb28gaXMgbm90IGNv bmZpZ3VyZWQgYnV0IHRoZSBsZWFmIGJhciBpcyBwcmVzZW50LCB0aGUgdmFsdWUgb2YgZm9vIGlu IHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUgc2hvdWxkIGJlIDEwIChyYXRoZXIgdGhhbiAwKS4N Cj4NCj4gSW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyL2NsZWFu ZXIgaWYgdGhlIG9yaWdpbiBpcyBtYXJrZWQgYXMgc3lzdGVtLg0KPg0KPiBNYXliZSBhIGJldHRl ciBZQU5HIGRlc2NyaXB0aW9uIGZvciBiYXIgY291bGQgYmU6ICJXaGVuIHByZXNlbnQsIHRoZSBz eXN0ZW0gb3ZlcnJpZGVzIHRoZSBkZWZhdWx0IHZhbHVlIG9mIGZvbyB0byAxMC4iDQo+DQo+IFdo YXQgaXMgeW91ciBhbmQvb3IgV0cgb3Bpbmlvbj8NCj4NCj4gVGhhbmtzIGFnYWluDQo+DQo+IEl0 YWxvDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSnVlcmdlbiBT Y2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+XQ0KPj4gU2VudDog bWVyY29sZWTDrCAyMCBnZW5uYWlvIDIwMjEgMTc6MDUNCj4+IFRvOiBJdGFsbyBCdXNpIDxJdGFs by5CdXNpQGh1YXdlaS5jb208bWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNvbT4+DQo+PiBDYzog J25ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPicgPG5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVz dGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlcyB3aXRoDQo+PiBZQU5HDQo+ Pg0KPj4gT24gV2VkLCBKYW4gMjAsIDIwMjEgYXQgMDI6NDE6MzlQTSArMDAwMCwgSXRhbG8gQnVz aSB3cm90ZToNCj4+ID4NCj4+ID4gV2hhdCBhYm91dCB0aGUgY2FzZSB0aGUgbGVhZiBpcyBub3Qg Y29uZGl0aW9uYWwgKGJ1dCBzdGlsbCBtYW5kYXRvcnkgZmFsc2UNCj4+IHNpbmNlIGEgWUFORyBk ZWZhdWx0IHN0YXRlbWVudCBpcyBkZWZpbmVkKT8NCj4+ID4NCj4+ID4gTWF5IHRoZSBzZXJ2ZXIg c3RpbGwgZGVjaWRlIG5vdCB0byB1c2UvaW1wbGVtZW50IHRoaXMgbGVhZiBpbiB0aGUgb3BlcmF0 aW9uYWwNCj4+IGRhdGFzdG9yZT8NCj4+ID4NCj4+ID4gRm9yIGV4YW1wbGUsIGluIGFwcGVuZGl4 IEMuMSBvZiBSRkM4MzQyLCBhdXRvLW5lZ290aWF0aW9uIGlzIGVuYWJsZWQgYnkNCj4+IGRlZmF1 bHQuDQo+PiA+IFdoYXQgc2hvdWxkIGJlIHRoZSBiZWhhdmlvciBvZiBhIHN5c3RlbSB3aGljaCBk b2VzIG5vdCBpbXBsZW1lbnQgYXV0by0NCj4+IG5lZ290aWF0aW9uPw0KPj4gPiBSZXR1cm4gdGhl IHZhbHVlIGZhbHNlIG9yIG5vIHZhbHVlIChpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlKT8N Cj4+ID4NCj4+DQo+PiBIZXJlIGFyZSBzb21lIG9mIHRoZSBydWxlcyBJIHBlcnNvbmFsbHkgbGlr ZToNCj4+DQo+PiAgLSA8b3BlcmF0aW9uYWw+IGlzIHRoZSBncm91bmQgdHJ1dGggYWJvdXQgd2hh dCBhIHN5c3RlbSBoYXMgYW5kIGRvZXMNCj4+ICAtIGRvIG5vdCBpbXBsZW1lbnQgbGVhZnMgdGhh dCBkbyBub3QgYXBwbHkNCj4+DQo+PiBIZW5jZSwgaW50ZXJmYWNlcyBzdXBwb3J0aW5nIGF1dG8t bmVnb3RpYXRpb24gaGF2ZSBlaXRoZXIgYXV0by0NCj4+IG5lZ290aWF0aW9uL2VuYWJsZWQgPSB0 cnVlIG9yIGF1dG8tbmVnb3RpYXRpb24vZW5hYmxlZCA9IGZhbHNlIGluDQo+PiA8b3BlcmF0aW9u YWw+LiBBbmQgaW50ZXJmYWNlcyBub3Qgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUg bm90aGluZw0KPj4gdG8gcmVwb3J0IGFib3V0IGF1dG8tbmVnb3RpYXRpb24uIFllcywgSSBkbyBu b3Qgd2FudCB0byBzZWUgYXV0by0NCj4+IG5lZ290aWF0aW9uL2VuYWJsZWQgPSBmYWxzZSBvbiBh IGxvb3BiYWNrIGludGVyZmFjZS4NCj4+DQo+PiBNeSBoaXN0b3JpYyBFdGhlcm5ldCBpbnRlcmZh Y2UgZnJvbSB0aGUgbGFzdCBjZW50dXJ5IHdvdWxkIGFsc28gbm90IHJlcG9ydA0KPj4gYXV0by1u ZWdvdGlhdGlvbi9lbmFibGVkIGluIDxvcGVyYXRpb25hbD4uIFlvdSBtYXkgaGl0IGFwcGxpY2F0 aW9ucyB0aGF0IGxvdmUNCj4+IHRvIGhhdmUgYXV0by1uZWdvdGlhdGlvbi9lbmFibGVkIGF2YWls YWJsZSBvbiBhbGwgRXRoZXJuZXQgaW50ZXJmYWNlcyBhbmQgdGhlbg0KPj4geW91IGVuZCBpbiBh IGRlYmF0ZSB3aGVyZSB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0ZWxsIHlvdSB0aGF0IG5v DQo+PiBpbmZvcm1hdGlvbiBpbiA8b3BlcmF0aW9uYWw+IG1heSBoYXZlIG1hbnkgcmVhc29ucyAo aW5zdHJ1bWVudGF0aW9uIG5vdA0KPj4gaW1wbGVtZW50ZWQsIGFjY2VzcyBjb250cm9sIHJ1bGVz LCB3aGF0ZXZlciBhbmQgYnkgcmVwb3J0aW5nIGVuYWJsZWQ9ZmFsc2UNCj4+IHlvdSBkbyB0aGVt IGEgZmF2b3IpIGJ1dCB0aGUgdHJ1ZSBhbnN3ZXIgaW4gc3VjaCBhIGRlYmF0ZSBpcyBvZnRlbiB0 aGF0DQo+PiBtb2RlbGluZyB0aGluZ3MgYXMgYSBib29sZWFuIGlzIHNpbXBsaXN0aWMgc2luY2Ug dGhlcmUgYXJlIG9mdGVuIG1vcmUgdGhhbg0KPj4gZXhhY3RseSB0d28gc3RhdGVzIChpbiB0aGlz IGNhc2UsIGVuYWJsZWQsIGRpc2FibGVkLCBmYWlsZWQsIG5vdC1hdmFpbGFibGUsIC4uLikuDQo+ PiBTbyB5b3Ugc2V0dGxlIG9uIGJsYW1pbmcgdGhlIG1vZGVsIHdyaXRlci4gOy0pDQo+Pg0KPj4g L2pzDQo+Pg0KPj4gLS0NCj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2Jz IFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg ICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+PiBGYXg6ICAgKzQ5 IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+ DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoN Ci0tDQpMYWRpc2xhdiBMaG90a2ENCkhlYWQsIENaLk5JQyBMYWJzDQpQR1AgS2V5IElEOiAweEI4 RjkyQjA4QTlGNzZDNjcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg== --_000_cfec6d0a6e1248a1a35f54b701d2976chuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIs c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+TGFkYSwgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBmZWVkYmFja3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBpZiB0aGUgYmFz ZSBtb2RlbCBhbmQgdGhlIGF1Z21lbnRhdGlvbiBtb2RlbCBhcmUgZGVmaW5lZCBhdCB0aGUgc2Ft ZSB0aW1lLCB3ZSBjYW4gYXZvaWQgZGVmaW5pbmcgYW55IFlBTkcgZGVmYXVsdCBzdGF0ZW1lbnQg aW4gdGhlDQogYmFzZSBtb2RlbCBhbmQgcHJvdmlkaW5nIGEgcHJvcGVyIGRlc2NyaXB0aW9uIG9m IHRoZSBkZXNpcmVkIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QmFzZWQgb24gcHJldmlvdXMgZGlzY3Vzc2lvbiB3aXRoIEp1ZXJnZW4sIEkgaGF2 ZSB1bmRlcnN0b29kIHRoYXQsIGluIHRoaXMgY2FzZSwgdGhlIG9yaWdpbiBpbiB0aGUgb3BlcmF0 aW9uYWwgZGF0YXN0b3JlIGNhbiBiZSBlaXRoZXIgc2V0IHRvIGRlZmF1bHQgb3IgdG8gc3lzdGVt DQogKEp1ZXJnZW4gcHJlZmVycyB0aGUgbGF0dGVyIGJ1dCB0aGUgZm9ybWVyIGlzIGFsbG93ZWQg Ynkgc2VjdGlvbiA1LjMuNCBvZiBSRkM4MzQyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhpcyB3b3VsZCBiZSB0aGUgaWRlYWwgc29sdXRpb24s IGJ1dCBpbiBwcmFjdGljZSB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgdGhlIGJhc2UgbW9kZWwgaGFz IGJlZW4gd3JpdHRlbiBiZWZvcmUgdGhlIGF1Z21lbnRhdGlvbiBtb2RlbCBhbmQvb3IgdGhlIGF1 dGhvcg0KIG9mIHRoZSBiYXNlIG1vZGVsIGlzIG5vdCBhd2FyZSBvZiB0aGUgbmVlZHMgZnJvbSB0 aGUgYXV0aG9yIG9mIHRoZSBhdWdtZW50YXRpb24gbW9kZWwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIHRoZXNlIGNhc2VzLCB0aGUgWUFORyBkZWZhdWx0 IHN0YXRlbWVudCBhbHJlYWR5IGV4aXN0cyBpbiB0aGUgYmFzZSBtb2RlbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklzIGl0IHJlYWxseSByZXF1aXJlZCB0byBj aGFuZ2UgdGhlIGJhc2UgbW9kZWwgb3IgY291bGQgYSB3b3JrLWFyb3VuZCBiZSBmb3VuZD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIHByaW5jaXBsZSwgdGhl IHN5c3RlbSBoYXMgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHVuZGVyc3RhbmQgdGhhdCwgaWYgbm8g dmFsdWUgZm9yIHRoZSBsZWFmIGZvbyBpcyBwcm92aWRlZCBpbiB0aGUgaW50ZW5kZWQgRFMsIHRo ZSB2YWx1ZSBpbiB0aGUgYXBwbGllZCBjb25maWd1cmF0aW9uDQogZm9yIHRoZSBsZWFmIGZvbyBz aG91bGQgYmUgMTAgcmF0aGVyIHRoYW4gdGhlIHZhbHVlIGRlZmluZWQgaW4gdGhlIFlBTkcgZGVm YXVsdCBzdGF0ZW1lbnQgKGkuZS4sIDApLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QmFzZWQgeW91ciBjb21tZW50cywgSSB0aGluayB0aGF0IGluIHRoaXMgY2Fz ZSwgdGhlIG9yaWdpbiBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIG11c3Qgbm90IGJlIHNl dCB0byBkZWZhdWx0LCBidXQgSSBhbSB3b25kZXJpbmcgd2hldGhlciBpdCBjb3VsZCBiZSBzZXQN CiB0byBzeXN0ZW0gaW5zdGVhZC4gSW4gb3RoZXIgd29yZHMsIHRoZSBhcHBsaWVkIGNvbmZpZ3Vy YXRpb24gZm9yIGZvbyBpcyBwcm92aWRlZCBieSB0aGUgc3lzdGVtIG9uIHRoZSBiYXNpcyBvZiB0 aGUgcnVsZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb25maWd1cmF0aW9uIG9mIGJhci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoaXMgaXMgcG9zc2libGUs IHRoZW4gdGhlIGlzc3VlIGNvdWxkIGJlIHNvbHZlZCB3aXRob3V0IHRoZSBuZWVkIHRvIHJlcXVl c3QgYSBjaGFuZ2UgdG8gdGhlIGJhc2UgbW9kZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGUgZGVzY3JpcHRpb24gaW4gdGhlIGF1Z21lbnRlZCBtb2RlbCBu ZWVkcyB0byBiZSBjbGVhbmVkLXVwIHNpbmNlIGluIG15IGluaXRpYWwgbWFpbCBpdCB3YXMgbWlz bGVhZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1heWJl IGEgYmV0dGVyIGFsdGVybmF0aXZlIGNvdWxkIGJlIHNvbWV0aGluZyBsaWtlIOKAnDwvc3Bhbj5X aGVuIGJhciBpcyBwcmVzZW50IGFuZCBmb28gaXMgbm90IGNvbmZpZ3VyZWQsIHRoZSBzeXN0ZW0g YXBwbGllcyB0aGUgdmFsdWUgMTAgdG8gZm9vIHJhdGhlciB0aGFuIGl0cw0KIGRlZmF1bHQgdmFs dWUuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnSAoaXQgY291bGQgYmUgZnVydGhl ciBpbXByb3ZlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5X aGF0IGRvIHlvdSB0aGluaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkl0YWxvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBC aWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1h cnRlZMOsIDkgbWFyem8gMjAyMSAxNzo1ODxicj4NCjxiPlRvOjwvYj4gSXRhbG8gQnVzaSAmbHQ7 SXRhbG8uQnVzaUBodWF3ZWkuY29tJmd0OzsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7OyBuZXRtb2RAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIFF1ZXN0aW9ucyBhYm91dCBob3cgdG8gYXNz aWduIGRlZmF1bHQgdmFsdWVzIHdpdGggWUFORzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA5LCAyMDIxIGF0IDg6NDYg QU0gTGFkaXNsYXYgTGhvdGthICZsdDs8YSBocmVmPSJtYWlsdG86bGFkaXNsYXYubGhvdGthQG5p Yy5jeiI+bGFkaXNsYXYubGhvdGthQG5pYy5jejwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5JdGFsbyBCdXNpICZsdDs8YSBocmVmPSJtYWlsdG86SXRhbG8uQnVz aUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+SXRhbG8uQnVzaUBodWF3ZWkuY29tPC9hPiZn dDsgd3JpdGVzOjxicj4NCjxicj4NCiZndDsgSGkgSnVlcmdlbiw8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaGFua3MgYWdhaW4gZm9yIHlvdXIgY2xlYXIgZXhwbGFuYXRpb24gb24gdGhpcyB0b3BpYzxi cj4NCiZndDs8YnI+DQomZ3Q7IEkgaGF2ZSBmb3VuZCBhIHNpbWlsYXIgYnV0IHNsaWdodGx5IGRp ZmZlcmVudCBpc3N1ZS4gSW4gdGhpcyBjYXNlLCBhIFlBTkcgZGVmYXVsdCBzdGF0ZW1lbnQgZXhp c3RzIGluIHRoZSBiYXNlIG1vZHVsZSBidXQgdGhlIGludGVudGlvbiB3aXRoIHRoZSBhdWdtZW50 YXRpb24gaXMgdG8gJnF1b3Q7b3ZlcndyaXRlJnF1b3Q7IHRoZSBkZWZhdWx0IHZhbHVlIG9uIHRo ZSBiYXNpcyBvZiBhbm90aGVyIGF0dHJpYnV0ZSwgZGVmaW5lZCBpbiB0aGUgbW9kdWxlIHdoaWNo DQogYXVnbWVudHMgdGhlIGJhc2UgbW9kdWxlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZvciBleGFt cGxlLCBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHN1Y2ggYSBjb2RlIGlzIHZhbGlkOjxicj4NCjxi cj4NClllcywgdGhpcyBpcyB2YWxpZCwgSSdkIGp1c3Qgc3VnZ2VzdDo8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IGFn cmVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBkbyBub3Qgc2VlIGhvdyB0aGUgZGVzY3JpcHRpb24tc3RtdCBmb3IgL2ZvbyBjYW4gY2hhbmdl IHRoZSBkZWZhdWx0IGxlYWYgcHJvY2Vzc2luZyBmb3IgL2JhcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSByZW1vdmUgdGhl IGRlZmF1bHQgc3RhdGVtZW50IGZvciAmcXVvdDtmb28mcXVvdDssIGFzIGl0IG1heSBiZSBjb25m dXNpbmcgdG8gYm90aCBodW1hbnMgYW5kIHRvb2xzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWMgNy4zLjQ6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElmIHRoZSBiYXNlIHR5cGUgaGFzIGEgZGVmYXVs dCB2YWx1ZSBhbmQgdGhlIG5ldyBkZXJpdmVkIHR5cGUgZG9lczxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBub3Qgc3Bl Y2lmeSBhIG5ldyBkZWZhdWx0IHZhbHVlLCB0aGUgYmFzZSB0eXBlJ3MgZGVmYXVsdCB2YWx1ZSBp czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBhbHNvIHRoZSBkZWZhdWx0IHZhbHVlIG9mIHRoZSBuZXcgZGVyaXZlZCB0 eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBh Z2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJl Zm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnNlYyA3LjYuMTxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJicmVhay1iZWZvcmU6cGFnZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgVGhlIGRlZmF1bHQgdmFsdWUgb2YgYSBsZWFmIGlzIHRoZSB2YWx1ZSB0aGF0IHRoZSBzZXJ2 ZXIgdXNlcyBpZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbGVhZiBkb2VzIG5vdCBleGlzdCBpbiB0aGUgZGF0 YSB0cmVlLiZuYnNwOyBUaGUgdXNhZ2Ugb2YgdGhlIGRlZmF1bHQgdmFsdWU8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg ZGVwZW5kcyBvbiB0aGUgbGVhZidzIGNsb3Nlc3QgYW5jZXN0b3Igbm9kZSBpbiB0aGUgc2NoZW1h IHRyZWUgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBpcyBub3QgYSBub24tcHJlc2VuY2UgY29udGFpbmVyIChz ZWUgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi03 LjUuMSI+U2VjdGlvbiA3LjUuMTwvYT4pOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvJm5ic3A7IElmIG5v IHN1Y2ggYW5jZXN0b3IgZXhpc3RzIGluIHRoZSBzY2hlbWEgdHJlZSwgdGhlIGRlZmF1bHQgdmFs dWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVVTVCBiZSB1c2VkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBvJm5ic3A7IE90aGVyd2lzZSwgaWYgdGhpcyBhbmNlc3RvciBpcyBhIGNhc2Ugbm9k ZSwgdGhlIGRlZmF1bHQgdmFsdWUgTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBi ZSB1c2VkIGlmIGFueSBub2RlIGZyb20gdGhlIGNhc2UgZXhpc3RzIGluIHRoZSBkYXRhIHRyZWUg b3IgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhc2Ugbm9kZSBpcyB0aGUgY2hv aWNlJ3MgZGVmYXVsdCBjYXNlLCBhbmQgaWYgbm8gbm9kZXMgZnJvbSBhbnk8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgb3RoZXIgY2FzZSBleGlzdCBpbiB0aGUgZGF0YSB0cmVlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBvJm5ic3A7IE90aGVyd2lzZSwgdGhlIGRlZmF1bHQgdmFsdWUgTVVTVCBi ZSB1c2VkIGlmIHRoZSBhbmNlc3RvciBub2RlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGV4aXN0cyBpbiB0aGUgZGF0YSB0cmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotIHNwZWNpZnkgdGhlIGRl ZmF1bHQgKGJvdGggY2FzZXMpIGluIHRoZSBkZXNjcmlwdGlvbiBvZiAmcXVvdDtmb28mcXVvdDs8 YnI+DQo8YnI+DQpBIHNpbWlsYXIgZXhhbXBsZSBpcyBpbiB0aGUgbW9kdWxlIGlldGYtaXB2Ni1y b3V0ZXItYWR2ZXJ0aXNlbWVudHMsIGUuZy4gbGVhZiAmcXVvdDttaW4tcnRyLWFkdi1pbnRlcnZh bCZxdW90Ozo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9y ZmMvcmZjODM0OS5odG1sI3NlY3Rpb24tOS4xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvcmZjL3JmYzgzNDkuaHRtbCNzZWN0aW9uLTkuMTwvYT48YnI+DQo8YnI+ DQpMYWRhPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0Ozxicj4NCiZndDsgbW9kdWxlIGV4YW1wbGUt YmFzZSB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtjb250YWluZXIgZXhhbXBsZSB7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhZiBmb28gezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0eXBlIHVpbnQ4Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkZWZhdWx0IDA7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsmbmJz cDsgJm5ic3A7fTxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7IG1vZHVsZSBleGFtcGxl LWF1Z21lbnQgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7aW1wb3J0IGV4YW1wbGUgezxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO3ByZWZpeCBleDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO308 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthdWdtZW50ICZxdW90O2V4OmV4YW1wbGUm cXVvdDsgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2xlYWYgYmFyIHs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBlbXB0eTs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZxdW90O1doZW4gcHJlc2VudCwgdGhlIGRlZmF1bHQgdmFsdWUgZm9y IGZvbyBpcyAxMC4mcXVvdDs7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgfTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJbiB0aGlzIGNhc2UsIHdoZW4gdGhlIGxlYWYgZm9vIGlzIG5vdCBjb25maWd1cmVkIGJ1dCB0 aGUgbGVhZiBiYXIgaXMgcHJlc2VudCwgdGhlIHZhbHVlIG9mIGZvbyBpbiB0aGUgb3BlcmF0aW9u YWwgZGF0YXN0b3JlIHNob3VsZCBiZSAxMCAocmF0aGVyIHRoYW4gMCkuPGJyPg0KJmd0Ozxicj4N CiZndDsgSW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyL2NsZWFu ZXIgaWYgdGhlIG9yaWdpbiBpcyBtYXJrZWQgYXMgc3lzdGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7 IE1heWJlIGEgYmV0dGVyIFlBTkcgZGVzY3JpcHRpb24gZm9yIGJhciBjb3VsZCBiZTogJnF1b3Q7 V2hlbiBwcmVzZW50LCB0aGUgc3lzdGVtIG92ZXJyaWRlcyB0aGUgZGVmYXVsdCB2YWx1ZSBvZiBm b28gdG8gMTAuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBpcyB5b3VyIGFuZC9vciBX RyBvcGluaW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyBhZ2Fpbjxicj4NCiZndDs8YnI+ DQomZ3Q7IEl0YWxvPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFy Z2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT5dPGJy Pg0KJmd0OyZndDsgU2VudDogbWVyY29sZWTDrCAyMCBnZW5uYWlvIDIwMjEgMTc6MDU8YnI+DQom Z3Q7Jmd0OyBUbzogSXRhbG8gQnVzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkl0YWxvLkJ1c2lAaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkl0YWxvLkJ1c2lAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyZndDsgQ2M6ICc8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPicgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVzdGlvbnMgYWJvdXQgaG93IHRvIGFzc2ln biBkZWZhdWx0IHZhbHVlcyB3aXRoPGJyPg0KJmd0OyZndDsgWUFORzxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgT24gV2VkLCBKYW4gMjAsIDIwMjEgYXQgMDI6NDE6MzlQTSAmIzQzOzAwMDAs IEl0YWxvIEJ1c2kgd3JvdGU6PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsg V2hhdCBhYm91dCB0aGUgY2FzZSB0aGUgbGVhZiBpcyBub3QgY29uZGl0aW9uYWwgKGJ1dCBzdGls bCBtYW5kYXRvcnkgZmFsc2U8YnI+DQomZ3Q7Jmd0OyBzaW5jZSBhIFlBTkcgZGVmYXVsdCBzdGF0 ZW1lbnQgaXMgZGVmaW5lZCk/PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsg TWF5IHRoZSBzZXJ2ZXIgc3RpbGwgZGVjaWRlIG5vdCB0byB1c2UvaW1wbGVtZW50IHRoaXMgbGVh ZiBpbiB0aGUgb3BlcmF0aW9uYWw8YnI+DQomZ3Q7Jmd0OyBkYXRhc3RvcmU/PGJyPg0KJmd0OyZn dDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgRm9yIGV4YW1wbGUsIGluIGFwcGVuZGl4IEMuMSBv ZiBSRkM4MzQyLCBhdXRvLW5lZ290aWF0aW9uIGlzIGVuYWJsZWQgYnk8YnI+DQomZ3Q7Jmd0OyBk ZWZhdWx0Ljxicj4NCiZndDsmZ3Q7ICZndDsgV2hhdCBzaG91bGQgYmUgdGhlIGJlaGF2aW9yIG9m IGEgc3lzdGVtIHdoaWNoIGRvZXMgbm90IGltcGxlbWVudCBhdXRvLTxicj4NCiZndDsmZ3Q7IG5l Z290aWF0aW9uPzxicj4NCiZndDsmZ3Q7ICZndDsgUmV0dXJuIHRoZSB2YWx1ZSBmYWxzZSBvciBu byB2YWx1ZSAoaW4gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSk/PGJyPg0KJmd0OyZndDsgJmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSGVyZSBhcmUgc29tZSBvZiB0aGUgcnVsZXMg SSBwZXJzb25hbGx5IGxpa2U6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAtICZs dDtvcGVyYXRpb25hbCZndDsgaXMgdGhlIGdyb3VuZCB0cnV0aCBhYm91dCB3aGF0IGEgc3lzdGVt IGhhcyBhbmQgZG9lczxicj4NCiZndDsmZ3Q7Jm5ic3A7IC0gZG8gbm90IGltcGxlbWVudCBsZWFm cyB0aGF0IGRvIG5vdCBhcHBseTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSGVuY2UsIGlu dGVyZmFjZXMgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUgZWl0aGVyIGF1dG8tPGJy Pg0KJmd0OyZndDsgbmVnb3RpYXRpb24vZW5hYmxlZCA9IHRydWUgb3IgYXV0by1uZWdvdGlhdGlv bi9lbmFibGVkID0gZmFsc2UgaW48YnI+DQomZ3Q7Jmd0OyAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiBB bmQgaW50ZXJmYWNlcyBub3Qgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUgbm90aGlu Zzxicj4NCiZndDsmZ3Q7IHRvIHJlcG9ydCBhYm91dCBhdXRvLW5lZ290aWF0aW9uLiBZZXMsIEkg ZG8gbm90IHdhbnQgdG8gc2VlIGF1dG8tPGJyPg0KJmd0OyZndDsgbmVnb3RpYXRpb24vZW5hYmxl ZCA9IGZhbHNlIG9uIGEgbG9vcGJhY2sgaW50ZXJmYWNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgTXkgaGlzdG9yaWMgRXRoZXJuZXQgaW50ZXJmYWNlIGZyb20gdGhlIGxhc3QgY2VudHVy eSB3b3VsZCBhbHNvIG5vdCByZXBvcnQ8YnI+DQomZ3Q7Jmd0OyBhdXRvLW5lZ290aWF0aW9uL2Vu YWJsZWQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy4gWW91IG1heSBoaXQgYXBwbGljYXRpb25zIHRo YXQgbG92ZTxicj4NCiZndDsmZ3Q7IHRvIGhhdmUgYXV0by1uZWdvdGlhdGlvbi9lbmFibGVkIGF2 YWlsYWJsZSBvbiBhbGwgRXRoZXJuZXQgaW50ZXJmYWNlcyBhbmQgdGhlbjxicj4NCiZndDsmZ3Q7 IHlvdSBlbmQgaW4gYSBkZWJhdGUgd2hlcmUgdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdGVs bCB5b3UgdGhhdCBubzxicj4NCiZndDsmZ3Q7IGluZm9ybWF0aW9uIGluICZsdDtvcGVyYXRpb25h bCZndDsgbWF5IGhhdmUgbWFueSByZWFzb25zIChpbnN0cnVtZW50YXRpb24gbm90PGJyPg0KJmd0 OyZndDsgaW1wbGVtZW50ZWQsIGFjY2VzcyBjb250cm9sIHJ1bGVzLCB3aGF0ZXZlciBhbmQgYnkg cmVwb3J0aW5nIGVuYWJsZWQ9ZmFsc2U8YnI+DQomZ3Q7Jmd0OyB5b3UgZG8gdGhlbSBhIGZhdm9y KSBidXQgdGhlIHRydWUgYW5zd2VyIGluIHN1Y2ggYSBkZWJhdGUgaXMgb2Z0ZW4gdGhhdDxicj4N CiZndDsmZ3Q7IG1vZGVsaW5nIHRoaW5ncyBhcyBhIGJvb2xlYW4gaXMgc2ltcGxpc3RpYyBzaW5j ZSB0aGVyZSBhcmUgb2Z0ZW4gbW9yZSB0aGFuPGJyPg0KJmd0OyZndDsgZXhhY3RseSB0d28gc3Rh dGVzIChpbiB0aGlzIGNhc2UsIGVuYWJsZWQsIGRpc2FibGVkLCBmYWlsZWQsIG5vdC1hdmFpbGFi bGUsIC4uLikuPGJyPg0KJmd0OyZndDsgU28geW91IHNldHRsZSBvbiBibGFtaW5nIHRoZSBtb2Rl bCB3cml0ZXIuIDstKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgL2pzPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIPGJyPg0KJmd0OyZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55PGJyPg0KJmd0OyZndDsgRmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAy MDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0 bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJy Pg0KPGJyPg0KLS0gPGJyPg0KTGFkaXNsYXYgTGhvdGthPGJyPg0KSGVhZCwgQ1ouTklDIExhYnM8 YnI+DQpQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjc8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_cfec6d0a6e1248a1a35f54b701d2976chuaweicom_-- From nobody Tue Mar 9 11:52:49 2021 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 CE34E3A08B0 for ; Tue, 9 Mar 2021 11:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyIKuViNx97b for ; Tue, 9 Mar 2021 11:52:45 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2064.outbound.protection.outlook.com [40.107.20.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6796C3A08AA for ; Tue, 9 Mar 2021 11:52:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E2Sk2DaOdl1h5bkdK2QfS2T/iPzo9vAOnuQjjRfMNC5fOl+PpINwUn9uvs3YXYte9sPUZ99Ir0sTt4i6HOwdsELWpuHI+oYDc+zn/TAjB4ChLGjjkF9gT2/niQryvTnl1r0wOLKvU8UuOGtgJSltehq/S3PhiJBu/oOIru2OavmqmUXhnJ6VVV5qkK7IseJg221ELk26JzCWPU8bprGzA6Ttat/6uZOJTUeonK02biUzOTNlgZznGXzXVl3Gk+ViYHjx4R86Sw27F3u0ZWdtl7if9d1ba7SclPvnvsUrw4HznPfyqxWUDXuT27UDpgWF8jlLf8ofSsYiySiHgVN6ew== 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=4uZepd94h2zbnypo+0IKSpBqdZdYujkyRH+wkO95908=; b=MQ4cA6luZ8s8hVYXRxaSqZmUx6Kr1pPGc8h6WH/PLHVu31Xq6LKFtqitcco2d1vSLQQSp17edIZ2gNeszvaMKF5suVoDdAGzzjLSykUVOINvVkWJ+/8Ztp2FbpQo17+GS72QZPmHn4v9v/L9S4NgC2mVn46jMuLzDzCcJ1PNSqq24OnF71arto0nw6k2hmWq56lrjbrhgQvBtG3ULbnvzhewMvET6tBCzvKFt7OCGYLNhwkZmNhdw4gBIPrufSq4zJrOli/qzuiSiWybZ8MbJmgSSMYhYX3rT6zIhaDyE0JvhBCnDKMPLOFPmugG6GDpTewp31Cg6oiyJ9/NpUkdkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4uZepd94h2zbnypo+0IKSpBqdZdYujkyRH+wkO95908=; b=aC984fGHhEDfW5V5uj3VSA4RZ+OB1DfFNpnpQrTDJfCQ4Zb/iUUFJFYgKcOF3mwStn+AOdI/eJh/3PEGnpaYoR9mVm4AqyZJg/2gBm+TwIRZC3PnWv6xxln1bzz+6QRG0F3BeJqg4jySLcyAxHekbtbfM/dAM1hvuFvlprmdoC8= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0884.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Tue, 9 Mar 2021 19:52:42 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3912.027; Tue, 9 Mar 2021 19:52:42 +0000 Date: Tue, 9 Mar 2021 20:52:41 +0100 From: Juergen Schoenwaelder To: Italo Busi Cc: "'netmod@ietf.org'" Message-ID: <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Italo Busi , "'netmod@ietf.org'" References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <521a9ccd02e14d178a6e62971b4809ea@huawei.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR10CA0042.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::22) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR10CA0042.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Tue, 9 Mar 2021 19:52:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b97363db-0049-4ce0-5c32-08d8e334e6ed X-MS-TrafficTypeDiagnostic: AM8P190MB0884: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oPzyjbGZCrlxXUDUBqfcii0bz3PSsmdEcN5Bu0g6W38NnKEtbnJ+6UuQ81KHuhMNNkLrDPhtFHtI5DU3jXQ4idx1RA+KXnqkQLKzlyGd4m+Ss/Q2+9rVcerkErSQBKMxt8vBzJmIWLbiNV8t2pm9X3gg0XoZpuwyFdaxsfEdCo/weiISWzxlcvxuduiMT8wwcrpr+MJfS39EvVRuhTZlL7P32duoc0dWdm7QJID59SSqAorUFnS/7rk2ZONUx+SF4daI956udmOpDR2uOxMKBGa0UQgYGN49bKwNz53Cejo6dWmNHENeE6br5wAeLjyBrMsPlyKviK05yQ9Iqew5D0zoaNrg92e6A8GnKkjA8g8HYSYvNlkfqaRjanModYwpQ74g5YVBZEbizA+DbWlnjH1LIgp8j8GNI0D1HeoVJLGMWMIPBoFiA8c21DOMTAEt8JqETmllRNL0OxUlX3Nxiv+WjNepo2xPnToSrCoJpupoH6kAwOqHLushcF50MPvgE5tD8w2sJ2vhU1ZXh2P7utIUT2VHnBuBLl9Z5DELaYXs7cl7t+1fr/dS73onZL6UgP62xFBa/C8FTwmmUhzCEtfukpui0VdGT/VwS6HOGeY= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(83380400001)(2906002)(956004)(6916009)(3450700001)(8676002)(4326008)(6486002)(86362001)(16526019)(66476007)(8936002)(1076003)(26005)(498600001)(186003)(53546011)(6496006)(52116002)(5660300002)(66946007)(66556008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?E/iOt3cM0ggPGJGbbu4CknTZKXu3UFZwY5slkh4N8p0BuVdP37kpz8eaLi?= =?iso-8859-1?Q?RQbCHDRV0RIkGz2oRLakF99aJ7+USaYlszlgeJnxPB80t2JxzCEuRCUjVM?= =?iso-8859-1?Q?KCgOmZw+fLHQNkBr512RG65Mdv12BALdW4/wesGdyMz9j1pS7Rzcmx26ea?= =?iso-8859-1?Q?sHK1yNPp+Vjqx9W2oWX11gkYg+gLcnbPJpZ8Ey2iKh9B7NyoFGiPRvyJUz?= =?iso-8859-1?Q?YOZjLZnZk+vE+Lues+FO6wXsUUZDrgllPkIhGkJIwH3P3kaRzcv2H+jEjS?= =?iso-8859-1?Q?B7tRwNeCaZDT+LqzfI+i5MPmZr7UK1dXqI8Pf0BbYfrvWZwzV3rpyPVATf?= =?iso-8859-1?Q?QRpKmD/Gm5VXFbyWQbIs6jnWs2m0cm27hwf45PuVuDcmXfEC8Tk5kIHblK?= =?iso-8859-1?Q?jJv1T2pxIfVbv4mlEt1QROwH3vzZsDeL2cR2QugAr1EVvh3mmIDL3jYEWp?= =?iso-8859-1?Q?x2/IdEDJmjm1Syd82Ql+QjwvvOU70ipTyRBgCT3AS61kobZupQ1a7UJmaz?= =?iso-8859-1?Q?bNOprPovcMSYxOF/PHfQYCjLHW2Iy/r9ehU4KjGEvhN54w1DH2oFZSme5w?= =?iso-8859-1?Q?czbrzWqEmTNYvUW2MMZq4U8fJ8oLzpeKKc3Y8KeJqg/9s08adF2Fmdccaf?= =?iso-8859-1?Q?MSDmjii8gNzGm2bZBdIf8p13GNutWLku6xR70JHSqfj/8X7bEfvGBsRDeG?= =?iso-8859-1?Q?5LJc2MAwN/gQBHkF4yo9OdSlv0aV6CSOubr0pbXiEwO/sshvEhAJ368+QS?= =?iso-8859-1?Q?cw+FjK3vhYCES0U68wyZHeTAUd1iCM9cKgjiRngrka1GVQv/N6vT1JlUoi?= =?iso-8859-1?Q?gaWrida2k7ZeO2WDOrMzyXYOY9USVId/7/X9Rf+ikhb7HqbWPeswU1QAcF?= =?iso-8859-1?Q?8V9i91SuKH+6RItghKRGhMM3zp6VN4cG0K2V1peRdj/NaR07hHu9Uh7j7a?= =?iso-8859-1?Q?GRYSDAs5BgLJXyaLaWSUCF0yTEmP4/O+Fse4+e+SCJupd+uNGm99XPI5a7?= =?iso-8859-1?Q?rVmbZJfs3uXA1VJXzqnPGHOEviFVtU8/hxWBNsyUrah9tnHgy/anoUXL/1?= =?iso-8859-1?Q?j1Q8UlrGdm2oOjzcoTKse3f1Xm5FSHsqkikDML94XtKir9c6ss+AFRayhU?= =?iso-8859-1?Q?960rY86rFg0x9FpB08Lcjo/bBLMY00pUD/ZP7ZVdMKnoRQ9ORdjNo+8SlQ?= =?iso-8859-1?Q?JUdzNmbn5RymY3+ajIxq4UaHlRf4ataXZComJyjnOYdj1xuhXtS88qJ/ai?= =?iso-8859-1?Q?tfuFAxlJNHdFxdPDZVgh7kbM1mHDLR/cjVj/7GoA5cK+btvin8fWIvRl/a?= =?iso-8859-1?Q?JxGol+jaNOpQFi6UNLqlqUPxQAChLK3UVtZBJyIm9InaQG2bGuzLw5etXx?= =?iso-8859-1?Q?Edd78CJs0b?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: b97363db-0049-4ce0-5c32-08d8e334e6ed X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2021 19:52:42.6090 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sIrXr9Pn1egVh8aZSIv/0a8ebkavKz9XbnQRZ1lSN5VvVYpBa0B6evsVzu7ArYyAdnDMZwspsi0qpV1TiSiNES4h2Q1u56BdjUDrqs4LQPs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0884 Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 19:52:48 -0000 Changing the semantics of a definition via augments is bad design. A system that does not understand the augment will believe the default is 0. Since there is no way to force an existing implementation to understand a certain augmentation, different implementation will rightfully disagree on the default value in effect. /js On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > Hi Juergen, > > Thanks again for your clear explanation on this topic > > I have found a similar but slightly different issue. In this case, a YANG default statement exists in the base module but the intention with the augmentation is to "overwrite" the default value on the basis of another attribute, defined in the module which augments the base module. > > For example, I am wondering whether such a code is valid: > > module example-base { > container example { > leaf foo { > type uint8; > default 0; > } > } > } > > module example-augment { > import example { > prefix ex; > } > > augment "ex:example" { > leaf bar { > type empty; > description > "When present, the default value for foo is 10."; > } > } > } > > > In this case, when the leaf foo is not configured but the leaf bar is present, the value of foo in the operational datastore should be 10 (rather than 0). > > In this case, I think that it would be better/cleaner if the origin is marked as system. > > Maybe a better YANG description for bar could be: "When present, the system overrides the default value of foo to 10." > > What is your and/or WG opinion? > > Thanks again > > Italo > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: mercoledì 20 gennaio 2021 17:05 > > To: Italo Busi > > Cc: 'netmod@ietf.org' > > Subject: Re: [netmod] Questions about how to assign default values with > > YANG > > > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > > > > > What about the case the leaf is not conditional (but still mandatory false > > since a YANG default statement is defined)? > > > > > > May the server still decide not to use/implement this leaf in the operational > > datastore? > > > > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by > > default. > > > What should be the behavior of a system which does not implement auto- > > negotiation? > > > Return the value false or no value (in the operational datastore)? > > > > > > > Here are some of the rules I personally like: > > > > - is the ground truth about what a system has and does > > - do not implement leafs that do not apply > > > > Hence, interfaces supporting auto-negotiation have either auto- > > negotiation/enabled = true or auto-negotiation/enabled = false in > > . And interfaces not supporting auto-negotiation have nothing > > to report about auto-negotiation. Yes, I do not want to see auto- > > negotiation/enabled = false on a loopback interface. > > > > My historic Ethernet interface from the last century would also not report > > auto-negotiation/enabled in . You may hit applications that love > > to have auto-negotiation/enabled available on all Ethernet interfaces and then > > you end in a debate where the application developers tell you that no > > information in may have many reasons (instrumentation not > > implemented, access control rules, whatever and by reporting enabled=false > > you do them a favor) but the true answer in such a debate is often that > > modeling things as a boolean is simplistic since there are often more than > > exactly two states (in this case, enabled, disabled, failed, not-available, ...). > > So you settle on blaming the model writer. ;-) > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 9 12:11:47 2021 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 9B54B3A09B5 for ; Tue, 9 Mar 2021 12:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBmm4DF1m5At for ; Tue, 9 Mar 2021 12:11:44 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB863A09BD for ; Tue, 9 Mar 2021 12:11:43 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id k9so29335710lfo.12 for ; Tue, 09 Mar 2021 12:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zKaU2HncztpDaw71xz/LlpcxFDnc/okg6h/DOGykPpY=; b=s8hGCxoTdp0/OJflWmW67aU7ls7aWuPvcSVbHLkhtW9pTFrIQ4Ut+r+PyFNC5yvpUv kuq9iP+0oUeH4FJ08xcVduVu54w4n9wSU8WiIthisS/QhbbybEwPKZ6GHUN0UrAG1B0v bTgilqWD4YZbG1yM0/8+v1ubNsGj32rzrtzhSfeBr7gnIPSo1xAb4v72FGuEd83Ey6Sp 7jLyUeX4ZJgMZg4u9m8yfhts7lFoLoH9qGGnxZMcyVhxeC9urqSDEZ23qz6gP0eO/GS2 xOtP35LVBhq1IuWksSUn1p40ADpUmMYhnukhK0GY5PVn4Jhmi9rTrNdR/Qu/ncPWv1Kj BPqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zKaU2HncztpDaw71xz/LlpcxFDnc/okg6h/DOGykPpY=; b=j0V7YMquVT8SGvhhLytTdnZl+xDRQTwaPGHOdxCiNKnMd1Bc3wW88RRsL5ZdLGj0ba v5FZ9pWimq0yudKtkQLOn2jPVa6t0DOB9dcpM1m6XQ4aCwWOyq0R0pvL9T98ijg8cEVu 9a7oDjTC9ajcVu+Mp4xN/CfWaiJTL2IiafrgUupR2mVgmgIlcp6HG01o5/BEAL91Bioe LznvxQAFilPJpGdsRb5Uj0LJkITCPpJ7ns+ITgdAUVKsZ6UtgFFDhrzQCGrgB1s4EkQi u4SSUsdSdBSg55ARPeVOnLALI3Pn79uBp0hWYkZSlhCKzCPxSp/Emw+ZwCH7+r3L0tjG BfjQ== X-Gm-Message-State: AOAM531RLGiaVQolnGsEQI3NjfJy2yk73qXCaiM0If1u3by7YjuIj96t 47I4qDzFLWM9MJIJPpy6YgDGz7G4+JwGBNuU3R+yzQ== X-Google-Smtp-Source: ABdhPJzWMuDsIdGJeU2l4KbOkERINskSB6Ll3qjbiFIeyS1H6ZBBrUMFo4E540q7nE33bGW0LVLWsEgqszRI3mo/1Xs= X-Received: by 2002:a19:6d07:: with SMTP id i7mr6058096lfc.568.1615320701061; Tue, 09 Mar 2021 12:11:41 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> In-Reply-To: <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Tue, 9 Mar 2021 12:11:30 -0800 Message-ID: To: Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095ded705bd202801" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 20:11:47 -0000 --00000000000095ded705bd202801 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Changing the semantics of a definition via augments is bad design. > > A system that does not understand the augment will believe the default > is 0. Since there is no way to force an existing implementation to > understand a certain augmentation, different implementation will > rightfully disagree on the default value in effect. > > deviation /ex:example/ex:foo { delete { default 0; } } IMO it was a bad idea to say deviations MUST NOT appear in standard modules= . Here is a use-case for it. The old-client does not know about the new dynamic default but it could kno= w that the old YANG default is not being used. > /js > Andy > > On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > > Hi Juergen, > > > > Thanks again for your clear explanation on this topic > > > > I have found a similar but slightly different issue. In this case, a > YANG default statement exists in the base module but the intention with t= he > augmentation is to "overwrite" the default value on the basis of another > attribute, defined in the module which augments the base module. > > > > For example, I am wondering whether such a code is valid: > > > > module example-base { > > container example { > > leaf foo { > > type uint8; > > default 0; > > } > > } > > } > > > > module example-augment { > > import example { > > prefix ex; > > } > > > > augment "ex:example" { > > leaf bar { > > type empty; > > description > > "When present, the default value for foo is 10."; > > } > > } > > } > > > > > > In this case, when the leaf foo is not configured but the leaf bar is > present, the value of foo in the operational datastore should be 10 (rath= er > than 0). > > > > In this case, I think that it would be better/cleaner if the origin is > marked as system. > > > > Maybe a better YANG description for bar could be: "When present, the > system overrides the default value of foo to 10." > > > > What is your and/or WG opinion? > > > > Thanks again > > > > Italo > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto: > j.schoenwaelder@jacobs-university.de] > > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 > > > To: Italo Busi > > > Cc: 'netmod@ietf.org' > > > Subject: Re: [netmod] Questions about how to assign default values wi= th > > > YANG > > > > > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > > > > > > > What about the case the leaf is not conditional (but still mandator= y > false > > > since a YANG default statement is defined)? > > > > > > > > May the server still decide not to use/implement this leaf in the > operational > > > datastore? > > > > > > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enable= d > by > > > default. > > > > What should be the behavior of a system which does not implement > auto- > > > negotiation? > > > > Return the value false or no value (in the operational datastore)? > > > > > > > > > > Here are some of the rules I personally like: > > > > > > - is the ground truth about what a system has and does > > > - do not implement leafs that do not apply > > > > > > Hence, interfaces supporting auto-negotiation have either auto- > > > negotiation/enabled =3D true or auto-negotiation/enabled =3D false in > > > . And interfaces not supporting auto-negotiation have > nothing > > > to report about auto-negotiation. Yes, I do not want to see auto- > > > negotiation/enabled =3D false on a loopback interface. > > > > > > My historic Ethernet interface from the last century would also not > report > > > auto-negotiation/enabled in . You may hit applications > that love > > > to have auto-negotiation/enabled available on all Ethernet interfaces > and then > > > you end in a debate where the application developers tell you that no > > > information in may have many reasons (instrumentation n= ot > > > implemented, access control rules, whatever and by reporting > enabled=3Dfalse > > > you do them a favor) but the true answer in such a debate is often th= at > > > modeling things as a boolean is simplistic since there are often more > than > > > exactly two states (in this case, enabled, disabled, failed, > not-available, ...). > > > So you settle on blaming the model writer. ;-) > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000095ded705bd202801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 9, 2021 at 11:52 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Changing the semantics of a definitio= n via augments is bad design.

A system that does not understand the augment will believe the default
is 0. Since there is no way to force an existing implementation to
understand a certain augmentation, different implementation will
rightfully disagree on the default value in effect.



deviation /ex:example/e= x:foo {
=C2=A0 =C2=A0 delete {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0default 0;
=C2=A0 =C2=A0 =C2=A0}
}

IMO it was a bad idea to say deviations MUST NOT appear in standard= modules.
Here is a use-case for it.

The= old-client does not know about the new dynamic default but it could know
that the old YANG default is not being used.

<= div>=C2=A0
/js

Andy
=C2=A0

On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote:
> Hi Juergen,
>
> Thanks again for your clear explanation on this topic
>
> I have found a similar but slightly different issue. In this case, a Y= ANG default statement exists in the base module but the intention with the = augmentation is to "overwrite" the default value on the basis of = another attribute, defined in the module which augments the base module. >
> For example, I am wondering whether such a code is valid:
>
> module example-base {
>=C2=A0 =C2=A0container example {
>=C2=A0 =C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> module example-augment {
>=C2=A0 =C2=A0import example {
>=C2=A0 =C2=A0 =C2=A0prefix ex;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0augment "ex:example" {
>=C2=A0 =C2=A0 =C2=A0leaf bar {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When present, the default value= for foo is 10.";
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
>
> In this case, when the leaf foo is not configured but the leaf bar is = present, the value of foo in the operational datastore should be 10 (rather= than 0).
>
> In this case, I think that it would be better/cleaner if the origin is= marked as system.
>
> Maybe a better YANG description for bar could be: "When present, = the system overrides the default value of foo to 10."
>
> What is your and/or WG opinion?
>
> Thanks again
>
> Italo
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-univers= ity.de]
> > Sent: mercoled=C3=AC 20 gennaio 2021 17:05
> > To: Italo Busi <Italo.Busi@huawei.com>
> > Cc: 'net= mod@ietf.org' <netmod@ietf.org>
> > Subject: Re: [netmod] Questions about how to assign default value= s with
> > YANG
> >
> > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote:
> > >
> > > What about the case the leaf is not conditional (but still m= andatory false
> > since a YANG default statement is defined)?
> > >
> > > May the server still decide not to use/implement this leaf i= n the operational
> > datastore?
> > >
> > > For example, in appendix C.1 of RFC8342, auto-negotiation is= enabled by
> > default.
> > > What should be the behavior of a system which does not imple= ment auto-
> > negotiation?
> > > Return the value false or no value (in the operational datas= tore)?
> > >
> >
> > Here are some of the rules I personally like:
> >
> >=C2=A0 - <operational> is the ground truth about what a syst= em has and does
> >=C2=A0 - do not implement leafs that do not apply
> >
> > Hence, interfaces supporting auto-negotiation have either auto- > > negotiation/enabled =3D true or auto-negotiation/enabled =3D fals= e in
> > <operational>. And interfaces not supporting auto-negotiati= on have nothing
> > to report about auto-negotiation. Yes, I do not want to see auto-=
> > negotiation/enabled =3D false on a loopback interface.
> >
> > My historic Ethernet interface from the last century would also n= ot report
> > auto-negotiation/enabled in <operational>. You may hit appl= ications that love
> > to have auto-negotiation/enabled available on all Ethernet interf= aces and then
> > you end in a debate where the application developers tell you tha= t no
> > information in <operational> may have many reasons (instrum= entation not
> > implemented, access control rules, whatever and by reporting enab= led=3Dfalse
> > you do them a favor) but the true answer in such a debate is ofte= n that
> > modeling things as a boolean is simplistic since there are often = more than
> > exactly two states (in this case, enabled, disabled, failed, not-= available, ...).
> > So you settle on blaming the model writer. ;-)
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000095ded705bd202801-- From nobody Tue Mar 9 18:37:55 2021 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 EC3213A1708; Tue, 9 Mar 2021 18:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.499, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXRtPPVMKeyp; Tue, 9 Mar 2021 18:37:47 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4786E3A1706; Tue, 9 Mar 2021 18:37:47 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id u18so23545072ljd.3; Tue, 09 Mar 2021 18:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SE9s899ucjiDQGnnkF8fyv+0yZoTJg107n7mXS4f5as=; b=GYjk0xlNJr/cS4hXMTpjwVT2FefXb/Jr5jQgJ/r1aOUnxMqhqe82Olz+GhOOnreldR X2FXio/BF/HFFSKlloT0p4kdKFQp1X3kjZoM+qtdQ3Op8vvIXhpJIsEHRCjV2tDU54vZ RpIvpyr60hqnzEBI67d7QWW2+8GZLgTrwjyTqOFAgr1cuEX9+4PK+gx5dqU/EHt1JeIk BmOy9FJb8db2RGapkQros0i4QLptN6jSVRVrRB5ylx/pamRR/HGIJS02LZMu6GTTndrA rrb6CDaK1H0GMY4Qb6YhgG4FPxffJmFWNQd3Njl+ggTAUpZ7DBMltYSMpgAWrP9Kte1c brVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SE9s899ucjiDQGnnkF8fyv+0yZoTJg107n7mXS4f5as=; b=hKZnSmwIz1JtF9HV/jB1xEYVTktSa2mzDHtdTuRFk3Ljbkp84tgqeyTkmSH2Rnkn9M Z8jzJT7mUcC70NZa4Gc5V/a1J6wvEKeiqKxwxdGShNxb55hXyMSqNtX7GNYp3S4ny1w/ tvhtJcJLpKO78ZFuHvQId+xWPgz4p84TA3kAIJMRuOH1kGMdLeP9k37AD+x85lxpjvqX WhcynUcYZ1q2vhhJQ1MSMlrYX1vwmp5CYQs/DN3UZGusnUZYBw95RT1hv0Iomt/dup4h 71rFP4uXWKLI/h9ha2TmBz3AYYfIA48NFNuN3AH71GY0ZzbO9tqmnmRoVTmsC2S/H8pf dZig== X-Gm-Message-State: AOAM530pEPB4f5Pzdl/ybthyj0tbppHt045cX7+dzAD0tKfUcvx0qsJV TNfsjAJmH86LQWiZdDHCfFieBtLmYfmuLFnKSsI= X-Google-Smtp-Source: ABdhPJxiGTLbLQvzEy0/pLeAM7M4TAl8VPv3Co3B9jTXl1MOGhzII2yHX0u+5W+DWHzuxUrRaoHS920ORRj4Ay0WCNU= X-Received: by 2002:a2e:988:: with SMTP id 130mr440488ljj.380.1615343860288; Tue, 09 Mar 2021 18:37:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Wed, 10 Mar 2021 11:37:04 +0900 Message-ID: To: Qin Wu Cc: "pauljeong@skku.edu" , "i2nsf@ietf.org" , "netmod@ietf.org" , "draft-ietf-i2nsf-capability-data-model@ietf.org" , "draft-ietf-netmod-eca-policy@ietf.org" , skku-iotlab-members Content-Type: multipart/alternative; boundary="000000000000fb8fef05bd258c32" Archived-At: Subject: Re: [netmod] ECA Policy: Relationship with I2NSF YANG capability-data-model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 02:37:50 -0000 --000000000000fb8fef05bd258c32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Qin and NETMOD WG, I totally agree with Qin that the ECA of I2NSF NSF Capabilities is a good example for security services as the editor of the I2NSF YANG data model drafts. Qin's clarification about the ECA makes sense to me. Thanks. Best Regards, Paul On Tue, Mar 9, 2021 at 1:05 PM Qin Wu wrote: > Hi, > One of issues raised on draft-ietf-netmod-eca-policy-00 during adoption > call is Relationship with I2NSF YANG capability-data-model. > I believe two work in I2NSF WG are related to draft-ietf-netmod-eca-polic= y > (https://tools.ietf.org/html/draft-ietf-netmod-eca-policy-01). > 1. RFC8329, which define ECA as Imperative paradigm related to data packe= t > or data flow treatment, three clause are defined > a. An Event clause is used to trigger the evaluation of the Condition > clause of the I2NSF Policy Rule. > b. A Condition clause is used to determine whether or not the set of > Actions in the I2NSF Policy Rule can be executed or not. > c. An Action clause defines the type of operations that may be performed > on this packet or flow. > I think this ECA paradigm is also security policy specific, not generic > enough > > 2. draft-ietf-i2nsf-capability-data-model, which use RFC8529 as basis for > the design of the capability model in > draft-ietf-i2nsf-capability-data-model; > > Here is the ECA definition we proposed in draft-ietf-netmod-eca-policy > a. The event is defined as one related to datastore subscription or even= t > stream subscription. > b. Condition: Condition can be seen as a logical test that, if satisfied > or evaluated to be true, causes the action to be carried out. > c. Action: Update or invocation on local managed object attributes. > As you can see ECA is not tied to specific technology, to clarify the > relationship with I2NSF YANG capability-data-model, we think > NSF can be an example use case for draft-ietf-netmod-eca-policy. > Let us know if this proposal make sense to you. Thanks! > > -Qin (on behalf of authors) > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Qin Wu > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B412=E6=9C=8823=E6=97=A5= 22:30 > =E6=94=B6=E4=BB=B6=E4=BA=BA: tom petch ; Dhruv Dhody= ; > Lou Berger > =E6=8A=84=E9=80=81: NetMod WG Chairs ; NETMOD Gro= up < > netmod@ietf.org> > =E4=B8=BB=E9=A2=98: Re: [netmod] Adoption poll for draft-wwx-netmod-event= -yang-10 > > Hi, Tom: > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 tom petch > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B412=E6=9C=8823=E6=97=A5= 19:14 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Dhruv Dhody ; Lou Berg= er > =E6=8A=84=E9=80=81: NetMod WG Chairs ; NETMOD Gro= up < > netmod@ietf.org> > =E4=B8=BB=E9=A2=98: Re: [netmod] Adoption poll for draft-wwx-netmod-event= -yang-10 > > From: netmod on behalf of Dhruv Dhody < > dhruv.ietf@gmail.com> > Sent: 21 December 2020 17:12 > > Hi Lou, WG, > > I find the motivation in the Introduction to be focused on ECA at the > network devices (with all the talk about issues with Centralized network > management). > > I see the value of ECA on the controller as well, say a customer network > controller or an orchestrator can set the ECA on a central controller > (reference ACTN in TEAS WG). Perhaps you would consider adding a sentence > to describe this as well. The client-server terminology in the rest of th= e > document covers it already. > > And I do see value in this and support adoption. > > > My take is that the I-D is unclear on what ECA is. > > [Qin]: Thanks Tom, Adrian raised the similar issue about the abstract > improvement and we will address this in v-01. > > ECA has been worked on in at least two IETF WG AFAICT. It cropped up in > I2RS but as I recall, it was along the lines of 'This is ECA' 'No It is > not' 'Yes it is' which gave me the impression that ECA is not a > well-defined, or well-understood, term. > > More recently, I2NSF have produced a YANG capability-data-model which is > 55 pages of ECA. Lacking a definition in this netmod I-D, I am unclear > what the relationship is between the I2NSF I-D and the netmod I-D, whethe= r > or not they are using ECA in the same sense. > [Qin]: I haven't followed closely on what had been done in I2NSF. But I > did talk with two of I2NSF proponents in this year. They tend to agree th= e > model proposed in draft-wwx will serve as the basis for I2NSF security > policy model or NSF facing interface DM. Unfortunately I haven't seen the= ir > update to do the alignment. I missed their I2NSF recharter discussion > meeting. But I would also highly recommend they import the model in > draft-wwx and reuse some of these building block. I plan to raise this > issue later on. > For I2RS model, it was packet forwarding policy model, which has been > expired for many years. If that draft needs to be revived, I think we can > follow the similar approach for I2NSF security policy model. > > Thanks! > Dhruv > > On Tue, Dec 8, 2020 at 3:59 AM Lou Berger wrote: > > > > This email begins a 2-week adoption poll for: > > > > https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10 > > > > Please voice your support or technical objections on list before the > > end of December 21, any time zone. > > > > Thank you! > > > > Netmod Chairs > > > > PS Note the IPR poll is running concurrently as the private response > > all indicated that no IPR exists. The draft will not be formally > > adopted until both the IPR and WG polls are complete. > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000fb8fef05bd258c32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Qin and NETMOD WG,
I totally agree with = Qin that the ECA of I2NSF NSF Capabilities is a good example for security s= ervices
as the editor of the I2NSF YANG data model drafts.

Qin's clarification about the ECA makes sense to= me.

Thanks.

Best Regards= ,
Paul

On Tue, Mar 9, 2021 at 1:05 PM Qin Wu <bill.wu@huawei.com> wrote:
Hi,
One of issues raised on draft-ietf-netmod-eca-policy-00 during adoption cal= l is Relationship with I2NSF YANG capability-data-model.
I believe two work in I2NSF WG are related to draft-ietf-netmod-eca-policy = (https://tools.ietf.org/html/draft-ietf-n= etmod-eca-policy-01).
1. RFC8329, which define ECA as Imperative paradigm related to data packet = or data flow treatment, three clause are defined
=C2=A0a. An Event clause is used to trigger the evaluation of the Condition= clause of the I2NSF Policy Rule.
=C2=A0b. A Condition clause is used to determine whether or not the set of = Actions in the I2NSF Policy Rule can be executed or not.
=C2=A0c. An Action clause defines the type of operations that may be perfor= med on this packet or flow.
I think this ECA paradigm is also security policy specific, not generic eno= ugh

2. draft-ietf-i2nsf-capability-data-model, which use RFC8529 as basis for t= he design of the capability model in draft-ietf-i2nsf-capability-data-model= ;

Here is the ECA definition we proposed in draft-ietf-netmod-eca-policy
=C2=A0a. The event is defined as one related to datastore subscription or e= vent stream subscription.
=C2=A0b. Condition: Condition can be seen as a logical test that, if satisf= ied or evaluated to be true, causes the action to be carried out.
=C2=A0c. Action: Update or invocation on local managed object attributes. As you can see ECA is not tied to specific technology, to clarify the relat= ionship with I2NSF YANG capability-data-model, we think
NSF can be an example use case for draft-ietf-netmod-eca-policy.
Let us know if this proposal make sense to you. Thanks!

-Qin (on behalf of authors)
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 Qin Wu
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B412=E6=9C=8823=E6=97=A5 2= 2:30
=E6=94=B6=E4=BB=B6=E4=BA=BA: tom petch <ietfc@btconnect.com>; Dhruv Dhody <dhruv.ietf@gmail.com>; Lou Berger <lberger@labn.net>
=E6=8A=84=E9=80=81: NetMod WG Chairs <netmod-chairs@ietf.org>; NETMOD Group <= netmod@ietf.org>= ;
=E4=B8=BB=E9=A2=98: Re: [netmod] Adoption poll for draft-wwx-netmod-event-y= ang-10

Hi, Tom:
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 tom petch
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B412=E6=9C=8823=E6=97=A5 1= 9:14
=E6=94=B6=E4=BB=B6=E4=BA=BA: Dhruv Dhody <dhruv.ietf@gmail.com>; Lou Berger <lberger@labn.net>= ;
=E6=8A=84=E9=80=81: NetMod WG Chairs <netmod-chairs@ietf.org>; NETMOD Group <= netmod@ietf.org>= ;
=E4=B8=BB=E9=A2=98: Re: [netmod] Adoption poll for draft-wwx-netmod-event-y= ang-10

From: netmod <netmod-bounces@ietf.org> on behalf of Dhruv Dhody <dhruv.ietf@gmail.com>=
Sent: 21 December 2020 17:12

Hi Lou, WG,

I find the motivation in the Introduction to be focused on ECA at the netwo= rk devices (with all the talk about issues with Centralized network managem= ent).

I see the value of ECA on the controller as well, say a customer network co= ntroller or an orchestrator can set the ECA on a central controller (refere= nce ACTN in TEAS WG). Perhaps you would consider adding a sentence to descr= ibe this as well. The client-server terminology in the rest of the document= covers it already.

And I do see value in this and support adoption.

<tp>
My take is that the I-D is unclear on what ECA is.

[Qin]: Thanks Tom, Adrian raised the similar issue about the abstract impro= vement and we will address this in v-01.

ECA has been worked on in at least two IETF WG AFAICT.=C2=A0 It cropped up = in I2RS but as I recall, it was along the lines of 'This is ECA'=C2= =A0 'No It is not'=C2=A0 'Yes it is' which gave me the impr= ession that ECA is not a well-defined, or well-understood, term.

More recently, I2NSF have produced a YANG capability-data-model which is 55= pages of ECA.=C2=A0 Lacking a definition in this netmod I-D, I am unclear = what the relationship is between the I2NSF I-D and the netmod I-D, whether = or not they are using ECA in the same sense.
[Qin]: I haven't followed closely on what had been done in I2NSF.=C2=A0= But I did talk with two of I2NSF proponents in this year. They tend to agr= ee the model proposed in draft-wwx will serve as the basis for I2NSF securi= ty policy model or NSF facing interface DM. Unfortunately I haven't see= n their update to do the alignment. I missed their I2NSF recharter discussi= on meeting. But I would also highly recommend they import the model in draf= t-wwx and reuse some of these building block. I plan to raise this issue la= ter on.
For I2RS model, it was packet forwarding policy model, which has been expir= ed for many years. If that draft needs to be revived, I think we can follow= the similar approach for I2NSF security policy model.

Thanks!
Dhruv

On Tue, Dec 8, 2020 at 3:59 AM Lou Berger <lberger@labn.net> wrote:
>
> This email begins a 2-week adoption poll for:
>
> https://tools.ietf.org/html/draft-wwx= -netmod-event-yang-10
>
> Please voice your support or technical objections on list before the <= br> > end of December 21, any time zone.
>
> Thank you!
>
> Netmod Chairs
>
> PS Note the IPR poll is running concurrently as the private response <= br> > all indicated that no IPR exists.=C2=A0 The draft will not be formally=
> adopted until both the IPR and WG polls are complete.
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000fb8fef05bd258c32-- From nobody Wed Mar 10 00:08:04 2021 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 AEE1E3A1D51 for ; Wed, 10 Mar 2021 00:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tma9ymuzPN4M for ; Wed, 10 Mar 2021 00:07:59 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EEA3A1D4E for ; Wed, 10 Mar 2021 00:07:59 -0800 (PST) Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwPhz0sFFz67wr4; Wed, 10 Mar 2021 16:03:31 +0800 (CST) Received: from fraeml737-chm.china.huawei.com (10.206.15.218) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:07:54 +0100 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 10 Mar 2021 09:07:54 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.181]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0513.000; Wed, 10 Mar 2021 16:07:47 +0800 From: Qin Wu To: Juergen Schoenwaelder , "'NETMOD Group'" Thread-Topic: ECA Policy: What is an adequate abstraction level to express policies and intent Thread-Index: AdcVX5UyabdLLRhXR7azT92xVCZekw== Date: Wed, 10 Mar 2021 08:07:46 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 08:08:03 -0000 SGksIEp1ZXJnZW46DQpDb21lIGJhY2sgdG8gdGhlIGtleSBpc3N1ZXMgZm9yIEVDQSBQb2xpY3ku DQpJIHRoaW5rIFBvbGljaWVzIG5lZWQgdG8gYmUgcmVhZGFibGUgYW5kIGhlbmNlIGJlIGV4cHJl c3NlZCBhdCBhIGhpZ2ggbGV2ZWwgb2YgYWJzdHJhY3Rpb24gYW5kIGluIGEgc3VpdGFibGUgX2xh bmd1YWdlXy4NCkJ1dCBJIHByb3Bvc2UgdG8gc2VwYXJhdGUgcG9saWN5IGV4cHJlc3Npb24gYW5k IGludGVudCByZXByZXNlbnRhdGlvbiwgZXNwZWNpYWxseSBoaWdoIGxldmVsIHNlcnZpY2UgaW50 ZW50IHJlcHJlc2VudGF0aW9uLCB0cmFuc2xhdGlvbiwgbWFwcGluZyB3aGljaCBpcyB0aGUgaG90 IHRvcGljIGluIE5NUkcuDQpIaWdoIGxldmVsIGxhbmd1YWdlIHdlIHNlbGVjdCBmb3IgcG9saWN5 IHJlcHJlc2VudGF0aW9uIGlzIFlBTkcsIGV4cHJlc3NlZCBieSB0aGUgTk1TIG9yIGNvbnRyb2xs ZXIuDQpXZSBjYW4gY29tcGFyZSBZQU5HIHZzIE5FVENPTkYgd2l0aCBSTU9OIHZzIFNOTVAsIFJB TU9OIGlzIGFuIGV4dGVuc2lvbiBvZiBTTk1QLCBwcm92aWRlcyB0cmFmZmljIGZsb3cgZGF0YSBm b3IgdHJvdWJsZXNob290aW5nIGFuZCB0aGUgY29udHJvbHMgbmVjZXNzYXJ5IHRvIGFkanVzdCBm b3IgYmV0dGVyIHBlcmZvcm1hbmNlIGZyb20gYSBjZW50cmFsIGNvbnNvbGUuDQpJIHRoaW5rIHdl IHNldCBzaW1pbGFyIGdvYWwgYXMgUk9NT04gaW4gb3VyIGRyYWZ0Lg0KDQpVbmxpa2Ugb3RoZXIg aW50ZW50IHRyYW5zbGF0aW9uIG9yIG1hcHBpbmcsIHdlIGNvbXBpbGUgSGlnaC1sZXZlbCBwb2xp Y3kgZXhwcmVzc2lvbiBkb3duIGludG8gbW9yZSB2ZXJib3NlIHByaW1pdGl2ZSByZXByZXNlbnRh dGlvbnMgdGhhdCBhcmUgY2xvc2VyIHRvIGFuIGV4ZWN1dGlvbiBhYnN0cmFjdGlvbi4gWUFORyBl eHByZXNzaW9uIGlzIGNhcGFibGUgZm9yIHN1Y2ggYSBjb21waWxhdGlvbjsuDQpQcmltaXRpdmUg cmVwcmVzZW50YXRpb24gaW4gdGhlIGRldmljZSBpcyBzY3JpcHQgbGFuZ3VhZ2UsIHR5cGljYWwg ZXhhbXBsZXMgYXJlIFB5dGhvbiBvciBUQ0wgdXNlZCBpbiB0aGUgZGV2aWNlDQoNCk9mIGNvdXJz ZSB0aGVyZSBpcyBwaXRmYWxsIHRvIHN0YXJ0IHNvbWV3aGVyZSBpbiB0aGUgbWlkZGxlIG9mIHNl dmVyYWwgbGF5ZXJzIG9mIGFic3RyYWN0aW9uIGFuZCB0aGVuIGdldHRpbmcgc3R1Y2sgc29tZXdo ZXJlIHdoZW4gY29tcGlsaW5nIHRoaW5ncyBkb3duIHRvIF9lZmZpY2llbnRfIGluc3RydW1lbnRh dGlvbnMuDQpPbmUgb2YgbGVzc29uIHdlIGxlYXJuIGZyb20gdGhlIHBhc3QgaXMgU1VQQSBpcyBk ZWZpbmVkIGFuZCBkZXNjcmliZWQgdmVyeSBhYnN0cmFjdGx5LCB3aXRoIGl0cyBoaWdoLWxldmVs IGJsb2NrcyBhbmQgVU1McywgYW5kIGlzIHZlcnkgZGlmZmljdWx0IHRvIGJlIHdyaXR0ZW4gaW4g WUFORyBhbmQgaGFyZGVyIHRvIGJlIGltcGxlbWVudGVkLg0KV2Ugd2lsbCBhdm9pZCBzdWNoIHBp dGZhbGwuDQoNCkF0IHRoZSBjdXJyZW50IHN0YWdlIFlBTkcgaXMgdXNlZCBmb3IgYWJzdHJhY3Rp b24gYW5kIHJlcHJlc2VudGF0aW9uLiBZQU5HIGlzIGJvdGggcmVwcmVzZW50YXRpdmUgYW5kIGlt cGxlbWVudGFibGUuDQoNCi1RaW4gKG9uIGJlaGFsZiBvZiBhdXRob3JzKQ0KLS0tLS3Tyrz+1K28 /i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0Kt6LLzcqxvOQ6IDIwMjDE6jEy1MIzMMjVIDI6NTYN CsrVvP7IyzogQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4NCrOty806ICdORVRN T0QgR3JvdXAnIDxuZXRtb2RAaWV0Zi5vcmc+DQrW98ziOiBSZTogW25ldG1vZF0gQWRvcHRpb24g cG9sbCBmb3IgZHJhZnQtd3d4LW5ldG1vZC1ldmVudC15YW5nLTEwDQoNCkFkcmlhbiwNCg0Kc29t ZSBrZXkgaXNzdWVzIHdoZW4gaXQgY29tZXMgdG8gcG9saWN5LWJhc2VkIG1hbmFnZW1lbnQgc3lz dGVtczoNCg0KIC0gV2hhdCBpcyBhbiBhZGVxdWF0ZSBhYnN0cmFjdGlvbiBsZXZlbCB0byBleHBy ZXNzIHBvbGljaWVzIGFuZCBpbnRlbnQ/DQoNCiAgIFRoaXMgcXVlc3Rpb24gaGFzIG5vIHNpbXBs ZSBhbnN3ZXIuIEkgYmVsaWV2ZSBwb2xpY2llcyBuZWVkIHRvIGJlDQogICByZWFkYWJsZSBhbmQg aGVuY2UgdGhleSBuZWVkIHRvIGJlIGV4cHJlc3NlZCBhdCBhIGhpZ2ggbGV2ZWwgb2YNCiAgIGFi c3RyYWN0aW9uIGFuZCBpbiBhIHN1aXRhYmxlIF9sYW5ndWFnZV8uIEhpZ2gtbGV2ZWwgcG9saWN5 DQogICBleHByZXNzaW9uIG1heSBiZSBjb21waWxlZCBkb3duIGludG8gbW9yZSB2ZXJib3NlIHBy aW1pdGl2ZQ0KICAgcmVwcmVzZW50YXRpb25zIHRoYXQgYXJlIGNsb3NlciB0byBhbiBleGVjdXRp b24gYWJzdHJhY3Rpb24uIEENCiAgIGNvbW1vbiBwaXRmYWxsIGlzIHRvIHN0YXJ0IHNvbWV3aGVy ZSBpbiB0aGUgbWlkZGxlIG9mIHNldmVyYWwNCiAgIGxheWVycyBvZiBhYnN0cmFjdGlvbiBhbmQg dGhlbiBnZXR0aW5nIHN0dWNrIHdpdGggc29tZXRoaW5nIGF3a3dhcmQNCiAgIHRvIHB1dCBhIGNs ZWFuIGhpZ2hlciBsYXllciBhYnN0cmFjdCBvbnRvIGFuZCB0byBjb21waWxlIHRoaW5ncw0KICAg ZG93biB0byBfZWZmaWNpZW50XyBpbnN0cnVtZW50YXRpb25zLg0KDQogLSBXaGVyZSBhcmUgcG9s aWNpZXMgZXhlY3V0ZWQ/DQoNCiAgIFRoaXMgY2FuIHJhbmdlIGZyb20gYSBsb2dpY2FsbHkgY2Vu dHJhbGl6ZWQgcG9saWN5IGV4ZWN1dGlvbg0KICAgZW5naW5lLCB3aGljaCBpcyBwYXJ0IG9mIHdo YXQgcGVvcGxlIGNhbGwgYW4gb3JjaGVzdHJhdG9yIHRoZXNlDQogICBkYXlzLCB0byBmdWxseSBk aXN0cmlidXRlZCBwb2xpY3kgZXhlY3V0aW9uIG1vZGVscy4gSW4gcmVhbGl0eSwgeW91DQogICBs aWtlbHkgd2FudCB0byBkaXN0cmlidXRlIGZ1bmN0aW9ucyBkeW5hbWljYWxseSBidXQgdGhpcyBt YWtlcw0KICAgc29sdXRpb25zIHRlY2huaWNhbGx5IG11Y2ggbW9yZSBjb21wbGljYXRlZC4gR2l2 ZW4gdG9kYXkncyBzY2FsYWJsZQ0KICAgY29tcHV0aW5nIGFuZCBuZXR3b3JraW5nIGNhcGFiaWxp dGllcywgbG9naWNhbGx5IGNlbnRyYWxpemVkDQogICBzb2x1dGlvbnMgYXJlIG9uIHRoZSByaXNl IGFuZCBoYXZlIHJlcGxhY2VkIHRoZSBkaXN0cmlidXRlZA0KICAgYXBwcm9hY2hlcyBvZiB0aGUg OTBzLg0KDQogLSBXaGVuIHRvIGRldGVjdCBhbmQgcmVzb2x2ZSBwb2xpY3kgY29uZmxpY3RzPw0K DQogICBEZXRlY3RpbmcgYW5kIHJlc29sdmluZyBjb25mbGljdHMgaW4gbGFyZ2VyIGNvbGxlY3Rp b25zIG9mIHBvbGljaWVzDQogICBpcyBub24tdHJpdmlhbC4gVGhpcyBpbmNsdWRlcyBwcm9ibGVt cyByYW5naW5nIGZyb20gbWljcm8gdGltZXNjYWxlDQogICBhdG9taWNpdHkgaXNzdWVzIHRvIGxh cmdlciB0aW1lc2NhbGUgc3RhYmlsaXR5IGlzc3VlcyAoaW50ZXJhY3RpbmcNCiAgIHBvbGljeSBj b250cm9sIGxvb3BzKS4gSWYgcG9saWN5IGV4ZWN1dGlvbiBpcyBkaXN0cmlidXRlZCAob3IgdGhl DQogICBldmVudCAvIGluZm9ybWF0aW9uIHNvdXJjZXMgYXJlIGRpc3RyaWJ1dGVkKSwgdGhpcyB1 bHRpbWF0ZWx5DQogICByZXNvbHZlcyB0byBwcm9ibGVtcyBzdWNoIGFzIHRha2luZyBjb25zaXN0 ZW50IHNuYXBzaG90cyBvciBmaW5kaW5nDQogICB3YXlzIHRvIHdvcmsgd2l0aCBpbmNvbnNpc3Rl bnQgb2JzZXJ2YXRpb25zIG9mIGEgZGlzdHJpYnV0ZWQgc3lzdGVtDQogICB0aGF0IGFyZSBndWFy YW50ZWVkIHRvIGNvbnZlcmdlIHRvIHN0YWJsZSBzdGF0ZXMgKHNlbGYtc3RhYmlsaXppbmcNCiAg IGFsZ29yaXRobXMpLg0KDQogLSBXaG8gaXMgaW50ZXJlc3RlZCBpbiBpbnRlcm9wZXJhYmxlIHBv bGljeSByZXByZXNlbnRhdGlvbnMgLyBsYW5ndWFnZXM/DQoNCiAgIFRoZSBJRVRGIGlzIGFib3V0 IGludGVyb3BlcmFiaWxpdHkuIFdoYXQgYXJlIHRoZSBidXNpbmVzcyBtb2RlbHMNCiAgIHRoYXQg cHVzaCBmb3IgaW50ZXJvcGVyYWJsZSBwb2xpY3kgYmFzZWQgbWFuYWdlbWVudCBzdGFuZGFyZHM/ IFdobw0KICAgYmVuZWZpdHMgZnJvbSBoYXZpbmcgYW4gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZCBh bmQgaG93IG11Y2ggZWZmb3J0DQogICBhcmUgb3JnYW5pemF0aW9ucyB3aWxsaW5nIHRvIGludmVz dCBpbnRvIGVuZ2luZWVyaW5nIGEgcmVhc29uYWJsZQ0KICAgc29sdXRpb24gYWRkcmVzc2luZyB0 aGUgb3RoZXIgKG5vbi10cml2aWFsKSBxdWVzdGlvbnMgcmFpc2VkIGFib3ZlPw0KICAgV2lsbCB0 aGV5IGJlIGltcGxlbWVudGluZyB0aGUgc29sdXRpb24gaW4gdGhlaXIgcHJvZHVjdHM/DQoNCk15 IHBvc2l0aW9uIGlzIHRoYXQgdGhlcmUgYXJlIHdheSB0b28gbWFueSBkaWZmaWN1bHQgdGVjaG5p Y2FsIGlzc3VlcyB0byByZXNvbHZlIGZvciB0aGlzIHdvcmsgdG8gYmUgdmlhYmxlIGZvciB0aGUg SUVURi4gSW5zdGVhZCwgSSBzdWdnZXN0IHRoYXQgcGVvcGxlIGdvIGFuZCB3b3JrIG91dCBzb2x1 dGlvbnMgYW5kIG9uY2UgdGhlIHNpbHZlciBidWxsZXQgaGFzIGJlZW4gZm91bmQsIGJyaW5nIGl0 IHRvIHRoZSBJRVRGLiAoSGlzdG9yaWNhbGx5LCBhbGwgYXR0ZW1wdHMgdG8gY2FzdCBwb2xpY2ll cyBpbnRvIGV4aXN0aW5nIGRhdGEgbW9kZWxzIHN1Y2ggYXMgTUlCIG1vZHVsZXMgb3IgTERBUCBz Y2hlbWEgbGVkIHRvIHNvbWV0aGluZyBhd2t3YXJkIGFuZCB1bnVzYWJsZS4gSSBiZWxpZXZlIFlB TkcgbW9kdWxlcyBhcmUgbm8NCmRpZmZlcmVudC4pDQoNCi9qcw0KDQpTb21lIHJlbGV2YW50IFJG Q3MgKHRoZXJlIG1heSBiZSBtb3JlKToNCg0KMzA1MiBTZXJ2aWNlIE1hbmFnZW1lbnQgQXJjaGl0 ZWN0dXJlcyBJc3N1ZXMgYW5kIFJldmlldy4gTS4gRWRlciwgUy4gTmFnLg0KICAgICBKYW51YXJ5 IDIwMDEuIChGb3JtYXQ6IFRYVCwgSFRNTCkgKFN0YXR1czogSU5GT1JNQVRJT05BTCkgKERPSToN CiAgICAgMTAuMTc0ODcvUkZDMzA1MikNCg0KMzA4NCBDT1BTIFVzYWdlIGZvciBQb2xpY3kgUHJv dmlzaW9uaW5nIChDT1BTLVBSKS4gSy4gQ2hhbiwgSi4gU2VsaWdzb24sDQogICAgIEQuIER1cmhh bSwgUy4gR2FpLCBLLiBNY0Nsb2docmllLCBTLiBIZXJ6b2csIEYuIFJlaWNobWV5ZXIsIFIuDQog ICAgIFlhdmF0a2FyLCBBLiBTbWl0aC4gTWFyY2ggMjAwMS4gKEZvcm1hdDogVFhULCBIVE1MKSAo U3RhdHVzOg0KICAgICBISVNUT1JJQykgKERPSTogMTAuMTc0ODcvUkZDMzA4NCkNCg0KMzE1OSBT dHJ1Y3R1cmUgb2YgUG9saWN5IFByb3Zpc2lvbmluZyBJbmZvcm1hdGlvbiAoU1BQSSkuIEsuIE1j Q2xvZ2hyaWUsDQogICAgIE0uIEZpbmUsIEouIFNlbGlnc29uLCBLLiBDaGFuLCBTLiBIYWhuLCBS LiBTYWhpdGEsIEEuIFNtaXRoLCBGLg0KICAgICBSZWljaG1leWVyLiBBdWd1c3QgMjAwMS4gKEZv cm1hdDogVFhULCBIVE1MKSAoU3RhdHVzOiBISVNUT1JJQykNCiAgICAgKERPSTogMTAuMTc0ODcv UkZDMzE1OSkNCg0KMzMxOCBGcmFtZXdvcmsgUG9saWN5IEluZm9ybWF0aW9uIEJhc2UuIFIuIFNh aGl0YSwgRWQuLCBTLiBIYWhuLCBLLiBDaGFuLA0KICAgICBLLiBNY0Nsb2docmllLiBNYXJjaCAy MDAzLiAoRm9ybWF0OiBUWFQsIEhUTUwpIChTdGF0dXM6IEhJU1RPUklDKQ0KICAgICAoRE9JOiAx MC4xNzQ4Ny9SRkMzMzE4KQ0KDQozNDYwIFBvbGljeSBDb3JlIEluZm9ybWF0aW9uIE1vZGVsIChQ Q0lNKSBFeHRlbnNpb25zLiBCLiBNb29yZSwgRWQuLg0KICAgICBKYW51YXJ5IDIwMDMuIChGb3Jt YXQ6IFRYVCwgSFRNTCkgKFVwZGF0ZXMgUkZDMzA2MCkgKFN0YXR1czoNCiAgICAgUFJPUE9TRUQg U1RBTkRBUkQpIChET0k6IDEwLjE3NDg3L1JGQzM0NjApDQoNCjM2NDQgUG9saWN5IFF1YWxpdHkg b2YgU2VydmljZSAoUW9TKSBJbmZvcm1hdGlvbiBNb2RlbC4gWS4gU25pciwgWS4NCiAgICAgUmFt YmVyZywgSi4gU3RyYXNzbmVyLCBSLiBDb2hlbiwgQi4gTW9vcmUuIE5vdmVtYmVyIDIwMDMuIChG b3JtYXQ6DQogICAgIFRYVCwgSFRNTCkgKFN0YXR1czogUFJPUE9TRUQgU1RBTkRBUkQpIChET0k6 IDEwLjE3NDg3L1JGQzM2NDQpDQoNCjMxOTggVGVybWlub2xvZ3kgZm9yIFBvbGljeS1CYXNlZCBN YW5hZ2VtZW50LiBBLiBXZXN0ZXJpbmVuLCBKLg0KICAgICBTY2huaXpsZWluLCBKLiBTdHJhc3Nu ZXIsIE0uIFNjaGVybGluZywgQi4gUXVpbm4sIFMuIEhlcnpvZywgQS4NCiAgICAgSHV5bmgsIE0u IENhcmxzb24sIEouIFBlcnJ5LCBTLiBXYWxkYnVzc2VyLiBOb3ZlbWJlciAyMDAxLiAoRm9ybWF0 Og0KICAgICBUWFQsIEhUTUwpIChTdGF0dXM6IElORk9STUFUSU9OQUwpIChET0k6IDEwLjE3NDg3 L1JGQzMxOTgpDQoNCjQwMTEgUG9saWN5IEJhc2VkIE1hbmFnZW1lbnQgTUlCLiBTLiBXYWxkYnVz c2VyLCBKLiBTYXBlcmlhLCBULiBIb25nYWwuDQogICAgIE1hcmNoIDIwMDUuIChGb3JtYXQ6IFRY VCwgSFRNTCkgKFN0YXR1czogUFJPUE9TRUQgU1RBTkRBUkQpIChET0k6DQogICAgIDEwLjE3NDg3 L1JGQzQwMTEpDQoNCjQxMDQgUG9saWN5IENvcmUgRXh0ZW5zaW9uIExpZ2h0d2VpZ2h0IERpcmVj dG9yeSBBY2Nlc3MgUHJvdG9jb2wgU2NoZW1hDQogICAgIChQQ0VMUykuIE0uIFBhbmEsIEVkLiwg QS4gUmV5ZXMsIEEuIEJhcmJhLCBELiBNb3JvbiwgTS4gQnJ1bm5lci4NCiAgICAgSnVuZSAyMDA1 LiAoRm9ybWF0OiBUWFQsIEhUTUwpIChVcGRhdGVzIFJGQzM3MDMpIChTdGF0dXM6IFBST1BPU0VE DQogICAgIFNUQU5EQVJEKSAoRE9JOiAxMC4xNzQ4Ny9SRkM0MTA0KQ0KDQo4MzI4IFBvbGljeS1C YXNlZCBNYW5hZ2VtZW50IEZyYW1ld29yayBmb3IgdGhlIFNpbXBsaWZpZWQgVXNlIG9mIFBvbGlj eQ0KICAgICBBYnN0cmFjdGlvbnMgKFNVUEEpLiBXLiBMaXUsIEMuIFhpZSwgSi4gU3RyYXNzbmVy LCBHLiBLYXJhZ2lhbm5pcywNCiAgICAgTS4gS2x5dXMsIEouIEJpLCBZLiBDaGVuZywgRC4gWmhh bmcuIE1hcmNoIDIwMTguIChGb3JtYXQ6IFRYVCwgSFRNTCkNCiAgICAgKFN0YXR1czogSU5GT1JN QVRJT05BTCkgKERPSTogMTAuMTc0ODcvUkZDODMyOCkNCg0KV0dzL1JHcyB0aGF0IGF0IGxlYXN0 IHBhcnRpYWxseSByZWxhdGVkIHRvIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50Og0KDQotIFNpbXBs aWZpZWQgVXNlIG9mIFBvbGljeSBBYnN0cmFjdGlvbnMgV0cgKHN1cGEpICgyMDE1IC0gMjAxNykN Cg0KLSBQb2xpY3kgRnJhbWV3b3JrIFdHIChwb2xpY3kpICgxOTk4IC0gMjAwNCkNCg0KLSBSZXNv dXJjZSBBbGxvY2F0aW9uIFByb3RvY29sIFdHIChyYXApICgxOTk3IC0gMjAwNSkNCg0KLSBEaXN0 cmlidXRlZCBNYW5hZ2VtZW50IFdHIChkaXNtYW4pICgxOTk2IC0gMjAwNikNCg0KLSBTZXJ2aWNl cyBNYW5hZ2VtZW50IFJHIChzbXJnKSAoMjAxOT8gLSAyMDAxPykNCg0KLSBOZXR3b3JrIE1hbmFn ZW1lbnQgUkcgKG5tcmcpDQoNCiAgLSBkcmFmdC1jbGVtbS1ubXJnLWRpc3QtaW50ZW50ICgyMDE3 LTIwMTkpDQogIC0gZHJhZnQtaXJ0Zi1ubXJnLWlibi1jb25jZXB0cy1kZWZpbml0aW9ucy0wMi50 eHQgKDIwMTktMjAyMCkNCg0KT3RoZXIgcmVzb3VyY2VzOg0KDQotIGh0dHBzOi8vZW4ud2lraXBl ZGlhLm9yZy93aWtpL1BvbGljeS1iYXNlZF9tYW5hZ2VtZW50DQoNCi0gaHR0cHM6Ly93d3cueW91 dHViZS5jb20vd2F0Y2g/dj1FX3Ytb2Y1ODJ4Zw0KDQotIEJvdXRhYmEsIFIuIGFuZCBJLiBBaWIs ICJQb2xpY3ktQmFzZWQgTWFuYWdlbWVudDogQQ0KICBIaXN0b3JpY2FsIFBlcnNwZWN0aXZlIi4g Sm91cm5hbCBvZiBOZXR3b3JrIGFuZCBTeXN0ZW1zDQogIE1hbmFnZW1lbnQgKEpOU00pLCBTcHJp bmdlciwgVm9sLiAxNSAoNCksIERlY2VtYmVyIDIwMDcuDQogIGh0dHBzOi8vZG9pLm9yZy8xMC4x MDA3L3MxMDkyMi0wMDctOTA4My04DQoNCi0gUGF2bG91LCBHLiwgIk9uIHRoZSBFdm9sdXRpb24g b2YgTWFuYWdlbWVudCBBcHByb2FjaGVzLCBGcmFtZXdvcmtzDQogIGFuZCBQcm90b2NvbHM6IEEg SGlzdG9yaWNhbCBQZXJzcGVjdGl2ZSIuIEpvdXJuYWwgb2YgTmV0d29yayBhbmQNCiAgU3lzdGVt cyBNYW5hZ2VtZW50IChKTlNNKSwgU3ByaW5nZXIsIFZvbC4gMTUgKDQpLCBEZWNlbWJlciAyMDA3 Lg0KICBodHRwczovL2RvaS5vcmcvMTAuMTAwNy9zMTA5MjItMDA3LTkwODItOQ0KDQotIFN0cmFz c25lciwgSi4sICJQb2xpY3ktQmFzZWQgTmV0d29yayBNYW5hZ2VtZW50OiBTb2x1dGlvbnMgZm9y IHRoZQ0KICBOZXh0IEdlbmVyYXRpb24iLCBNb3JnYW4gS2F1Zm1hbm4sIERlY2VtYmVyIDIwMDMu DQoNCg0KT24gVHVlLCBEZWMgMjksIDIwMjAgYXQgMDQ6MjY6MTJQTSAtMDAwMCwgQWRyaWFuIEZh cnJlbCB3cm90ZToNCj4gSGkgSnVlcmdlbiwNCj4gDQo+IFdoYXQgeW91IHNheSBhYm91dCBsZWFy bmluZyBsZXNzb25zIGZyb20gdGhlIHBhc3QgaXMgd2lzZSBhbmQgdmFsdWFibGUuDQo+IA0KPiBT YWRseSAod2VsbCwgaXQncyBhIGdvb2QgdGhpbmcsIHJlYWxseSkgd2UgaGF2ZSBuZXcgcGVvcGxl IGluIHRoZSBJRVRGIA0KPiBhbmQgdGhlIG1lbW9yeSBvZiBldmVudHMgb3ZlciB0aGUgbGFzdCAy MCB5ZWFycyBhcmUgbm90IGltbWVkaWF0ZWx5IA0KPiBhY2Nlc3NpYmxlIHRvIHRoZW0uIE90aGVy cywgd2hvIGFyZSBvbGQgYW5kIGdyZXksIGhhdmUgYmVlbiBhcm91bmQgDQo+IHRoYXQgbG9uZyBi dXQgd2VyZSBub3QgbmVjZXNzYXJpbHkgaW52b2x2ZWQgaW4gcHJldmlvdXMgRUNBIGRpc2N1c3Np b25zLg0KPiANCj4gU2luY2UgImludGVudC1iYXNlZCBuZXR3b3JraW5nIiBpcyBhIGJpZyB0aGlu ZyBvbmNlIGFnYWluIChzZWUgcmVjZW50IA0KPiByZXBvcnRzIG9mIGFjcXVpc2l0aW9ucyBpbiB0 aGlzIHNlY3RvcikgdGhlIGV4Y2l0ZW1lbnQgYWJvdXQgRUNBIG1heSANCj4gYmUgZm9yZ2l2ZW4s IGJ1dCBpdCB3b3VsZCBoZWxwIHRvIGdyb3VuZCB0aGUgZGlzY3Vzc2lvbnMgaWYgdGhvc2Ugd2hv IA0KPiBjYW4gcmVtZW1iZXIgcHJldmlvdXMgZWZmb3J0cyB3b3VsZCBzaGFyZSB0aGVpciBleHBl cmllbmNlcyBvciBhdCANCj4gbGVhc3Qgc29tZSBwb2ludGVycy4NCj4gDQo+IEJlc3QsDQo+IEFk cmlhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIDxu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEp1ZXJnZW4gDQo+IFNjaG9lbndh ZWxkZXINCj4gU2VudDogMjMgRGVjZW1iZXIgMjAyMCAxODowOQ0KPiBUbzogQW5keSBCaWVybWFu IDxhbmR5QHl1bWF3b3Jrcy5jb20+DQo+IENjOiBOZXRNb2QgV0cgQ2hhaXJzIDxuZXRtb2QtY2hh aXJzQGlldGYub3JnPjsgTkVUTU9EIEdyb3VwIA0KPiA8bmV0bW9kQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBSZTogW25ldG1vZF0gQWRvcHRpb24gcG9sbCBmb3IgZHJhZnQtd3d4LW5ldG1vZC1ldmVu dC15YW5nLTEwDQo+IA0KPiBPbiBXZWQsIERlYyAyMywgMjAyMCBhdCAwNzowNTo0NEFNIC0wODAw LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4gT24gV2VkLCBEZWMgMjMsIDIwMjAgYXQgMzoxNCBB TSB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3RlOg0KPiA+IA0KPiA+ID4gRnJv bTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERocnV2IERo b2R5IDwgDQo+ID4gPiBkaHJ1di5pZXRmQGdtYWlsLmNvbT4NCj4gPiA+IFNlbnQ6IDIxIERlY2Vt YmVyIDIwMjAgMTc6MTINCj4gPiA+DQo+ID4gPiBIaSBMb3UsIFdHLA0KPiA+ID4NCj4gPiA+IEkg ZmluZCB0aGUgbW90aXZhdGlvbiBpbiB0aGUgSW50cm9kdWN0aW9uIHRvIGJlIGZvY3VzZWQgb24g RUNBIGF0IA0KPiA+ID4gdGhlIG5ldHdvcmsgZGV2aWNlcyAod2l0aCBhbGwgdGhlIHRhbGsgYWJv dXQgaXNzdWVzIHdpdGggDQo+ID4gPiBDZW50cmFsaXplZCBuZXR3b3JrIG1hbmFnZW1lbnQpLg0K PiA+ID4NCj4gPiA+IEkgc2VlIHRoZSB2YWx1ZSBvZiBFQ0Egb24gdGhlIGNvbnRyb2xsZXIgYXMg d2VsbCwgc2F5IGEgY3VzdG9tZXIgDQo+ID4gPiBuZXR3b3JrIGNvbnRyb2xsZXIgb3IgYW4gb3Jj aGVzdHJhdG9yIGNhbiBzZXQgdGhlIEVDQSBvbiBhIGNlbnRyYWwgDQo+ID4gPiBjb250cm9sbGVy IChyZWZlcmVuY2UgQUNUTiBpbiBURUFTIFdHKS4gUGVyaGFwcyB5b3Ugd291bGQgY29uc2lkZXIg DQo+ID4gPiBhZGRpbmcgYSBzZW50ZW5jZSB0byBkZXNjcmliZSB0aGlzIGFzIHdlbGwuIFRoZSBj bGllbnQtc2VydmVyIA0KPiA+ID4gdGVybWlub2xvZ3kgaW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3Vt ZW50IGNvdmVycyBpdCBhbHJlYWR5Lg0KPiA+ID4NCj4gPiA+IEFuZCBJIGRvIHNlZSB2YWx1ZSBp biB0aGlzIGFuZCBzdXBwb3J0IGFkb3B0aW9uLg0KPiA+ID4NCj4gPiA+IDx0cD4NCj4gPiA+IE15 IHRha2UgaXMgdGhhdCB0aGUgSS1EIGlzIHVuY2xlYXIgb24gd2hhdCBFQ0EgaXMuDQo+ID4gPg0K PiA+ID4gRUNBIGhhcyBiZWVuIHdvcmtlZCBvbiBpbiBhdCBsZWFzdCB0d28gSUVURiBXRyBBRkFJ Q1QuICBJdCBjcm9wcGVkIA0KPiA+ID4gdXAgaW4gSTJSUyBidXQgYXMgSSByZWNhbGwsIGl0IHdh cyBhbG9uZyB0aGUgbGluZXMgb2YgJ1RoaXMgaXMgDQo+ID4gPiBFQ0EnICAnTm8gSXQgaXMgbm90 JyAgJ1llcyBpdCBpcycgd2hpY2ggZ2F2ZSBtZSB0aGUgaW1wcmVzc2lvbiANCj4gPiA+IHRoYXQg RUNBIGlzIG5vdCBhIHdlbGwtZGVmaW5lZCwgb3Igd2VsbC11bmRlcnN0b29kLCB0ZXJtLg0KPiA+ ID4NCj4gPiA+IE1vcmUgcmVjZW50bHksIEkyTlNGIGhhdmUgcHJvZHVjZWQgYSBZQU5HIGNhcGFi aWxpdHktZGF0YS1tb2RlbCANCj4gPiA+IHdoaWNoIGlzDQo+ID4gPiA1NSBwYWdlcyBvZiBFQ0Eu ICBMYWNraW5nIGEgZGVmaW5pdGlvbiBpbiB0aGlzIG5ldG1vZCBJLUQsIEkgYW0gDQo+ID4gPiB1 bmNsZWFyIHdoYXQgdGhlIHJlbGF0aW9uc2hpcCBpcyBiZXR3ZWVuIHRoZSBJMk5TRiBJLUQgYW5k IHRoZSANCj4gPiA+IG5ldG1vZCBJLUQsDQo+IHdoZXRoZXINCj4gPiA+IG9yIG5vdCB0aGV5IGFy ZSB1c2luZyBFQ0EgaW4gdGhlIHNhbWUgc2Vuc2UuDQo+ID4gPg0KPiA+ID4NCj4gPiBIaSBUb20s DQo+ID4gDQo+ID4gSXQgdXN1YWxseSBoZWxwcyB0byBhZ3JlZSBvbiB0aGUgcHJvYmxlbS1zcGFj ZSBiZWZvcmUgZm9jdXNpbmcgb24gDQo+ID4gdGhlIHNvbHV0aW9uLXNwYWNlLg0KPiA+IEVDQSBz ZWVtcyBsaWtlIGEgbWV0aG9kb2xvZ3kgKGFsYSBNVkMpIG1vcmUgdGhhbiBhbnl0aGluZyBlbHNl Lg0KPiA+IFRoZSBwcm9ibGVtIHN0YXRlbWVudCBzZWVtcyB0byBiZSB0aGF0IHNvbWUgY2xpZW50 IHRhc2tzIG5lZWQgdG8gYmUNCj4gaGFuZGxlZA0KPiA+IG9uIHRoZQ0KPiA+IHNlcnZlciB1c2lu ZyBFQ0EgbWV0aG9kb2xvZ3ksIGluc3RlYWQgb2Ygb24gdGhlIGNsaWVudC4NCj4gPiBXaGljaCB0 YXNrcz8gU2VlbXMgdG8gYmUgYW55IHRhc2sgb2YgYXJiaXRyYXJ5IHB1cnBvc2Ugb3IgY29tcGxl eGl0eS4NCj4gPiBBbmQgbm93IHRoZSBzY29wZSBpcyBzdXBwb3NlZCB0byBpbmNsdWRlIGNvbnRy b2xsZXJzIChqdXN0IGFub3RoZXINCj4gY2xpZW50KSwNCj4gPiBzbyB0aGUgcHJvYmxlbS1zdG10 DQo+ID4gaXMgZXZlbiBsZXNzIGNsZWFyLg0KPiA+IA0KPiA+IFRoZSB0cmFkaXRpb25hbCBhcHBy b2FjaCBpcyB0byBwaWNrIHNwZWNpZmljIGNsaWVudCB0YXNrcyB0byBtb3ZlIHRvIA0KPiA+IHRo ZSBzZXJ2ZXIuDQo+ID4gVGhlIGV4YW1wbGUgb2YgZGV0ZWN0aW5nIGFuZCByZXBvcnRpbmcgcm91 dGUtZmxhcHMgaGFzIGJlZW4gdXNlZC4NCj4gPiAoTm8gRUNBIGV4YW1wbGUgb2YgdGhpcyBjb21w bGV4aXR5IGhhcyBiZWVuIHByb3ZpZGVkIHlldCkuDQo+ID4gVGhlIHRyYWRpdGlvbmFsIGFwcHJv YWNoIHdvdWxkIGJlIHRvIHdyaXRlIGEgcm91dGUtZmxhcC1kZXRlY3Rpb24gDQo+ID4gWUFORyBt b2R1bGUgd2l0aCBzb21lIGNvbmZpZ3VyYXRpb24sIG1vbml0b3JpbmcgZGF0YSwgYW5kIA0KPiA+ IG5vdGlmaWNhdGlvbiBldmVudHMuDQo+ID4gDQo+ID4gVGhlIGdlbmVyYWxpemVkIGFwcHJvYWNo IGlzIGxpa2VseSB0byBiZSBleHRyZW1lbHkgY29tcGxleCB0byANCj4gPiBzdGFuZGFyZGl6ZSBh bmQgaW1wbGVtZW50Lg0KPiA+DQo+IA0KPiBFQ0Egd29yayBoYXMgYSBsb25nIDIwKyB5ZWFyIHRy YWRpdGlvbiBpbiB0aGUgSUVURiBhbmQgc2V2ZXJhbCANCj4gc3BlY2lmaWNhdGlvbnMgaGF2ZSBi ZWVuIHB1Ymxpc2hlZCBvdmVyIHRoZSB5ZWFycyBieSB2YXJpb3VzIHdvcmtpbmcgDQo+IGdyb3Vw cy4gQXMgZmFyIGFzIEkgY2FuIHRlbGwsIG5vbmUgb2YgdGhlbSBnb3QgdHJhY3Rpb24gaW4gdGVy bXMgb2YgDQo+IHNpZ25pZmlhbnQgZGVwbG95bWVudCBvZiBpbnRlcm9wZXJhYmxlIGltcGxlbWVu dGF0aW9ucy4NCj4gDQo+IEkgd291bGQgaGF2ZSBob3BlZCB0aGF0IHRoZSBuZXh0IGl0ZXJhdGlv biBvZiBFQ0Egd29yayB3b3VsZCBoYXZlIA0KPiBzdGFydGVkIHdpdGggYSBkZWVwIHJlZmxlY3Rp b24gYWJvdXQgd2h5IGFsbCB0aGUgcHJldmlvdXMgYXR0ZW1wdHMgDQo+IGZhaWxlZCB0byBnYWlu IHRyYWN0aW9uIGFuZCBzb21lIGdlbnVpbmUgaW5zaWdodHMgaG93IHRvIGRlc2lnbiB0aGluZ3Mg DQo+IGRpZmZlcmVudGx5IGluIG9yZGVyIHRvIGltcHJvdmUgdGhlIGxpa2VsaWhvb2QgdG8gaGF2 ZSBpbXBhY3QuDQo+IA0KPiAvanMNCj4gDQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg ICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQy MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55 DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KDQotLSAN Ckp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVu IGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAy ODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxo dHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Wed Mar 10 00:08:21 2021 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 85E473A1D52 for ; Wed, 10 Mar 2021 00:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mEMK4u5675kg for ; Wed, 10 Mar 2021 00:08:17 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E6F3A1D4E for ; Wed, 10 Mar 2021 00:08:16 -0800 (PST) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwPjM3h6Dz67ws7; Wed, 10 Mar 2021 16:03:51 +0800 (CST) Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:08:14 +0100 Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 10 Mar 2021 09:08:14 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.181]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0513.000; Wed, 10 Mar 2021 16:08:12 +0800 From: Qin Wu To: Juergen Schoenwaelder , "'NETMOD Group'" Thread-Topic: ECA Policy: Where are policies executed Thread-Index: AdcVgjtMegyP3MlwTKOG6P4gg3d+Tg== Date: Wed, 10 Mar 2021 08:08:11 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADE4F3CDdggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] ECA Policy: Where are policies executed X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 08:08:21 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADE4F3CDdggeml511mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEp1ZXJnZW46DQoNCkkgdGhpbmsgcG9saWN5IG1hbmFnZW1lbnQgcG9saWN5LWJhc2VkIG1h bmFnZW1lbnQgd2FzIHNwZWNpZmllZCBqb2ludCBieSBJRVRGIGFuZCBETVRGLA0KDQpUd28ga2V5 IGZ1bmN0aW9uYWwgZWxlbWVudHMgYXJlIFBEUCBhbmQgUEVQLA0KDQpJbiB0aGUgY2VudHJhbGl6 ZWQgcG9saWN5IG1hbmFnZW1lbnQsIFBEUCBpcyBwYXJ0IG9mIE5NUywgUEVQIGlzIHBhcnQgb2Yg TmV0d29yayBEZXZpY2UuDQoNCkluIHRoZSBpbi1uZXR3b3JrIHBvbGljeSBtYW5hZ2VtZW50LCB3 aGVuIHRoZSBwb2xpY3kgY29udHJvbCBtYW5hZ2VtZW50IGZ1bmN0aW9uIGlzIGRlbGVnYXRlZCBm cm9tIE5NUy9ORVRDT05GIENsaWVudA0KDQp0byB0aGUgbmV0d29yayBkZXZpY2Ugb3IgTkVUQ09O RiBzZXZlciwgbG9jYWwgUERQIGlzIGludHJvZHVjZWQgdG8gdGhlIHNlcnZlciAgdG8gcGVyZm9y bSBwb2xpY3kgbWFuYWdlbWVudC4NCg0KV2hldGhlciBpdCBpcyBjZW50cmFsaXplZCBwb2xpY3kg bWFuYWdlbWVudCAsb3IgaW4tbmV0d29yayBwb2xpY3kgbWFuYWdlbWVudCwgd2UgYmVsaWV2ZSB0 aGUgcG9saWN5IGlzIGVuZm9yY2VkIGluIHRoZSBuZXR3b3JrIGRldmljZS9ORVRDT05GIHNlcnZl ci4NCg0KDQoNCkhvd2V2ZXIgcG9saWN5IGZyYW1ld29yayBpcyBub3QgaW4gdGhlIHNjb3BlIG9m IHRoaXMgd29yaywgd2UgZm9jdXMgb24gRUNBIHBvbGljaWVzIGV4ZWN1dGVkIGJ5IHRoZSBORVRD T05GL1JFU0NPTkYgc2VydmVyLg0KDQoNCg0KLVFpbiAob24gYmVoYWxmIG9mIGF1dGhvcnMpDQoN Ci0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCreiy83KsbzkOiAyMDIwxOox MtTCMzDI1SAyOjU2DQrK1bz+yMs6IEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+ DQqzrcvNOiAnTkVUTU9EIEdyb3VwJyA8bmV0bW9kQGlldGYub3JnPg0K1vfM4jogUmU6IFtuZXRt b2RdIEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXd3eC1uZXRtb2QtZXZlbnQteWFuZy0xMA0KDQoN Cg0KQWRyaWFuLA0KDQoNCg0Kc29tZSBrZXkgaXNzdWVzIHdoZW4gaXQgY29tZXMgdG8gcG9saWN5 LWJhc2VkIG1hbmFnZW1lbnQgc3lzdGVtczoNCg0KDQoNCi0gV2hhdCBpcyBhbiBhZGVxdWF0ZSBh YnN0cmFjdGlvbiBsZXZlbCB0byBleHByZXNzIHBvbGljaWVzIGFuZCBpbnRlbnQ/DQoNCg0KDQog ICBUaGlzIHF1ZXN0aW9uIGhhcyBubyBzaW1wbGUgYW5zd2VyLiBJIGJlbGlldmUgcG9saWNpZXMg bmVlZCB0byBiZQ0KDQogICByZWFkYWJsZSBhbmQgaGVuY2UgdGhleSBuZWVkIHRvIGJlIGV4cHJl c3NlZCBhdCBhIGhpZ2ggbGV2ZWwgb2YNCg0KICAgYWJzdHJhY3Rpb24gYW5kIGluIGEgc3VpdGFi bGUgX2xhbmd1YWdlXy4gSGlnaC1sZXZlbCBwb2xpY3kNCg0KICAgZXhwcmVzc2lvbiBtYXkgYmUg Y29tcGlsZWQgZG93biBpbnRvIG1vcmUgdmVyYm9zZSBwcmltaXRpdmUNCg0KICAgcmVwcmVzZW50 YXRpb25zIHRoYXQgYXJlIGNsb3NlciB0byBhbiBleGVjdXRpb24gYWJzdHJhY3Rpb24uIEENCg0K ICAgY29tbW9uIHBpdGZhbGwgaXMgdG8gc3RhcnQgc29tZXdoZXJlIGluIHRoZSBtaWRkbGUgb2Yg c2V2ZXJhbA0KDQogICBsYXllcnMgb2YgYWJzdHJhY3Rpb24gYW5kIHRoZW4gZ2V0dGluZyBzdHVj ayB3aXRoIHNvbWV0aGluZyBhd2t3YXJkDQoNCiAgIHRvIHB1dCBhIGNsZWFuIGhpZ2hlciBsYXll ciBhYnN0cmFjdCBvbnRvIGFuZCB0byBjb21waWxlIHRoaW5ncw0KDQogICBkb3duIHRvIF9lZmZp Y2llbnRfIGluc3RydW1lbnRhdGlvbnMuDQoNCg0KDQotIFdoZXJlIGFyZSBwb2xpY2llcyBleGVj dXRlZD8NCg0KDQoNCiAgIFRoaXMgY2FuIHJhbmdlIGZyb20gYSBsb2dpY2FsbHkgY2VudHJhbGl6 ZWQgcG9saWN5IGV4ZWN1dGlvbg0KDQogICBlbmdpbmUsIHdoaWNoIGlzIHBhcnQgb2Ygd2hhdCBw ZW9wbGUgY2FsbCBhbiBvcmNoZXN0cmF0b3IgdGhlc2UNCg0KICAgZGF5cywgdG8gZnVsbHkgZGlz dHJpYnV0ZWQgcG9saWN5IGV4ZWN1dGlvbiBtb2RlbHMuIEluIHJlYWxpdHksIHlvdQ0KDQogICBs aWtlbHkgd2FudCB0byBkaXN0cmlidXRlIGZ1bmN0aW9ucyBkeW5hbWljYWxseSBidXQgdGhpcyBt YWtlcw0KDQogICBzb2x1dGlvbnMgdGVjaG5pY2FsbHkgbXVjaCBtb3JlIGNvbXBsaWNhdGVkLiBH aXZlbiB0b2RheSdzIHNjYWxhYmxlDQoNCiAgIGNvbXB1dGluZyBhbmQgbmV0d29ya2luZyBjYXBh YmlsaXRpZXMsIGxvZ2ljYWxseSBjZW50cmFsaXplZA0KDQogICBzb2x1dGlvbnMgYXJlIG9uIHRo ZSByaXNlIGFuZCBoYXZlIHJlcGxhY2VkIHRoZSBkaXN0cmlidXRlZA0KDQogICBhcHByb2FjaGVz IG9mIHRoZSA5MHMuDQoNCg0KDQotIFdoZW4gdG8gZGV0ZWN0IGFuZCByZXNvbHZlIHBvbGljeSBj b25mbGljdHM/DQoNCg0KDQogICBEZXRlY3RpbmcgYW5kIHJlc29sdmluZyBjb25mbGljdHMgaW4g bGFyZ2VyIGNvbGxlY3Rpb25zIG9mIHBvbGljaWVzDQoNCiAgIGlzIG5vbi10cml2aWFsLiBUaGlz IGluY2x1ZGVzIHByb2JsZW1zIHJhbmdpbmcgZnJvbSBtaWNybyB0aW1lc2NhbGUNCg0KICAgYXRv bWljaXR5IGlzc3VlcyB0byBsYXJnZXIgdGltZXNjYWxlIHN0YWJpbGl0eSBpc3N1ZXMgKGludGVy YWN0aW5nDQoNCiAgIHBvbGljeSBjb250cm9sIGxvb3BzKS4gSWYgcG9saWN5IGV4ZWN1dGlvbiBp cyBkaXN0cmlidXRlZCAob3IgdGhlDQoNCiAgIGV2ZW50IC8gaW5mb3JtYXRpb24gc291cmNlcyBh cmUgZGlzdHJpYnV0ZWQpLCB0aGlzIHVsdGltYXRlbHkNCg0KICAgcmVzb2x2ZXMgdG8gcHJvYmxl bXMgc3VjaCBhcyB0YWtpbmcgY29uc2lzdGVudCBzbmFwc2hvdHMgb3IgZmluZGluZw0KDQogICB3 YXlzIHRvIHdvcmsgd2l0aCBpbmNvbnNpc3RlbnQgb2JzZXJ2YXRpb25zIG9mIGEgZGlzdHJpYnV0 ZWQgc3lzdGVtDQoNCiAgIHRoYXQgYXJlIGd1YXJhbnRlZWQgdG8gY29udmVyZ2UgdG8gc3RhYmxl IHN0YXRlcyAoc2VsZi1zdGFiaWxpemluZw0KDQogICBhbGdvcml0aG1zKS4NCg0KDQoNCi0gV2hv IGlzIGludGVyZXN0ZWQgaW4gaW50ZXJvcGVyYWJsZSBwb2xpY3kgcmVwcmVzZW50YXRpb25zIC8g bGFuZ3VhZ2VzPw0KDQoNCg0KICAgVGhlIElFVEYgaXMgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eS4g V2hhdCBhcmUgdGhlIGJ1c2luZXNzIG1vZGVscw0KDQogICB0aGF0IHB1c2ggZm9yIGludGVyb3Bl cmFibGUgcG9saWN5IGJhc2VkIG1hbmFnZW1lbnQgc3RhbmRhcmRzPyBXaG8NCg0KICAgYmVuZWZp dHMgZnJvbSBoYXZpbmcgYW4gaW50ZXJvcGVyYWJsZSBzdGFuZGFyZCBhbmQgaG93IG11Y2ggZWZm b3J0DQoNCiAgIGFyZSBvcmdhbml6YXRpb25zIHdpbGxpbmcgdG8gaW52ZXN0IGludG8gZW5naW5l ZXJpbmcgYSByZWFzb25hYmxlDQoNCiAgIHNvbHV0aW9uIGFkZHJlc3NpbmcgdGhlIG90aGVyIChu b24tdHJpdmlhbCkgcXVlc3Rpb25zIHJhaXNlZCBhYm92ZT8NCg0KICAgV2lsbCB0aGV5IGJlIGlt cGxlbWVudGluZyB0aGUgc29sdXRpb24gaW4gdGhlaXIgcHJvZHVjdHM/DQoNCg0KDQpNeSBwb3Np dGlvbiBpcyB0aGF0IHRoZXJlIGFyZSB3YXkgdG9vIG1hbnkgZGlmZmljdWx0IHRlY2huaWNhbCBp c3N1ZXMgdG8gcmVzb2x2ZSBmb3IgdGhpcyB3b3JrIHRvIGJlIHZpYWJsZSBmb3IgdGhlIElFVEYu IEluc3RlYWQsIEkgc3VnZ2VzdCB0aGF0IHBlb3BsZSBnbyBhbmQgd29yayBvdXQgc29sdXRpb25z IGFuZCBvbmNlIHRoZSBzaWx2ZXIgYnVsbGV0IGhhcyBiZWVuIGZvdW5kLCBicmluZyBpdCB0byB0 aGUgSUVURi4gKEhpc3RvcmljYWxseSwgYWxsIGF0dGVtcHRzIHRvIGNhc3QgcG9saWNpZXMgaW50 byBleGlzdGluZyBkYXRhIG1vZGVscyBzdWNoIGFzIE1JQiBtb2R1bGVzIG9yIExEQVAgc2NoZW1h IGxlZCB0byBzb21ldGhpbmcgYXdrd2FyZCBhbmQgdW51c2FibGUuIEkgYmVsaWV2ZSBZQU5HIG1v ZHVsZXMgYXJlIG5vDQoNCmRpZmZlcmVudC4pDQoNCg0KDQovanMNCg0KDQoNClNvbWUgcmVsZXZh bnQgUkZDcyAodGhlcmUgbWF5IGJlIG1vcmUpOg0KDQoNCg0KMzA1MiBTZXJ2aWNlIE1hbmFnZW1l bnQgQXJjaGl0ZWN0dXJlcyBJc3N1ZXMgYW5kIFJldmlldy4gTS4gRWRlciwgUy4gTmFnLg0KDQog ICAgIEphbnVhcnkgMjAwMS4gKEZvcm1hdDogVFhULCBIVE1MKSAoU3RhdHVzOiBJTkZPUk1BVElP TkFMKSAoRE9JOg0KDQogICAgIDEwLjE3NDg3L1JGQzMwNTIpDQoNCg0KDQozMDg0IENPUFMgVXNh Z2UgZm9yIFBvbGljeSBQcm92aXNpb25pbmcgKENPUFMtUFIpLiBLLiBDaGFuLCBKLiBTZWxpZ3Nv biwNCg0KICAgICBELiBEdXJoYW0sIFMuIEdhaSwgSy4gTWNDbG9naHJpZSwgUy4gSGVyem9nLCBG LiBSZWljaG1leWVyLCBSLg0KDQogICAgIFlhdmF0a2FyLCBBLiBTbWl0aC4gTWFyY2ggMjAwMS4g KEZvcm1hdDogVFhULCBIVE1MKSAoU3RhdHVzOg0KDQogICAgIEhJU1RPUklDKSAoRE9JOiAxMC4x NzQ4Ny9SRkMzMDg0KQ0KDQoNCg0KMzE1OSBTdHJ1Y3R1cmUgb2YgUG9saWN5IFByb3Zpc2lvbmlu ZyBJbmZvcm1hdGlvbiAoU1BQSSkuIEsuIE1jQ2xvZ2hyaWUsDQoNCiAgICAgTS4gRmluZSwgSi4g U2VsaWdzb24sIEsuIENoYW4sIFMuIEhhaG4sIFIuIFNhaGl0YSwgQS4gU21pdGgsIEYuDQoNCiAg ICAgUmVpY2htZXllci4gQXVndXN0IDIwMDEuIChGb3JtYXQ6IFRYVCwgSFRNTCkgKFN0YXR1czog SElTVE9SSUMpDQoNCiAgICAgKERPSTogMTAuMTc0ODcvUkZDMzE1OSkNCg0KDQoNCjMzMTggRnJh bWV3b3JrIFBvbGljeSBJbmZvcm1hdGlvbiBCYXNlLiBSLiBTYWhpdGEsIEVkLiwgUy4gSGFobiwg Sy4gQ2hhbiwNCg0KICAgICBLLiBNY0Nsb2docmllLiBNYXJjaCAyMDAzLiAoRm9ybWF0OiBUWFQs IEhUTUwpIChTdGF0dXM6IEhJU1RPUklDKQ0KDQogICAgIChET0k6IDEwLjE3NDg3L1JGQzMzMTgp DQoNCg0KDQozNDYwIFBvbGljeSBDb3JlIEluZm9ybWF0aW9uIE1vZGVsIChQQ0lNKSBFeHRlbnNp b25zLiBCLiBNb29yZSwgRWQuLg0KDQogICAgIEphbnVhcnkgMjAwMy4gKEZvcm1hdDogVFhULCBI VE1MKSAoVXBkYXRlcyBSRkMzMDYwKSAoU3RhdHVzOg0KDQogICAgIFBST1BPU0VEIFNUQU5EQVJE KSAoRE9JOiAxMC4xNzQ4Ny9SRkMzNDYwKQ0KDQoNCg0KMzY0NCBQb2xpY3kgUXVhbGl0eSBvZiBT ZXJ2aWNlIChRb1MpIEluZm9ybWF0aW9uIE1vZGVsLiBZLiBTbmlyLCBZLg0KDQogICAgIFJhbWJl cmcsIEouIFN0cmFzc25lciwgUi4gQ29oZW4sIEIuIE1vb3JlLiBOb3ZlbWJlciAyMDAzLiAoRm9y bWF0Og0KDQogICAgIFRYVCwgSFRNTCkgKFN0YXR1czogUFJPUE9TRUQgU1RBTkRBUkQpIChET0k6 IDEwLjE3NDg3L1JGQzM2NDQpDQoNCg0KDQozMTk4IFRlcm1pbm9sb2d5IGZvciBQb2xpY3ktQmFz ZWQgTWFuYWdlbWVudC4gQS4gV2VzdGVyaW5lbiwgSi4NCg0KICAgICBTY2huaXpsZWluLCBKLiBT dHJhc3NuZXIsIE0uIFNjaGVybGluZywgQi4gUXVpbm4sIFMuIEhlcnpvZywgQS4NCg0KICAgICBI dXluaCwgTS4gQ2FybHNvbiwgSi4gUGVycnksIFMuIFdhbGRidXNzZXIuIE5vdmVtYmVyIDIwMDEu IChGb3JtYXQ6DQoNCiAgICAgVFhULCBIVE1MKSAoU3RhdHVzOiBJTkZPUk1BVElPTkFMKSAoRE9J OiAxMC4xNzQ4Ny9SRkMzMTk4KQ0KDQoNCg0KNDAxMSBQb2xpY3kgQmFzZWQgTWFuYWdlbWVudCBN SUIuIFMuIFdhbGRidXNzZXIsIEouIFNhcGVyaWEsIFQuIEhvbmdhbC4NCg0KICAgICBNYXJjaCAy MDA1LiAoRm9ybWF0OiBUWFQsIEhUTUwpIChTdGF0dXM6IFBST1BPU0VEIFNUQU5EQVJEKSAoRE9J Og0KDQogICAgIDEwLjE3NDg3L1JGQzQwMTEpDQoNCg0KDQo0MTA0IFBvbGljeSBDb3JlIEV4dGVu c2lvbiBMaWdodHdlaWdodCBEaXJlY3RvcnkgQWNjZXNzIFByb3RvY29sIFNjaGVtYQ0KDQogICAg IChQQ0VMUykuIE0uIFBhbmEsIEVkLiwgQS4gUmV5ZXMsIEEuIEJhcmJhLCBELiBNb3JvbiwgTS4g QnJ1bm5lci4NCg0KICAgICBKdW5lIDIwMDUuIChGb3JtYXQ6IFRYVCwgSFRNTCkgKFVwZGF0ZXMg UkZDMzcwMykgKFN0YXR1czogUFJPUE9TRUQNCg0KICAgICBTVEFOREFSRCkgKERPSTogMTAuMTc0 ODcvUkZDNDEwNCkNCg0KDQoNCjgzMjggUG9saWN5LUJhc2VkIE1hbmFnZW1lbnQgRnJhbWV3b3Jr IGZvciB0aGUgU2ltcGxpZmllZCBVc2Ugb2YgUG9saWN5DQoNCiAgICAgQWJzdHJhY3Rpb25zIChT VVBBKS4gVy4gTGl1LCBDLiBYaWUsIEouIFN0cmFzc25lciwgRy4gS2FyYWdpYW5uaXMsDQoNCiAg ICAgTS4gS2x5dXMsIEouIEJpLCBZLiBDaGVuZywgRC4gWmhhbmcuIE1hcmNoIDIwMTguIChGb3Jt YXQ6IFRYVCwgSFRNTCkNCg0KICAgICAoU3RhdHVzOiBJTkZPUk1BVElPTkFMKSAoRE9JOiAxMC4x NzQ4Ny9SRkM4MzI4KQ0KDQoNCg0KV0dzL1JHcyB0aGF0IGF0IGxlYXN0IHBhcnRpYWxseSByZWxh dGVkIHRvIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50Og0KDQoNCg0KLSBTaW1wbGlmaWVkIFVzZSBv ZiBQb2xpY3kgQWJzdHJhY3Rpb25zIFdHIChzdXBhKSAoMjAxNSAtIDIwMTcpDQoNCg0KDQotIFBv bGljeSBGcmFtZXdvcmsgV0cgKHBvbGljeSkgKDE5OTggLSAyMDA0KQ0KDQoNCg0KLSBSZXNvdXJj ZSBBbGxvY2F0aW9uIFByb3RvY29sIFdHIChyYXApICgxOTk3IC0gMjAwNSkNCg0KDQoNCi0gRGlz dHJpYnV0ZWQgTWFuYWdlbWVudCBXRyAoZGlzbWFuKSAoMTk5NiAtIDIwMDYpDQoNCg0KDQotIFNl cnZpY2VzIE1hbmFnZW1lbnQgUkcgKHNtcmcpICgyMDE5PyAtIDIwMDE/KQ0KDQoNCg0KLSBOZXR3 b3JrIE1hbmFnZW1lbnQgUkcgKG5tcmcpDQoNCg0KDQogIC0gZHJhZnQtY2xlbW0tbm1yZy1kaXN0 LWludGVudCAoMjAxNy0yMDE5KQ0KDQogIC0gZHJhZnQtaXJ0Zi1ubXJnLWlibi1jb25jZXB0cy1k ZWZpbml0aW9ucy0wMi50eHQgKDIwMTktMjAyMCkNCg0KDQoNCk90aGVyIHJlc291cmNlczoNCg0K DQoNCi0gaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUG9saWN5LWJhc2VkX21hbmFnZW1l bnQNCg0KDQoNCi0gaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1FX3Ytb2Y1ODJ4Zw0K DQoNCg0KLSBCb3V0YWJhLCBSLiBhbmQgSS4gQWliLCAiUG9saWN5LUJhc2VkIE1hbmFnZW1lbnQ6 IEENCg0KICBIaXN0b3JpY2FsIFBlcnNwZWN0aXZlIi4gSm91cm5hbCBvZiBOZXR3b3JrIGFuZCBT eXN0ZW1zDQoNCiAgTWFuYWdlbWVudCAoSk5TTSksIFNwcmluZ2VyLCBWb2wuIDE1ICg0KSwgRGVj ZW1iZXIgMjAwNy4NCg0KICBodHRwczovL2RvaS5vcmcvMTAuMTAwNy9zMTA5MjItMDA3LTkwODMt OA0KDQoNCg0KLSBQYXZsb3UsIEcuLCAiT24gdGhlIEV2b2x1dGlvbiBvZiBNYW5hZ2VtZW50IEFw cHJvYWNoZXMsIEZyYW1ld29ya3MNCg0KICBhbmQgUHJvdG9jb2xzOiBBIEhpc3RvcmljYWwgUGVy c3BlY3RpdmUiLiBKb3VybmFsIG9mIE5ldHdvcmsgYW5kDQoNCiAgU3lzdGVtcyBNYW5hZ2VtZW50 IChKTlNNKSwgU3ByaW5nZXIsIFZvbC4gMTUgKDQpLCBEZWNlbWJlciAyMDA3Lg0KDQogIGh0dHBz Oi8vZG9pLm9yZy8xMC4xMDA3L3MxMDkyMi0wMDctOTA4Mi05DQoNCg0KDQotIFN0cmFzc25lciwg Si4sICJQb2xpY3ktQmFzZWQgTmV0d29yayBNYW5hZ2VtZW50OiBTb2x1dGlvbnMgZm9yIHRoZQ0K DQogIE5leHQgR2VuZXJhdGlvbiIsIE1vcmdhbiBLYXVmbWFubiwgRGVjZW1iZXIgMjAwMy4NCg0K DQoNCg0KDQpPbiBUdWUsIERlYyAyOSwgMjAyMCBhdCAwNDoyNjoxMlBNIC0wMDAwLCBBZHJpYW4g RmFycmVsIHdyb3RlOg0KDQo+IEhpIEp1ZXJnZW4sDQoNCj4NCg0KPiBXaGF0IHlvdSBzYXkgYWJv dXQgbGVhcm5pbmcgbGVzc29ucyBmcm9tIHRoZSBwYXN0IGlzIHdpc2UgYW5kIHZhbHVhYmxlLg0K DQo+DQoNCj4gU2FkbHkgKHdlbGwsIGl0J3MgYSBnb29kIHRoaW5nLCByZWFsbHkpIHdlIGhhdmUg bmV3IHBlb3BsZSBpbiB0aGUgSUVURg0KDQo+IGFuZCB0aGUgbWVtb3J5IG9mIGV2ZW50cyBvdmVy IHRoZSBsYXN0IDIwIHllYXJzIGFyZSBub3QgaW1tZWRpYXRlbHkNCg0KPiBhY2Nlc3NpYmxlIHRv IHRoZW0uIE90aGVycywgd2hvIGFyZSBvbGQgYW5kIGdyZXksIGhhdmUgYmVlbiBhcm91bmQNCg0K PiB0aGF0IGxvbmcgYnV0IHdlcmUgbm90IG5lY2Vzc2FyaWx5IGludm9sdmVkIGluIHByZXZpb3Vz IEVDQSBkaXNjdXNzaW9ucy4NCg0KPg0KDQo+IFNpbmNlICJpbnRlbnQtYmFzZWQgbmV0d29ya2lu ZyIgaXMgYSBiaWcgdGhpbmcgb25jZSBhZ2FpbiAoc2VlIHJlY2VudA0KDQo+IHJlcG9ydHMgb2Yg YWNxdWlzaXRpb25zIGluIHRoaXMgc2VjdG9yKSB0aGUgZXhjaXRlbWVudCBhYm91dCBFQ0EgbWF5 DQoNCj4gYmUgZm9yZ2l2ZW4sIGJ1dCBpdCB3b3VsZCBoZWxwIHRvIGdyb3VuZCB0aGUgZGlzY3Vz c2lvbnMgaWYgdGhvc2Ugd2hvDQoNCj4gY2FuIHJlbWVtYmVyIHByZXZpb3VzIGVmZm9ydHMgd291 bGQgc2hhcmUgdGhlaXIgZXhwZXJpZW5jZXMgb3IgYXQNCg0KPiBsZWFzdCBzb21lIHBvaW50ZXJz Lg0KDQo+DQoNCj4gQmVzdCwNCg0KPiBBZHJpYW4NCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQoNCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgSnVlcmdlbg0KDQo+IFNj aG9lbndhZWxkZXINCg0KPiBTZW50OiAyMyBEZWNlbWJlciAyMDIwIDE4OjA5DQoNCj4gVG86IEFu ZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+ Pg0KDQo+IENjOiBOZXRNb2QgV0cgQ2hhaXJzIDxuZXRtb2QtY2hhaXJzQGlldGYub3JnPG1haWx0 bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnPj47IE5FVE1PRCBHcm91cA0KDQo+IDxuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQoNCj4gU3ViamVjdDogUmU6IFtuZXRtb2Rd IEFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXd3eC1uZXRtb2QtZXZlbnQteWFuZy0xMA0KDQo+DQoN Cj4gT24gV2VkLCBEZWMgMjMsIDIwMjAgYXQgMDc6MDU6NDRBTSAtMDgwMCwgQW5keSBCaWVybWFu IHdyb3RlOg0KDQo+ID4gT24gV2VkLCBEZWMgMjMsIDIwMjAgYXQgMzoxNCBBTSB0b20gcGV0Y2gg PGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+PiB3cm90ZToN Cg0KPiA+DQoNCj4gPiA+IEZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERocnV2IERob2R5IDwN Cg0KPiA+ID4gZGhydXYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRocnV2LmlldGZAZ21haWwuY29t Pj4NCg0KPiA+ID4gU2VudDogMjEgRGVjZW1iZXIgMjAyMCAxNzoxMg0KDQo+ID4gPg0KDQo+ID4g PiBIaSBMb3UsIFdHLA0KDQo+ID4gPg0KDQo+ID4gPiBJIGZpbmQgdGhlIG1vdGl2YXRpb24gaW4g dGhlIEludHJvZHVjdGlvbiB0byBiZSBmb2N1c2VkIG9uIEVDQSBhdA0KDQo+ID4gPiB0aGUgbmV0 d29yayBkZXZpY2VzICh3aXRoIGFsbCB0aGUgdGFsayBhYm91dCBpc3N1ZXMgd2l0aA0KDQo+ID4g PiBDZW50cmFsaXplZCBuZXR3b3JrIG1hbmFnZW1lbnQpLg0KDQo+ID4gPg0KDQo+ID4gPiBJIHNl ZSB0aGUgdmFsdWUgb2YgRUNBIG9uIHRoZSBjb250cm9sbGVyIGFzIHdlbGwsIHNheSBhIGN1c3Rv bWVyDQoNCj4gPiA+IG5ldHdvcmsgY29udHJvbGxlciBvciBhbiBvcmNoZXN0cmF0b3IgY2FuIHNl dCB0aGUgRUNBIG9uIGEgY2VudHJhbA0KDQo+ID4gPiBjb250cm9sbGVyIChyZWZlcmVuY2UgQUNU TiBpbiBURUFTIFdHKS4gUGVyaGFwcyB5b3Ugd291bGQgY29uc2lkZXINCg0KPiA+ID4gYWRkaW5n IGEgc2VudGVuY2UgdG8gZGVzY3JpYmUgdGhpcyBhcyB3ZWxsLiBUaGUgY2xpZW50LXNlcnZlcg0K DQo+ID4gPiB0ZXJtaW5vbG9neSBpbiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgY292ZXJzIGl0 IGFscmVhZHkuDQoNCj4gPiA+DQoNCj4gPiA+IEFuZCBJIGRvIHNlZSB2YWx1ZSBpbiB0aGlzIGFu ZCBzdXBwb3J0IGFkb3B0aW9uLg0KDQo+ID4gPg0KDQo+ID4gPiA8dHA+DQoNCj4gPiA+IE15IHRh a2UgaXMgdGhhdCB0aGUgSS1EIGlzIHVuY2xlYXIgb24gd2hhdCBFQ0EgaXMuDQoNCj4gPiA+DQoN Cj4gPiA+IEVDQSBoYXMgYmVlbiB3b3JrZWQgb24gaW4gYXQgbGVhc3QgdHdvIElFVEYgV0cgQUZB SUNULiAgSXQgY3JvcHBlZA0KDQo+ID4gPiB1cCBpbiBJMlJTIGJ1dCBhcyBJIHJlY2FsbCwgaXQg d2FzIGFsb25nIHRoZSBsaW5lcyBvZiAnVGhpcyBpcw0KDQo+ID4gPiBFQ0EnICAnTm8gSXQgaXMg bm90JyAgJ1llcyBpdCBpcycgd2hpY2ggZ2F2ZSBtZSB0aGUgaW1wcmVzc2lvbg0KDQo+ID4gPiB0 aGF0IEVDQSBpcyBub3QgYSB3ZWxsLWRlZmluZWQsIG9yIHdlbGwtdW5kZXJzdG9vZCwgdGVybS4N Cg0KPiA+ID4NCg0KPiA+ID4gTW9yZSByZWNlbnRseSwgSTJOU0YgaGF2ZSBwcm9kdWNlZCBhIFlB TkcgY2FwYWJpbGl0eS1kYXRhLW1vZGVsDQoNCj4gPiA+IHdoaWNoIGlzDQoNCj4gPiA+IDU1IHBh Z2VzIG9mIEVDQS4gIExhY2tpbmcgYSBkZWZpbml0aW9uIGluIHRoaXMgbmV0bW9kIEktRCwgSSBh bQ0KDQo+ID4gPiB1bmNsZWFyIHdoYXQgdGhlIHJlbGF0aW9uc2hpcCBpcyBiZXR3ZWVuIHRoZSBJ Mk5TRiBJLUQgYW5kIHRoZQ0KDQo+ID4gPiBuZXRtb2QgSS1ELA0KDQo+IHdoZXRoZXINCg0KPiA+ ID4gb3Igbm90IHRoZXkgYXJlIHVzaW5nIEVDQSBpbiB0aGUgc2FtZSBzZW5zZS4NCg0KPiA+ID4N Cg0KPiA+ID4NCg0KPiA+IEhpIFRvbSwNCg0KPiA+DQoNCj4gPiBJdCB1c3VhbGx5IGhlbHBzIHRv IGFncmVlIG9uIHRoZSBwcm9ibGVtLXNwYWNlIGJlZm9yZSBmb2N1c2luZyBvbg0KDQo+ID4gdGhl IHNvbHV0aW9uLXNwYWNlLg0KDQo+ID4gRUNBIHNlZW1zIGxpa2UgYSBtZXRob2RvbG9neSAoYWxh IE1WQykgbW9yZSB0aGFuIGFueXRoaW5nIGVsc2UuDQoNCj4gPiBUaGUgcHJvYmxlbSBzdGF0ZW1l bnQgc2VlbXMgdG8gYmUgdGhhdCBzb21lIGNsaWVudCB0YXNrcyBuZWVkIHRvIGJlDQoNCj4gaGFu ZGxlZA0KDQo+ID4gb24gdGhlDQoNCj4gPiBzZXJ2ZXIgdXNpbmcgRUNBIG1ldGhvZG9sb2d5LCBp bnN0ZWFkIG9mIG9uIHRoZSBjbGllbnQuDQoNCj4gPiBXaGljaCB0YXNrcz8gU2VlbXMgdG8gYmUg YW55IHRhc2sgb2YgYXJiaXRyYXJ5IHB1cnBvc2Ugb3IgY29tcGxleGl0eS4NCg0KPiA+IEFuZCBu b3cgdGhlIHNjb3BlIGlzIHN1cHBvc2VkIHRvIGluY2x1ZGUgY29udHJvbGxlcnMgKGp1c3QgYW5v dGhlcg0KDQo+IGNsaWVudCksDQoNCj4gPiBzbyB0aGUgcHJvYmxlbS1zdG10DQoNCj4gPiBpcyBl dmVuIGxlc3MgY2xlYXIuDQoNCj4gPg0KDQo+ID4gVGhlIHRyYWRpdGlvbmFsIGFwcHJvYWNoIGlz IHRvIHBpY2sgc3BlY2lmaWMgY2xpZW50IHRhc2tzIHRvIG1vdmUgdG8NCg0KPiA+IHRoZSBzZXJ2 ZXIuDQoNCj4gPiBUaGUgZXhhbXBsZSBvZiBkZXRlY3RpbmcgYW5kIHJlcG9ydGluZyByb3V0ZS1m bGFwcyBoYXMgYmVlbiB1c2VkLg0KDQo+ID4gKE5vIEVDQSBleGFtcGxlIG9mIHRoaXMgY29tcGxl eGl0eSBoYXMgYmVlbiBwcm92aWRlZCB5ZXQpLg0KDQo+ID4gVGhlIHRyYWRpdGlvbmFsIGFwcHJv YWNoIHdvdWxkIGJlIHRvIHdyaXRlIGEgcm91dGUtZmxhcC1kZXRlY3Rpb24NCg0KPiA+IFlBTkcg bW9kdWxlIHdpdGggc29tZSBjb25maWd1cmF0aW9uLCBtb25pdG9yaW5nIGRhdGEsIGFuZA0KDQo+ ID4gbm90aWZpY2F0aW9uIGV2ZW50cy4NCg0KPiA+DQoNCj4gPiBUaGUgZ2VuZXJhbGl6ZWQgYXBw cm9hY2ggaXMgbGlrZWx5IHRvIGJlIGV4dHJlbWVseSBjb21wbGV4IHRvDQoNCj4gPiBzdGFuZGFy ZGl6ZSBhbmQgaW1wbGVtZW50Lg0KDQo+ID4NCg0KPg0KDQo+IEVDQSB3b3JrIGhhcyBhIGxvbmcg MjArIHllYXIgdHJhZGl0aW9uIGluIHRoZSBJRVRGIGFuZCBzZXZlcmFsDQoNCj4gc3BlY2lmaWNh dGlvbnMgaGF2ZSBiZWVuIHB1Ymxpc2hlZCBvdmVyIHRoZSB5ZWFycyBieSB2YXJpb3VzIHdvcmtp bmcNCg0KPiBncm91cHMuIEFzIGZhciBhcyBJIGNhbiB0ZWxsLCBub25lIG9mIHRoZW0gZ290IHRy YWN0aW9uIGluIHRlcm1zIG9mDQoNCj4gc2lnbmlmaWFudCBkZXBsb3ltZW50IG9mIGludGVyb3Bl cmFibGUgaW1wbGVtZW50YXRpb25zLg0KDQo+DQoNCj4gSSB3b3VsZCBoYXZlIGhvcGVkIHRoYXQg dGhlIG5leHQgaXRlcmF0aW9uIG9mIEVDQSB3b3JrIHdvdWxkIGhhdmUNCg0KPiBzdGFydGVkIHdp dGggYSBkZWVwIHJlZmxlY3Rpb24gYWJvdXQgd2h5IGFsbCB0aGUgcHJldmlvdXMgYXR0ZW1wdHMN Cg0KPiBmYWlsZWQgdG8gZ2FpbiB0cmFjdGlvbiBhbmQgc29tZSBnZW51aW5lIGluc2lnaHRzIGhv dyB0byBkZXNpZ24gdGhpbmdzDQoNCj4gZGlmZmVyZW50bHkgaW4gb3JkZXIgdG8gaW1wcm92ZSB0 aGUgbGlrZWxpaG9vZCB0byBoYXZlIGltcGFjdC4NCg0KPg0KDQo+IC9qcw0KDQo+DQoNCj4gLS0N Cg0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp bmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCg0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCj4NCg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCg0KPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4NCg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo+ DQoNCg0KDQotLQ0KDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQoNCkZheDogICArNDkgNDIxIDIw MCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm5ldG1v ZCBtYWlsaW5nIGxpc3QNCg0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABAADE4F3CDdggeml511mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Juergen:

I think policy management po= licy-based management was specified joint by IETF and DMTF,

Two key functional elements = are PDP and PEP,

In the centralized policy ma= nagement, PDP is part of NMS, PEP is part of Network Device.

In the in-network policy man= agement, when the policy control management function is delegated from NMS/= NETCONF Client

to the network device or NET= CONF sever, local PDP is introduced to the server  to perform policy m= anagement.

Whether it is centralized po= licy management ,or in-network policy management, we believe the policy is = enforced in the network device/NETCONF server.

 

However policy framework is = not in the scope of this work, we focus on ECA policies executed by the NET= CONF/RESCONF server.

 

-Qin (on behalf of authors)<= o:p>

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: netmod [mailto:netmod-bounces@ietf.org] =B4=FA=B1=ED Juergen Schoenwaelder
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA12=D4=C230=C8=D5 2:56
=CA=D5=BC=FE=C8=CB: Adrian Farrel <adrian@olddog.co.uk>
=B3=AD=CB=CD: 'NETMOD Group' <netmod@ietf.org>
=D6=F7=CC=E2: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-1= 0

 

Adrian,

 

some key issues when it come= s to policy-based management systems:

 

- What is an adequate abstra= ction level to express policies and intent?

 

   This question h= as no simple answer. I believe policies need to be

   readable and he= nce they need to be expressed at a high level of

   abstraction and= in a suitable _language_. High-level policy

   expression may = be compiled down into more verbose primitive

   representations= that are closer to an execution abstraction. A

   common pitfall = is to start somewhere in the middle of several

   layers of abstr= action and then getting stuck with something awkward

   to put a clean = higher layer abstract onto and to compile things

   down to _effici= ent_ instrumentations.

 

- Where are policies execute= d?

 

   This can range = from a logically centralized policy execution

   engine, which i= s part of what people call an orchestrator these

   days, to fully = distributed policy execution models. In reality, you

   likely want to = distribute functions dynamically but this makes

   solutions techn= ically much more complicated. Given today's scalable

   computing and n= etworking capabilities, logically centralized

   solutions are o= n the rise and have replaced the distributed

   approaches of t= he 90s.

 

- When to detect and resolve= policy conflicts?

 

   Detecting and r= esolving conflicts in larger collections of policies

   is non-trivial.= This includes problems ranging from micro timescale

   atomicity issue= s to larger timescale stability issues (interacting

   policy control = loops). If policy execution is distributed (or the

   event / informa= tion sources are distributed), this ultimately

   resolves to pro= blems such as taking consistent snapshots or finding

   ways to work wi= th inconsistent observations of a distributed system

   that are guaran= teed to converge to stable states (self-stabilizing

   algorithms).

 

- Who is interested in inter= operable policy representations / languages?

 

   The IETF is abo= ut interoperability. What are the business models

   that push for i= nteroperable policy based management standards? Who

   benefits from h= aving an interoperable standard and how much effort

   are organizatio= ns willing to invest into engineering a reasonable

   solution addres= sing the other (non-trivial) questions raised above?

   Will they be im= plementing the solution in their products?

 

My position is that there ar= e way too many difficult technical issues to resolve for this work to be vi= able for the IETF. Instead, I suggest that people go and work out solutions= and once the silver bullet has been found, bring it to the IETF. (Historically, all attempts to cast policies = into existing data models such as MIB modules or LDAP schema led to somethi= ng awkward and unusable. I believe YANG modules are no

different.)

 

/js

 

Some relevant RFCs (there ma= y be more):

 

3052 Service Management Arch= itectures Issues and Review. M. Eder, S. Nag.

     Jan= uary 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:

     10.= 17487/RFC3052)

 

3084 COPS Usage for Policy P= rovisioning (COPS-PR). K. Chan, J. Seligson,

     D. = Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R.

     Yav= atkar, A. Smith. March 2001. (Format: TXT, HTML) (Status:=

     HIS= TORIC) (DOI: 10.17487/RFC3084)

 

3159 Structure of Policy Pro= visioning Information (SPPI). K. McCloghrie,

     M. = Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F.

     Rei= chmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC)

     (DO= I: 10.17487/RFC3159)

 

3318 Framework Policy Inform= ation Base. R. Sahita, Ed., S. Hahn, K. Chan,

     K. = McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC)

     (DO= I: 10.17487/RFC3318)

 

3460 Policy Core Information= Model (PCIM) Extensions. B. Moore, Ed..

     Jan= uary 2003. (Format: TXT, HTML) (Updates RFC3060) (Status:=

     PRO= POSED STANDARD) (DOI: 10.17487/RFC3460)

 

3644 Policy Quality of Servi= ce (QoS) Information Model. Y. Snir, Y.

     Ram= berg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format:<= /span>

     TXT= , HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644)

 

3198 Terminology for Policy-= Based Management. A. Westerinen, J.

     Sch= nizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.

     Huy= nh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format:=

     TXT= , HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198)

 

4011 Policy Based Management= MIB. S. Waldbusser, J. Saperia, T. Hongal.

     Mar= ch 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:

     10.= 17487/RFC4011)

 

4104 Policy Core Extension L= ightweight Directory Access Protocol Schema

     (PC= ELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.

     Jun= e 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED<= /span>

     STA= NDARD) (DOI: 10.17487/RFC4104)

 

8328 Policy-Based Management= Framework for the Simplified Use of Policy

     Abs= tractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis,<= /span>

     M. = Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML)

     (St= atus: INFORMATIONAL) (DOI: 10.17487/RFC8328)

 

WGs/RGs that at least partia= lly related to policy-based management:

 

- Simplified Use of Policy A= bstractions WG (supa) (2015 - 2017)

 

- Policy Framework WG (polic= y) (1998 - 2004)

 

- Resource Allocation Protoc= ol WG (rap) (1997 - 2005)

 

- Distributed Management WG = (disman) (1996 - 2006)

 

- Services Management RG (sm= rg) (2019? - 2001?)

 

- Network Management RG (nmr= g)

 

  - draft-clemm-nmrg-di= st-intent (2017-2019)

  - draft-irtf-nmrg-ibn= -concepts-definitions-02.txt (2019-2020)

 

Other resources:<= /span>

 

- https://en.wikipedia.= org/wiki/Policy-based_management

 

- https://www.youtube.c= om/watch?v=3DE_v-of582xg

 

- Boutaba, R. and I. Aib, &q= uot;Policy-Based Management: A

  Historical Perspectiv= e". Journal of Network and Systems

  Management (JNSM), Sp= ringer, Vol. 15 (4), December 2007.

  https://doi.org/10.10= 07/s10922-007-9083-8

 

- Pavlou, G., "On the E= volution of Management Approaches, Frameworks

  and Protocols: A Hist= orical Perspective". Journal of Network and

  Systems Management (J= NSM), Springer, Vol. 15 (4), December 2007.

  https://doi.org/10.10= 07/s10922-007-9082-9

 

- Strassner, J., "Polic= y-Based Network Management: Solutions for the

  Next Generation"= , Morgan Kaufmann, December 2003.

 

 

On Tue, Dec 29, 2020 at 04:2= 6:12PM -0000, Adrian Farrel wrote:

> Hi Juergen,<= /span>

>

> What you say about lear= ning lessons from the past is wise and valuable.

>

> Sadly (well, it's a goo= d thing, really) we have new people in the IETF

> and the memory of event= s over the last 20 years are not immediately

> accessible to them. Oth= ers, who are old and grey, have been around

> that long but were not = necessarily involved in previous ECA discussions.

>

> Since "intent-base= d networking" is a big thing once again (see recent

> reports of acquisitions= in this sector) the excitement about ECA may

> be forgiven, but it wou= ld help to ground the discussions if those who

> can remember previous e= fforts would share their experiences or at

> least some pointers.

>

> Best,=

> Adrian

>

> -----Original Message--= ---

> From: netmod <netmod-bounces@ietf.org> On Behalf Of Juergen

> Schoenwaelder

> Sent: 23 December 2020 = 18:09

> To: Andy Bierman <andy@yumaworks.com>

> Cc: NetMod WG Chairs &l= t;netmod-chairs@ietf.org>; NETMOD Group

> <netmo= d@ietf.org>

> Subject: Re: [netmod] A= doption poll for draft-wwx-netmod-event-yang-10

>

> On Wed, Dec 23, 2020 at= 07:05:44AM -0800, Andy Bierman wrote:

> > On Wed, Dec 23, 20= 20 at 3:14 AM tom petch <ietfc@btconnect.com> wrote:

> > =

> > > From: netmod = <netmod-bounces@ietf.org> on behalf = of Dhruv Dhody <

> > > dhruv.ietf@gmail.com<= /span>>

> > > Sent: 21 Dece= mber 2020 17:12

> > >

> > > Hi Lou, WG,

> > >

> > > I find the mo= tivation in the Introduction to be focused on ECA at

> > > the network d= evices (with all the talk about issues with

> > > Centralized n= etwork management).

> > >

> > > I see the val= ue of ECA on the controller as well, say a customer

> > > network contr= oller or an orchestrator can set the ECA on a central

> > > controller (r= eference ACTN in TEAS WG). Perhaps you would consider

> > > adding a sent= ence to describe this as well. The client-server

> > > terminology i= n the rest of the document covers it already.

> > >

> > > And I do see = value in this and support adoption.

> > >

> > > <tp>

> > > My take is th= at the I-D is unclear on what ECA is.

> > >

> > > ECA has been = worked on in at least two IETF WG AFAICT.  It cropped

> > > up in I2RS bu= t as I recall, it was along the lines of 'This is

> > > ECA'  'N= o It is not'  'Yes it is' which gave me the impression

> > > that ECA is n= ot a well-defined, or well-understood, term.

> > >

> > > More recently= , I2NSF have produced a YANG capability-data-model

> > > which is=

> > > 55 pages of E= CA.  Lacking a definition in this netmod I-D, I am

> > > unclear what = the relationship is between the I2NSF I-D and the

> > > netmod I-D,

> whether

> > > or not they a= re using ECA in the same sense.

> > >

> > >

> > Hi Tom,=

> > =

> > It usually helps t= o agree on the problem-space before focusing on

> > the solution-space= .

> > ECA seems like a m= ethodology (ala MVC) more than anything else.

> > The problem statem= ent seems to be that some client tasks need to be

> handled

> > on the<= /span>

> > server using ECA m= ethodology, instead of on the client.

> > Which tasks? Seems= to be any task of arbitrary purpose or complexity.

> > And now the scope = is supposed to include controllers (just another

> client),

> > so the problem-stm= t

> > is even less clear= .

> > =

> > The traditional ap= proach is to pick specific client tasks to move to

> > the server.

> > The example of det= ecting and reporting route-flaps has been used.

> > (No ECA example of= this complexity has been provided yet).

> > The traditional ap= proach would be to write a route-flap-detection

> > YANG module with s= ome configuration, monitoring data, and

> > notification event= s.

> > =

> > The generalized ap= proach is likely to be extremely complex to

> > standardize and im= plement.

> ><= /p>

>

> ECA work has a long 20&= #43; year tradition in the IETF and several

> specifications have bee= n published over the years by various working

> groups. As far as I can= tell, none of them got traction in terms of

> signifiant deployment o= f interoperable implementations.

>

> I would have hoped that= the next iteration of ECA work would have

> started with a deep ref= lection about why all the previous attempts

> failed to gain traction= and some genuine insights how to design things

> differently in order to= improve the likelihood to have impact.

>

> /js

>

> --

> Juergen Schoenwaelder&n= bsp;          Jacobs Universit= y Bremen gGmbH

> Phone: +49 421 200 = 3587         Campus Ring 1 | 28759 = Bremen | Germany

> Fax:   +4= 9 421 200 3103         <https://www.jacobs-university.de/>

>

> _______________________= ________________________

> netmod mailing list

> netmod@ie= tf.org

> https://www.ietf.org/= mailman/listinfo/netmod

>

 

--

Juergen Schoenwaelder &= nbsp;         Jacobs University Bre= men gGmbH

Phone: +49 421 200 3587&= nbsp;        Campus Ring 1 | 28759 Breme= n | Germany

Fax:   +49 421= 200 3103         <https://www.jacobs-university.de/>

 

____________________________= ___________________

netmod mailing list

netmod@ietf.or= g

https://www.ietf.org/mailman/listinfo/netmod<= /span>

 

--_000_B8F9A780D330094D99AF023C5877DABAADE4F3CDdggeml511mbschi_-- From nobody Wed Mar 10 00:25:33 2021 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 291053A1EF3 for ; Wed, 10 Mar 2021 00:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wdTZ8LA5_11S for ; Wed, 10 Mar 2021 00:25:28 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA093A1EF2 for ; Wed, 10 Mar 2021 00:25:27 -0800 (PST) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwPgz4zcpz67sn1; Wed, 10 Mar 2021 16:02:39 +0800 (CST) Received: from fraeml708-chm.china.huawei.com (10.206.15.36) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:08:36 +0100 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 10 Mar 2021 09:08:36 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.181]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0513.000; Wed, 10 Mar 2021 16:08:32 +0800 From: Qin Wu To: Juergen Schoenwaelder , "'NETMOD Group'" Thread-Topic: ECA Policy: When to detect and resolve policy conflicts? Thread-Index: AdcVg3g45rpKy13fRu2py1vAM+lobw== Date: Wed, 10 Mar 2021 08:08:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADE4F3E0dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] ECA Policy: When to detect and resolve policy conflicts? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 08:25:32 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADE4F3E0dggeml511mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEp1ZXJnZW46DQoNCkZyb20gRUNBIFBvbGljeSBpbmplY3RlZCBpbnRvIHRoZSBuZXR3b3Jr IGRldmljZS9ORVRDT05GIHNlcnZlciwgdG8gRUNBIHNlcnZpY2UgbG9naWMgZXhlY3V0aW9uLCBp dCBjb21wcmlzZXMgb2YNCg0KMS4gICAgICAgRXh0cmFjdCBzdGFuZGFyZCBwb2xpY3kgdmFyaWFi bGVzIGZyb20gRXZlbnQNCg0KMi4gICAgICAgTWFwcGluZyBQb2xpY3kgdmFyaWFibGUgaW50byBY UEFUSCB2YXJpYWJsZXMNCg0KMy4gICAgICAgRUNBIFhQQVRIIEV2YWx1YXRpb24NCg0KNC4gICAg ICAgRUNBIEFjdGlvbiBFeGVjdXRpb24NCg0KRm91ciBwaGFzZSwgd2UgdGhpbmsgcG9saWN5IGNv bmZsaWN0IG1heSBoYXBwZW4gaW4gdGhlIHBoYXNlIG9mIEVDQSBYUEFUSCBFdmFsdWF0aW9uIG9y IEVDQSBBY3Rpb24gRXhlY3V0aW9uIHBoYXNlLA0KDQpJbiBib3RoIHBoYXNlcywgaWYgUG9saWN5 IGNvbmZsaWN0IGlzIGRldGVjdGVkLCB0aGUgRUNBIGV4Y2VwdGlvbiB3aWxsIGJlIGxvZ2dlZCBh bmQgaW5mb3JtIHRvIHRoZSBsb2NhbCBtYW5hZ2VtZW50IGZ1bmN0aW9uLg0KDQoNCg0KSW4gYWRk aXRpb24sIFBvbGljeSBjb25mbGljdCBjYW4gYWxzbyBiZSBkZXRlY3RlZCBpbiB0aGUgUG9saWN5 IGRlc2lnbi9kZWZpbml0aW9uIHN0YWdlLg0KDQoNCg0KTGFzdCwgd2UgYWxzbyBpbnRyb2R1Y2Ug RUNBIHBvbGljeSB2ZXJpZmljYXRpb24gZnVuY3Rpb24sIGkuZS4sIHVzZSBEaWFnbm9zdGljIGV2 ZW50IHRvIGRlYnVnIHRoZSBwb2xpY3kgY29uZmxpY3QNCg0KYmVmb3JlIHRoZSBwb2xpY3kgY2Fu IGJlIGVuZm9yY2VkIGluIHRoZSBuZXR3b3JrIGRldmljZS4NCg0KDQoNCi1RaW4gKG9uIGJlaGFs ZiBvZiBhdXRob3JzKQ0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWls dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVlcmdlbiBTY2hvZW53YWVsZGVyDQq3 osvNyrG85DogMjAyMMTqMTLUwjMwyNUgMjo1Ng0KytW8/sjLOiBBZHJpYW4gRmFycmVsIDxhZHJp YW5Ab2xkZG9nLmNvLnVrPg0Ks63LzTogJ05FVE1PRCBHcm91cCcgPG5ldG1vZEBpZXRmLm9yZz4N Ctb3zOI6IFJlOiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC13d3gtbmV0bW9kLWV2 ZW50LXlhbmctMTANCg0KDQoNCkFkcmlhbiwNCg0KDQoNCnNvbWUga2V5IGlzc3VlcyB3aGVuIGl0 IGNvbWVzIHRvIHBvbGljeS1iYXNlZCBtYW5hZ2VtZW50IHN5c3RlbXM6DQoNCg0KDQotIFdoYXQg aXMgYW4gYWRlcXVhdGUgYWJzdHJhY3Rpb24gbGV2ZWwgdG8gZXhwcmVzcyBwb2xpY2llcyBhbmQg aW50ZW50Pw0KDQoNCg0KICAgVGhpcyBxdWVzdGlvbiBoYXMgbm8gc2ltcGxlIGFuc3dlci4gSSBi ZWxpZXZlIHBvbGljaWVzIG5lZWQgdG8gYmUNCg0KICAgcmVhZGFibGUgYW5kIGhlbmNlIHRoZXkg bmVlZCB0byBiZSBleHByZXNzZWQgYXQgYSBoaWdoIGxldmVsIG9mDQoNCiAgIGFic3RyYWN0aW9u IGFuZCBpbiBhIHN1aXRhYmxlIF9sYW5ndWFnZV8uIEhpZ2gtbGV2ZWwgcG9saWN5DQoNCiAgIGV4 cHJlc3Npb24gbWF5IGJlIGNvbXBpbGVkIGRvd24gaW50byBtb3JlIHZlcmJvc2UgcHJpbWl0aXZl DQoNCiAgIHJlcHJlc2VudGF0aW9ucyB0aGF0IGFyZSBjbG9zZXIgdG8gYW4gZXhlY3V0aW9uIGFi c3RyYWN0aW9uLiBBDQoNCiAgIGNvbW1vbiBwaXRmYWxsIGlzIHRvIHN0YXJ0IHNvbWV3aGVyZSBp biB0aGUgbWlkZGxlIG9mIHNldmVyYWwNCg0KICAgbGF5ZXJzIG9mIGFic3RyYWN0aW9uIGFuZCB0 aGVuIGdldHRpbmcgc3R1Y2sgd2l0aCBzb21ldGhpbmcgYXdrd2FyZA0KDQogICB0byBwdXQgYSBj bGVhbiBoaWdoZXIgbGF5ZXIgYWJzdHJhY3Qgb250byBhbmQgdG8gY29tcGlsZSB0aGluZ3MNCg0K ICAgZG93biB0byBfZWZmaWNpZW50XyBpbnN0cnVtZW50YXRpb25zLg0KDQoNCg0KLSBXaGVyZSBh cmUgcG9saWNpZXMgZXhlY3V0ZWQ/DQoNCg0KDQogICBUaGlzIGNhbiByYW5nZSBmcm9tIGEgbG9n aWNhbGx5IGNlbnRyYWxpemVkIHBvbGljeSBleGVjdXRpb24NCg0KICAgZW5naW5lLCB3aGljaCBp cyBwYXJ0IG9mIHdoYXQgcGVvcGxlIGNhbGwgYW4gb3JjaGVzdHJhdG9yIHRoZXNlDQoNCiAgIGRh eXMsIHRvIGZ1bGx5IGRpc3RyaWJ1dGVkIHBvbGljeSBleGVjdXRpb24gbW9kZWxzLiBJbiByZWFs aXR5LCB5b3UNCg0KICAgbGlrZWx5IHdhbnQgdG8gZGlzdHJpYnV0ZSBmdW5jdGlvbnMgZHluYW1p Y2FsbHkgYnV0IHRoaXMgbWFrZXMNCg0KICAgc29sdXRpb25zIHRlY2huaWNhbGx5IG11Y2ggbW9y ZSBjb21wbGljYXRlZC4gR2l2ZW4gdG9kYXkncyBzY2FsYWJsZQ0KDQogICBjb21wdXRpbmcgYW5k IG5ldHdvcmtpbmcgY2FwYWJpbGl0aWVzLCBsb2dpY2FsbHkgY2VudHJhbGl6ZWQNCg0KICAgc29s dXRpb25zIGFyZSBvbiB0aGUgcmlzZSBhbmQgaGF2ZSByZXBsYWNlZCB0aGUgZGlzdHJpYnV0ZWQN Cg0KICAgYXBwcm9hY2hlcyBvZiB0aGUgOTBzLg0KDQoNCg0KLSBXaGVuIHRvIGRldGVjdCBhbmQg cmVzb2x2ZSBwb2xpY3kgY29uZmxpY3RzPw0KDQoNCg0KICAgRGV0ZWN0aW5nIGFuZCByZXNvbHZp bmcgY29uZmxpY3RzIGluIGxhcmdlciBjb2xsZWN0aW9ucyBvZiBwb2xpY2llcw0KDQogICBpcyBu b24tdHJpdmlhbC4gVGhpcyBpbmNsdWRlcyBwcm9ibGVtcyByYW5naW5nIGZyb20gbWljcm8gdGlt ZXNjYWxlDQoNCiAgIGF0b21pY2l0eSBpc3N1ZXMgdG8gbGFyZ2VyIHRpbWVzY2FsZSBzdGFiaWxp dHkgaXNzdWVzIChpbnRlcmFjdGluZw0KDQogICBwb2xpY3kgY29udHJvbCBsb29wcykuIElmIHBv bGljeSBleGVjdXRpb24gaXMgZGlzdHJpYnV0ZWQgKG9yIHRoZQ0KDQogICBldmVudCAvIGluZm9y bWF0aW9uIHNvdXJjZXMgYXJlIGRpc3RyaWJ1dGVkKSwgdGhpcyB1bHRpbWF0ZWx5DQoNCiAgIHJl c29sdmVzIHRvIHByb2JsZW1zIHN1Y2ggYXMgdGFraW5nIGNvbnNpc3RlbnQgc25hcHNob3RzIG9y IGZpbmRpbmcNCg0KICAgd2F5cyB0byB3b3JrIHdpdGggaW5jb25zaXN0ZW50IG9ic2VydmF0aW9u cyBvZiBhIGRpc3RyaWJ1dGVkIHN5c3RlbQ0KDQogICB0aGF0IGFyZSBndWFyYW50ZWVkIHRvIGNv bnZlcmdlIHRvIHN0YWJsZSBzdGF0ZXMgKHNlbGYtc3RhYmlsaXppbmcNCg0KICAgYWxnb3JpdGht cykuDQoNCg0KDQotIFdobyBpcyBpbnRlcmVzdGVkIGluIGludGVyb3BlcmFibGUgcG9saWN5IHJl cHJlc2VudGF0aW9ucyAvIGxhbmd1YWdlcz8NCg0KDQoNCiAgIFRoZSBJRVRGIGlzIGFib3V0IGlu dGVyb3BlcmFiaWxpdHkuIFdoYXQgYXJlIHRoZSBidXNpbmVzcyBtb2RlbHMNCg0KICAgdGhhdCBw dXNoIGZvciBpbnRlcm9wZXJhYmxlIHBvbGljeSBiYXNlZCBtYW5hZ2VtZW50IHN0YW5kYXJkcz8g V2hvDQoNCiAgIGJlbmVmaXRzIGZyb20gaGF2aW5nIGFuIGludGVyb3BlcmFibGUgc3RhbmRhcmQg YW5kIGhvdyBtdWNoIGVmZm9ydA0KDQogICBhcmUgb3JnYW5pemF0aW9ucyB3aWxsaW5nIHRvIGlu dmVzdCBpbnRvIGVuZ2luZWVyaW5nIGEgcmVhc29uYWJsZQ0KDQogICBzb2x1dGlvbiBhZGRyZXNz aW5nIHRoZSBvdGhlciAobm9uLXRyaXZpYWwpIHF1ZXN0aW9ucyByYWlzZWQgYWJvdmU/DQoNCiAg IFdpbGwgdGhleSBiZSBpbXBsZW1lbnRpbmcgdGhlIHNvbHV0aW9uIGluIHRoZWlyIHByb2R1Y3Rz Pw0KDQoNCg0KTXkgcG9zaXRpb24gaXMgdGhhdCB0aGVyZSBhcmUgd2F5IHRvbyBtYW55IGRpZmZp Y3VsdCB0ZWNobmljYWwgaXNzdWVzIHRvIHJlc29sdmUgZm9yIHRoaXMgd29yayB0byBiZSB2aWFi bGUgZm9yIHRoZSBJRVRGLiBJbnN0ZWFkLCBJIHN1Z2dlc3QgdGhhdCBwZW9wbGUgZ28gYW5kIHdv cmsgb3V0IHNvbHV0aW9ucyBhbmQgb25jZSB0aGUgc2lsdmVyIGJ1bGxldCBoYXMgYmVlbiBmb3Vu ZCwgYnJpbmcgaXQgdG8gdGhlIElFVEYuIChIaXN0b3JpY2FsbHksIGFsbCBhdHRlbXB0cyB0byBj YXN0IHBvbGljaWVzIGludG8gZXhpc3RpbmcgZGF0YSBtb2RlbHMgc3VjaCBhcyBNSUIgbW9kdWxl cyBvciBMREFQIHNjaGVtYSBsZWQgdG8gc29tZXRoaW5nIGF3a3dhcmQgYW5kIHVudXNhYmxlLiBJ IGJlbGlldmUgWUFORyBtb2R1bGVzIGFyZSBubw0KDQpkaWZmZXJlbnQuKQ0KDQoNCg0KL2pzDQoN Cg0KDQpTb21lIHJlbGV2YW50IFJGQ3MgKHRoZXJlIG1heSBiZSBtb3JlKToNCg0KDQoNCjMwNTIg U2VydmljZSBNYW5hZ2VtZW50IEFyY2hpdGVjdHVyZXMgSXNzdWVzIGFuZCBSZXZpZXcuIE0uIEVk ZXIsIFMuIE5hZy4NCg0KICAgICBKYW51YXJ5IDIwMDEuIChGb3JtYXQ6IFRYVCwgSFRNTCkgKFN0 YXR1czogSU5GT1JNQVRJT05BTCkgKERPSToNCg0KICAgICAxMC4xNzQ4Ny9SRkMzMDUyKQ0KDQoN Cg0KMzA4NCBDT1BTIFVzYWdlIGZvciBQb2xpY3kgUHJvdmlzaW9uaW5nIChDT1BTLVBSKS4gSy4g Q2hhbiwgSi4gU2VsaWdzb24sDQoNCiAgICAgRC4gRHVyaGFtLCBTLiBHYWksIEsuIE1jQ2xvZ2hy aWUsIFMuIEhlcnpvZywgRi4gUmVpY2htZXllciwgUi4NCg0KICAgICBZYXZhdGthciwgQS4gU21p dGguIE1hcmNoIDIwMDEuIChGb3JtYXQ6IFRYVCwgSFRNTCkgKFN0YXR1czoNCg0KICAgICBISVNU T1JJQykgKERPSTogMTAuMTc0ODcvUkZDMzA4NCkNCg0KDQoNCjMxNTkgU3RydWN0dXJlIG9mIFBv bGljeSBQcm92aXNpb25pbmcgSW5mb3JtYXRpb24gKFNQUEkpLiBLLiBNY0Nsb2docmllLA0KDQog ICAgIE0uIEZpbmUsIEouIFNlbGlnc29uLCBLLiBDaGFuLCBTLiBIYWhuLCBSLiBTYWhpdGEsIEEu IFNtaXRoLCBGLg0KDQogICAgIFJlaWNobWV5ZXIuIEF1Z3VzdCAyMDAxLiAoRm9ybWF0OiBUWFQs IEhUTUwpIChTdGF0dXM6IEhJU1RPUklDKQ0KDQogICAgIChET0k6IDEwLjE3NDg3L1JGQzMxNTkp DQoNCg0KDQozMzE4IEZyYW1ld29yayBQb2xpY3kgSW5mb3JtYXRpb24gQmFzZS4gUi4gU2FoaXRh LCBFZC4sIFMuIEhhaG4sIEsuIENoYW4sDQoNCiAgICAgSy4gTWNDbG9naHJpZS4gTWFyY2ggMjAw My4gKEZvcm1hdDogVFhULCBIVE1MKSAoU3RhdHVzOiBISVNUT1JJQykNCg0KICAgICAoRE9JOiAx MC4xNzQ4Ny9SRkMzMzE4KQ0KDQoNCg0KMzQ2MCBQb2xpY3kgQ29yZSBJbmZvcm1hdGlvbiBNb2Rl bCAoUENJTSkgRXh0ZW5zaW9ucy4gQi4gTW9vcmUsIEVkLi4NCg0KICAgICBKYW51YXJ5IDIwMDMu IChGb3JtYXQ6IFRYVCwgSFRNTCkgKFVwZGF0ZXMgUkZDMzA2MCkgKFN0YXR1czoNCg0KICAgICBQ Uk9QT1NFRCBTVEFOREFSRCkgKERPSTogMTAuMTc0ODcvUkZDMzQ2MCkNCg0KDQoNCjM2NDQgUG9s aWN5IFF1YWxpdHkgb2YgU2VydmljZSAoUW9TKSBJbmZvcm1hdGlvbiBNb2RlbC4gWS4gU25pciwg WS4NCg0KICAgICBSYW1iZXJnLCBKLiBTdHJhc3NuZXIsIFIuIENvaGVuLCBCLiBNb29yZS4gTm92 ZW1iZXIgMjAwMy4gKEZvcm1hdDoNCg0KICAgICBUWFQsIEhUTUwpIChTdGF0dXM6IFBST1BPU0VE IFNUQU5EQVJEKSAoRE9JOiAxMC4xNzQ4Ny9SRkMzNjQ0KQ0KDQoNCg0KMzE5OCBUZXJtaW5vbG9n eSBmb3IgUG9saWN5LUJhc2VkIE1hbmFnZW1lbnQuIEEuIFdlc3RlcmluZW4sIEouDQoNCiAgICAg U2Nobml6bGVpbiwgSi4gU3RyYXNzbmVyLCBNLiBTY2hlcmxpbmcsIEIuIFF1aW5uLCBTLiBIZXJ6 b2csIEEuDQoNCiAgICAgSHV5bmgsIE0uIENhcmxzb24sIEouIFBlcnJ5LCBTLiBXYWxkYnVzc2Vy LiBOb3ZlbWJlciAyMDAxLiAoRm9ybWF0Og0KDQogICAgIFRYVCwgSFRNTCkgKFN0YXR1czogSU5G T1JNQVRJT05BTCkgKERPSTogMTAuMTc0ODcvUkZDMzE5OCkNCg0KDQoNCjQwMTEgUG9saWN5IEJh c2VkIE1hbmFnZW1lbnQgTUlCLiBTLiBXYWxkYnVzc2VyLCBKLiBTYXBlcmlhLCBULiBIb25nYWwu DQoNCiAgICAgTWFyY2ggMjAwNS4gKEZvcm1hdDogVFhULCBIVE1MKSAoU3RhdHVzOiBQUk9QT1NF RCBTVEFOREFSRCkgKERPSToNCg0KICAgICAxMC4xNzQ4Ny9SRkM0MDExKQ0KDQoNCg0KNDEwNCBQ b2xpY3kgQ29yZSBFeHRlbnNpb24gTGlnaHR3ZWlnaHQgRGlyZWN0b3J5IEFjY2VzcyBQcm90b2Nv bCBTY2hlbWENCg0KICAgICAoUENFTFMpLiBNLiBQYW5hLCBFZC4sIEEuIFJleWVzLCBBLiBCYXJi YSwgRC4gTW9yb24sIE0uIEJydW5uZXIuDQoNCiAgICAgSnVuZSAyMDA1LiAoRm9ybWF0OiBUWFQs IEhUTUwpIChVcGRhdGVzIFJGQzM3MDMpIChTdGF0dXM6IFBST1BPU0VEDQoNCiAgICAgU1RBTkRB UkQpIChET0k6IDEwLjE3NDg3L1JGQzQxMDQpDQoNCg0KDQo4MzI4IFBvbGljeS1CYXNlZCBNYW5h Z2VtZW50IEZyYW1ld29yayBmb3IgdGhlIFNpbXBsaWZpZWQgVXNlIG9mIFBvbGljeQ0KDQogICAg IEFic3RyYWN0aW9ucyAoU1VQQSkuIFcuIExpdSwgQy4gWGllLCBKLiBTdHJhc3NuZXIsIEcuIEth cmFnaWFubmlzLA0KDQogICAgIE0uIEtseXVzLCBKLiBCaSwgWS4gQ2hlbmcsIEQuIFpoYW5nLiBN YXJjaCAyMDE4LiAoRm9ybWF0OiBUWFQsIEhUTUwpDQoNCiAgICAgKFN0YXR1czogSU5GT1JNQVRJ T05BTCkgKERPSTogMTAuMTc0ODcvUkZDODMyOCkNCg0KDQoNCldHcy9SR3MgdGhhdCBhdCBsZWFz dCBwYXJ0aWFsbHkgcmVsYXRlZCB0byBwb2xpY3ktYmFzZWQgbWFuYWdlbWVudDoNCg0KDQoNCi0g U2ltcGxpZmllZCBVc2Ugb2YgUG9saWN5IEFic3RyYWN0aW9ucyBXRyAoc3VwYSkgKDIwMTUgLSAy MDE3KQ0KDQoNCg0KLSBQb2xpY3kgRnJhbWV3b3JrIFdHIChwb2xpY3kpICgxOTk4IC0gMjAwNCkN Cg0KDQoNCi0gUmVzb3VyY2UgQWxsb2NhdGlvbiBQcm90b2NvbCBXRyAocmFwKSAoMTk5NyAtIDIw MDUpDQoNCg0KDQotIERpc3RyaWJ1dGVkIE1hbmFnZW1lbnQgV0cgKGRpc21hbikgKDE5OTYgLSAy MDA2KQ0KDQoNCg0KLSBTZXJ2aWNlcyBNYW5hZ2VtZW50IFJHIChzbXJnKSAoMjAxOT8gLSAyMDAx PykNCg0KDQoNCi0gTmV0d29yayBNYW5hZ2VtZW50IFJHIChubXJnKQ0KDQoNCg0KICAtIGRyYWZ0 LWNsZW1tLW5tcmctZGlzdC1pbnRlbnQgKDIwMTctMjAxOSkNCg0KICAtIGRyYWZ0LWlydGYtbm1y Zy1pYm4tY29uY2VwdHMtZGVmaW5pdGlvbnMtMDIudHh0ICgyMDE5LTIwMjApDQoNCg0KDQpPdGhl ciByZXNvdXJjZXM6DQoNCg0KDQotIGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1BvbGlj eS1iYXNlZF9tYW5hZ2VtZW50DQoNCg0KDQotIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNo P3Y9RV92LW9mNTgyeGcNCg0KDQoNCi0gQm91dGFiYSwgUi4gYW5kIEkuIEFpYiwgIlBvbGljeS1C YXNlZCBNYW5hZ2VtZW50OiBBDQoNCiAgSGlzdG9yaWNhbCBQZXJzcGVjdGl2ZSIuIEpvdXJuYWwg b2YgTmV0d29yayBhbmQgU3lzdGVtcw0KDQogIE1hbmFnZW1lbnQgKEpOU00pLCBTcHJpbmdlciwg Vm9sLiAxNSAoNCksIERlY2VtYmVyIDIwMDcuDQoNCiAgaHR0cHM6Ly9kb2kub3JnLzEwLjEwMDcv czEwOTIyLTAwNy05MDgzLTgNCg0KDQoNCi0gUGF2bG91LCBHLiwgIk9uIHRoZSBFdm9sdXRpb24g b2YgTWFuYWdlbWVudCBBcHByb2FjaGVzLCBGcmFtZXdvcmtzDQoNCiAgYW5kIFByb3RvY29sczog QSBIaXN0b3JpY2FsIFBlcnNwZWN0aXZlIi4gSm91cm5hbCBvZiBOZXR3b3JrIGFuZA0KDQogIFN5 c3RlbXMgTWFuYWdlbWVudCAoSk5TTSksIFNwcmluZ2VyLCBWb2wuIDE1ICg0KSwgRGVjZW1iZXIg MjAwNy4NCg0KICBodHRwczovL2RvaS5vcmcvMTAuMTAwNy9zMTA5MjItMDA3LTkwODItOQ0KDQoN Cg0KLSBTdHJhc3NuZXIsIEouLCAiUG9saWN5LUJhc2VkIE5ldHdvcmsgTWFuYWdlbWVudDogU29s dXRpb25zIGZvciB0aGUNCg0KICBOZXh0IEdlbmVyYXRpb24iLCBNb3JnYW4gS2F1Zm1hbm4sIERl Y2VtYmVyIDIwMDMuDQoNCg0KDQoNCg0KT24gVHVlLCBEZWMgMjksIDIwMjAgYXQgMDQ6MjY6MTJQ TSAtMDAwMCwgQWRyaWFuIEZhcnJlbCB3cm90ZToNCg0KPiBIaSBKdWVyZ2VuLA0KDQo+DQoNCj4g V2hhdCB5b3Ugc2F5IGFib3V0IGxlYXJuaW5nIGxlc3NvbnMgZnJvbSB0aGUgcGFzdCBpcyB3aXNl IGFuZCB2YWx1YWJsZS4NCg0KPg0KDQo+IFNhZGx5ICh3ZWxsLCBpdCdzIGEgZ29vZCB0aGluZywg cmVhbGx5KSB3ZSBoYXZlIG5ldyBwZW9wbGUgaW4gdGhlIElFVEYNCg0KPiBhbmQgdGhlIG1lbW9y eSBvZiBldmVudHMgb3ZlciB0aGUgbGFzdCAyMCB5ZWFycyBhcmUgbm90IGltbWVkaWF0ZWx5DQoN Cj4gYWNjZXNzaWJsZSB0byB0aGVtLiBPdGhlcnMsIHdobyBhcmUgb2xkIGFuZCBncmV5LCBoYXZl IGJlZW4gYXJvdW5kDQoNCj4gdGhhdCBsb25nIGJ1dCB3ZXJlIG5vdCBuZWNlc3NhcmlseSBpbnZv bHZlZCBpbiBwcmV2aW91cyBFQ0EgZGlzY3Vzc2lvbnMuDQoNCj4NCg0KPiBTaW5jZSAiaW50ZW50 LWJhc2VkIG5ldHdvcmtpbmciIGlzIGEgYmlnIHRoaW5nIG9uY2UgYWdhaW4gKHNlZSByZWNlbnQN Cg0KPiByZXBvcnRzIG9mIGFjcXVpc2l0aW9ucyBpbiB0aGlzIHNlY3RvcikgdGhlIGV4Y2l0ZW1l bnQgYWJvdXQgRUNBIG1heQ0KDQo+IGJlIGZvcmdpdmVuLCBidXQgaXQgd291bGQgaGVscCB0byBn cm91bmQgdGhlIGRpc2N1c3Npb25zIGlmIHRob3NlIHdobw0KDQo+IGNhbiByZW1lbWJlciBwcmV2 aW91cyBlZmZvcnRzIHdvdWxkIHNoYXJlIHRoZWlyIGV4cGVyaWVuY2VzIG9yIGF0DQoNCj4gbGVh c3Qgc29tZSBwb2ludGVycy4NCg0KPg0KDQo+IEJlc3QsDQoNCj4gQWRyaWFuDQoNCj4NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9m IEp1ZXJnZW4NCg0KPiBTY2hvZW53YWVsZGVyDQoNCj4gU2VudDogMjMgRGVjZW1iZXIgMjAyMCAx ODowOQ0KDQo+IFRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tPj4NCg0KPiBDYzogTmV0TW9kIFdHIENoYWlycyA8bmV0bW9kLWNoYWly c0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4+OyBORVRNT0QgR3JvdXAN Cg0KPiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KDQo+IFN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC13d3gtbmV0bW9kLWV2ZW50 LXlhbmctMTANCg0KPg0KDQo+IE9uIFdlZCwgRGVjIDIzLCAyMDIwIGF0IDA3OjA1OjQ0QU0gLTA4 MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCg0KPiA+IE9uIFdlZCwgRGVjIDIzLCAyMDIwIGF0IDM6 MTQgQU0gdG9tIHBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0BidGNvbm5l Y3QuY29tPj4gd3JvdGU6DQoNCj4gPg0KDQo+ID4gPiBGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBv ZiBEaHJ1diBEaG9keSA8DQoNCj4gPiA+IGRocnV2LmlldGZAZ21haWwuY29tPG1haWx0bzpkaHJ1 di5pZXRmQGdtYWlsLmNvbT4+DQoNCj4gPiA+IFNlbnQ6IDIxIERlY2VtYmVyIDIwMjAgMTc6MTIN Cg0KPiA+ID4NCg0KPiA+ID4gSGkgTG91LCBXRywNCg0KPiA+ID4NCg0KPiA+ID4gSSBmaW5kIHRo ZSBtb3RpdmF0aW9uIGluIHRoZSBJbnRyb2R1Y3Rpb24gdG8gYmUgZm9jdXNlZCBvbiBFQ0EgYXQN Cg0KPiA+ID4gdGhlIG5ldHdvcmsgZGV2aWNlcyAod2l0aCBhbGwgdGhlIHRhbGsgYWJvdXQgaXNz dWVzIHdpdGgNCg0KPiA+ID4gQ2VudHJhbGl6ZWQgbmV0d29yayBtYW5hZ2VtZW50KS4NCg0KPiA+ ID4NCg0KPiA+ID4gSSBzZWUgdGhlIHZhbHVlIG9mIEVDQSBvbiB0aGUgY29udHJvbGxlciBhcyB3 ZWxsLCBzYXkgYSBjdXN0b21lcg0KDQo+ID4gPiBuZXR3b3JrIGNvbnRyb2xsZXIgb3IgYW4gb3Jj aGVzdHJhdG9yIGNhbiBzZXQgdGhlIEVDQSBvbiBhIGNlbnRyYWwNCg0KPiA+ID4gY29udHJvbGxl ciAocmVmZXJlbmNlIEFDVE4gaW4gVEVBUyBXRykuIFBlcmhhcHMgeW91IHdvdWxkIGNvbnNpZGVy DQoNCj4gPiA+IGFkZGluZyBhIHNlbnRlbmNlIHRvIGRlc2NyaWJlIHRoaXMgYXMgd2VsbC4gVGhl IGNsaWVudC1zZXJ2ZXINCg0KPiA+ID4gdGVybWlub2xvZ3kgaW4gdGhlIHJlc3Qgb2YgdGhlIGRv Y3VtZW50IGNvdmVycyBpdCBhbHJlYWR5Lg0KDQo+ID4gPg0KDQo+ID4gPiBBbmQgSSBkbyBzZWUg dmFsdWUgaW4gdGhpcyBhbmQgc3VwcG9ydCBhZG9wdGlvbi4NCg0KPiA+ID4NCg0KPiA+ID4gPHRw Pg0KDQo+ID4gPiBNeSB0YWtlIGlzIHRoYXQgdGhlIEktRCBpcyB1bmNsZWFyIG9uIHdoYXQgRUNB IGlzLg0KDQo+ID4gPg0KDQo+ID4gPiBFQ0EgaGFzIGJlZW4gd29ya2VkIG9uIGluIGF0IGxlYXN0 IHR3byBJRVRGIFdHIEFGQUlDVC4gIEl0IGNyb3BwZWQNCg0KPiA+ID4gdXAgaW4gSTJSUyBidXQg YXMgSSByZWNhbGwsIGl0IHdhcyBhbG9uZyB0aGUgbGluZXMgb2YgJ1RoaXMgaXMNCg0KPiA+ID4g RUNBJyAgJ05vIEl0IGlzIG5vdCcgICdZZXMgaXQgaXMnIHdoaWNoIGdhdmUgbWUgdGhlIGltcHJl c3Npb24NCg0KPiA+ID4gdGhhdCBFQ0EgaXMgbm90IGEgd2VsbC1kZWZpbmVkLCBvciB3ZWxsLXVu ZGVyc3Rvb2QsIHRlcm0uDQoNCj4gPiA+DQoNCj4gPiA+IE1vcmUgcmVjZW50bHksIEkyTlNGIGhh dmUgcHJvZHVjZWQgYSBZQU5HIGNhcGFiaWxpdHktZGF0YS1tb2RlbA0KDQo+ID4gPiB3aGljaCBp cw0KDQo+ID4gPiA1NSBwYWdlcyBvZiBFQ0EuICBMYWNraW5nIGEgZGVmaW5pdGlvbiBpbiB0aGlz IG5ldG1vZCBJLUQsIEkgYW0NCg0KPiA+ID4gdW5jbGVhciB3aGF0IHRoZSByZWxhdGlvbnNoaXAg aXMgYmV0d2VlbiB0aGUgSTJOU0YgSS1EIGFuZCB0aGUNCg0KPiA+ID4gbmV0bW9kIEktRCwNCg0K PiB3aGV0aGVyDQoNCj4gPiA+IG9yIG5vdCB0aGV5IGFyZSB1c2luZyBFQ0EgaW4gdGhlIHNhbWUg c2Vuc2UuDQoNCj4gPiA+DQoNCj4gPiA+DQoNCj4gPiBIaSBUb20sDQoNCj4gPg0KDQo+ID4gSXQg dXN1YWxseSBoZWxwcyB0byBhZ3JlZSBvbiB0aGUgcHJvYmxlbS1zcGFjZSBiZWZvcmUgZm9jdXNp bmcgb24NCg0KPiA+IHRoZSBzb2x1dGlvbi1zcGFjZS4NCg0KPiA+IEVDQSBzZWVtcyBsaWtlIGEg bWV0aG9kb2xvZ3kgKGFsYSBNVkMpIG1vcmUgdGhhbiBhbnl0aGluZyBlbHNlLg0KDQo+ID4gVGhl IHByb2JsZW0gc3RhdGVtZW50IHNlZW1zIHRvIGJlIHRoYXQgc29tZSBjbGllbnQgdGFza3MgbmVl ZCB0byBiZQ0KDQo+IGhhbmRsZWQNCg0KPiA+IG9uIHRoZQ0KDQo+ID4gc2VydmVyIHVzaW5nIEVD QSBtZXRob2RvbG9neSwgaW5zdGVhZCBvZiBvbiB0aGUgY2xpZW50Lg0KDQo+ID4gV2hpY2ggdGFz a3M/IFNlZW1zIHRvIGJlIGFueSB0YXNrIG9mIGFyYml0cmFyeSBwdXJwb3NlIG9yIGNvbXBsZXhp dHkuDQoNCj4gPiBBbmQgbm93IHRoZSBzY29wZSBpcyBzdXBwb3NlZCB0byBpbmNsdWRlIGNvbnRy b2xsZXJzIChqdXN0IGFub3RoZXINCg0KPiBjbGllbnQpLA0KDQo+ID4gc28gdGhlIHByb2JsZW0t c3RtdA0KDQo+ID4gaXMgZXZlbiBsZXNzIGNsZWFyLg0KDQo+ID4NCg0KPiA+IFRoZSB0cmFkaXRp b25hbCBhcHByb2FjaCBpcyB0byBwaWNrIHNwZWNpZmljIGNsaWVudCB0YXNrcyB0byBtb3ZlIHRv DQoNCj4gPiB0aGUgc2VydmVyLg0KDQo+ID4gVGhlIGV4YW1wbGUgb2YgZGV0ZWN0aW5nIGFuZCBy ZXBvcnRpbmcgcm91dGUtZmxhcHMgaGFzIGJlZW4gdXNlZC4NCg0KPiA+IChObyBFQ0EgZXhhbXBs ZSBvZiB0aGlzIGNvbXBsZXhpdHkgaGFzIGJlZW4gcHJvdmlkZWQgeWV0KS4NCg0KPiA+IFRoZSB0 cmFkaXRpb25hbCBhcHByb2FjaCB3b3VsZCBiZSB0byB3cml0ZSBhIHJvdXRlLWZsYXAtZGV0ZWN0 aW9uDQoNCj4gPiBZQU5HIG1vZHVsZSB3aXRoIHNvbWUgY29uZmlndXJhdGlvbiwgbW9uaXRvcmlu ZyBkYXRhLCBhbmQNCg0KPiA+IG5vdGlmaWNhdGlvbiBldmVudHMuDQoNCj4gPg0KDQo+ID4gVGhl IGdlbmVyYWxpemVkIGFwcHJvYWNoIGlzIGxpa2VseSB0byBiZSBleHRyZW1lbHkgY29tcGxleCB0 bw0KDQo+ID4gc3RhbmRhcmRpemUgYW5kIGltcGxlbWVudC4NCg0KPiA+DQoNCj4NCg0KPiBFQ0Eg d29yayBoYXMgYSBsb25nIDIwKyB5ZWFyIHRyYWRpdGlvbiBpbiB0aGUgSUVURiBhbmQgc2V2ZXJh bA0KDQo+IHNwZWNpZmljYXRpb25zIGhhdmUgYmVlbiBwdWJsaXNoZWQgb3ZlciB0aGUgeWVhcnMg YnkgdmFyaW91cyB3b3JraW5nDQoNCj4gZ3JvdXBzLiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgbm9u ZSBvZiB0aGVtIGdvdCB0cmFjdGlvbiBpbiB0ZXJtcyBvZg0KDQo+IHNpZ25pZmlhbnQgZGVwbG95 bWVudCBvZiBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCg0KPg0KDQo+IEkgd291bGQg aGF2ZSBob3BlZCB0aGF0IHRoZSBuZXh0IGl0ZXJhdGlvbiBvZiBFQ0Egd29yayB3b3VsZCBoYXZl DQoNCj4gc3RhcnRlZCB3aXRoIGEgZGVlcCByZWZsZWN0aW9uIGFib3V0IHdoeSBhbGwgdGhlIHBy ZXZpb3VzIGF0dGVtcHRzDQoNCj4gZmFpbGVkIHRvIGdhaW4gdHJhY3Rpb24gYW5kIHNvbWUgZ2Vu dWluZSBpbnNpZ2h0cyBob3cgdG8gZGVzaWduIHRoaW5ncw0KDQo+IGRpZmZlcmVudGx5IGluIG9y ZGVyIHRvIGltcHJvdmUgdGhlIGxpa2VsaWhvb2QgdG8gaGF2ZSBpbXBhY3QuDQoNCj4NCg0KPiAv anMNCg0KPg0KDQo+IC0tDQoNCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCg0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAg ICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQoNCj4gRmF4OiAg ICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0KDQo+DQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQoNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg0KPg0KDQoNCg0KLS0NCg0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAg ICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCg0KUGhvbmU6ICs0OSA0MjEgMjAw IDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KDQpG YXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVy c2l0eS5kZS8+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpuZXRtb2QgbWFpbGluZyBsaXN0DQoNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0K --_000_B8F9A780D330094D99AF023C5877DABAADE4F3E0dggeml511mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Juergen:

From ECA Policy injected int= o the network device/NETCONF server, to ECA service logic execution, it com= prises of

1= .   &= nbsp;   Extract standard policy= variables from Event

2= .   &= nbsp;   Mapping Policy variable= into XPATH variables

3= .   &= nbsp;   ECA XPATH Evaluation

4= .   &= nbsp;   ECA Action Execution

Four phase, we think policy = conflict may happen in the phase of ECA XPATH Evaluation or ECA Action Exec= ution phase,

In both phases, if Policy co= nflict is detected, the ECA exception will be logged and inform to the loca= l management function.

 

In addition, Policy conflict= can also be detected in the Policy design/definition stage.

 

Last, we also introduce ECA = policy verification function, i.e., use Diagnostic event to debug the polic= y conflict

before the policy can be enf= orced in the network device.

 

-Qin (on behalf of authors)<= o:p>

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: netmod [mailto:netmod-bounces@ietf.org] =B4=FA=B1=ED Juergen Schoenwaelder
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA12=D4=C230=C8=D5 2:56
=CA=D5=BC=FE=C8=CB: Adrian Farrel <adrian@olddog.co.uk>
=B3=AD=CB=CD: 'NETMOD Group' <netmod@ietf.org>
=D6=F7=CC=E2: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-1= 0

 

Adrian,

 

some key issues when it come= s to policy-based management systems:

 

- What is an adequate abstra= ction level to express policies and intent?

 

   This question h= as no simple answer. I believe policies need to be

   readable and he= nce they need to be expressed at a high level of

   abstraction and= in a suitable _language_. High-level policy

   expression may = be compiled down into more verbose primitive

   representations= that are closer to an execution abstraction. A

   common pitfall = is to start somewhere in the middle of several

   layers of abstr= action and then getting stuck with something awkward

   to put a clean = higher layer abstract onto and to compile things

   down to _effici= ent_ instrumentations.

 

- Where are policies execute= d?

 

   This can range = from a logically centralized policy execution

   engine, which i= s part of what people call an orchestrator these

   days, to fully = distributed policy execution models. In reality, you

   likely want to = distribute functions dynamically but this makes

   solutions techn= ically much more complicated. Given today's scalable

   computing and n= etworking capabilities, logically centralized

   solutions are o= n the rise and have replaced the distributed

   approaches of t= he 90s.

 

- When to detect and resolve= policy conflicts?

 

   Detecting and r= esolving conflicts in larger collections of policies

   is non-trivial.= This includes problems ranging from micro timescale

   atomicity issue= s to larger timescale stability issues (interacting

   policy control = loops). If policy execution is distributed (or the

   event / informa= tion sources are distributed), this ultimately

   resolves to pro= blems such as taking consistent snapshots or finding

   ways to work wi= th inconsistent observations of a distributed system

   that are guaran= teed to converge to stable states (self-stabilizing

   algorithms).

 

- Who is interested in inter= operable policy representations / languages?

 

   The IETF is abo= ut interoperability. What are the business models

   that push for i= nteroperable policy based management standards? Who

   benefits from h= aving an interoperable standard and how much effort

   are organizatio= ns willing to invest into engineering a reasonable

   solution addres= sing the other (non-trivial) questions raised above?

   Will they be im= plementing the solution in their products?

 

My position is that there ar= e way too many difficult technical issues to resolve for this work to be vi= able for the IETF. Instead, I suggest that people go and work out solutions= and once the silver bullet has been found, bring it to the IETF. (Historically, all attempts to cast policies = into existing data models such as MIB modules or LDAP schema led to somethi= ng awkward and unusable. I believe YANG modules are no

different.)

 

/js

 

Some relevant RFCs (there ma= y be more):

 

3052 Service Management Arch= itectures Issues and Review. M. Eder, S. Nag.

     Jan= uary 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:

     10.= 17487/RFC3052)

 

3084 COPS Usage for Policy P= rovisioning (COPS-PR). K. Chan, J. Seligson,

     D. = Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R.

     Yav= atkar, A. Smith. March 2001. (Format: TXT, HTML) (Status:=

     HIS= TORIC) (DOI: 10.17487/RFC3084)

 

3159 Structure of Policy Pro= visioning Information (SPPI). K. McCloghrie,

     M. = Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F.

     Rei= chmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC)

     (DO= I: 10.17487/RFC3159)

 

3318 Framework Policy Inform= ation Base. R. Sahita, Ed., S. Hahn, K. Chan,

     K. = McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC)

     (DO= I: 10.17487/RFC3318)

 

3460 Policy Core Information= Model (PCIM) Extensions. B. Moore, Ed..

     Jan= uary 2003. (Format: TXT, HTML) (Updates RFC3060) (Status:=

     PRO= POSED STANDARD) (DOI: 10.17487/RFC3460)

 

3644 Policy Quality of Servi= ce (QoS) Information Model. Y. Snir, Y.

     Ram= berg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format:<= /span>

     TXT= , HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644)

 

3198 Terminology for Policy-= Based Management. A. Westerinen, J.

     Sch= nizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.

     Huy= nh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format:=

     TXT= , HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198)

 

4011 Policy Based Management= MIB. S. Waldbusser, J. Saperia, T. Hongal.

     Mar= ch 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:

     10.= 17487/RFC4011)

 

4104 Policy Core Extension L= ightweight Directory Access Protocol Schema

     (PC= ELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.

     Jun= e 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED<= /span>

     STA= NDARD) (DOI: 10.17487/RFC4104)

 

8328 Policy-Based Management= Framework for the Simplified Use of Policy

     Abs= tractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis,<= /span>

     M. = Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML)

     (St= atus: INFORMATIONAL) (DOI: 10.17487/RFC8328)

 

WGs/RGs that at least partia= lly related to policy-based management:

 

- Simplified Use of Policy A= bstractions WG (supa) (2015 - 2017)

 

- Policy Framework WG (polic= y) (1998 - 2004)

 

- Resource Allocation Protoc= ol WG (rap) (1997 - 2005)

 

- Distributed Management WG = (disman) (1996 - 2006)

 

- Services Management RG (sm= rg) (2019? - 2001?)

 

- Network Management RG (nmr= g)

 

  - draft-clemm-nmrg-di= st-intent (2017-2019)

  - draft-irtf-nmrg-ibn= -concepts-definitions-02.txt (2019-2020)

 

Other resources:<= /span>

 

- https://en.wikipedia.= org/wiki/Policy-based_management

 

- https://www.youtube.c= om/watch?v=3DE_v-of582xg

 

- Boutaba, R. and I. Aib, &q= uot;Policy-Based Management: A

  Historical Perspectiv= e". Journal of Network and Systems

  Management (JNSM), Sp= ringer, Vol. 15 (4), December 2007.

  https://doi.org/10.10= 07/s10922-007-9083-8

 

- Pavlou, G., "On the E= volution of Management Approaches, Frameworks

  and Protocols: A Hist= orical Perspective". Journal of Network and

  Systems Management (J= NSM), Springer, Vol. 15 (4), December 2007.

  https://doi.org/10.10= 07/s10922-007-9082-9

 

- Strassner, J., "Polic= y-Based Network Management: Solutions for the

  Next Generation"= , Morgan Kaufmann, December 2003.

 

 

On Tue, Dec 29, 2020 at 04:2= 6:12PM -0000, Adrian Farrel wrote:

> Hi Juergen,<= /span>

>

> What you say about lear= ning lessons from the past is wise and valuable.

>

> Sadly (well, it's a goo= d thing, really) we have new people in the IETF

> and the memory of event= s over the last 20 years are not immediately

> accessible to them. Oth= ers, who are old and grey, have been around

> that long but were not = necessarily involved in previous ECA discussions.

>

> Since "intent-base= d networking" is a big thing once again (see recent

> reports of acquisitions= in this sector) the excitement about ECA may

> be forgiven, but it wou= ld help to ground the discussions if those who

> can remember previous e= fforts would share their experiences or at

> least some pointers.

>

> Best,=

> Adrian

>

> -----Original Message--= ---

> From: netmod <netmod-bounces@ietf.org> On Behalf Of Juergen

> Schoenwaelder

> Sent: 23 December 2020 = 18:09

> To: Andy Bierman <andy@yumaworks.com>

> Cc: NetMod WG Chairs &l= t;netmod-chairs@ietf.org>; NETMOD Group

> <netmo= d@ietf.org>

> Subject: Re: [netmod] A= doption poll for draft-wwx-netmod-event-yang-10

>

> On Wed, Dec 23, 2020 at= 07:05:44AM -0800, Andy Bierman wrote:

> > On Wed, Dec 23, 20= 20 at 3:14 AM tom petch <ietfc@btconnect.com> wrote:

> > =

> > > From: netmod = <netmod-bounces@ietf.org> on behalf = of Dhruv Dhody <

> > > dhruv.ietf@gmail.com<= /span>>

> > > Sent: 21 Dece= mber 2020 17:12

> > >

> > > Hi Lou, WG,

> > >

> > > I find the mo= tivation in the Introduction to be focused on ECA at

> > > the network d= evices (with all the talk about issues with

> > > Centralized n= etwork management).

> > >

> > > I see the val= ue of ECA on the controller as well, say a customer

> > > network contr= oller or an orchestrator can set the ECA on a central

> > > controller (r= eference ACTN in TEAS WG). Perhaps you would consider

> > > adding a sent= ence to describe this as well. The client-server

> > > terminology i= n the rest of the document covers it already.

> > >

> > > And I do see = value in this and support adoption.

> > >

> > > <tp>

> > > My take is th= at the I-D is unclear on what ECA is.

> > >

> > > ECA has been = worked on in at least two IETF WG AFAICT.  It cropped

> > > up in I2RS bu= t as I recall, it was along the lines of 'This is

> > > ECA'  'N= o It is not'  'Yes it is' which gave me the impression

> > > that ECA is n= ot a well-defined, or well-understood, term.

> > >

> > > More recently= , I2NSF have produced a YANG capability-data-model

> > > which is=

> > > 55 pages of E= CA.  Lacking a definition in this netmod I-D, I am

> > > unclear what = the relationship is between the I2NSF I-D and the

> > > netmod I-D,

> whether

> > > or not they a= re using ECA in the same sense.

> > >

> > >

> > Hi Tom,=

> > =

> > It usually helps t= o agree on the problem-space before focusing on

> > the solution-space= .

> > ECA seems like a m= ethodology (ala MVC) more than anything else.

> > The problem statem= ent seems to be that some client tasks need to be

> handled

> > on the<= /span>

> > server using ECA m= ethodology, instead of on the client.

> > Which tasks? Seems= to be any task of arbitrary purpose or complexity.

> > And now the scope = is supposed to include controllers (just another

> client),

> > so the problem-stm= t

> > is even less clear= .

> > =

> > The traditional ap= proach is to pick specific client tasks to move to

> > the server.

> > The example of det= ecting and reporting route-flaps has been used.

> > (No ECA example of= this complexity has been provided yet).

> > The traditional ap= proach would be to write a route-flap-detection

> > YANG module with s= ome configuration, monitoring data, and

> > notification event= s.

> > =

> > The generalized ap= proach is likely to be extremely complex to

> > standardize and im= plement.

> ><= /p>

>

> ECA work has a long 20&= #43; year tradition in the IETF and several

> specifications have bee= n published over the years by various working

> groups. As far as I can= tell, none of them got traction in terms of

> signifiant deployment o= f interoperable implementations.

>

> I would have hoped that= the next iteration of ECA work would have

> started with a deep ref= lection about why all the previous attempts

> failed to gain traction= and some genuine insights how to design things

> differently in order to= improve the likelihood to have impact.

>

> /js

>

> --

> Juergen Schoenwaelder&n= bsp;          Jacobs Universit= y Bremen gGmbH

> Phone: +49 421 200 = 3587         Campus Ring 1 | 28759 = Bremen | Germany

> Fax:   +4= 9 421 200 3103         <https://www.jacobs-university.de/>

>

> _______________________= ________________________

> netmod mailing list

> netmod@ie= tf.org

> https://www.ietf.org/= mailman/listinfo/netmod

>

 

--

Juergen Schoenwaelder &= nbsp;         Jacobs University Bre= men gGmbH

Phone: +49 421 200 3587&= nbsp;        Campus Ring 1 | 28759 Breme= n | Germany

Fax:   +49 421= 200 3103         <https://www.jacobs-university.de/>

 

____________________________= ___________________

netmod mailing list

netmod@ietf.or= g

https://www.ietf.org/mailman/listinfo/netmod<= /span>

--_000_B8F9A780D330094D99AF023C5877DABAADE4F3E0dggeml511mbschi_-- From nobody Wed Mar 10 00:43:33 2021 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 2EA4E3A1F4B for ; Wed, 10 Mar 2021 00:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGSldQ687ej4 for ; Wed, 10 Mar 2021 00:43:29 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2058.outbound.protection.outlook.com [40.107.20.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C153A1F48 for ; Wed, 10 Mar 2021 00:43:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GGQwhLcS7/ubmW4l+ErLd1I4IkfBKXg6jjh1Oi8dshFLWP86HuyOycns2MZaXdjfGXzuXsLa2ZfpgGnSaBmQqjmGI74aA4C0KWDLfp8jJhSbGOCxgNFXkIGX/Ljr/Tm7IbnjTgHyI6716pM9io3rARrvb5shiZNsZJaYLq7M9Jis4swlZWqKKYIdYrfHIlQ625BFJYd2tHOhB5V18Hn7j600ZFHOQfJCTgM3q9pYD7Lh25cjxGFg0i2a5JWnWomdlgGYykQbStX1tvgFnJaeJuwx1u6OQrzm0EG/Q3nyCO7g+OuKzG69R327C78GiGlXf6i0u8BsO/iLfF0iVRYQrQ== 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=9KRoBAqSMWYQB5JDrtwrAhER8DMKLDp2/hw01YrRRVk=; b=dhtEix4wxhxLVtlsgjFw53GXlXmpWFw47xpM9+iaOqz1h5azD3YiCe3AkCzJml6n2klCOYM9OdU2EijgsAqqscuV92eVtf6uwCKpmNRfI6dEXucWSPzafq2uX3s5VU/rlZ2FUBNEF1iu1rwEESwvyiVqJJutzfw9VSBeyx4MBdc35SIuvfBmOgENpcAQa0sDudgF/FoqxrPGAMfjgcVi9wM8YzKBYTkjUT5Kyyzo9QGW3gL9F/1uzGEpOrEQBw9KkgKHGLTUe2FXgRng4/bhTp43xRJ4FZQiCTm3uY2/s5IXv+r21xv/wnuFG3D/58d8whCCXTkLxlTuBfZvHA0BUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9KRoBAqSMWYQB5JDrtwrAhER8DMKLDp2/hw01YrRRVk=; b=DCiwS7qFjLt4/+hJM4KwB7zsSOgXV6g5m0Xi3PDtfXIMKhvm93YdtPlVJnKZpGu/C6g6LCjtvinb3GnKjrePJqMSe5dVT/oBegh6rSDRFg6YIMrIb/is9G2w7CzyfBQZ/m8iapoiZfuBz4vvGlk8PxnCtlBRMDjb6HOxQAUwnig= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0754.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.29; Wed, 10 Mar 2021 08:43:25 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 08:43:25 +0000 Date: Wed, 10 Mar 2021 09:43:24 +0100 From: Juergen Schoenwaelder To: Qin Wu Cc: 'NETMOD Group' Message-ID: <20210310084324.xkr4xbsainfnxrvr@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Qin Wu , 'NETMOD Group' References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR03CA0080.eurprd03.prod.outlook.com (2603:10a6:208:69::21) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR03CA0080.eurprd03.prod.outlook.com (2603:10a6:208:69::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Wed, 10 Mar 2021 08:43:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c4f482c-6498-419b-ed3b-08d8e3a091d4 X-MS-TrafficTypeDiagnostic: AM0P190MB0754: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M56casFDORuymZn76IIaJr5VdOYd4g077V2JanLs0jioHre//OLksl/v20LUwAivIk3dZbr/E49d6qGCcX6P1um6fqf2injfDizOHWRcsbuhm/QPpNZ0kycvC9MYubMZQy/z7D6nN0Bauf1Ex13aoLn5SblogUl2kexgrm/5B113/8fbLG9oUuVAGhxgP41/K7wTJ+Tt9sp/M6goeyFrzsEroFIWs/LH/ZNpmIjBhz6tRaVcbh22/tAtD22D/Ib0sLbvpotkKHwQVL7Qp7XkVvABBCJWhpWQQPv8gDbOBstze9J63KAzBV8UvEBrimiPK8/pUHyYUOX37MGaK80Y16pq7y7SM942dpWCeJ5NgpK1DsnWsiPqTW5PO2xUQYhuoHt5aX1mkEl1OJ2ltpzUMc3HgE4NoLN1X7N+Kqfjcvu/q81ysbTH0N7B5qeKFleIvMywUfpKpsqvdU9J/VTQ9NeU4fkYHJwWI5LDBRyisWBWLwNaAxdF7x0ryy8vNhsBNaaC/YiyTmluSH9ftqyWBSXBlUXOGNPwBdUnohblcayLCFckoTEE1nCdv9ptbuB14zRKNIqTRZ2DUz5QE75eR57uSALa7+XCJ92sIMbXc48= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(8936002)(4326008)(498600001)(956004)(5660300002)(52116002)(30864003)(2906002)(3450700001)(6496006)(26005)(186003)(6916009)(16526019)(8676002)(1076003)(53546011)(966005)(66946007)(86362001)(66476007)(83380400001)(66556008)(6486002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?YVhVRHJpczd0b1gzMFNIQmdSb0pXYmJZMzgvUW1SWjdvaXlzdVBOb3JjVEUv?= =?utf-8?B?RjZpYWk0Y1RNWDJKL0I0VlpQWGVwQ3prZk5DSFVOY3NOOC8yWXdTOFN2UnAv?= =?utf-8?B?MnU1YjVVNEd0cHdtSDUzOXYvMFB3NFZ2NFVicTNBQTlIa1IrOW9wWU9RZ29h?= =?utf-8?B?MlYvdjJSbVJDMnFsQVQ3cXdCU0wxanppVWVNUFR5VERESUdadDhMdE0weWtl?= =?utf-8?B?dVZDZWFXMTBWWDk1OWhyQUpPY0s3MHBibDZJNlRYSklsRXdKQ2dPcG1RWG52?= =?utf-8?B?OG1PYmE0VU9NS1FyVExOdmpFbTQ3eW5oYUVGV2dMMXdVZTZpQk9Db2ZKeWwr?= =?utf-8?B?QmEzckx2bnVZSWFmSDg5c25kVGwwaE5HaFoyRUdjZ3d5TUhzL1RCMndpT1VM?= =?utf-8?B?bXhUVW10TVQvbE9tTVhmcC8yTjlBWmRxNEtpTmJhUGZGSFBaRnZPSWZmY2tD?= =?utf-8?B?a0xFblo0YlhRK3B1Tkp3UG5HelNUWGpVTlBiVnVmd0hEc1laMlBJS2dHbkZ1?= =?utf-8?B?SG9jTmZEMit0dGZTRUcvQzVKd3JDR1MxbjRVUzZLaWloUGhFN01NcjQzcTNR?= =?utf-8?B?MjQzUXpCaTVrbExTMTM4Qkg4NzM3WGZONkhsU3pFLy94UFAzbVJyZWtkTDFj?= =?utf-8?B?d0hKdmthN09QS3ViQllGZWIvcmxQVkpBRkhJQjhWcjdQbFU1M2doM25RT0NB?= =?utf-8?B?SmQzVkF0b2U4dzJWWm9NMnFqVE5aNzBvMXFTU2xDM1lPeDF5UWdtdmJQVzlW?= =?utf-8?B?Y0szdmNBaURPQ3FVeEQrV0g1TWE0ZmwvckNyU213b1RYMmN3WGZNUWdSTlVK?= =?utf-8?B?b0ZOdkVreGRHZUU0UWF5M3h1SXBtdTBIMXVoUU51VENieUlHRGVndVZHK0FN?= =?utf-8?B?MXN2czFzUXpsZTRJUzAyTm5ISC8wVFh5c0VvWnJQVENyT1ZWQXBRamdFZERV?= =?utf-8?B?NWtxb3VGNG9ubzZWcTlqTzVNdzJ2V3Rpd1ExaTFiY3hnVGlROGEwcFNNY2Vk?= =?utf-8?B?WVJmMmk0T01MQTFRa09KYzJ2Mkl3MUFWMmtQUnJ2Z1hRamhCQWxjRGt6Sm1X?= =?utf-8?B?K2NuVDI0Ym1KMzRZbWVWUGtsOVBsNTk1WmZuWngrVTkzdXFIMDBnOXJGK2Vp?= =?utf-8?B?YUMvSnppbDFuN0ZhL3VHV1FpYkJ3ZlJhSUsrc3F1blpQVit4OW1LZGdwamFx?= =?utf-8?B?bGNDT2RLY1JiYWJkYythbERla3FEeE5MRDNrclFmSWNlQnNyQkYyajMyTDll?= =?utf-8?B?UzlkaExjaC9xNCtpbVhvdEo2ZWI0SEgyZTJsR1Y1MGlXWmxYb1Z1VkM4QmlD?= =?utf-8?B?VVZOcklEZ3dtUHJPSWFYN1BwWkU5S3hyaVp4NzBUUlFINHBiSWFzZEVaQ2R5?= =?utf-8?B?SGVwMHViaVFHOFMzRWZMdzJxMDBETmViSUxNTlN2UjRrWEpobjkxaWpnQXU4?= =?utf-8?B?cG9sVm10alJra2IzcEQyRGR4dlp5MHV5ZVFQclBwaVdwZkNyOFFQbDBNaDFo?= =?utf-8?B?Z1lNc3ozMXdlMC9aL3RycGV5Y2ViY2NmeUwwR0tkM1JRVDlBK1FValNtMnlm?= =?utf-8?B?REh4UW9NcENrK1dkcHFuRG5FWGlSVlY4V05QM3NBQlI2bFpLcUZUYStFd3I4?= =?utf-8?B?RTFRcmlTZmxOOFZLdnZvN2tWVFBOK0xOZWVXZWh0SG5NYUZPV042OUxZL0ho?= =?utf-8?B?QktYditNOWY3c2trUFdvVG9IVmlGS0tTbGVGUnRDNmgzR3JwYnNvaFJHdnZz?= =?utf-8?Q?eGgMiX+XQ2iO0+65xDbMkR1ocnZqegeREoBr/Gj?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 6c4f482c-6498-419b-ed3b-08d8e3a091d4 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2021 08:43:25.5162 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: H1sxJ7+GKf+ew4XTqdY6rjYSsQaaoUJ0MTAqHXoIhytdOWAZjbGKy5oceSRMb+xzTi7qXkoLLixE/7xV7VnTn/Gn1HCoXyDPZvmxZh0Qx2g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0754 Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 08:43:32 -0000 Dear Qin, I believe this work repeats failures of the past but since the WG agreed to entertain this, I will keep my mouth shut. I suggest you do not spend your energy to convince the that this work is viable since it is rather unlikely that I will change my mind. YANG is for me _not_ a suitable policy language, it is at best a language to carry policies written in a suitable policy language (and I am not even sure about this). All attempts in the past to reach agreement on a common usable standard policy language leading up to interoperable implementations failed. The reasons are manifold but strong (I think), standards-based interoperability at a generic policy language abstraction layer is for me a myths. Please don't take this personal in any way. I just do not believe into this work but I am happy to be proven wrong. /js On Wed, Mar 10, 2021 at 08:07:46AM +0000, Qin Wu wrote: > Hi, Juergen: > Come back to the key issues for ECA Policy. > I think Policies need to be readable and hence be expressed at a high level of abstraction and in a suitable _language_. > But I propose to separate policy expression and intent representation, especially high level service intent representation, translation, mapping which is the hot topic in NMRG. > High level language we select for policy representation is YANG, expressed by the NMS or controller. > We can compare YANG vs NETCONF with RMON vs SNMP, RAMON is an extension of SNMP, provides traffic flow data for troubleshooting and the controls necessary to adjust for better performance from a central console. > I think we set similar goal as ROMON in our draft. > > Unlike other intent translation or mapping, we compile High-level policy expression down into more verbose primitive representations that are closer to an execution abstraction. YANG expression is capable for such a compilation;. > Primitive representation in the device is script language, typical examples are Python or TCL used in the device > > Of course there is pitfall to start somewhere in the middle of several layers of abstraction and then getting stuck somewhere when compiling things down to _efficient_ instrumentations. > One of lesson we learn from the past is SUPA is defined and described very abstractly, with its high-level blocks and UMLs, and is very difficult to be written in YANG and harder to be implemented. > We will avoid such pitfall. > > At the current stage YANG is used for abstraction and representation. YANG is both representative and implementable. > > -Qin (on behalf of authors) > -----邮件原件----- > å‘件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder > å‘é€æ—¶é—´: 2020å¹´12月30æ—¥ 2:56 > 收件人: Adrian Farrel > 抄é€: 'NETMOD Group' > 主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10 > > Adrian, > > some key issues when it comes to policy-based management systems: > > - What is an adequate abstraction level to express policies and intent? > > This question has no simple answer. I believe policies need to be > readable and hence they need to be expressed at a high level of > abstraction and in a suitable _language_. High-level policy > expression may be compiled down into more verbose primitive > representations that are closer to an execution abstraction. A > common pitfall is to start somewhere in the middle of several > layers of abstraction and then getting stuck with something awkward > to put a clean higher layer abstract onto and to compile things > down to _efficient_ instrumentations. > > - Where are policies executed? > > This can range from a logically centralized policy execution > engine, which is part of what people call an orchestrator these > days, to fully distributed policy execution models. In reality, you > likely want to distribute functions dynamically but this makes > solutions technically much more complicated. Given today's scalable > computing and networking capabilities, logically centralized > solutions are on the rise and have replaced the distributed > approaches of the 90s. > > - When to detect and resolve policy conflicts? > > Detecting and resolving conflicts in larger collections of policies > is non-trivial. This includes problems ranging from micro timescale > atomicity issues to larger timescale stability issues (interacting > policy control loops). If policy execution is distributed (or the > event / information sources are distributed), this ultimately > resolves to problems such as taking consistent snapshots or finding > ways to work with inconsistent observations of a distributed system > that are guaranteed to converge to stable states (self-stabilizing > algorithms). > > - Who is interested in interoperable policy representations / languages? > > The IETF is about interoperability. What are the business models > that push for interoperable policy based management standards? Who > benefits from having an interoperable standard and how much effort > are organizations willing to invest into engineering a reasonable > solution addressing the other (non-trivial) questions raised above? > Will they be implementing the solution in their products? > > My position is that there are way too many difficult technical issues to resolve for this work to be viable for the IETF. Instead, I suggest that people go and work out solutions and once the silver bullet has been found, bring it to the IETF. (Historically, all attempts to cast policies into existing data models such as MIB modules or LDAP schema led to something awkward and unusable. I believe YANG modules are no > different.) > > /js > > Some relevant RFCs (there may be more): > > 3052 Service Management Architectures Issues and Review. M. Eder, S. Nag. > January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: > 10.17487/RFC3052) > > 3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson, > D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. > Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status: > HISTORIC) (DOI: 10.17487/RFC3084) > > 3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie, > M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. > Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC) > (DOI: 10.17487/RFC3159) > > 3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan, > K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC) > (DOI: 10.17487/RFC3318) > > 3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed.. > January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status: > PROPOSED STANDARD) (DOI: 10.17487/RFC3460) > > 3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y. > Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format: > TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644) > > 3198 Terminology for Policy-Based Management. A. Westerinen, J. > Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. > Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format: > TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198) > > 4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal. > March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: > 10.17487/RFC4011) > > 4104 Policy Core Extension Lightweight Directory Access Protocol Schema > (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner. > June 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED > STANDARD) (DOI: 10.17487/RFC4104) > > 8328 Policy-Based Management Framework for the Simplified Use of Policy > Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis, > M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML) > (Status: INFORMATIONAL) (DOI: 10.17487/RFC8328) > > WGs/RGs that at least partially related to policy-based management: > > - Simplified Use of Policy Abstractions WG (supa) (2015 - 2017) > > - Policy Framework WG (policy) (1998 - 2004) > > - Resource Allocation Protocol WG (rap) (1997 - 2005) > > - Distributed Management WG (disman) (1996 - 2006) > > - Services Management RG (smrg) (2019? - 2001?) > > - Network Management RG (nmrg) > > - draft-clemm-nmrg-dist-intent (2017-2019) > - draft-irtf-nmrg-ibn-concepts-definitions-02.txt (2019-2020) > > Other resources: > > - https://en.wikipedia.org/wiki/Policy-based_management > > - https://www.youtube.com/watch?v=E_v-of582xg > > - Boutaba, R. and I. Aib, "Policy-Based Management: A > Historical Perspective". Journal of Network and Systems > Management (JNSM), Springer, Vol. 15 (4), December 2007. > https://doi.org/10.1007/s10922-007-9083-8 > > - Pavlou, G., "On the Evolution of Management Approaches, Frameworks > and Protocols: A Historical Perspective". Journal of Network and > Systems Management (JNSM), Springer, Vol. 15 (4), December 2007. > https://doi.org/10.1007/s10922-007-9082-9 > > - Strassner, J., "Policy-Based Network Management: Solutions for the > Next Generation", Morgan Kaufmann, December 2003. > > > On Tue, Dec 29, 2020 at 04:26:12PM -0000, Adrian Farrel wrote: > > Hi Juergen, > > > > What you say about learning lessons from the past is wise and valuable. > > > > Sadly (well, it's a good thing, really) we have new people in the IETF > > and the memory of events over the last 20 years are not immediately > > accessible to them. Others, who are old and grey, have been around > > that long but were not necessarily involved in previous ECA discussions. > > > > Since "intent-based networking" is a big thing once again (see recent > > reports of acquisitions in this sector) the excitement about ECA may > > be forgiven, but it would help to ground the discussions if those who > > can remember previous efforts would share their experiences or at > > least some pointers. > > > > Best, > > Adrian > > > > -----Original Message----- > > From: netmod On Behalf Of Juergen > > Schoenwaelder > > Sent: 23 December 2020 18:09 > > To: Andy Bierman > > Cc: NetMod WG Chairs ; NETMOD Group > > > > Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10 > > > > On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote: > > > On Wed, Dec 23, 2020 at 3:14 AM tom petch wrote: > > > > > > > From: netmod on behalf of Dhruv Dhody < > > > > dhruv.ietf@gmail.com> > > > > Sent: 21 December 2020 17:12 > > > > > > > > Hi Lou, WG, > > > > > > > > I find the motivation in the Introduction to be focused on ECA at > > > > the network devices (with all the talk about issues with > > > > Centralized network management). > > > > > > > > I see the value of ECA on the controller as well, say a customer > > > > network controller or an orchestrator can set the ECA on a central > > > > controller (reference ACTN in TEAS WG). Perhaps you would consider > > > > adding a sentence to describe this as well. The client-server > > > > terminology in the rest of the document covers it already. > > > > > > > > And I do see value in this and support adoption. > > > > > > > > > > > > My take is that the I-D is unclear on what ECA is. > > > > > > > > ECA has been worked on in at least two IETF WG AFAICT. It cropped > > > > up in I2RS but as I recall, it was along the lines of 'This is > > > > ECA' 'No It is not' 'Yes it is' which gave me the impression > > > > that ECA is not a well-defined, or well-understood, term. > > > > > > > > More recently, I2NSF have produced a YANG capability-data-model > > > > which is > > > > 55 pages of ECA. Lacking a definition in this netmod I-D, I am > > > > unclear what the relationship is between the I2NSF I-D and the > > > > netmod I-D, > > whether > > > > or not they are using ECA in the same sense. > > > > > > > > > > > Hi Tom, > > > > > > It usually helps to agree on the problem-space before focusing on > > > the solution-space. > > > ECA seems like a methodology (ala MVC) more than anything else. > > > The problem statement seems to be that some client tasks need to be > > handled > > > on the > > > server using ECA methodology, instead of on the client. > > > Which tasks? Seems to be any task of arbitrary purpose or complexity. > > > And now the scope is supposed to include controllers (just another > > client), > > > so the problem-stmt > > > is even less clear. > > > > > > The traditional approach is to pick specific client tasks to move to > > > the server. > > > The example of detecting and reporting route-flaps has been used. > > > (No ECA example of this complexity has been provided yet). > > > The traditional approach would be to write a route-flap-detection > > > YANG module with some configuration, monitoring data, and > > > notification events. > > > > > > The generalized approach is likely to be extremely complex to > > > standardize and implement. > > > > > > > ECA work has a long 20+ year tradition in the IETF and several > > specifications have been published over the years by various working > > groups. As far as I can tell, none of them got traction in terms of > > signifiant deployment of interoperable implementations. > > > > I would have hoped that the next iteration of ECA work would have > > started with a deep reflection about why all the previous attempts > > failed to gain traction and some genuine insights how to design things > > differently in order to improve the likelihood to have impact. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 10 00:54:29 2021 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 26B623A1F79 for ; Wed, 10 Mar 2021 00:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TSFpaPassQod for ; Wed, 10 Mar 2021 00:54:23 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CAA3A1F76 for ; Wed, 10 Mar 2021 00:54:23 -0800 (PST) Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwQfJ4JfDz67nQT; Wed, 10 Mar 2021 16:46:16 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 09:54:19 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Wed, 10 Mar 2021 09:54:19 +0100 From: Italo Busi To: 'Andy Bierman' , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Questions about how to assign default values with YANG Thread-Index: AdbvCmZgzen+a6G4QWicT/glaRAynP///QGA///e3yCAAEHcAP//waGggACHKYD/tcyd8BK8WnuAAACoPAD//yMQoA== Date: Wed, 10 Mar 2021 08:54:18 +0000 Message-ID: References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.173] Content-Type: multipart/alternative; boundary="_000_bbbd4244a0474c48b3fdecb791cb936ahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 08:54:27 -0000 --_000_bbbd4244a0474c48b3fdecb791cb936ahuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwgSnVlcmdlbiwNCg0KSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGlzc3VlIHdp dGggYSBjbGllbnQgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBhdWdtZW50Lg0KDQpXaGVu IHRoaXMgY2xpZW50IHdyaXRlcyBpbiB0aGUgcnVubmluZyBEUywgaXQgd2lsbCBub3Qgc2V0IHRo ZSBiYXIgYXR0cmlidXRlICh3aGljaCBpcyBhbHNvIGRlZmluZWQgaW4gdGhlIGF1Z21lbnQgbW9k dWxlKSBhbmQgdGhlcmVmb3JlIHRoZSBkZWZhdWx0IHZhbHVlIDAgd2lsbCBiZSBhcHBsaWVkIGJ5 IHRoZSBzeXN0ZW0sIGFzIGV4cGVjdGVkIGJ5IHRoZSBjbGllbnQuDQoNCldoZW4gdGhpcyBjbGll bnQgcmVhZHMgZnJvbSB0aGUgb3BlcmF0aW9uYWwgRFMgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlv biwgcHJvdmlkZWQgYnkgYW5vdGhlciBjbGllbnQgd2hpY2ggdW5kZXJzdGFuZHMgdGhlIGF1Z21l bnQsIGl0IHdpbGwgc2VlIHRoYXQgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBmb3IgdGhlIGxl YWYgZm9vIGlzIDEwLg0KDQpUaGlzIGlzIGEgdmFsaWQgYXBwbGllZCBjb25maWd1cmF0aW9uIGlm IHRoZSBvdGhlciBjbGllbnQgaGFkIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0aGUgdmFsdWUgMTAg aW4gdGhlIHJ1bm5pbmcgRFMuDQoNClRoZSBvbmx5IGRpZmZlcmVuY2Ugd291bGQgYmUgdGhhdCB3 aGVuIHRoZSB2YWx1ZSAxMCBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgYnkgdGhlIG90aGVyIGNs aWVudCB0aGUgb3JpZ2luIGlzIHNldCB0byBpbnRlbmRlZCB3aGlsZSB3aGVuIOKAnGltcGxpY2l0 bHnigJ0gY29uZmlndXJlZCB1c2luZyB0aGUgYXR0cmlidXRlIGJhciwgdGhlIG9yaWdpbiBjYW4g YmUgc2V0IHRvIHN5c3RlbSAoSSB0aGluayBpdCB3b3VsZCBub3QgYmUgY29ycmVjdCB0byBzZXQg dGhlIG9yaWdpbiB0byBkZWZhdWx0IGluIHRoaXMgY2FzZSkuDQoNCkJUVywgSSBhZ3JlZSB0aGF0 IHRoaXMgaXMgbm90IHRoZSBtb3N0IGVsZWdhbnQvY2xlYW4gZGVzaWduIGFuZCB0aGF0IHRoZSBi ZXN0IGFwcHJvYWNoIHdvdWxkIGJlIG5vdCB0byBkZWZpbmUgYW55IGRlZmF1bHQgdmFsdWUgaW4g dGhlIGJhc2UgbW9kZWwuIEkgYW0ganVzdCB3aWxsaW5nIHRvIHVuZGVyc3RhbmQgaWYgYSB3b3Jr LWFyb3VuZCBpcyBwb3NzaWJsZSwgd2l0aG91dCBicmVha2luZyBhbnkgY2xpZW50LCB0byBhbGxv dyByZS11c2luZyBhbiBleGlzdGluZyBtb2R1bGUgd2hpY2ggaGFzIGFscmVhZHkgZGVmaW5lZCBh IGRlZmF1bHQgdmFsdWUuDQoNCkl0YWxvDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IG1hcnRlZMOsIDkgbWFyem8gMjAyMSAyMToxMg0KVG86 IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPjsgSXRhbG8gQnVzaSA8SXRhbG8uQnVzaUBodWF3ZWkuY29tPjsgbmV0bW9kQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlc3Rpb25zIGFib3V0IGhvdyB0byBhc3NpZ24gZGVm YXVsdCB2YWx1ZXMgd2l0aCBZQU5HDQoNCg0KDQpPbiBUdWUsIE1hciA5LCAyMDIxIGF0IDExOjUy IEFNIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90 ZToNCkNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgYSBkZWZpbml0aW9uIHZpYSBhdWdtZW50cyBp cyBiYWQgZGVzaWduLg0KDQpBIHN5c3RlbSB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIGF1 Z21lbnQgd2lsbCBiZWxpZXZlIHRoZSBkZWZhdWx0DQppcyAwLiBTaW5jZSB0aGVyZSBpcyBubyB3 YXkgdG8gZm9yY2UgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdG8NCnVuZGVyc3RhbmQgYSBj ZXJ0YWluIGF1Z21lbnRhdGlvbiwgZGlmZmVyZW50IGltcGxlbWVudGF0aW9uIHdpbGwNCnJpZ2h0 ZnVsbHkgZGlzYWdyZWUgb24gdGhlIGRlZmF1bHQgdmFsdWUgaW4gZWZmZWN0Lg0KDQoNCmRldmlh dGlvbiAvZXg6ZXhhbXBsZS9leDpmb28gew0KICAgIGRlbGV0ZSB7DQogICAgICAgZGVmYXVsdCAw Ow0KICAgICB9DQp9DQoNCklNTyBpdCB3YXMgYSBiYWQgaWRlYSB0byBzYXkgZGV2aWF0aW9ucyBN VVNUIE5PVCBhcHBlYXIgaW4gc3RhbmRhcmQgbW9kdWxlcy4NCkhlcmUgaXMgYSB1c2UtY2FzZSBm b3IgaXQuDQoNClRoZSBvbGQtY2xpZW50IGRvZXMgbm90IGtub3cgYWJvdXQgdGhlIG5ldyBkeW5h bWljIGRlZmF1bHQgYnV0IGl0IGNvdWxkIGtub3cNCnRoYXQgdGhlIG9sZCBZQU5HIGRlZmF1bHQg aXMgbm90IGJlaW5nIHVzZWQuDQoNCg0KL2pzDQoNCkFuZHkNCg0KDQpPbiBNb24sIE1hciAwOCwg MjAyMSBhdCAwODoxOTozOVBNICswMDAwLCBJdGFsbyBCdXNpIHdyb3RlOg0KPiBIaSBKdWVyZ2Vu LA0KPg0KPiBUaGFua3MgYWdhaW4gZm9yIHlvdXIgY2xlYXIgZXhwbGFuYXRpb24gb24gdGhpcyB0 b3BpYw0KPg0KPiBJIGhhdmUgZm91bmQgYSBzaW1pbGFyIGJ1dCBzbGlnaHRseSBkaWZmZXJlbnQg aXNzdWUuIEluIHRoaXMgY2FzZSwgYSBZQU5HIGRlZmF1bHQgc3RhdGVtZW50IGV4aXN0cyBpbiB0 aGUgYmFzZSBtb2R1bGUgYnV0IHRoZSBpbnRlbnRpb24gd2l0aCB0aGUgYXVnbWVudGF0aW9uIGlz IHRvICJvdmVyd3JpdGUiIHRoZSBkZWZhdWx0IHZhbHVlIG9uIHRoZSBiYXNpcyBvZiBhbm90aGVy IGF0dHJpYnV0ZSwgZGVmaW5lZCBpbiB0aGUgbW9kdWxlIHdoaWNoIGF1Z21lbnRzIHRoZSBiYXNl IG1vZHVsZS4NCj4NCj4gRm9yIGV4YW1wbGUsIEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgc3VjaCBh IGNvZGUgaXMgdmFsaWQ6DQo+DQo+IG1vZHVsZSBleGFtcGxlLWJhc2Ugew0KPiAgIGNvbnRhaW5l ciBleGFtcGxlIHsNCj4gICAgIGxlYWYgZm9vIHsNCj4gICAgICAgdHlwZSB1aW50ODsNCj4gICAg ICAgZGVmYXVsdCAwOw0KPiAgICAgfQ0KPiAgIH0NCj4gfQ0KPg0KPiBtb2R1bGUgZXhhbXBsZS1h dWdtZW50IHsNCj4gICBpbXBvcnQgZXhhbXBsZSB7DQo+ICAgICBwcmVmaXggZXg7DQo+ICAgfQ0K Pg0KPiAgIGF1Z21lbnQgImV4OmV4YW1wbGUiIHsNCj4gICAgIGxlYWYgYmFyIHsNCj4gICAgICAg dHlwZSBlbXB0eTsNCj4gICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAiV2hlbiBwcmVzZW50 LCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgZm9vIGlzIDEwLiI7DQo+ICAgICB9DQo+ICAgfQ0KPiB9 DQo+DQo+DQo+IEluIHRoaXMgY2FzZSwgd2hlbiB0aGUgbGVhZiBmb28gaXMgbm90IGNvbmZpZ3Vy ZWQgYnV0IHRoZSBsZWFmIGJhciBpcyBwcmVzZW50LCB0aGUgdmFsdWUgb2YgZm9vIGluIHRoZSBv cGVyYXRpb25hbCBkYXRhc3RvcmUgc2hvdWxkIGJlIDEwIChyYXRoZXIgdGhhbiAwKS4NCj4NCj4g SW4gdGhpcyBjYXNlLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyL2NsZWFuZXIgaWYg dGhlIG9yaWdpbiBpcyBtYXJrZWQgYXMgc3lzdGVtLg0KPg0KPiBNYXliZSBhIGJldHRlciBZQU5H IGRlc2NyaXB0aW9uIGZvciBiYXIgY291bGQgYmU6ICJXaGVuIHByZXNlbnQsIHRoZSBzeXN0ZW0g b3ZlcnJpZGVzIHRoZSBkZWZhdWx0IHZhbHVlIG9mIGZvbyB0byAxMC4iDQo+DQo+IFdoYXQgaXMg eW91ciBhbmQvb3IgV0cgb3Bpbmlvbj8NCj4NCj4gVGhhbmtzIGFnYWluDQo+DQo+IEl0YWxvDQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFp bHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT5dDQo+ID4gU2VudDogbWVy Y29sZWTDrCAyMCBnZW5uYWlvIDIwMjEgMTc6MDUNCj4gPiBUbzogSXRhbG8gQnVzaSA8SXRhbG8u QnVzaUBodWF3ZWkuY29tPG1haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb20+Pg0KPiA+IENjOiAn bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+JyA8bmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KPiA+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVz dGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlcyB3aXRoDQo+ID4gWUFORw0K PiA+DQo+ID4gT24gV2VkLCBKYW4gMjAsIDIwMjEgYXQgMDI6NDE6MzlQTSArMDAwMCwgSXRhbG8g QnVzaSB3cm90ZToNCj4gPiA+DQo+ID4gPiBXaGF0IGFib3V0IHRoZSBjYXNlIHRoZSBsZWFmIGlz IG5vdCBjb25kaXRpb25hbCAoYnV0IHN0aWxsIG1hbmRhdG9yeSBmYWxzZQ0KPiA+IHNpbmNlIGEg WUFORyBkZWZhdWx0IHN0YXRlbWVudCBpcyBkZWZpbmVkKT8NCj4gPiA+DQo+ID4gPiBNYXkgdGhl IHNlcnZlciBzdGlsbCBkZWNpZGUgbm90IHRvIHVzZS9pbXBsZW1lbnQgdGhpcyBsZWFmIGluIHRo ZSBvcGVyYXRpb25hbA0KPiA+IGRhdGFzdG9yZT8NCj4gPiA+DQo+ID4gPiBGb3IgZXhhbXBsZSwg aW4gYXBwZW5kaXggQy4xIG9mIFJGQzgzNDIsIGF1dG8tbmVnb3RpYXRpb24gaXMgZW5hYmxlZCBi eQ0KPiA+IGRlZmF1bHQuDQo+ID4gPiBXaGF0IHNob3VsZCBiZSB0aGUgYmVoYXZpb3Igb2YgYSBz eXN0ZW0gd2hpY2ggZG9lcyBub3QgaW1wbGVtZW50IGF1dG8tDQo+ID4gbmVnb3RpYXRpb24/DQo+ ID4gPiBSZXR1cm4gdGhlIHZhbHVlIGZhbHNlIG9yIG5vIHZhbHVlIChpbiB0aGUgb3BlcmF0aW9u YWwgZGF0YXN0b3JlKT8NCj4gPiA+DQo+ID4NCj4gPiBIZXJlIGFyZSBzb21lIG9mIHRoZSBydWxl cyBJIHBlcnNvbmFsbHkgbGlrZToNCj4gPg0KPiA+ICAtIDxvcGVyYXRpb25hbD4gaXMgdGhlIGdy b3VuZCB0cnV0aCBhYm91dCB3aGF0IGEgc3lzdGVtIGhhcyBhbmQgZG9lcw0KPiA+ICAtIGRvIG5v dCBpbXBsZW1lbnQgbGVhZnMgdGhhdCBkbyBub3QgYXBwbHkNCj4gPg0KPiA+IEhlbmNlLCBpbnRl cmZhY2VzIHN1cHBvcnRpbmcgYXV0by1uZWdvdGlhdGlvbiBoYXZlIGVpdGhlciBhdXRvLQ0KPiA+ IG5lZ290aWF0aW9uL2VuYWJsZWQgPSB0cnVlIG9yIGF1dG8tbmVnb3RpYXRpb24vZW5hYmxlZCA9 IGZhbHNlIGluDQo+ID4gPG9wZXJhdGlvbmFsPi4gQW5kIGludGVyZmFjZXMgbm90IHN1cHBvcnRp bmcgYXV0by1uZWdvdGlhdGlvbiBoYXZlIG5vdGhpbmcNCj4gPiB0byByZXBvcnQgYWJvdXQgYXV0 by1uZWdvdGlhdGlvbi4gWWVzLCBJIGRvIG5vdCB3YW50IHRvIHNlZSBhdXRvLQ0KPiA+IG5lZ290 aWF0aW9uL2VuYWJsZWQgPSBmYWxzZSBvbiBhIGxvb3BiYWNrIGludGVyZmFjZS4NCj4gPg0KPiA+ IE15IGhpc3RvcmljIEV0aGVybmV0IGludGVyZmFjZSBmcm9tIHRoZSBsYXN0IGNlbnR1cnkgd291 bGQgYWxzbyBub3QgcmVwb3J0DQo+ID4gYXV0by1uZWdvdGlhdGlvbi9lbmFibGVkIGluIDxvcGVy YXRpb25hbD4uIFlvdSBtYXkgaGl0IGFwcGxpY2F0aW9ucyB0aGF0IGxvdmUNCj4gPiB0byBoYXZl IGF1dG8tbmVnb3RpYXRpb24vZW5hYmxlZCBhdmFpbGFibGUgb24gYWxsIEV0aGVybmV0IGludGVy ZmFjZXMgYW5kIHRoZW4NCj4gPiB5b3UgZW5kIGluIGEgZGViYXRlIHdoZXJlIHRoZSBhcHBsaWNh dGlvbiBkZXZlbG9wZXJzIHRlbGwgeW91IHRoYXQgbm8NCj4gPiBpbmZvcm1hdGlvbiBpbiA8b3Bl cmF0aW9uYWw+IG1heSBoYXZlIG1hbnkgcmVhc29ucyAoaW5zdHJ1bWVudGF0aW9uIG5vdA0KPiA+ IGltcGxlbWVudGVkLCBhY2Nlc3MgY29udHJvbCBydWxlcywgd2hhdGV2ZXIgYW5kIGJ5IHJlcG9y dGluZyBlbmFibGVkPWZhbHNlDQo+ID4geW91IGRvIHRoZW0gYSBmYXZvcikgYnV0IHRoZSB0cnVl IGFuc3dlciBpbiBzdWNoIGEgZGViYXRlIGlzIG9mdGVuIHRoYXQNCj4gPiBtb2RlbGluZyB0aGlu Z3MgYXMgYSBib29sZWFuIGlzIHNpbXBsaXN0aWMgc2luY2UgdGhlcmUgYXJlIG9mdGVuIG1vcmUg dGhhbg0KPiA+IGV4YWN0bHkgdHdvIHN0YXRlcyAoaW4gdGhpcyBjYXNlLCBlbmFibGVkLCBkaXNh YmxlZCwgZmFpbGVkLCBub3QtYXZhaWxhYmxlLCAuLi4pLg0KPiA+IFNvIHlvdSBzZXR0bGUgb24g YmxhbWluZyB0aGUgbW9kZWwgd3JpdGVyLiA7LSkNCj4gPg0KPiA+IC9qcw0KPiA+DQo+ID4gLS0N Cj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp bmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+DQoNCi0tDQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0K --_000_bbbd4244a0474c48b3fdecb791cb936ahuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkFuZHksIEp1ZXJnZW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgaXNzdWUgd2l0aCBhIGNsaWVu dCB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIGF1Z21lbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGVuIHRoaXMgY2xpZW50IHdyaXRlcyBpbiB0aGUg cnVubmluZyBEUywgaXQgd2lsbCBub3Qgc2V0IHRoZSBiYXIgYXR0cmlidXRlICh3aGljaCBpcyBh bHNvIGRlZmluZWQgaW4gdGhlIGF1Z21lbnQgbW9kdWxlKSBhbmQgdGhlcmVmb3JlIHRoZSBkZWZh dWx0IHZhbHVlIDAgd2lsbA0KIGJlIGFwcGxpZWQgYnkgdGhlIHN5c3RlbSwgYXMgZXhwZWN0ZWQg YnkgdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PldoZW4gdGhpcyBjbGllbnQgcmVhZHMgZnJvbSB0aGUgb3BlcmF0aW9uYWwgRFMgdGhlIGFwcGxp ZWQgY29uZmlndXJhdGlvbiwgcHJvdmlkZWQgYnkgYW5vdGhlciBjbGllbnQgd2hpY2ggdW5kZXJz dGFuZHMgdGhlIGF1Z21lbnQsIGl0IHdpbGwgc2VlIHRoYXQgdGhlIGFwcGxpZWQNCiBjb25maWd1 cmF0aW9uIGZvciB0aGUgbGVhZiBmb28gaXMgMTAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGEgdmFsaWQgYXBwbGllZCBjb25maWd1cmF0aW9uIGlm IHRoZSBvdGhlciBjbGllbnQgaGFkIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0aGUgdmFsdWUgMTAg aW4gdGhlIHJ1bm5pbmcgRFMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGUgb25seSBkaWZmZXJlbmNlIHdvdWxkIGJlIHRoYXQgd2hlbiB0aGUgdmFsdWUgMTAg aXMgZXhwbGljaXRseSBjb25maWd1cmVkIGJ5IHRoZSBvdGhlciBjbGllbnQgdGhlIG9yaWdpbiBp cyBzZXQgdG8gaW50ZW5kZWQgd2hpbGUgd2hlbiDigJxpbXBsaWNpdGx54oCdIGNvbmZpZ3VyZWQN CiB1c2luZyB0aGUgYXR0cmlidXRlIGJhciwgdGhlIG9yaWdpbiBjYW4gYmUgc2V0IHRvIHN5c3Rl bSAoSSB0aGluayBpdCB3b3VsZCBub3QgYmUgY29ycmVjdCB0byBzZXQgdGhlIG9yaWdpbiB0byBk ZWZhdWx0IGluIHRoaXMgY2FzZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5CVFcsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgbW9zdCBlbGVnYW50L2Ns ZWFuIGRlc2lnbiBhbmQgdGhhdCB0aGUgYmVzdCBhcHByb2FjaCB3b3VsZCBiZSBub3QgdG8gZGVm aW5lIGFueSBkZWZhdWx0IHZhbHVlIGluIHRoZSBiYXNlIG1vZGVsLiBJIGFtIGp1c3Qgd2lsbGlu Zw0KIHRvIHVuZGVyc3RhbmQgaWYgYSB3b3JrLWFyb3VuZCBpcyBwb3NzaWJsZSwgd2l0aG91dCBi cmVha2luZyBhbnkgY2xpZW50LCB0byBhbGxvdyByZS11c2luZyBhbiBleGlzdGluZyBtb2R1bGUg d2hpY2ggaGFzIGFscmVhZHkgZGVmaW5lZCBhIGRlZmF1bHQgdmFsdWUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0 YWxvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFu IFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1hcnRlZMOs IDkgbWFyem8gMjAyMSAyMToxMjxicj4NCjxiPlRvOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVy ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7OyBJdGFsbyBCdXNp ICZsdDtJdGFsby5CdXNpQGh1YXdlaS5jb20mZ3Q7OyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIFF1ZXN0aW9ucyBhYm91dCBob3cgdG8gYXNzaWduIGRl ZmF1bHQgdmFsdWVzIHdpdGggWUFORzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA5LCAyMDIxIGF0IDExOjUyIEFNIEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZSI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkNoYW5naW5nIHRo ZSBzZW1hbnRpY3Mgb2YgYSBkZWZpbml0aW9uIHZpYSBhdWdtZW50cyBpcyBiYWQgZGVzaWduLjxi cj4NCjxicj4NCkEgc3lzdGVtIHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgYXVnbWVudCB3 aWxsIGJlbGlldmUgdGhlIGRlZmF1bHQ8YnI+DQppcyAwLiBTaW5jZSB0aGVyZSBpcyBubyB3YXkg dG8gZm9yY2UgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdG88YnI+DQp1bmRlcnN0YW5kIGEg Y2VydGFpbiBhdWdtZW50YXRpb24sIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiB3aWxsPGJyPg0K cmlnaHRmdWxseSBkaXNhZ3JlZSBvbiB0aGUgZGVmYXVsdCB2YWx1ZSBpbiBlZmZlY3QuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmRldmlhdGlvbiAvZXg6ZXhhbXBsZS9leDpmb28gezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBkZWxldGUgezxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZGVmYXVsdCAwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyBpdCB3YXMgYSBiYWQgaWRl YSB0byBzYXkgZGV2aWF0aW9ucyBNVVNUIE5PVCBhcHBlYXIgaW4gc3RhbmRhcmQgbW9kdWxlcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUg aXMgYSB1c2UtY2FzZSBmb3IgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvbGQtY2xpZW50IGRvZXMgbm90IGtub3cgYWJvdXQgdGhl IG5ldyBkeW5hbWljIGRlZmF1bHQgYnV0IGl0IGNvdWxkIGtub3c8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgdGhlIG9sZCBZQU5HIGRlZmF1 bHQgaXMgbm90IGJlaW5nIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L2pzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9uIE1vbiwg TWFyIDA4LCAyMDIxIGF0IDA4OjE5OjM5UE0gJiM0MzswMDAwLCBJdGFsbyBCdXNpIHdyb3RlOjxi cj4NCiZndDsgSGkgSnVlcmdlbiw8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGFnYWluIGZv ciB5b3VyIGNsZWFyIGV4cGxhbmF0aW9uIG9uIHRoaXMgdG9waWM8YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSBoYXZlIGZvdW5kIGEgc2ltaWxhciBidXQgc2xpZ2h0bHkgZGlmZmVyZW50IGlzc3VlLiBJ biB0aGlzIGNhc2UsIGEgWUFORyBkZWZhdWx0IHN0YXRlbWVudCBleGlzdHMgaW4gdGhlIGJhc2Ug bW9kdWxlIGJ1dCB0aGUgaW50ZW50aW9uIHdpdGggdGhlIGF1Z21lbnRhdGlvbiBpcyB0byAmcXVv dDtvdmVyd3JpdGUmcXVvdDsgdGhlIGRlZmF1bHQgdmFsdWUgb24gdGhlIGJhc2lzIG9mIGFub3Ro ZXIgYXR0cmlidXRlLCBkZWZpbmVkIGluIHRoZSBtb2R1bGUgd2hpY2gNCiBhdWdtZW50cyB0aGUg YmFzZSBtb2R1bGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvciBleGFtcGxlLCBJIGFtIHdvbmRl cmluZyB3aGV0aGVyIHN1Y2ggYSBjb2RlIGlzIHZhbGlkOjxicj4NCiZndDsgPGJyPg0KJmd0OyBt b2R1bGUgZXhhbXBsZS1iYXNlIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2NvbnRhaW5lciBleGFt cGxlIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGZvbyB7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdWludDg7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RlZmF1bHQgMDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt9 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyB9PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IG1vZHVsZSBleGFtcGxlLWF1Z21lbnQgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7aW1wb3J0IGV4 YW1wbGUgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3ByZWZpeCBleDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7YXVnbWVudCAm cXVvdDtleDpleGFtcGxlJnF1b3Q7IHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFm IGJhciB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgZW1wdHk7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2NyaXB0aW9uPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtXaGVuIHByZXNlbnQsIHRoZSBk ZWZhdWx0IHZhbHVlIGZvciBmb28gaXMgMTAuJnF1b3Q7Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO308YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7IH08YnI+DQomZ3Q7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBJbiB0aGlzIGNhc2UsIHdoZW4gdGhlIGxlYWYgZm9vIGlzIG5v dCBjb25maWd1cmVkIGJ1dCB0aGUgbGVhZiBiYXIgaXMgcHJlc2VudCwgdGhlIHZhbHVlIG9mIGZv byBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIHNob3VsZCBiZSAxMCAocmF0aGVyIHRoYW4g MCkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHRoaXMgY2FzZSwgSSB0aGluayB0aGF0IGl0IHdv dWxkIGJlIGJldHRlci9jbGVhbmVyIGlmIHRoZSBvcmlnaW4gaXMgbWFya2VkIGFzIHN5c3RlbS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgTWF5YmUgYSBiZXR0ZXIgWUFORyBkZXNjcmlwdGlvbiBmb3Ig YmFyIGNvdWxkIGJlOiAmcXVvdDtXaGVuIHByZXNlbnQsIHRoZSBzeXN0ZW0gb3ZlcnJpZGVzIHRo ZSBkZWZhdWx0IHZhbHVlIG9mIGZvbyB0byAxMC4mcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsg V2hhdCBpcyB5b3VyIGFuZC9vciBXRyBvcGluaW9uPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFu a3MgYWdhaW48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXRhbG88YnI+DQomZ3Q7IDxicj4NCiZndDsg Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPC9hPl08YnI+DQomZ3Q7ICZndDsgU2VudDogbWVyY29sZWTDrCAy MCBnZW5uYWlvIDIwMjEgMTc6MDU8YnI+DQomZ3Q7ICZndDsgVG86IEl0YWxvIEJ1c2kgJmx0Ozxh IGhyZWY9Im1haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5JdGFs by5CdXNpQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBDYzogJzxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+ JyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5l dG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbbmV0bW9k XSBRdWVzdGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlcyB3aXRoPGJyPg0K Jmd0OyAmZ3Q7IFlBTkc8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gV2VkLCBKYW4g MjAsIDIwMjEgYXQgMDI6NDE6MzlQTSAmIzQzOzAwMDAsIEl0YWxvIEJ1c2kgd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaGF0IGFib3V0IHRoZSBjYXNlIHRo ZSBsZWFmIGlzIG5vdCBjb25kaXRpb25hbCAoYnV0IHN0aWxsIG1hbmRhdG9yeSBmYWxzZTxicj4N CiZndDsgJmd0OyBzaW5jZSBhIFlBTkcgZGVmYXVsdCBzdGF0ZW1lbnQgaXMgZGVmaW5lZCk/PGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBNYXkgdGhlIHNlcnZlciBzdGls bCBkZWNpZGUgbm90IHRvIHVzZS9pbXBsZW1lbnQgdGhpcyBsZWFmIGluIHRoZSBvcGVyYXRpb25h bDxicj4NCiZndDsgJmd0OyBkYXRhc3RvcmU/PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyBGb3IgZXhhbXBsZSwgaW4gYXBwZW5kaXggQy4xIG9mIFJGQzgzNDIsIGF1dG8t bmVnb3RpYXRpb24gaXMgZW5hYmxlZCBieTxicj4NCiZndDsgJmd0OyBkZWZhdWx0Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7IFdoYXQgc2hvdWxkIGJlIHRoZSBiZWhhdmlvciBvZiBhIHN5c3RlbSB3aGlj aCBkb2VzIG5vdCBpbXBsZW1lbnQgYXV0by08YnI+DQomZ3Q7ICZndDsgbmVnb3RpYXRpb24/PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgUmV0dXJuIHRoZSB2YWx1ZSBmYWxzZSBvciBubyB2YWx1ZSAoaW4g dGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSk/PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgSGVyZSBhcmUgc29tZSBvZiB0aGUgcnVsZXMgSSBwZXJzb25h bGx5IGxpa2U6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IC0gJmx0O29wZXJh dGlvbmFsJmd0OyBpcyB0aGUgZ3JvdW5kIHRydXRoIGFib3V0IHdoYXQgYSBzeXN0ZW0gaGFzIGFu ZCBkb2VzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IC0gZG8gbm90IGltcGxlbWVudCBsZWFmcyB0aGF0 IGRvIG5vdCBhcHBseTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBIZW5jZSwgaW50ZXJm YWNlcyBzdXBwb3J0aW5nIGF1dG8tbmVnb3RpYXRpb24gaGF2ZSBlaXRoZXIgYXV0by08YnI+DQom Z3Q7ICZndDsgbmVnb3RpYXRpb24vZW5hYmxlZCA9IHRydWUgb3IgYXV0by1uZWdvdGlhdGlvbi9l bmFibGVkID0gZmFsc2UgaW48YnI+DQomZ3Q7ICZndDsgJmx0O29wZXJhdGlvbmFsJmd0Oy4gQW5k IGludGVyZmFjZXMgbm90IHN1cHBvcnRpbmcgYXV0by1uZWdvdGlhdGlvbiBoYXZlIG5vdGhpbmc8 YnI+DQomZ3Q7ICZndDsgdG8gcmVwb3J0IGFib3V0IGF1dG8tbmVnb3RpYXRpb24uIFllcywgSSBk byBub3Qgd2FudCB0byBzZWUgYXV0by08YnI+DQomZ3Q7ICZndDsgbmVnb3RpYXRpb24vZW5hYmxl ZCA9IGZhbHNlIG9uIGEgbG9vcGJhY2sgaW50ZXJmYWNlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBNeSBoaXN0b3JpYyBFdGhlcm5ldCBpbnRlcmZhY2UgZnJvbSB0aGUgbGFzdCBjZW50 dXJ5IHdvdWxkIGFsc28gbm90IHJlcG9ydDxicj4NCiZndDsgJmd0OyBhdXRvLW5lZ290aWF0aW9u L2VuYWJsZWQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy4gWW91IG1heSBoaXQgYXBwbGljYXRpb25z IHRoYXQgbG92ZTxicj4NCiZndDsgJmd0OyB0byBoYXZlIGF1dG8tbmVnb3RpYXRpb24vZW5hYmxl ZCBhdmFpbGFibGUgb24gYWxsIEV0aGVybmV0IGludGVyZmFjZXMgYW5kIHRoZW48YnI+DQomZ3Q7 ICZndDsgeW91IGVuZCBpbiBhIGRlYmF0ZSB3aGVyZSB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVy cyB0ZWxsIHlvdSB0aGF0IG5vPGJyPg0KJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIGluICZsdDtvcGVy YXRpb25hbCZndDsgbWF5IGhhdmUgbWFueSByZWFzb25zIChpbnN0cnVtZW50YXRpb24gbm90PGJy Pg0KJmd0OyAmZ3Q7IGltcGxlbWVudGVkLCBhY2Nlc3MgY29udHJvbCBydWxlcywgd2hhdGV2ZXIg YW5kIGJ5IHJlcG9ydGluZyBlbmFibGVkPWZhbHNlPGJyPg0KJmd0OyAmZ3Q7IHlvdSBkbyB0aGVt IGEgZmF2b3IpIGJ1dCB0aGUgdHJ1ZSBhbnN3ZXIgaW4gc3VjaCBhIGRlYmF0ZSBpcyBvZnRlbiB0 aGF0PGJyPg0KJmd0OyAmZ3Q7IG1vZGVsaW5nIHRoaW5ncyBhcyBhIGJvb2xlYW4gaXMgc2ltcGxp c3RpYyBzaW5jZSB0aGVyZSBhcmUgb2Z0ZW4gbW9yZSB0aGFuPGJyPg0KJmd0OyAmZ3Q7IGV4YWN0 bHkgdHdvIHN0YXRlcyAoaW4gdGhpcyBjYXNlLCBlbmFibGVkLCBkaXNhYmxlZCwgZmFpbGVkLCBu b3QtYXZhaWxhYmxlLCAuLi4pLjxicj4NCiZndDsgJmd0OyBTbyB5b3Ugc2V0dGxlIG9uIGJsYW1p bmcgdGhlIG1vZGVsIHdyaXRlci4gOy0pPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC9q czxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBKdWVyZ2Vu IFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NCiZndDsgJmd0OyBQaG9uZTogJiM0Mzs0 OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJp bmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQomZ3Q7ICZndDsgRmF4OiZuYnNwOyAm bmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQom Z3Q7IDxicj4NCjxicj4NCi0tIDxicj4NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH bWJIPGJyPg0KUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGJyPg0K RmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9h PiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0 bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_bbbd4244a0474c48b3fdecb791cb936ahuaweicom_-- From nobody Wed Mar 10 02:01:13 2021 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 B49A73A20C7 for ; Wed, 10 Mar 2021 02:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XScVg98W0pzu for ; Wed, 10 Mar 2021 02:01:09 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20078.outbound.protection.outlook.com [40.107.2.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179E83A20C5 for ; Wed, 10 Mar 2021 02:01:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOficUk2Bg2qYRm7eQqfu5Cjlc1dpaDW6jp+t3OUqZm7ad285hGwWENL2cX5Rae7Bzqj0BCMHS3Sc3n40Tg9KP6C0gxzaJm+aC9Ua8lnn9aEVxcAVi6P9p1S67A9IH5slnPeBHzdVEysmFa7S1wca0W22EUsYvkdjdBEr0g75Rr616MWP/NsspSuOCSkwGs2obZtiTGhIOozerR/1rC3he6pdMEtOzqwBv6BQNHwAtoXsDyislQkoIgW8xP4Dd7N/3l5LTeNyuVTSqQh5jkcgDmy3FkjqGZ88QeMRczdwWjo/4Ya8o2I1Yj2TxFNNqBwIlXg+UaRStBptTYWqyL8bA== 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=T2Kpm4NmjWBCDjf5X8vSiBEg9QzKgCEGG+FXaMI1my4=; b=LQ5EJJx6A1yer7zbtcBkEH0QrhF4CWUJakIXFYVcet+OjQngXnLebxGbu+gtnoaOguCeZY2r1XN2zF29cZq5SaLpFH9xGUCG3QTQGrBhwyfeRWwD3JK65IFbudwrgkRfhThMAXO6lgH16gV+rRLgwsY5vmLVtQuh1UtCAId5xn5d+6NkNR2Q4llicJE6A1j+IuAIUIG1qFyVSeF7eQlnsGtpqquJIOYP6ftHL9dnbWLkmaE6mLrNP2yRR4Y6MG9yChfQqIihhOeAOsZXhegduDvgz7y5oKilMfp6eoygS16cPBFdvUKXKpHhvfdvTcrxNW/9J97N7jIhtbX/xmFgQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T2Kpm4NmjWBCDjf5X8vSiBEg9QzKgCEGG+FXaMI1my4=; b=O//NG9ZPW6/igyOYK3u67rCLZ4Tbd3NmviuvCwzrw+WqrRWaKk+1Fr+rqafT/KGkr0iJKvwRHQ+I2X1ZdamQPhBlYh/INovf/wowuF9ww5Iy/o3eZuTOMTxEko0B0Fzi2bb/7VKCWHtJ+PFOLNlx4rpor1zxAdEp/Q8NrctOIB4= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0578.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:1a1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.29; Wed, 10 Mar 2021 10:01:01 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 10:01:01 +0000 Date: Wed, 10 Mar 2021 11:00:58 +0100 From: Juergen Schoenwaelder To: Italo Busi Cc: 'Andy Bierman' , "netmod@ietf.org" Message-ID: <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Italo Busi , 'Andy Bierman' , "netmod@ietf.org" References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR04CA0024.eurprd04.prod.outlook.com (2603:10a6:208:122::37) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR04CA0024.eurprd04.prod.outlook.com (2603:10a6:208:122::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Wed, 10 Mar 2021 10:01:00 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: db608112-c637-4e29-0d63-08d8e3ab68b3 X-MS-TrafficTypeDiagnostic: AM0P190MB0578: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XkHe3bkJVmbWcseBUZJuermp/l2PrSLQD2UnW1tdjih0j+06bueReXDDm3EhAm391oSFz9fsO1DXs/bLipHFiOTtg4q9dwH/on5eBZFL/5xgsZtuI6brTxJyMxwmDyWjiGDkejNoN1bGmpuOi8tmyMdjY9NS3p+azBI5w/y+oBuUylXTkHPiUuEx3C+zDGsEWuH3RTv6189PCwNZb3zSOzHHSd1aUAAjIMRNnAGa8dA1sHBsJyox6H/v1JacrCxBXnIDsWd+b4oT9W2rgitdjx1g7z04iLF5BPe3lbVtCBv/Cthp4e9iFgtcflQF2jv7M8vp2iQG/grw6oMGN6WbLEtgiiSzqQ3bu9fiJyd8hDjnWod/GIYr12moRs10Vdd9oh77FaAOcibHgem84iZhslwexSWPTELWBToknOpIg8HRoscHOK6gzw6VPri2MTsC8VLa3hiLHm0BEARYj6RjV8AfjXdY3HI4OmyA+ycFlYzNhKhgdf4y4LBrmu6YSayiiTMoowjno9V6wfN8gAw56fd/51+Qd+z6o0Op1terGXPujL2niI9jMNEYI+49L8rmTkFxGs5TqiJ8BRGtwXMKGs4be7cWz+kBlSPbLccDFJg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(366004)(39830400003)(376002)(316002)(6486002)(186003)(26005)(53546011)(16526019)(966005)(8936002)(786003)(2906002)(1076003)(83380400001)(3450700001)(66946007)(66476007)(66556008)(478600001)(6916009)(956004)(5660300002)(8676002)(52116002)(54906003)(86362001)(4326008)(6496006); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ek5OQzVjMms5NE9CNnd3QWNFMFIzNHpRVjA2S0wyc2VIeTdWa2IwWHpLcTJE?= =?utf-8?B?MnJia1hvNjJEbWVBdFliNlZqanJVS2hOc0ZiSjU1OC9qT2ovemh4TlJqL3hS?= =?utf-8?B?angweUdGR1hQaUR4UWlBUmR1ejh6aUZlQUpwUDNkV2JNMko2YjkxZ29oMmZt?= =?utf-8?B?N2Z5dVFQckhzbEptT3VtY21Db1V6NHZmUUN4M3RBdkNpWDJDVnM4WUt2cS9M?= =?utf-8?B?dGxWVFFHN2ZQUS9OL2JncXZHRmp4TEt2ZG9VMS9tNmVSSTFmOHp1T2RmWGxq?= =?utf-8?B?Y2ttQjBBdS9YZE8zbTZBRDM0bUNFOXpLYVZIbms2Y3dFaFpDWlpNc1ZPcHVK?= =?utf-8?B?OXBNR2JDcG82dzNUOGl1eW9XUmQvdGZ5RERNSnhPZEt3Y25BY0E5UTBNb1Va?= =?utf-8?B?Z2dkVGg3WXlhZEhxOVppWkpUQm1pdGRwVi9nYkRzem96ZFNHQUxRTmw3Tndq?= =?utf-8?B?bnFlOE5ycXBROHd5UWFuTG04bkFkSWZkZ3ViN0tjVG9mTXRjektEUzVXdTF6?= =?utf-8?B?dVNEZnlRaHRrMm1MWHFNUWVxUWlyU015bXRhOU14NVBXRnJZMnZYeG4yZThD?= =?utf-8?B?QVRWYW9DeTZjNDJCSDFVSmxUZDhkeTZMR1pxVWdraWV5WW02Q2ZCTUQ0VDVQ?= =?utf-8?B?SjE2MjVMcWQwMStqU3lvQVp6S1pQTUJ3NVEvb1R0ZE15NVd6R0tVdS9OaFdr?= =?utf-8?B?ZGxkSGxQRHo5SFBvYmtURTA3alJrNlpBd25PRm03NWxNcG1qMk1HZEh3SWpj?= =?utf-8?B?UGNjWHE2RTVpNkE0V25GWEx6c3Q1cmduMENhTkg1Rk0xZ1dLeTUzT2FBdVhz?= =?utf-8?B?M1hkV2dYckZrSit3SUVsQ3pnb3pkVjhBaTQwV0IxUVRlcHVKdU83UUhjdUpT?= =?utf-8?B?dTQ3ZDFaNmR0dmhwOWdNSEo4NUwxb0w1dFg2cnFySW5rdERFNmZLZVBuL09s?= =?utf-8?B?Qjg3RzJzZW5CSTFIaTN4S0lLUHhVTkF5cHdGOFUxUmMvRGRCemErYTkxYmFL?= =?utf-8?B?SU5wdXRkSDNYVHljSG9wMkxRbEZOT1pWRnI3OU52OWlvQ1BZdTYzVHhFM2xQ?= =?utf-8?B?UVkrSForcTdwMHJiNkp0V0psRlk3QUVnQ3RVSi96N2hLUWN1V1F3bUIwZ09R?= =?utf-8?B?UTZuck1aZTI5dWEwU0xhNzVwOXB1QUNmVjExck1yR25KY2g1OUp2V2hxWUtH?= =?utf-8?B?bnJoaVdyMHpLbERHS3kyZUR1RFlXQ093b2lsT3VMT1VIaXhSNUhWYUUzWDRH?= =?utf-8?B?QmxRRkEzaVVQN1ZuLzgzMzZ1dWVqK0ZRYTlPcnVrZnpOdWxqOU9SS3IvbHV2?= =?utf-8?B?d1JjQk5VbjZRN0h5eUE5c0RYbWc1VFFGZnRNdkZpYVVLVXNMaXFFU1ZHM3lF?= =?utf-8?B?TkgyQjh0ZDJoWDVoMVBUNzREcVlDaUxYRWpLU0JiREgzR1dXT1UzSCtmUDVO?= =?utf-8?B?ZENhM0hVZHk2K0tQVXluMjhHcjF5V1AyM09kTy9Kb0MyOU0zajNvMVhQTFZK?= =?utf-8?B?YnY4Rll4TzZDQ0lna1JaRGJYZkE0aHY4SUl6Tkl1YmdlZXhQQjZMY1IxajJ3?= =?utf-8?B?ekZuVE80bHA4RHQ4aC83VmtkSnhFYUt0ZGpHZ00yRE9PZ2xWR0ZFcTQrcHln?= =?utf-8?B?N0xtQVJxam5laVZhS2ZEZHVxMStUaVVMK0tYNENndWRtVFh3T0s3T04xc0V5?= =?utf-8?B?L0NIK0V2M3FKOERTU25XZ1FiblZtMWd3ZVRRTjJ4K3U5MlhXUXI0OWRQSlJV?= =?utf-8?Q?oFyeejAp/1bfQBUvdElHtrCx524Tt5TuwNJNQC+?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: db608112-c637-4e29-0d63-08d8e3ab68b3 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2021 10:01:01.4914 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: iyKzW2tYJZdu7f26IpfByoGLUg+ghPyqFh3zSzTOO9tyt51OrtFCykI4mMXsskRQOCcoH9ql87He5Ohn2GDzuws+/k/og8/TPJzf+sthTLk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0578 Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 10:01:12 -0000 A client that has no clue of the annotated leaf can rightfully assume that the default 0 applies. If another client creates this magic leaf that changes the default to 10, then there is going to be confusion. A definition that says 'default 0' says the default is 0. It does not say the default may be zero or something different depending on whether the moon shines or other circumstances. I believe you can't undo a default statement with a description somewhere else. /js On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: > Andy, Juergen, > > I am not sure I understand the issue with a client that does not understand the augment. > > When this client writes in the running DS, it will not set the bar attribute (which is also defined in the augment module) and therefore the default value 0 will be applied by the system, as expected by the client. > > When this client reads from the operational DS the applied configuration, provided by another client which understands the augment, it will see that the applied configuration for the leaf foo is 10. > > This is a valid applied configuration if the other client had explicitly configured the value 10 in the running DS. > > The only difference would be that when the value 10 is explicitly configured by the other client the origin is set to intended while when “implicitly†configured using the attribute bar, the origin can be set to system (I think it would not be correct to set the origin to default in this case). > > BTW, I agree that this is not the most elegant/clean design and that the best approach would be not to define any default value in the base model. I am just willing to understand if a work-around is possible, without breaking any client, to allow re-using an existing module which has already defined a default value. > > Italo > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: martedì 9 marzo 2021 21:12 > To: Juergen Schoenwaelder ; Italo Busi ; netmod@ietf.org > Subject: Re: [netmod] Questions about how to assign default values with YANG > > > > On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder > wrote: > Changing the semantics of a definition via augments is bad design. > > A system that does not understand the augment will believe the default > is 0. Since there is no way to force an existing implementation to > understand a certain augmentation, different implementation will > rightfully disagree on the default value in effect. > > > deviation /ex:example/ex:foo { > delete { > default 0; > } > } > > IMO it was a bad idea to say deviations MUST NOT appear in standard modules. > Here is a use-case for it. > > The old-client does not know about the new dynamic default but it could know > that the old YANG default is not being used. > > > /js > > Andy > > > On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > > Hi Juergen, > > > > Thanks again for your clear explanation on this topic > > > > I have found a similar but slightly different issue. In this case, a YANG default statement exists in the base module but the intention with the augmentation is to "overwrite" the default value on the basis of another attribute, defined in the module which augments the base module. > > > > For example, I am wondering whether such a code is valid: > > > > module example-base { > > container example { > > leaf foo { > > type uint8; > > default 0; > > } > > } > > } > > > > module example-augment { > > import example { > > prefix ex; > > } > > > > augment "ex:example" { > > leaf bar { > > type empty; > > description > > "When present, the default value for foo is 10."; > > } > > } > > } > > > > > > In this case, when the leaf foo is not configured but the leaf bar is present, the value of foo in the operational datastore should be 10 (rather than 0). > > > > In this case, I think that it would be better/cleaner if the origin is marked as system. > > > > Maybe a better YANG description for bar could be: "When present, the system overrides the default value of foo to 10." > > > > What is your and/or WG opinion? > > > > Thanks again > > > > Italo > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: mercoledì 20 gennaio 2021 17:05 > > > To: Italo Busi > > > > Cc: 'netmod@ietf.org' > > > > Subject: Re: [netmod] Questions about how to assign default values with > > > YANG > > > > > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > > > > > > > What about the case the leaf is not conditional (but still mandatory false > > > since a YANG default statement is defined)? > > > > > > > > May the server still decide not to use/implement this leaf in the operational > > > datastore? > > > > > > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by > > > default. > > > > What should be the behavior of a system which does not implement auto- > > > negotiation? > > > > Return the value false or no value (in the operational datastore)? > > > > > > > > > > Here are some of the rules I personally like: > > > > > > - is the ground truth about what a system has and does > > > - do not implement leafs that do not apply > > > > > > Hence, interfaces supporting auto-negotiation have either auto- > > > negotiation/enabled = true or auto-negotiation/enabled = false in > > > . And interfaces not supporting auto-negotiation have nothing > > > to report about auto-negotiation. Yes, I do not want to see auto- > > > negotiation/enabled = false on a loopback interface. > > > > > > My historic Ethernet interface from the last century would also not report > > > auto-negotiation/enabled in . You may hit applications that love > > > to have auto-negotiation/enabled available on all Ethernet interfaces and then > > > you end in a debate where the application developers tell you that no > > > information in may have many reasons (instrumentation not > > > implemented, access control rules, whatever and by reporting enabled=false > > > you do them a favor) but the true answer in such a debate is often that > > > modeling things as a boolean is simplistic since there are often more than > > > exactly two states (in this case, enabled, disabled, failed, not-available, ...). > > > So you settle on blaming the model writer. ;-) > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 10 02:21:33 2021 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 22E183A20E6 for ; Wed, 10 Mar 2021 02:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 wRahfi8YXTuL for ; Wed, 10 Mar 2021 02:21:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F0A3A1FB9 for ; Wed, 10 Mar 2021 02:21:29 -0800 (PST) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id B9292140AB7; Wed, 10 Mar 2021 11:21:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1615371686; bh=HE1Tr6iT8k7JUp4dymz9pCmqwhRNYZxzOKiW2UL5uDU=; h=From:To:Date; b=XbGlS2phgOZIk8KJEUb4C1aCkbEpQPYfB0Wo1QN10VY5yzcKUqeBYhWHY+pq7dNZs CHLArOnEHb40kswJNedtKh+U9aTphJK03ByVJZTYvKMD6KWU3wYc9wLQBvyapGtoLf 88y4CHLgmPhOw0CubecHjCJ12XdUTfviQbVcYZJA= From: Ladislav Lhotka To: Juergen Schoenwaelder , Italo Busi Cc: "netmod@ietf.org" In-Reply-To: <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> Mail-Followup-To: Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" Date: Wed, 10 Mar 2021 11:21:26 +0100 Message-ID: <87h7ljfgwp.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 10:21:32 -0000 Juergen Schoenwaelder writes: > A client that has no clue of the annotated leaf can rightfully assume > that the default 0 applies. If another client creates this magic leaf > that changes the default to 10, then there is going to be confusion. > > A definition that says 'default 0' says the default is 0. It does not > say the default may be zero or something different depending on > whether the moon shines or other circumstances. I believe you can't > undo a default statement with a description somewhere else. The problem with descriptions is that there seems to be a general agreement= that they can somehow supplement the formal YANG statements in specifying = the data model. This has no support in RFC 7950 though: - section 7.21.3 only says that a description is "a human-readable textual description of this definition" - section 8.1 doesn't include constraints specified in descriptions in the concept of data tree validity As a result, data model constraints specified in descriptions is a grey are= a, and it is totally unclear how far-reaching they can possibly be. Lada > > /js > > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: >> Andy, Juergen, >>=20 >> I am not sure I understand the issue with a client that does not underst= and the augment. >>=20 >> When this client writes in the running DS, it will not set the bar attri= bute (which is also defined in the augment module) and therefore the defaul= t value 0 will be applied by the system, as expected by the client. >>=20 >> When this client reads from the operational DS the applied configuration= , provided by another client which understands the augment, it will see tha= t the applied configuration for the leaf foo is 10. >>=20 >> This is a valid applied configuration if the other client had explicitly= configured the value 10 in the running DS. >>=20 >> The only difference would be that when the value 10 is explicitly config= ured by the other client the origin is set to intended while when =E2=80=9C= implicitly=E2=80=9D configured using the attribute bar, the origin can be s= et to system (I think it would not be correct to set the origin to default = in this case). >>=20 >> BTW, I agree that this is not the most elegant/clean design and that the= best approach would be not to define any default value in the base model. = I am just willing to understand if a work-around is possible, without break= ing any client, to allow re-using an existing module which has already defi= ned a default value. >>=20 >> Italo >>=20 >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: marted=C3=AC 9 marzo 2021 21:12 >> To: Juergen Schoenwaelder ; Italo = Busi ; netmod@ietf.org >> Subject: Re: [netmod] Questions about how to assign default values with = YANG >>=20 >>=20 >>=20 >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder > wrote: >> Changing the semantics of a definition via augments is bad design. >>=20 >> A system that does not understand the augment will believe the default >> is 0. Since there is no way to force an existing implementation to >> understand a certain augmentation, different implementation will >> rightfully disagree on the default value in effect. >>=20 >>=20 >> deviation /ex:example/ex:foo { >> delete { >> default 0; >> } >> } >>=20 >> IMO it was a bad idea to say deviations MUST NOT appear in standard modu= les. >> Here is a use-case for it. >>=20 >> The old-client does not know about the new dynamic default but it could = know >> that the old YANG default is not being used. >>=20 >>=20 >> /js >>=20 >> Andy >>=20 >>=20 >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: >> > Hi Juergen, >> > >> > Thanks again for your clear explanation on this topic >> > >> > I have found a similar but slightly different issue. In this case, a Y= ANG default statement exists in the base module but the intention with the = augmentation is to "overwrite" the default value on the basis of another at= tribute, defined in the module which augments the base module. >> > >> > For example, I am wondering whether such a code is valid: >> > >> > module example-base { >> > container example { >> > leaf foo { >> > type uint8; >> > default 0; >> > } >> > } >> > } >> > >> > module example-augment { >> > import example { >> > prefix ex; >> > } >> > >> > augment "ex:example" { >> > leaf bar { >> > type empty; >> > description >> > "When present, the default value for foo is 10."; >> > } >> > } >> > } >> > >> > >> > In this case, when the leaf foo is not configured but the leaf bar is = present, the value of foo in the operational datastore should be 10 (rather= than 0). >> > >> > In this case, I think that it would be better/cleaner if the origin is= marked as system. >> > >> > Maybe a better YANG description for bar could be: "When present, the s= ystem overrides the default value of foo to 10." >> > >> > What is your and/or WG opinion? >> > >> > Thanks again >> > >> > Italo >> > >> > > -----Original Message----- >> > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-universit= y.de] >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 >> > > To: Italo Busi > >> > > Cc: 'netmod@ietf.org' > >> > > Subject: Re: [netmod] Questions about how to assign default values w= ith >> > > YANG >> > > >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: >> > > > >> > > > What about the case the leaf is not conditional (but still mandato= ry false >> > > since a YANG default statement is defined)? >> > > > >> > > > May the server still decide not to use/implement this leaf in the = operational >> > > datastore? >> > > > >> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabl= ed by >> > > default. >> > > > What should be the behavior of a system which does not implement a= uto- >> > > negotiation? >> > > > Return the value false or no value (in the operational datastore)? >> > > > >> > > >> > > Here are some of the rules I personally like: >> > > >> > > - is the ground truth about what a system has and does >> > > - do not implement leafs that do not apply >> > > >> > > Hence, interfaces supporting auto-negotiation have either auto- >> > > negotiation/enabled =3D true or auto-negotiation/enabled =3D false in >> > > . And interfaces not supporting auto-negotiation have n= othing >> > > to report about auto-negotiation. Yes, I do not want to see auto- >> > > negotiation/enabled =3D false on a loopback interface. >> > > >> > > My historic Ethernet interface from the last century would also not = report >> > > auto-negotiation/enabled in . You may hit applications = that love >> > > to have auto-negotiation/enabled available on all Ethernet interface= s and then >> > > you end in a debate where the application developers tell you that no >> > > information in may have many reasons (instrumentation = not >> > > implemented, access control rules, whatever and by reporting enabled= =3Dfalse >> > > you do them a favor) but the true answer in such a debate is often t= hat >> > > modeling things as a boolean is simplistic since there are often mor= e than >> > > exactly two states (in this case, enabled, disabled, failed, not-ava= ilable, ...). >> > > So you settle on blaming the model writer. ;-) >> > > >> > > /js >> > > >> > > -- >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >> > > Fax: +49 421 200 3103 >> > >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 10 02:49:56 2021 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 C5B183A21A7 for ; Wed, 10 Mar 2021 02:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, 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=Ig6MJiIf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n291ELoP 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 CBJNvZuH9tpA for ; Wed, 10 Mar 2021 02:49:50 -0800 (PST) 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 C49CE3A21A4 for ; Wed, 10 Mar 2021 02:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14442; q=dns/txt; s=iport; t=1615373390; x=1616582990; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=25l1kDNuOYSpInvd4cPuaw85TKM6PUD5CvxeNbiEyPg=; b=Ig6MJiIfIfSPATjdzsvvXL00/5XRuMEuzJw3hhrZMRca5b+gdbmA48iI TsBQazWd4h8ZyIIBeSqsPjfK8OI1AP3Lxij5SXXvlHKhmNiwucCZ8CV4X TLuxut+B2IGrlBfCPz+ljlfTAiVRbnqMzYcshAyjOHGg/c/xISAgTB5vo s=; X-IPAS-Result: =?us-ascii?q?A0D6AAANo0hgkJtdJa1aHQEBAQEJARIBBQUBQIE+BQELA?= =?us-ascii?q?YEiMFF9WjYxCod/A4U5iFkDgQaTIoRzglMDVAsBAQENAQEyAgQBAYRNAoFyA?= =?us-ascii?q?iU3Bg4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGOA2GRAEBAQQtEwEBO?= =?us-ascii?q?A8CAQgRBAEBLzIdCAEBBAESCBeCUQGBflcDLwGiLgKKHnSBNIMEAQEGhRcYg?= =?us-ascii?q?hMJgTmCdoQHhkYmHIFJQoERQ4IjBy4+hD+DSIIrgkQGfFaBNREHZwKQU4sJg?= =?us-ascii?q?0WaaQqDAJxPpACPXYUOnXwihCYCAgICBAUCDgEBBoFqIoFZcBWDJFAXAg2OH?= =?us-ascii?q?xmDVopZczgCBgoBAQMJfIlBLYEGAYEOAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AkPEm8xaZ4YJe972oyWogzyj/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4XG4u1JiqzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZ0DbvXCzqzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,237,1610409600"; d="scan'208,217";a="658686516" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Mar 2021 10:49:49 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 12AAnnOT028954 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 10 Mar 2021 10:49:49 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 10 Mar 2021 04:49:49 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Mar 2021 05:49:40 -0500 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 10 Mar 2021 04:49:40 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GI6tWBaDzobyyF8wE0UyrQ8BImZWdxEbpR+kyiImv8QdONgS7wcFpp/fYWY6DRZUmFYk+54E9oLipTydwabJ2BVrno0iMOagYV+UEMW7Vxo562G0fymKJJCr0UaubG2hri/+d74ag4N9XhRkemHRUIyyw5NrEsm+2SSR4WJsmCB08zt0yhRf+6K2AvZWCassWE0RWQRPe9RXkot/M3dBXG9J/mQC31r8cpo4N4AFuzxAtelO+M7y7/8g7GHpv4p/HnRWI1mM6G+3kXrxWoLDYYttyuHBjAdC0C4kQ5kJtewE5+Z9/NJxWTo80MFWDF8nox/r27nXsN2m3Nn9UGgz1A== 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=sQxcxfRPHEU2Gz9qyVZ6ffIEiMZgyeJ4dfmky/VuxXE=; b=by0uwNywVVtC+uAgYiz0jOwE28bZ1yy8cEdHVXlUEWjw93+T+wtWxWSN30Nw1TkzJjx7XVqrshw7nXIwShaSm5jZmzjCrycwBUhdVYKATanIPXYiCTs5/Ypmw5168ZKAX8SyQvR54NUoc1FiadcUbJ4Of09EOeoOV960i3HArEUu+UQU/5oG+WR2X6rg5xq8MoJQali8e1QN8XHzgl+U/6qbxKbovJTF0e5yB1P/EaxZdGMQAmsaE8NGFtqsrEaGqgoxrfQxhiklDlWOKZJjk4BSwryWGy5jSZke1um5b2wTwpO0NOO2MqgHeBlLABUTcdx1uGTaKfXLG1nohUk7wg== 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=sQxcxfRPHEU2Gz9qyVZ6ffIEiMZgyeJ4dfmky/VuxXE=; b=n291ELoPhRIOVhPdHVtvfA+yAPPrnGOTeNMX8G1uV792uwX8zieNRB0/BkLEMydFWmrvAXwdpBg/bOwHxCg1Jh+SuvAy9kRVe0HTtVvacAHTI3Fpr/Rc2C+4j5CV2Ubhcx6UiRg7N7Y2gV2mG1AD3x86WqNoMoDJorejzW7NFqI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4583.namprd11.prod.outlook.com (2603:10b6:208:26a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.29; Wed, 10 Mar 2021 10:49:39 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3912.027; Wed, 10 Mar 2021 10:49:39 +0000 From: "Rob Wilton (rwilton)" To: Italo Busi , "'netmod@ietf.org'" Thread-Topic: Question about validation of the running datastore Thread-Index: AdcUWKEL4642SwgUTmapkFU2qHpl/gBQSfSg Date: Wed, 10 Mar 2021 10:49:38 +0000 Message-ID: References: <05f29409f0344549aa0de1da574cd9ad@huawei.com> In-Reply-To: <05f29409f0344549aa0de1da574cd9ad@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.26] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca50ca7e-9c30-4e04-b1ec-08d8e3b2342a x-ms-traffictypediagnostic: MN2PR11MB4583: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N7T3ihCIA07tgxgjDW9EI7nfPXhZf/VvAibzfimFlt/Hqz4U/NXwtJnWaLhnNQGqt2gFVgUbjr7ITcKFNEdxyosshFrAE49iaIKIxaDSwQ+B9sFfALYwEW3qLM9fICuVRRU/gUW1RZBVU7UwE4S+te1FtI9CofnQ8pWcU2ecbTwPxyP//OjkbncDWEVXSmk5TZAUwKd8HKt+l3SR0XzGjTGmRUc+pd2JLVUbm63r7c3GGvAIPfjubNCsfBgHdZuQp8Oe3RpJ/S/15MRh8kqkOZ7jaIL4kHD0SWfr8ZObAALrhaB0Tw3MPFBF2vLifkQPXqUF7uZMdV2vXm+nmEO72IEojDwTs6NKXdUWAyOs38fqQEFFVKidDKtb0vSgqs00POqRc7xWhou5U0S2tglEJ9nk+zrjX1cpiXYLTcSKmQg3lrf3R82yyZoHUiJ3YvDFU3qj3x8zNuEmOwTOK1PDLld7Q0XLdZKQlclDvmlxg5dGU8NrAq2tc1hEk1Vgfj8DLHr1FQWzPuyQ9ZfydINBpow4zLXnYDtqYJI+ygwQkfPIpbn0BW6MWHAoQ+E66ie/ 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:(136003)(396003)(366004)(346002)(39860400002)(376002)(86362001)(316002)(110136005)(186003)(33656002)(2906002)(55016002)(5660300002)(9686003)(71200400001)(26005)(52536014)(6506007)(53546011)(7696005)(9326002)(76116006)(66476007)(66946007)(8936002)(66556008)(83380400001)(64756008)(66446008)(8676002)(478600001)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?37QASTFGR3sv3LU4X3wFV7Fu50+W7RbFL/i26xvbU9sNDknI3CCL8HA0ho9I?= =?us-ascii?Q?HUH5iKiUi4G335sYeQcOTQibDd7lC++NhYnZ9jTs5u/AVlzANOKUsrAQiJYe?= =?us-ascii?Q?nZ5ICS+Dcb3TUGSzVMoxy/bPtmbTrvTMA5vfLSn/PQCDKgHbbEtj7zR3Dxfr?= =?us-ascii?Q?SCjUtZU4amDpyh2rL5FVhUj0fMxFm/DiAn5hWQE3Wmwmxmep/U5NKhDYCFJg?= =?us-ascii?Q?kJVeZw3bamm//wXft2bNcpR0g7Ok/QNBJYGdPkW81b/wtNYz2j0xqQ5kG6RU?= =?us-ascii?Q?kjQ1jYNjagYkgB1MMn+heeBpF9+bsDTIKe8E25wIFGrwPFtF0N445XFWmX0T?= =?us-ascii?Q?1UVBe55h3YhpVbJ7nW8faNOl4Me+79HJC3O461OTvE924BWEnQEMUzSMZXNf?= =?us-ascii?Q?lJfKe9b+/tXV202OErDJsPzo1DEbqh66DEfsWmiOnqcpDzcpy7t+JdmUBcr6?= =?us-ascii?Q?UpMgsMO7zHVaOBtyo/vSjgohIEQADJl+6IawnXNDWVHcJfhfD24l3XTcyqOk?= =?us-ascii?Q?biAg054SnE8evwYMQ7uXmkRF0Z0bwwS8rTy2WowO/Kf0NK90b+1AbLKCAUJQ?= =?us-ascii?Q?bYryipNG0+t3ZdZzSJ7Mf3+pJj1RIDF1oupqC6kjfPmSgBMfZHQhfb4hHyX2?= =?us-ascii?Q?pyu1rMPt7f++LHIqtaHIASvjsIEu+MQ1sEe0uBjfObzquEzHDZUZPi5WIRA3?= =?us-ascii?Q?WyidRe7eYzO/eVrQnksrlqR17YBztbJlAB/795xNV7VHC0iVYfWR/L6mFW8J?= =?us-ascii?Q?C0fcSKANR3G0fN2Le1a2H43628IrJvDx7QT4WYmuj9c0YrzeKY+I0GOjxicH?= =?us-ascii?Q?W5OylddbE9ZEKJaI2fXsTSxYMTF5zVUpeKfQ/2ipZBkoX6IvmrO6WE5gBlQu?= =?us-ascii?Q?OwGNqwUEDA6+KAq/G/PNMs/o3oV71VFYWxh5zCj0LDLFedhSDIwK11afPPrz?= =?us-ascii?Q?occ7mkvvpsCdlzfBNf0aej8b+b/VrpdvVcfu+gr89QjIPD7Jnhjgjpjj87yR?= =?us-ascii?Q?mmtkQIkgoy0Y1nCLpg+Sw/qO6DzbSKYRIr22O6n+C4vEvaQ37NP3KqyaHDnv?= =?us-ascii?Q?W1Ma0aza5z8I6Gn92p0ONUx6RMa7FFX9qDDeQsPZmXCA8XhhqGao0QidUzzn?= =?us-ascii?Q?uGZdPyQKrye10dHTJf3KCq+SFL+QqRx+WQnNL/wwBKhM+gAFl/a1+/JBxWfS?= =?us-ascii?Q?KGbfz5AplLDnXSrhhBowpP3DKKzFreCzeOKPys7PXEen61oY3brfpbpwZLQg?= =?us-ascii?Q?lIrN4yLbb3qv3mH0ZeXhC4OV48yCfJcfvrZyyAYXW4Vbc2Ws72KkYwUwBn40?= =?us-ascii?Q?zZ8=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43666B6A4BBF204854671DA6B5919MN2PR11MB4366namp_" 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: ca50ca7e-9c30-4e04-b1ec-08d8e3b2342a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 10:49:39.0882 (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: YrJdgNu2AklNMfgiGiNqkjM0R8Q/M2rZB+pzJEPrX/Fsrl7W5q4Pib+uZFGSPE0MOneGwCX/ExlRp/OpE9ugQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4583 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netmod] Question about validation of the running datastore X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 10:49:54 -0000 --_000_MN2PR11MB43666B6A4BBF204854671DA6B5919MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Italo, For NMDA: * The device should accept the configuration if it is plausible that th= e configuration could be applied. E.g., if you had the right linecards ins= erted, with the right optics, and the configuration won't exhaust the avail= able resources. * Once the device has accepted the configuration, then it should make i= ts best effort to apply that configuration, but some of that configuration = could fail to be applied for many reasons. E.g., hardware missing or faile= d, process bugs/failures, out of resources. * The operational datastore always reports exactly what the device is a= ctually doing. I.e., the operator is expected to monitor the operational = state of the device to determine whether the device is working correctly (w= hich includes whether the expected configuration has been successfully appl= ied). Enhancements like NMDA-diff may help achieve this. Conversely, the device can decide that the configuration is not valid and t= hen reject the configuration change (with appropriate errors being reported= ). Then the configuration and operational state of the device is left unch= anged. Regards, Rob // As a contributor. From: netmod On Behalf Of Italo Busi Sent: 08 March 2021 20:24 To: 'netmod@ietf.org' Subject: [netmod] Question about validation of the running datastore Hi all, I have a doubt about how and when the configured data in the running datast= ore can be validated. According to section 5.1.3 of RFC8342: MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]. In some cases, there are some complex semantic validation rules which canno= t be encoded in the rules defined in Section 8.1 of [RFC7950]. In this case the configuration is, from a semantic perspective, invalid and= cannot be applied, even if the configuration data tree is valid as defined= in Section 8.1 of [RFC7950]. It is not clear to me what is the expected behavior of the system when the = client provides such a configuration. One possible option is that the system accepts that configuration but it do= es not apply it. In this case, the configuration is written in the datastore, but never applied in the datastore. Another possible option is that the system accepts that configuration, it d= oes not apply it but returns to the client a warning message. Also in this = case, the configuration is written in the datastore, but never ap= plied in the datastore. A third option is that the system rejects that configuration and returns to= the client an error message. In this case, the configuration is not writte= n in the datastore and thus never applied in the da= tastore. I am wondering whether all these implementation options are allowed or whet= her there are some standard requirements/restrictions on some of them. Thanks, Italo --_000_MN2PR11MB43666B6A4BBF204854671DA6B5919MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Italo,=

&nbs= p;

For NMDA:=

  • The device should accept the con= figuration if it is plausible that the configuration could be applied. &nbs= p;E.g., if you had the right linecards inserted, with the right optics, and= the configuration won’t exhaust the available resources.
  • Once the device has accepted the= configuration, then it should make its best effort to apply that configura= tion, but some of that configuration could fail to be applied for many reas= ons.  E.g., hardware missing or failed, process bugs/failures, out of resources.
  • The operational datastore always= reports exactly what the device is actually doing.   I.e., the o= perator is expected to monitor the operational state of the device to deter= mine whether the device is working correctly (which includes whether the expected configuration has been successfully a= pplied).  Enhancements like NMDA-diff may help achieve this.

 

Conversely, the device can decide that the configuration= is not valid and then reject the configuration change (with appropriate er= rors being reported).  Then the configuration and operational state of the device is left unchanged.

&nbs= p;

Regards,
Rob

 

// As a contributor.

 

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of Italo Busi
Sent: 08 March 2021 20:24
To: 'netmod@ietf.org' <netmod@ietf.org>
Subject: [netmod] Question about validation of the running datastore=

 

Hi all,

 

I have a doubt about how and wh= en the configured data in the running datastore can be validated.

 

According to section 5.1.3 of R= FC8342:

 

   <running> MU= ST always be a valid configuration data tree, as defined<= /p>

   in Section 8.1 of = [RFC7950].

 

In some cases, there are some c= omplex semantic validation rules which cannot be encoded in the rules defin= ed in Section 8.1 of [RFC7950].

 

In this case the configuration = is, from a semantic perspective, invalid and cannot be applied, even if the= configuration data tree is valid as defined in Section 8.1 of [RFC7950].

 

It is not clear to me what is t= he expected behavior of the system when the client provides such a configur= ation.

 

One possible option is that the= system accepts that configuration but it does not apply it. In this case, = the configuration is written in the <running> datastore, but never ap= plied in the <operational> datastore.

 

Another possible option is that= the system accepts that configuration, it does not apply it but returns to= the client a warning message. Also in this case, the configuration is writ= ten in the <running> datastore, but never applied in the <operational> datastore.

 

A third option is that the syst= em rejects that configuration and returns to the client an error message. I= n this case, the configuration is not written in the <running> datast= ore and thus never applied in the <operational> datastore.

 

I am wondering whether all thes= e implementation options are allowed or whether there are some standard req= uirements/restrictions on some of them.

 

Thanks, Italo=

 

--_000_MN2PR11MB43666B6A4BBF204854671DA6B5919MN2PR11MB4366namp_-- From nobody Wed Mar 10 06:16:25 2021 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 B51613A0B41 for ; Wed, 10 Mar 2021 06:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.887 X-Spam-Level: X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a24S8lGaJpld for ; Wed, 10 Mar 2021 06:16:20 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82053A0B20 for ; Wed, 10 Mar 2021 06:16:19 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id r3so25529443lfc.13 for ; Wed, 10 Mar 2021 06:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C9bUIlmGchCpHAzkgtLItrOAMaHxSd26RI57TjonwDc=; b=eBdD69x1aXgwLIhNLlyFoFwqEqP5KXNJq2AwASPAgZN8Sk5Hbcu8hOTvLMdYJ8xCND Y8/XryhWEVivE3gJUtCorkIqBLMJg2SvG8wapmI18Rk2dirqLNSk0qLd7m0LrVp68IZz A43uiFYhT9V085eZnRFoadQEPvj3i9KdJPRiAeaWRl27kZHbkJPue9vKD8+SMu7n4xQd Pn9kkn9OhsqatTtsDrLPGLM53n/Ri6sz7CuxEhvCYn7hTvRSz4WUqCCjkEmtlk7axj/N wZ4OJ3H4OkEFj7uvncuB1zzfxPPloKTp4YGeGp3EUU23ng2RwF631/YZGp5PtvW6eD9x qtMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C9bUIlmGchCpHAzkgtLItrOAMaHxSd26RI57TjonwDc=; b=F+nWHkkYlF97cC4VBvPIuzVpl8fuGOn86M57Jn5Pz9aHvnLiWL2jKbMqgifFB1kO0b p7JSATgEWHcL7nUVshxnFJ/OpYHbRJ5+AoBpLAxNhJJVBbDS+04sWdLeKMisTol4pAwk fdDbrJ/dWLVro/+nBQ/nKvyc07bpgAshiKRIu+FYhMEZKLMIR0gpLNG0HPYBcMNN8FU9 TbKjBwpLiDqmWG2n1fA3HrT/amE50cySiWLJRWBS46Fn04U4dJkV6YfgFirEVELUoLCK FlMJwCjJVcMOf+JmA/kGcilkS58l3UTzuIw88kR1Kf/EdX97KTibRhKF4/zjRZjGumna QPhg== X-Gm-Message-State: AOAM531mbWp56ozjrvwoY1KZ6GyXv9qU8LqNrY74ke3RqaZq8/SKoJAM TdjfMtpodYGmrn5jjj78bDMnQl/FEG9hvhVNFU3y/w== X-Google-Smtp-Source: ABdhPJyVQ6NeuqBHsnviGtvbzzq29klhUWMn3W/+lqV0sq3BhAV1vxRGlt5NRifPRH8C9Uc/vsHfL/Cgz7y2yIg4QRE= X-Received: by 2002:a05:6512:a90:: with SMTP id m16mr2053442lfu.577.1615385777286; Wed, 10 Mar 2021 06:16:17 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Wed, 10 Mar 2021 06:16:06 -0800 Message-ID: To: Italo Busi Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006e42ee05bd2f4f6d" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 14:16:23 -0000 --0000000000006e42ee05bd2f4f6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2021 at 12:54 AM Italo Busi wrote: > Andy, Juergen, > > > > I am not sure I understand the issue with a client that does not > understand the augment. > > > > When this client writes in the running DS, it will not set the bar > attribute (which is also defined in the augment module) and therefore the > default value 0 will be applied by the system, as expected by the client. > > > > When this client reads from the operational DS the applied configuration, > provided by another client which understands the augment, it will see tha= t > the applied configuration for the leaf foo is 10. > > > > This is a valid applied configuration if the other client had explicitly > configured the value 10 in the running DS. > > > > The only difference would be that when the value 10 is explicitly > configured by the other client the origin is set to intended while when > =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, the orig= in can be set to > system (I think it would not be correct to set the origin to default in > this case). > > > > BTW, I agree that this is not the most elegant/clean design and that the > best approach would be not to define any default value in the base model.= I > am just willing to understand if a work-around is possible, without > breaking any client, to allow re-using an existing module which has alrea= dy > defined a default value. > Read sec. 7.6.1 again, especially this part: When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value. Your proposal violates this MUST because the default is in use according to the rules > > > Italo > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* marted=C3=AC 9 marzo 2021 21:12 > *To:* Juergen Schoenwaelder ; Italo > Busi ; netmod@ietf.org > *Subject:* Re: [netmod] Questions about how to assign default values with > YANG > > > > > > > > On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Changing the semantics of a definition via augments is bad design. > > A system that does not understand the augment will believe the default > is 0. Since there is no way to force an existing implementation to > understand a certain augmentation, different implementation will > rightfully disagree on the default value in effect. > > > > > > deviation /ex:example/ex:foo { > > delete { > > default 0; > > } > > } > > > > IMO it was a bad idea to say deviations MUST NOT appear in standard > modules. > > Here is a use-case for it. > > > > The old-client does not know about the new dynamic default but it could > know > > that the old YANG default is not being used. > > > > > > /js > > > > Andy > > > > > On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > > Hi Juergen, > > > > Thanks again for your clear explanation on this topic > > > > I have found a similar but slightly different issue. In this case, a > YANG default statement exists in the base module but the intention with t= he > augmentation is to "overwrite" the default value on the basis of another > attribute, defined in the module which augments the base module. > > > > For example, I am wondering whether such a code is valid: > > > > module example-base { > > container example { > > leaf foo { > > type uint8; > > default 0; > > } > > } > > } > > > > module example-augment { > > import example { > > prefix ex; > > } > > > > augment "ex:example" { > > leaf bar { > > type empty; > > description > > "When present, the default value for foo is 10."; > > } > > } > > } > > > > > > In this case, when the leaf foo is not configured but the leaf bar is > present, the value of foo in the operational datastore should be 10 (rath= er > than 0). > > > > In this case, I think that it would be better/cleaner if the origin is > marked as system. > > > > Maybe a better YANG description for bar could be: "When present, the > system overrides the default value of foo to 10." > > > > What is your and/or WG opinion? > > > > Thanks again > > > > Italo > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto: > j.schoenwaelder@jacobs-university.de] > > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 > > > To: Italo Busi > > > Cc: 'netmod@ietf.org' > > > Subject: Re: [netmod] Questions about how to assign default values wi= th > > > YANG > > > > > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > > > > > > > What about the case the leaf is not conditional (but still mandator= y > false > > > since a YANG default statement is defined)? > > > > > > > > May the server still decide not to use/implement this leaf in the > operational > > > datastore? > > > > > > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enable= d > by > > > default. > > > > What should be the behavior of a system which does not implement > auto- > > > negotiation? > > > > Return the value false or no value (in the operational datastore)? > > > > > > > > > > Here are some of the rules I personally like: > > > > > > - is the ground truth about what a system has and does > > > - do not implement leafs that do not apply > > > > > > Hence, interfaces supporting auto-negotiation have either auto- > > > negotiation/enabled =3D true or auto-negotiation/enabled =3D false in > > > . And interfaces not supporting auto-negotiation have > nothing > > > to report about auto-negotiation. Yes, I do not want to see auto- > > > negotiation/enabled =3D false on a loopback interface. > > > > > > My historic Ethernet interface from the last century would also not > report > > > auto-negotiation/enabled in . You may hit applications > that love > > > to have auto-negotiation/enabled available on all Ethernet interfaces > and then > > > you end in a debate where the application developers tell you that no > > > information in may have many reasons (instrumentation n= ot > > > implemented, access control rules, whatever and by reporting > enabled=3Dfalse > > > you do them a favor) but the true answer in such a debate is often th= at > > > modeling things as a boolean is simplistic since there are often more > than > > > exactly two states (in this case, enabled, disabled, failed, > not-available, ...). > > > So you settle on blaming the model writer. ;-) > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --0000000000006e42ee05bd2f4f6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 10, 2021 at 12:54 AM Ital= o Busi <Italo.Busi@huawei.com> wrote:

Andy, Juergen,

=C2=A0

I am not sure I understand the issue with a = client that does not understand the augment.

=C2=A0

When this client writes in the running DS, i= t will not set the bar attribute (which is also defined in the augment modu= le) and therefore the default value 0 will be applied by the system, as expected by the client.<= /p>

=C2=A0

When this client reads from the operational = DS the applied configuration, provided by another client which understands = the augment, it will see that the applied configuration for the leaf foo is 10.

=C2=A0

This is a valid applied configuration if the= other client had explicitly configured the value 10 in the running DS.<= /u>

=C2=A0

The only difference would be that when the v= alue 10 is explicitly configured by the other client the origin is set to i= ntended while when =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, the origin can be set to system (I think it would= not be correct to set the origin to default in this case).

=C2=A0

BTW, I agree that this is not the most elega= nt/clean design and that the best approach would be not to define any defau= lt value in the base model. I am just willing to understand if a work-around is possible, without breaking any client, t= o allow re-using an existing module which has already defined a default val= ue.



   When the default value is in use, the server M=
UST operationally
   behave as if the leaf was present in the data tree with the default
   value as its value.


Your proposal violate=
s this MUST because the default is in use according to the rules




=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0



Italo


<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: marted=C3=AC 9 marzo 2021 21:12
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Italo Busi <Italo.Busi@huawei.com>; netmod@ietf.org
Subject: Re: [netmod] Questions about how to assign default values w= ith YANG

=C2=A0

=C2=A0

=C2=A0

On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelde= r <j.schoenwaelder@jacobs-university.de> wrote:

Changing the semantics = of a definition via augments is bad design.

A system that does not understand the augment will believe the default
is 0. Since there is no way to force an existing implementation to
understand a certain augmentation, different implementation will
rightfully disagree on the default value in effect.

=C2=A0

=C2=A0

deviation /ex:example/ex:foo {

=C2=A0 =C2=A0 delete {

=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;<= /p>

=C2=A0 =C2=A0 =C2=A0}

}

=C2=A0

IMO it was a bad idea to say deviations MUST NOT app= ear in standard modules.

Here is a use-case for it.

=C2=A0

The old-client does not know about the new dynamic d= efault but it could know

that the old YANG default is not being used.<= u>

=C2=A0

=C2=A0

/js

=C2=A0

Andy

=C2=A0


On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote:
> Hi Juergen,
>
> Thanks again for your clear explanation on this topic
>
> I have found a similar but slightly different issue. In this case, a Y= ANG default statement exists in the base module but the intention with the = augmentation is to "overwrite" the default value on the basis of = another attribute, defined in the module which augments the base module.
>
> For example, I am wondering whether such a code is valid:
>
> module example-base {
>=C2=A0 =C2=A0container example {
>=C2=A0 =C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> module example-augment {
>=C2=A0 =C2=A0import example {
>=C2=A0 =C2=A0 =C2=A0prefix ex;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0augment "ex:example" {
>=C2=A0 =C2=A0 =C2=A0leaf bar {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When present, the default value= for foo is 10.";
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
>
> In this case, when the leaf foo is not configured but the leaf bar is = present, the value of foo in the operational datastore should be 10 (rather= than 0).
>
> In this case, I think that it would be better/cleaner if the origin is= marked as system.
>
> Maybe a better YANG description for bar could be: "When present, = the system overrides the default value of foo to 10."
>
> What is your and/or WG opinion?
>
> Thanks again
>
> Italo
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-univers= ity.de]
> > Sent: mercoled=C3=AC 20 gennaio 2021 17:05
> > To: Italo Busi <Italo.Busi@huawei.com>
> > Cc: 'net= mod@ietf.org' <netmod@ietf.org>
> > Subject: Re: [netmod] Questions about how to assign default value= s with
> > YANG
> >
> > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote:
> > >
> > > What about the case the leaf is not conditional (but still m= andatory false
> > since a YANG default statement is defined)?
> > >
> > > May the server still decide not to use/implement this leaf i= n the operational
> > datastore?
> > >
> > > For example, in appendix C.1 of RFC8342, auto-negotiation is= enabled by
> > default.
> > > What should be the behavior of a system which does not imple= ment auto-
> > negotiation?
> > > Return the value false or no value (in the operational datas= tore)?
> > >
> >
> > Here are some of the rules I personally like:
> >
> >=C2=A0 - <operational> is the ground truth about what a syst= em has and does
> >=C2=A0 - do not implement leafs that do not apply
> >
> > Hence, interfaces supporting auto-negotiation have either auto- > > negotiation/enabled =3D true or auto-negotiation/enabled =3D fals= e in
> > <operational>. And interfaces not supporting auto-negotiati= on have nothing
> > to report about auto-negotiation. Yes, I do not want to see auto-=
> > negotiation/enabled =3D false on a loopback interface.
> >
> > My historic Ethernet interface from the last century would also n= ot report
> > auto-negotiation/enabled in <operational>. You may hit appl= ications that love
> > to have auto-negotiation/enabled available on all Ethernet interf= aces and then
> > you end in a debate where the application developers tell you tha= t no
> > information in <operational> may have many reasons (instrum= entation not
> > implemented, access control rules, whatever and by reporting enab= led=3Dfalse
> > you do them a favor) but the true answer in such a debate is ofte= n that
> > modeling things as a boolean is simplistic since there are often = more than
> > exactly two states (in this case, enabled, disabled, failed, not-= available, ...).
> > So you settle on blaming the model writer. ;-)
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http= s://www.jacobs-university.de/>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jac= obs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

--0000000000006e42ee05bd2f4f6d-- From nobody Wed Mar 10 06:34:06 2021 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 810693A0CCB for ; Wed, 10 Mar 2021 06:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqdkPqi3Bm_Q for ; Wed, 10 Mar 2021 06:34:02 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01C33A0CC7 for ; Wed, 10 Mar 2021 06:34:01 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id hs11so39148136ejc.1 for ; Wed, 10 Mar 2021 06:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JuCp3FPrZHjMqSw0xMdJdjXC0bGYNmWkAtr9y6TEbqc=; b=HHpyLwDkZikeV3mlxMh3r9Ecr08rn1fc0MnvvQLDUYJdmn5Bm6Cgqk7TP2ZFmDdLNb VFfdzYCzaKP4r7hYhwcq/MfGPA+DW7pjyZNTVedY2PatKxRhNmjO77wPffuxFMDHe0ez P7AIvmfcmcxbUYwvtMU8ilGHBbctczDyCuLlGnjEcSmudha+1R8VwmldZxo5TdhUdBV8 ikISGmbXJKBYmoLko3rFt7zsYoNeg1fan/VVeOWTKEEuTcb7IFr1IYLe5q45jXSmmDcM HaWyMGuM5hZd56YDY6AMsaDksj3LDq0lfNEh2LyNk96NOPPiHTMUWzWijiLaOVfZYIX/ 0EhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JuCp3FPrZHjMqSw0xMdJdjXC0bGYNmWkAtr9y6TEbqc=; b=bL86jJZTqAdOI2CgUntBj4sH6qj/GQa4i2DJ2RQleGcgf7AmXeVB6ISHtz+nFCUCLn BdEUsQ90fy5Gs/6sv2pjbr6wbwb6T/lJIWmFJbYQ4brMHdGk39GvavUOYDtRsvfZbDt8 tfV3dAHauQbkweqobRZz/IqwdkhQc5Ue0Zjvyv8c3aXeaM7TKxjIrPcLFi1p9XCCXn5v ha2MM2ZyXDn9l+VmQk1SSo8MuQUxcbAEP6jBZvIhYFeL09uc/ZV3DTvcnzBGVyN2iuAK NIP4KStscHWIgZ9Y8KaMWn2rCM2555yZNFLxyl1PDToubFLMgvBE2U4WY8ZJZKWtl8OM 75lg== X-Gm-Message-State: AOAM531l9pHEkIcrcaeRwOkvr04tTbyc4xgUtv3PmnW6aqx+n3lCIFLg UadqBkeospYvI1CYgLnig9JozGeml47fpjZ6i3jhNA== X-Google-Smtp-Source: ABdhPJw5jkP1RC2nvJiqsFyfAJjtY2gUEsC2UrdAtbcJ6fF3OlFNj/89Z7XiWkOgHP/zZhvV0sq05akV9GvjJcfpIWg= X-Received: by 2002:a17:906:d19b:: with SMTP id c27mr3911390ejz.304.1615386839337; Wed, 10 Mar 2021 06:33:59 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> <87h7ljfgwp.fsf@nic.cz> In-Reply-To: <87h7ljfgwp.fsf@nic.cz> From: William Lupton Date: Wed, 10 Mar 2021 14:33:48 +0000 Message-ID: To: Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bbdbea05bd2f8e4e" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 14:34:06 -0000 --000000000000bbdbea05bd2f8e4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lada, all, Surely a description is the only way to add a normative requirement that can't be expressed via YANG statements (including XPath expressions)? I've always assumed that it's good practice to express what you can using the modeling language, and then use the description to express any non-modelable requirements. Obviously there's a problem if the description conflicts with a modeled requirement (and I think it's also good practice for the description not to repeat anything that's modeled elsewhere). I think that RFC 7950 can be interpreted as indicating that the description is more than just informative. I found this in Section 11, and I take this to imply that the description defines the semantics of a definition. A "description" statement may be added or changed without changing the semantics of the definition. For example, if a description says this (this is an example from RFC 7950), then isn't this a _normative_ semantic requirement? "The amount of local storage that can be used to hold syslog messages." William On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > A client that has no clue of the annotated leaf can rightfully assume > > that the default 0 applies. If another client creates this magic leaf > > that changes the default to 10, then there is going to be confusion. > > > > A definition that says 'default 0' says the default is 0. It does not > > say the default may be zero or something different depending on > > whether the moon shines or other circumstances. I believe you can't > > undo a default statement with a description somewhere else. > > The problem with descriptions is that there seems to be a general > agreement that they can somehow supplement the formal YANG statements in > specifying the data model. This has no support in RFC 7950 though: > > - section 7.21.3 only says that a description is "a human-readable textua= l > description of this definition" > > - section 8.1 doesn't include constraints specified in descriptions in th= e > concept of data tree validity > > As a result, data model constraints specified in descriptions is a grey > area, and it is totally unclear how far-reaching they can possibly be. > > Lada > > > > > /js > > > > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: > >> Andy, Juergen, > >> > >> I am not sure I understand the issue with a client that does not > understand the augment. > >> > >> When this client writes in the running DS, it will not set the bar > attribute (which is also defined in the augment module) and therefore the > default value 0 will be applied by the system, as expected by the client. > >> > >> When this client reads from the operational DS the applied > configuration, provided by another client which understands the augment, = it > will see that the applied configuration for the leaf foo is 10. > >> > >> This is a valid applied configuration if the other client had > explicitly configured the value 10 in the running DS. > >> > >> The only difference would be that when the value 10 is explicitly > configured by the other client the origin is set to intended while when > =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, the orig= in can be set to > system (I think it would not be correct to set the origin to default in > this case). > >> > >> BTW, I agree that this is not the most elegant/clean design and that > the best approach would be not to define any default value in the base > model. I am just willing to understand if a work-around is possible, > without breaking any client, to allow re-using an existing module which h= as > already defined a default value. > >> > >> Italo > >> > >> From: Andy Bierman [mailto:andy@yumaworks.com] > >> Sent: marted=C3=AC 9 marzo 2021 21:12 > >> To: Juergen Schoenwaelder ; > Italo Busi ; netmod@ietf.org > >> Subject: Re: [netmod] Questions about how to assign default values wit= h > YANG > >> > >> > >> > >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de j.schoenwaelder@jacobs-university.de>> wrote: > >> Changing the semantics of a definition via augments is bad design. > >> > >> A system that does not understand the augment will believe the default > >> is 0. Since there is no way to force an existing implementation to > >> understand a certain augmentation, different implementation will > >> rightfully disagree on the default value in effect. > >> > >> > >> deviation /ex:example/ex:foo { > >> delete { > >> default 0; > >> } > >> } > >> > >> IMO it was a bad idea to say deviations MUST NOT appear in standard > modules. > >> Here is a use-case for it. > >> > >> The old-client does not know about the new dynamic default but it coul= d > know > >> that the old YANG default is not being used. > >> > >> > >> /js > >> > >> Andy > >> > >> > >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > >> > Hi Juergen, > >> > > >> > Thanks again for your clear explanation on this topic > >> > > >> > I have found a similar but slightly different issue. In this case, a > YANG default statement exists in the base module but the intention with t= he > augmentation is to "overwrite" the default value on the basis of another > attribute, defined in the module which augments the base module. > >> > > >> > For example, I am wondering whether such a code is valid: > >> > > >> > module example-base { > >> > container example { > >> > leaf foo { > >> > type uint8; > >> > default 0; > >> > } > >> > } > >> > } > >> > > >> > module example-augment { > >> > import example { > >> > prefix ex; > >> > } > >> > > >> > augment "ex:example" { > >> > leaf bar { > >> > type empty; > >> > description > >> > "When present, the default value for foo is 10."; > >> > } > >> > } > >> > } > >> > > >> > > >> > In this case, when the leaf foo is not configured but the leaf bar i= s > present, the value of foo in the operational datastore should be 10 (rath= er > than 0). > >> > > >> > In this case, I think that it would be better/cleaner if the origin > is marked as system. > >> > > >> > Maybe a better YANG description for bar could be: "When present, the > system overrides the default value of foo to 10." > >> > > >> > What is your and/or WG opinion? > >> > > >> > Thanks again > >> > > >> > Italo > >> > > >> > > -----Original Message----- > >> > > From: Juergen Schoenwaelder [mailto: > j.schoenwaelder@jacobs-university.de j.schoenwaelder@jacobs-university.de>] > >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 > >> > > To: Italo Busi >> > >> > > Cc: 'netmod@ietf.org' > > >> > > Subject: Re: [netmod] Questions about how to assign default values > with > >> > > YANG > >> > > > >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > >> > > > > >> > > > What about the case the leaf is not conditional (but still > mandatory false > >> > > since a YANG default statement is defined)? > >> > > > > >> > > > May the server still decide not to use/implement this leaf in th= e > operational > >> > > datastore? > >> > > > > >> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is > enabled by > >> > > default. > >> > > > What should be the behavior of a system which does not implement > auto- > >> > > negotiation? > >> > > > Return the value false or no value (in the operational datastore= )? > >> > > > > >> > > > >> > > Here are some of the rules I personally like: > >> > > > >> > > - is the ground truth about what a system has and > does > >> > > - do not implement leafs that do not apply > >> > > > >> > > Hence, interfaces supporting auto-negotiation have either auto- > >> > > negotiation/enabled =3D true or auto-negotiation/enabled =3D false= in > >> > > . And interfaces not supporting auto-negotiation have > nothing > >> > > to report about auto-negotiation. Yes, I do not want to see auto- > >> > > negotiation/enabled =3D false on a loopback interface. > >> > > > >> > > My historic Ethernet interface from the last century would also no= t > report > >> > > auto-negotiation/enabled in . You may hit application= s > that love > >> > > to have auto-negotiation/enabled available on all Ethernet > interfaces and then > >> > > you end in a debate where the application developers tell you that > no > >> > > information in may have many reasons (instrumentatio= n > not > >> > > implemented, access control rules, whatever and by reporting > enabled=3Dfalse > >> > > you do them a favor) but the true answer in such a debate is often > that > >> > > modeling things as a boolean is simplistic since there are often > more than > >> > > exactly two states (in this case, enabled, disabled, failed, > not-available, ...). > >> > > So you settle on blaming the model writer. ;-) > >> > > > >> > > /js > >> > > > >> > > -- > >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >> > > Fax: +49 421 200 3103 > >> > > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000bbdbea05bd2f8e4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lada, all,

Surely a descript= ion is the only way to add a normative requirement that can't be expres= sed via YANG statements (including XPath expressions)?

=
I've always assumed that it's good practice to express what yo= u can using the modeling language, and then use the description to express = any non-modelable requirements. Obviously there's a problem if the desc= ription conflicts with a modeled requirement (and I think it's also goo= d practice for the description not to repeat anything=C2=A0that's model= ed elsewhere).

I think that RFC 7950 can be interp= reted as indicating that the description is more than just informative. I f= ound this in Section 11, and I take this to imply that the description defi= nes the semantics of a=C2=A0definition.

A "description" stateme=
nt may be added or changed without changing the
semantics of the definition.

For example, if a description says this (th= is is an example from RFC 7950), then isn't this a _normative_ semantic= requirement?

"The amount of local storage that can be used to hol=
d syslog messages."

William

On Wed, 10 Mar 2021 at 10:21, Ladi= slav Lhotka <ladislav.lhotka@n= ic.cz> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = writes:

> A client that has no clue of the annotated leaf can rightfully assume<= br> > that the default 0 applies. If another client creates this magic leaf<= br> > that changes the default to 10, then there is going to be confusion. >
> A definition that says 'default 0' says the default is 0. It d= oes not
> say the default may be zero or something different depending on
> whether the moon shines or other circumstances. I believe you can'= t
> undo a default statement with a description somewhere else.

The problem with descriptions is that there seems to be a general agreement= that they can somehow supplement the formal YANG statements in specifying = the data model. This has no support in RFC 7950 though:

- section 7.21.3 only says that a description is "a human-readable tex= tual
=C2=A0 description of this definition"

- section 8.1 doesn't include constraints specified in descriptions in = the
=C2=A0 concept of data tree validity

As a result, data model constraints specified in descriptions is a grey are= a, and it is totally unclear how far-reaching they can possibly be.

Lada

>
> /js
>
> On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote:
>> Andy, Juergen,
>>
>> I am not sure I understand the issue with a client that does not u= nderstand the augment.
>>
>> When this client writes in the running DS, it will not set the bar= attribute (which is also defined in the augment module) and therefore the = default value 0 will be applied by the system, as expected by the client. >>
>> When this client reads from the operational DS the applied configu= ration, provided by another client which understands the augment, it will s= ee that the applied configuration for the leaf foo is 10.
>>
>> This is a valid applied configuration if the other client had expl= icitly configured the value 10 in the running DS.
>>
>> The only difference would be that when the value 10 is explicitly = configured by the other client the origin is set to intended while when =E2= =80=9Cimplicitly=E2=80=9D configured using the attribute bar, the origin ca= n be set to system (I think it would not be correct to set the origin to de= fault in this case).
>>
>> BTW, I agree that this is not the most elegant/clean design and th= at the best approach would be not to define any default value in the base m= odel. I am just willing to understand if a work-around is possible, without= breaking any client, to allow re-using an existing module which has alread= y defined a default value.
>>
>> Italo
>>
>> From: Andy Bierman [mailto:andy@yumaworks.com]
>> Sent: marted=C3=AC 9 marzo 2021 21:12
>> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>>; Italo Busi <Italo.Busi@huawei.com>; netmod@ietf.org
>> Subject: Re: [netmod] Questions about how to assign default values= with YANG
>>
>>
>>
>> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <j.schoen= waelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university= .de>> wrote:
>> Changing the semantics of a definition via augments is bad design.=
>>
>> A system that does not understand the augment will believe the def= ault
>> is 0. Since there is no way to force an existing implementation to=
>> understand a certain augmentation, different implementation will >> rightfully disagree on the default value in effect.
>>
>>
>> deviation /ex:example/ex:foo {
>>=C2=A0 =C2=A0 =C2=A0delete {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default 0;
>>=C2=A0 =C2=A0 =C2=A0 }
>> }
>>
>> IMO it was a bad idea to say deviations MUST NOT appear in standar= d modules.
>> Here is a use-case for it.
>>
>> The old-client does not know about the new dynamic default but it = could know
>> that the old YANG default is not being used.
>>
>>
>> /js
>>
>> Andy
>>
>>
>> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote:
>> > Hi Juergen,
>> >
>> > Thanks again for your clear explanation on this topic
>> >
>> > I have found a similar but slightly different issue. In this = case, a YANG default statement exists in the base module but the intention = with the augmentation is to "overwrite" the default value on the = basis of another attribute, defined in the module which augments the base m= odule.
>> >
>> > For example, I am wondering whether such a code is valid:
>> >
>> > module example-base {
>> >=C2=A0 =C2=A0container example {
>> >=C2=A0 =C2=A0 =C2=A0leaf foo {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>> >=C2=A0 =C2=A0 =C2=A0}
>> >=C2=A0 =C2=A0}
>> > }
>> >
>> > module example-augment {
>> >=C2=A0 =C2=A0import example {
>> >=C2=A0 =C2=A0 =C2=A0prefix ex;
>> >=C2=A0 =C2=A0}
>> >
>> >=C2=A0 =C2=A0augment "ex:example" {
>> >=C2=A0 =C2=A0 =C2=A0leaf bar {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When present, the defa= ult value for foo is 10.";
>> >=C2=A0 =C2=A0 =C2=A0}
>> >=C2=A0 =C2=A0}
>> > }
>> >
>> >
>> > In this case, when the leaf foo is not configured but the lea= f bar is present, the value of foo in the operational datastore should be 1= 0 (rather than 0).
>> >
>> > In this case, I think that it would be better/cleaner if the = origin is marked as system.
>> >
>> > Maybe a better YANG description for bar could be: "When = present, the system overrides the default value of foo to 10."
>> >
>> > What is your and/or WG opinion?
>> >
>> > Thanks again
>> >
>> > Italo
>> >
>> > > -----Original Message-----
>> > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacob= s-university.de<mailto:j.schoenwaelder@jacobs-university.de>]<= br> >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05
>> > > To: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>=
>> > > Cc: 'netmod@ietf.org<mailto:netmod@ietf.org>' <netmod@ietf.org<mailto:netmod@ietf.org>>
>> > > Subject: Re: [netmod] Questions about how to assign defa= ult values with
>> > > YANG
>> > >
>> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wro= te:
>> > > >
>> > > > What about the case the leaf is not conditional (bu= t still mandatory false
>> > > since a YANG default statement is defined)?
>> > > >
>> > > > May the server still decide not to use/implement th= is leaf in the operational
>> > > datastore?
>> > > >
>> > > > For example, in appendix C.1 of RFC8342, auto-negot= iation is enabled by
>> > > default.
>> > > > What should be the behavior of a system which does = not implement auto-
>> > > negotiation?
>> > > > Return the value false or no value (in the operatio= nal datastore)?
>> > > >
>> > >
>> > > Here are some of the rules I personally like:
>> > >
>> > >=C2=A0 - <operational> is the ground truth about wh= at a system has and does
>> > >=C2=A0 - do not implement leafs that do not apply
>> > >
>> > > Hence, interfaces supporting auto-negotiation have eithe= r auto-
>> > > negotiation/enabled =3D true or auto-negotiation/enabled= =3D false in
>> > > <operational>. And interfaces not supporting auto-= negotiation have nothing
>> > > to report about auto-negotiation. Yes, I do not want to = see auto-
>> > > negotiation/enabled =3D false on a loopback interface. >> > >
>> > > My historic Ethernet interface from the last century wou= ld also not report
>> > > auto-negotiation/enabled in <operational>. You may= hit applications that love
>> > > to have auto-negotiation/enabled available on all Ethern= et interfaces and then
>> > > you end in a debate where the application developers tel= l you that no
>> > > information in <operational> may have many reasons= (instrumentation not
>> > > implemented, access control rules, whatever and by repor= ting enabled=3Dfalse
>> > > you do them a favor) but the true answer in such a debat= e is often that
>> > > modeling things as a boolean is simplistic since there a= re often more than
>> > > exactly two states (in this case, enabled, disabled, fai= led, not-available, ...).
>> > > So you settle on blaming the model writer. ;-)
>> > >
>> > > /js
>> > >
>> > > --
>> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
>> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
>> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<https://www.jacobs-university.de/>
>> >
>>
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg<mailto:netmo= d@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000bbdbea05bd2f8e4e-- From nobody Wed Mar 10 07:14:03 2021 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 307E33A0F49 for ; Wed, 10 Mar 2021 07:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 mH9VUffzYgst for ; Wed, 10 Mar 2021 07:13:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473FF3A0DDD for ; Wed, 10 Mar 2021 07:13:58 -0800 (PST) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 730FC140075; Wed, 10 Mar 2021 16:13:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1615389235; bh=rcYPSd4fjIFalGcspFi7mge7MM2Vohi9HYo2Nd+wJSQ=; h=From:To:Date; b=vjDL4PJXVSIatatsqYYXZgh7FJRSVtzIKEcywZbCSTa7jOW+3l4zriakkDlW1JHYc eQyObcbW04pIYal41oegJwmvlA8uQbcbUN998cbStrEtRxhvH3RoL1hnLGhYPgZnNA KA6FNBoT0PrRb0sEt4fqcsLOJSaXlgNf/+PnuOLU= From: Ladislav Lhotka To: William Lupton , Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" In-Reply-To: References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> <87h7ljfgwp.fsf@nic.cz> Mail-Followup-To: William Lupton , Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" Date: Wed, 10 Mar 2021 16:13:55 +0100 Message-ID: <87eegnf3d8.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 15:14:01 -0000 William Lupton writes: > Lada, all, > > Surely a description is the only way to add a normative requirement that > can't be expressed via YANG statements (including XPath expressions)? > > I've always assumed that it's good practice to express what you can using > the modeling language, and then use the description to express any > non-modelable requirements. Obviously there's a problem if the description > conflicts with a modeled requirement (and I think it's also good practice > for the description not to repeat anything that's modeled elsewhere). > > I think that RFC 7950 can be interpreted as indicating that the descripti= on > is more than just informative. I found this in Section 11, and I take this > to imply that the description defines the semantics of a definition. Even then, it is unclear what effects are permitted with this "more than in= formative". In a previous mail I refered to a standard module having a desc= ription that defines a (computed) default. This seems to be acceptable. But what about simulating a "when" statement for constraints that cannot be= expressed via XPath? For example: description "This leaf is only valid if the value of foo is prime."; I argued in the past that everything that cannot be expressed formally with= YANG statements should be left outside of scope for YANG, at least in term= s of data tree validation. > > A "description" statement may be added or changed without changing the > > semantics of the definition. > > > For example, if a description says this (this is an example from RFC 7950= ), > then isn't this a _normative_ semantic requirement? > > "The amount of local storage that can be used to hold syslog messages." Hmm, this seems to state semantics (meaning) of a parameter. What I am talk= ing about are semantic constraints (business rules) that a valid data tree = is required to satisfy. Lada > > > William > > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka > wrote: > >> Juergen Schoenwaelder writes: >> >> > A client that has no clue of the annotated leaf can rightfully assume >> > that the default 0 applies. If another client creates this magic leaf >> > that changes the default to 10, then there is going to be confusion. >> > >> > A definition that says 'default 0' says the default is 0. It does not >> > say the default may be zero or something different depending on >> > whether the moon shines or other circumstances. I believe you can't >> > undo a default statement with a description somewhere else. >> >> The problem with descriptions is that there seems to be a general >> agreement that they can somehow supplement the formal YANG statements in >> specifying the data model. This has no support in RFC 7950 though: >> >> - section 7.21.3 only says that a description is "a human-readable textu= al >> description of this definition" >> >> - section 8.1 doesn't include constraints specified in descriptions in t= he >> concept of data tree validity >> >> As a result, data model constraints specified in descriptions is a grey >> area, and it is totally unclear how far-reaching they can possibly be. >> >> Lada >> >> > >> > /js >> > >> > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: >> >> Andy, Juergen, >> >> >> >> I am not sure I understand the issue with a client that does not >> understand the augment. >> >> >> >> When this client writes in the running DS, it will not set the bar >> attribute (which is also defined in the augment module) and therefore the >> default value 0 will be applied by the system, as expected by the client. >> >> >> >> When this client reads from the operational DS the applied >> configuration, provided by another client which understands the augment,= it >> will see that the applied configuration for the leaf foo is 10. >> >> >> >> This is a valid applied configuration if the other client had >> explicitly configured the value 10 in the running DS. >> >> >> >> The only difference would be that when the value 10 is explicitly >> configured by the other client the origin is set to intended while when >> =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, the ori= gin can be set to >> system (I think it would not be correct to set the origin to default in >> this case). >> >> >> >> BTW, I agree that this is not the most elegant/clean design and that >> the best approach would be not to define any default value in the base >> model. I am just willing to understand if a work-around is possible, >> without breaking any client, to allow re-using an existing module which = has >> already defined a default value. >> >> >> >> Italo >> >> >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> >> Sent: marted=C3=AC 9 marzo 2021 21:12 >> >> To: Juergen Schoenwaelder ; >> Italo Busi ; netmod@ietf.org >> >> Subject: Re: [netmod] Questions about how to assign default values wi= th >> YANG >> >> >> >> >> >> >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>> wrote: >> >> Changing the semantics of a definition via augments is bad design. >> >> >> >> A system that does not understand the augment will believe the default >> >> is 0. Since there is no way to force an existing implementation to >> >> understand a certain augmentation, different implementation will >> >> rightfully disagree on the default value in effect. >> >> >> >> >> >> deviation /ex:example/ex:foo { >> >> delete { >> >> default 0; >> >> } >> >> } >> >> >> >> IMO it was a bad idea to say deviations MUST NOT appear in standard >> modules. >> >> Here is a use-case for it. >> >> >> >> The old-client does not know about the new dynamic default but it cou= ld >> know >> >> that the old YANG default is not being used. >> >> >> >> >> >> /js >> >> >> >> Andy >> >> >> >> >> >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: >> >> > Hi Juergen, >> >> > >> >> > Thanks again for your clear explanation on this topic >> >> > >> >> > I have found a similar but slightly different issue. In this case, a >> YANG default statement exists in the base module but the intention with = the >> augmentation is to "overwrite" the default value on the basis of another >> attribute, defined in the module which augments the base module. >> >> > >> >> > For example, I am wondering whether such a code is valid: >> >> > >> >> > module example-base { >> >> > container example { >> >> > leaf foo { >> >> > type uint8; >> >> > default 0; >> >> > } >> >> > } >> >> > } >> >> > >> >> > module example-augment { >> >> > import example { >> >> > prefix ex; >> >> > } >> >> > >> >> > augment "ex:example" { >> >> > leaf bar { >> >> > type empty; >> >> > description >> >> > "When present, the default value for foo is 10."; >> >> > } >> >> > } >> >> > } >> >> > >> >> > >> >> > In this case, when the leaf foo is not configured but the leaf bar = is >> present, the value of foo in the operational datastore should be 10 (rat= her >> than 0). >> >> > >> >> > In this case, I think that it would be better/cleaner if the origin >> is marked as system. >> >> > >> >> > Maybe a better YANG description for bar could be: "When present, the >> system overrides the default value of foo to 10." >> >> > >> >> > What is your and/or WG opinion? >> >> > >> >> > Thanks again >> >> > >> >> > Italo >> >> > >> >> > > -----Original Message----- >> >> > > From: Juergen Schoenwaelder [mailto: >> j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>] >> >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 >> >> > > To: Italo Busi > >> >> >> > > Cc: 'netmod@ietf.org' > > >> >> > > Subject: Re: [netmod] Questions about how to assign default values >> with >> >> > > YANG >> >> > > >> >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: >> >> > > > >> >> > > > What about the case the leaf is not conditional (but still >> mandatory false >> >> > > since a YANG default statement is defined)? >> >> > > > >> >> > > > May the server still decide not to use/implement this leaf in t= he >> operational >> >> > > datastore? >> >> > > > >> >> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is >> enabled by >> >> > > default. >> >> > > > What should be the behavior of a system which does not implement >> auto- >> >> > > negotiation? >> >> > > > Return the value false or no value (in the operational datastor= e)? >> >> > > > >> >> > > >> >> > > Here are some of the rules I personally like: >> >> > > >> >> > > - is the ground truth about what a system has and >> does >> >> > > - do not implement leafs that do not apply >> >> > > >> >> > > Hence, interfaces supporting auto-negotiation have either auto- >> >> > > negotiation/enabled =3D true or auto-negotiation/enabled =3D fals= e in >> >> > > . And interfaces not supporting auto-negotiation have >> nothing >> >> > > to report about auto-negotiation. Yes, I do not want to see auto- >> >> > > negotiation/enabled =3D false on a loopback interface. >> >> > > >> >> > > My historic Ethernet interface from the last century would also n= ot >> report >> >> > > auto-negotiation/enabled in . You may hit applicatio= ns >> that love >> >> > > to have auto-negotiation/enabled available on all Ethernet >> interfaces and then >> >> > > you end in a debate where the application developers tell you that >> no >> >> > > information in may have many reasons (instrumentati= on >> not >> >> > > implemented, access control rules, whatever and by reporting >> enabled=3Dfalse >> >> > > you do them a favor) but the true answer in such a debate is often >> that >> >> > > modeling things as a boolean is simplistic since there are often >> more than >> >> > > exactly two states (in this case, enabled, disabled, failed, >> not-available, ...). >> >> > > So you settle on blaming the model writer. ;-) >> >> > > >> >> > > /js >> >> > > >> >> > > -- >> >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >> > > Fax: +49 421 200 3103 >> >> > >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >> Fax: +49 421 200 3103 >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Mar 10 07:25:19 2021 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 899E23A1044 for ; Wed, 10 Mar 2021 07:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Wj1DxhQ7PH3W for ; Wed, 10 Mar 2021 07:25:15 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1312B3A1026 for ; Wed, 10 Mar 2021 07:25:15 -0800 (PST) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwbPY1zyhz67wqx; Wed, 10 Mar 2021 23:20:49 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 16:25:13 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Wed, 10 Mar 2021 16:25:13 +0100 From: Italo Busi To: 'Andy Bierman' CC: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Questions about how to assign default values with YANG Thread-Index: AdbvCmZgzen+a6G4QWicT/glaRAynP///QGA///e3yCAAEHcAP//waGggACHKYD/tcyd8BK8WnuAAACoPAD//yMQoP/99AcA//vNQxA= Date: Wed, 10 Mar 2021 15:25:13 +0000 Message-ID: <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.173] Content-Type: multipart/alternative; boundary="_000_3a5eea68b8554cbe9ed3e8bc63652ffchuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 15:25:19 -0000 --_000_3a5eea68b8554cbe9ed3e8bc63652ffchuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KSSBzZWUgeW91ciBwb2ludCwNCg0KQXQgdGhlIGJlZ2lubmluZyBvZiB0aGlz IHRocmVhZCwgSSBoYXZlIGhhZCBhIGRvdWJ0IGFib3V0IGhvdyB0byByZWNvbmNpbGUgc2VjLiA3 LjYuMSBvZiBSRkM3OTUwIHdpdGggc2VjLiA1LjMgb2YgUkZDODM0MjoNCg0KICAgUmVxdWVzdHMg dG8gcmV0cmlldmUgbm9kZXMgZnJvbSA8b3BlcmF0aW9uYWw+IGFsd2F5cyByZXR1cm4gdGhlIHZh bHVlDQogICBpbiB1c2UgaWYgdGhlIG5vZGUgZXhpc3RzLCByZWdhcmRsZXNzIG9mIGFueSBkZWZh dWx0IHZhbHVlIHNwZWNpZmllZA0KICAgaW4gdGhlIFlBTkcgbW9kdWxlLiAgSWYgbm8gdmFsdWUg aXMgcmV0dXJuZWQgZm9yIGEgZ2l2ZW4gbm9kZSwgdGhlbg0KICAgdGhpcyBpbXBsaWVzIHRoYXQg dGhlIG5vZGUgaXMgbm90IHVzZWQgYnkgdGhlIGRldmljZS4NCg0KTXkgdW5kZXJzdGFuZGluZyB0 aGF0IHRoZSBjbGllbnQgd2lsbCBhbHdheXMgZ2V0IHRoZSBhcHBsaWVkIHZhbHVlIGluZGVwZW5k ZW50bHkgb24gd2hldGhlciBpdCBpcyAwIG9yIDEwIG9yIGFub3RoZXIgdmFsdWUuDQoNCkFueXdh eSwgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgaXNzdWUgaXMgbWFpbmx5IGFib3V0IHRoZSBrZXl3 b3JkIOKAnGRlZmF1bHTigJ0gc28gbGV0IG1lIHRha2UgYSBzdGVwIGJhY2sgYW5kIHRyeSB0byBk ZWZpbmUgdGhlIGlzc3VlIEkgYW0gdHJ5aW5nIHRvIHNvbHZlLCB3aXRob3V0IGFzc3VtaW5nIGFu eSBzb2x1dGlvbi4NCg0KV2hhdCBJIG5lZWQgaXMgdG8gZmluZCBhIHNvbHV0aW9uIHRoYXQgYWxs b3dzIGEgY2xpZW50IHRvIHJlcXVlc3QgdGhlIHNlcnZlciB0byBhcHBseSB0aGUgdmFsdWUgMTAg Zm9yIHRoZSBsZWFmIGZvbyBpbiB0aGUgb3BlcmF0aW9uYWwgRFMgd2l0aG91dCDigJxleHBsaWNp dGx54oCdIHdyaXRpbmcgdGhlIHZhbHVlIDEwIGluIHRoZSBydW5uaW5nIERTIGJ1dCDigJxpbXBs aWNpdGx54oCdIGJ5IHdyaXRpbmcgYW5vdGhlciBsZWFmIGJhciBpbiB0aGUgcnVubmluZyBEUywg ZXZlbiBpZiB0aGUgbGVhZiBmb28gaGFzIGEgWUFORyBkZWZhdWx0IHN0YXRlbWVudCBkZWZpbmlu ZyAwIGFzIGl0cyBkZWZhdWx0IHZhbHVlLg0KDQpJIHRoaW5rIHRoYXQgdGhlIE5NREEgYXJjaGl0 ZWN0dXJlIGlzIHF1aXRlIGZsZXhpYmxlIGFuZCBjb3VsZCBiZSBsZXZlcmFnZWQgdG8gcmVzb2x2 ZSB0aGlzIGlzc3VlLg0KDQpTdGVwcGluZyBhd2F5IGZyb20gZGVmaW5pbmcgZGVmYXVsdCB2YWx1 ZXMsIG9uZSBwb3NzaWJpbGl0eSBjb3VsZCBiZSB0aGF0IHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRp b24gb2YgdGhlIHZhbHVlIG9mIGZvbyBpcyBkZWZpbmVkIGJ5IHRoZSBzeXN0ZW0gYmVmb3JlIGFw cGx5aW5nIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGluIHRoZSBvcGVyYXRpb25hbCBEUywg YXMgYSBzaWRlIGVmZmVjdCBvZiBhcHBseWluZyB0aGUgY29uZmlndXJhdGlvbiBvZiB0aGUgbGVh ZiBiYXIuDQoNCkFub3RoZXIgYWx0ZXJuYXRpdmUgd2hpY2ggaXMganVzdCBqdW1waW5nIHRvIG15 IG1pbmQsIGNvdWxkIGJlIHRoYXQgdGhlIHZhbHVlIG9mIDEwIGZvciB0aGUgbGVhZiBmb28gaXMg c2V0IGJ5IHRoZSBzeXN0ZW0gaW4gdGhlIGludGVuZGVkIERTLCBhcHBseWluZyBhIHNvcnQgb2Yg dGVtcGxhdGUuIFNob3VsZCBpbiB0aGlzIGNhc2UgdGhlIGRlZmluaXRpb24gb2YgdGhlIGxlYWYg YmFyIGJlIGludGVycHJldGVkIGFzIGEgdGVtcGxhdGUgY29uZmlndXJhdGlvbiBvciBob3cgc2hv dWxkIHRoZSByZXF1aXJlZCB0ZW1wbGF0ZSBjb25maWd1cmF0aW9uIGJlIHByb3ZpZGVkPw0KDQpD b3VsZCBhbnkgb2YgdGhpcyBvcHRpb24gYmUgdXNlZCB0byByZXNvbHZlIHRoaXMgaXNzdWU/DQoN Ckl0YWxvDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0N ClNlbnQ6IG1lcmNvbGVkw6wgMTAgbWFyem8gMjAyMSAxNToxNg0KVG86IEl0YWxvIEJ1c2kgPEl0 YWxvLkJ1c2lAaHVhd2VpLmNvbT4NCkNjOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT47IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtuZXRtb2RdIFF1ZXN0aW9ucyBhYm91dCBob3cgdG8gYXNzaWduIGRlZmF1bHQgdmFsdWVz IHdpdGggWUFORw0KDQoNCg0KT24gV2VkLCBNYXIgMTAsIDIwMjEgYXQgMTI6NTQgQU0gSXRhbG8g QnVzaSA8SXRhbG8uQnVzaUBodWF3ZWkuY29tPG1haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb20+ PiB3cm90ZToNCkFuZHksIEp1ZXJnZW4sDQoNCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRo ZSBpc3N1ZSB3aXRoIGEgY2xpZW50IHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUgYXVnbWVu dC4NCg0KV2hlbiB0aGlzIGNsaWVudCB3cml0ZXMgaW4gdGhlIHJ1bm5pbmcgRFMsIGl0IHdpbGwg bm90IHNldCB0aGUgYmFyIGF0dHJpYnV0ZSAod2hpY2ggaXMgYWxzbyBkZWZpbmVkIGluIHRoZSBh dWdtZW50IG1vZHVsZSkgYW5kIHRoZXJlZm9yZSB0aGUgZGVmYXVsdCB2YWx1ZSAwIHdpbGwgYmUg YXBwbGllZCBieSB0aGUgc3lzdGVtLCBhcyBleHBlY3RlZCBieSB0aGUgY2xpZW50Lg0KDQpXaGVu IHRoaXMgY2xpZW50IHJlYWRzIGZyb20gdGhlIG9wZXJhdGlvbmFsIERTIHRoZSBhcHBsaWVkIGNv bmZpZ3VyYXRpb24sIHByb3ZpZGVkIGJ5IGFub3RoZXIgY2xpZW50IHdoaWNoIHVuZGVyc3RhbmRz IHRoZSBhdWdtZW50LCBpdCB3aWxsIHNlZSB0aGF0IHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24g Zm9yIHRoZSBsZWFmIGZvbyBpcyAxMC4NCg0KVGhpcyBpcyBhIHZhbGlkIGFwcGxpZWQgY29uZmln dXJhdGlvbiBpZiB0aGUgb3RoZXIgY2xpZW50IGhhZCBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdGhl IHZhbHVlIDEwIGluIHRoZSBydW5uaW5nIERTLg0KDQpUaGUgb25seSBkaWZmZXJlbmNlIHdvdWxk IGJlIHRoYXQgd2hlbiB0aGUgdmFsdWUgMTAgaXMgZXhwbGljaXRseSBjb25maWd1cmVkIGJ5IHRo ZSBvdGhlciBjbGllbnQgdGhlIG9yaWdpbiBpcyBzZXQgdG8gaW50ZW5kZWQgd2hpbGUgd2hlbiDi gJxpbXBsaWNpdGx54oCdIGNvbmZpZ3VyZWQgdXNpbmcgdGhlIGF0dHJpYnV0ZSBiYXIsIHRoZSBv cmlnaW4gY2FuIGJlIHNldCB0byBzeXN0ZW0gKEkgdGhpbmsgaXQgd291bGQgbm90IGJlIGNvcnJl Y3QgdG8gc2V0IHRoZSBvcmlnaW4gdG8gZGVmYXVsdCBpbiB0aGlzIGNhc2UpLg0KDQpCVFcsIEkg YWdyZWUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgbW9zdCBlbGVnYW50L2NsZWFuIGRlc2lnbiBhbmQg dGhhdCB0aGUgYmVzdCBhcHByb2FjaCB3b3VsZCBiZSBub3QgdG8gZGVmaW5lIGFueSBkZWZhdWx0 IHZhbHVlIGluIHRoZSBiYXNlIG1vZGVsLiBJIGFtIGp1c3Qgd2lsbGluZyB0byB1bmRlcnN0YW5k IGlmIGEgd29yay1hcm91bmQgaXMgcG9zc2libGUsIHdpdGhvdXQgYnJlYWtpbmcgYW55IGNsaWVu dCwgdG8gYWxsb3cgcmUtdXNpbmcgYW4gZXhpc3RpbmcgbW9kdWxlIHdoaWNoIGhhcyBhbHJlYWR5 IGRlZmluZWQgYSBkZWZhdWx0IHZhbHVlLg0KDQoNClJlYWQgc2VjLiA3LjYuMSBhZ2FpbiwgZXNw ZWNpYWxseSB0aGlzIHBhcnQ6DQoNCiAgIFdoZW4gdGhlIGRlZmF1bHQgdmFsdWUgaXMgaW4gdXNl LCB0aGUgc2VydmVyIE1VU1Qgb3BlcmF0aW9uYWxseQ0KDQogICBiZWhhdmUgYXMgaWYgdGhlIGxl YWYgd2FzIHByZXNlbnQgaW4gdGhlIGRhdGEgdHJlZSB3aXRoIHRoZSBkZWZhdWx0DQoNCiAgIHZh bHVlIGFzIGl0cyB2YWx1ZS4NCg0KDQoNCg0KDQpZb3VyIHByb3Bvc2FsIHZpb2xhdGVzIHRoaXMg TVVTVCBiZWNhdXNlIHRoZSBkZWZhdWx0IGlzIGluIHVzZSBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVz DQoNCg0KDQoNCg0KSXRhbG8NCg0KDQpBbmR5DQoNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWls dG86YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+XQ0KU2VudDog bWFydGVkw6wgOSBtYXJ6byAyMDIxIDIxOjEyDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+OyBJdGFsbyBCdXNpIDxJdGFsby5CdXNpQGh1YXdlaS5j b208bWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNvbT4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRv Om5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVzdGlvbnMgYWJvdXQg aG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlcyB3aXRoIFlBTkcNCg0KDQoNCk9uIFR1ZSwgTWFy IDksIDIwMjEgYXQgMTE6NTIgQU0gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZT4+IHdyb3RlOg0KQ2hhbmdpbmcgdGhlIHNlbWFudGljcyBvZiBhIGRlZmluaXRp b24gdmlhIGF1Z21lbnRzIGlzIGJhZCBkZXNpZ24uDQoNCkEgc3lzdGVtIHRoYXQgZG9lcyBub3Qg dW5kZXJzdGFuZCB0aGUgYXVnbWVudCB3aWxsIGJlbGlldmUgdGhlIGRlZmF1bHQNCmlzIDAuIFNp bmNlIHRoZXJlIGlzIG5vIHdheSB0byBmb3JjZSBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0 bw0KdW5kZXJzdGFuZCBhIGNlcnRhaW4gYXVnbWVudGF0aW9uLCBkaWZmZXJlbnQgaW1wbGVtZW50 YXRpb24gd2lsbA0KcmlnaHRmdWxseSBkaXNhZ3JlZSBvbiB0aGUgZGVmYXVsdCB2YWx1ZSBpbiBl ZmZlY3QuDQoNCg0KZGV2aWF0aW9uIC9leDpleGFtcGxlL2V4OmZvbyB7DQogICAgZGVsZXRlIHsN CiAgICAgICBkZWZhdWx0IDA7DQogICAgIH0NCn0NCg0KSU1PIGl0IHdhcyBhIGJhZCBpZGVhIHRv IHNheSBkZXZpYXRpb25zIE1VU1QgTk9UIGFwcGVhciBpbiBzdGFuZGFyZCBtb2R1bGVzLg0KSGVy ZSBpcyBhIHVzZS1jYXNlIGZvciBpdC4NCg0KVGhlIG9sZC1jbGllbnQgZG9lcyBub3Qga25vdyBh Ym91dCB0aGUgbmV3IGR5bmFtaWMgZGVmYXVsdCBidXQgaXQgY291bGQga25vdw0KdGhhdCB0aGUg b2xkIFlBTkcgZGVmYXVsdCBpcyBub3QgYmVpbmcgdXNlZC4NCg0KDQovanMNCg0KQW5keQ0KDQoN Ck9uIE1vbiwgTWFyIDA4LCAyMDIxIGF0IDA4OjE5OjM5UE0gKzAwMDAsIEl0YWxvIEJ1c2kgd3Jv dGU6DQo+IEhpIEp1ZXJnZW4sDQo+DQo+IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciBjbGVhciBleHBs YW5hdGlvbiBvbiB0aGlzIHRvcGljDQo+DQo+IEkgaGF2ZSBmb3VuZCBhIHNpbWlsYXIgYnV0IHNs aWdodGx5IGRpZmZlcmVudCBpc3N1ZS4gSW4gdGhpcyBjYXNlLCBhIFlBTkcgZGVmYXVsdCBzdGF0 ZW1lbnQgZXhpc3RzIGluIHRoZSBiYXNlIG1vZHVsZSBidXQgdGhlIGludGVudGlvbiB3aXRoIHRo ZSBhdWdtZW50YXRpb24gaXMgdG8gIm92ZXJ3cml0ZSIgdGhlIGRlZmF1bHQgdmFsdWUgb24gdGhl IGJhc2lzIG9mIGFub3RoZXIgYXR0cmlidXRlLCBkZWZpbmVkIGluIHRoZSBtb2R1bGUgd2hpY2gg YXVnbWVudHMgdGhlIGJhc2UgbW9kdWxlLg0KPg0KPiBGb3IgZXhhbXBsZSwgSSBhbSB3b25kZXJp bmcgd2hldGhlciBzdWNoIGEgY29kZSBpcyB2YWxpZDoNCj4NCj4gbW9kdWxlIGV4YW1wbGUtYmFz ZSB7DQo+ICAgY29udGFpbmVyIGV4YW1wbGUgew0KPiAgICAgbGVhZiBmb28gew0KPiAgICAgICB0 eXBlIHVpbnQ4Ow0KPiAgICAgICBkZWZhdWx0IDA7DQo+ICAgICB9DQo+ICAgfQ0KPiB9DQo+DQo+ IG1vZHVsZSBleGFtcGxlLWF1Z21lbnQgew0KPiAgIGltcG9ydCBleGFtcGxlIHsNCj4gICAgIHBy ZWZpeCBleDsNCj4gICB9DQo+DQo+ICAgYXVnbWVudCAiZXg6ZXhhbXBsZSIgew0KPiAgICAgbGVh ZiBiYXIgew0KPiAgICAgICB0eXBlIGVtcHR5Ow0KPiAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAg ICAgICJXaGVuIHByZXNlbnQsIHRoZSBkZWZhdWx0IHZhbHVlIGZvciBmb28gaXMgMTAuIjsNCj4g ICAgIH0NCj4gICB9DQo+IH0NCj4NCj4NCj4gSW4gdGhpcyBjYXNlLCB3aGVuIHRoZSBsZWFmIGZv byBpcyBub3QgY29uZmlndXJlZCBidXQgdGhlIGxlYWYgYmFyIGlzIHByZXNlbnQsIHRoZSB2YWx1 ZSBvZiBmb28gaW4gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBzaG91bGQgYmUgMTAgKHJhdGhl ciB0aGFuIDApLg0KPg0KPiBJbiB0aGlzIGNhc2UsIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBi ZXR0ZXIvY2xlYW5lciBpZiB0aGUgb3JpZ2luIGlzIG1hcmtlZCBhcyBzeXN0ZW0uDQo+DQo+IE1h eWJlIGEgYmV0dGVyIFlBTkcgZGVzY3JpcHRpb24gZm9yIGJhciBjb3VsZCBiZTogIldoZW4gcHJl c2VudCwgdGhlIHN5c3RlbSBvdmVycmlkZXMgdGhlIGRlZmF1bHQgdmFsdWUgb2YgZm9vIHRvIDEw LiINCj4NCj4gV2hhdCBpcyB5b3VyIGFuZC9vciBXRyBvcGluaW9uPw0KPg0KPiBUaGFua3MgYWdh aW4NCj4NCj4gSXRhbG8NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl Pl0NCj4gPiBTZW50OiBtZXJjb2xlZMOsIDIwIGdlbm5haW8gMjAyMSAxNzowNQ0KPiA+IFRvOiBJ dGFsbyBCdXNpIDxJdGFsby5CdXNpQGh1YXdlaS5jb208bWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2Vp LmNvbT4+DQo+ID4gQ2M6ICduZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4n IDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQo+ID4gU3ViamVjdDog UmU6IFtuZXRtb2RdIFF1ZXN0aW9ucyBhYm91dCBob3cgdG8gYXNzaWduIGRlZmF1bHQgdmFsdWVz IHdpdGgNCj4gPiBZQU5HDQo+ID4NCj4gPiBPbiBXZWQsIEphbiAyMCwgMjAyMSBhdCAwMjo0MToz OVBNICswMDAwLCBJdGFsbyBCdXNpIHdyb3RlOg0KPiA+ID4NCj4gPiA+IFdoYXQgYWJvdXQgdGhl IGNhc2UgdGhlIGxlYWYgaXMgbm90IGNvbmRpdGlvbmFsIChidXQgc3RpbGwgbWFuZGF0b3J5IGZh bHNlDQo+ID4gc2luY2UgYSBZQU5HIGRlZmF1bHQgc3RhdGVtZW50IGlzIGRlZmluZWQpPw0KPiA+ ID4NCj4gPiA+IE1heSB0aGUgc2VydmVyIHN0aWxsIGRlY2lkZSBub3QgdG8gdXNlL2ltcGxlbWVu dCB0aGlzIGxlYWYgaW4gdGhlIG9wZXJhdGlvbmFsDQo+ID4gZGF0YXN0b3JlPw0KPiA+ID4NCj4g PiA+IEZvciBleGFtcGxlLCBpbiBhcHBlbmRpeCBDLjEgb2YgUkZDODM0MiwgYXV0by1uZWdvdGlh dGlvbiBpcyBlbmFibGVkIGJ5DQo+ID4gZGVmYXVsdC4NCj4gPiA+IFdoYXQgc2hvdWxkIGJlIHRo ZSBiZWhhdmlvciBvZiBhIHN5c3RlbSB3aGljaCBkb2VzIG5vdCBpbXBsZW1lbnQgYXV0by0NCj4g PiBuZWdvdGlhdGlvbj8NCj4gPiA+IFJldHVybiB0aGUgdmFsdWUgZmFsc2Ugb3Igbm8gdmFsdWUg KGluIHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUpPw0KPiA+ID4NCj4gPg0KPiA+IEhlcmUgYXJl IHNvbWUgb2YgdGhlIHJ1bGVzIEkgcGVyc29uYWxseSBsaWtlOg0KPiA+DQo+ID4gIC0gPG9wZXJh dGlvbmFsPiBpcyB0aGUgZ3JvdW5kIHRydXRoIGFib3V0IHdoYXQgYSBzeXN0ZW0gaGFzIGFuZCBk b2VzDQo+ID4gIC0gZG8gbm90IGltcGxlbWVudCBsZWFmcyB0aGF0IGRvIG5vdCBhcHBseQ0KPiA+ DQo+ID4gSGVuY2UsIGludGVyZmFjZXMgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUg ZWl0aGVyIGF1dG8tDQo+ID4gbmVnb3RpYXRpb24vZW5hYmxlZCA9IHRydWUgb3IgYXV0by1uZWdv dGlhdGlvbi9lbmFibGVkID0gZmFsc2UgaW4NCj4gPiA8b3BlcmF0aW9uYWw+LiBBbmQgaW50ZXJm YWNlcyBub3Qgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUgbm90aGluZw0KPiA+IHRv IHJlcG9ydCBhYm91dCBhdXRvLW5lZ290aWF0aW9uLiBZZXMsIEkgZG8gbm90IHdhbnQgdG8gc2Vl IGF1dG8tDQo+ID4gbmVnb3RpYXRpb24vZW5hYmxlZCA9IGZhbHNlIG9uIGEgbG9vcGJhY2sgaW50 ZXJmYWNlLg0KPiA+DQo+ID4gTXkgaGlzdG9yaWMgRXRoZXJuZXQgaW50ZXJmYWNlIGZyb20gdGhl IGxhc3QgY2VudHVyeSB3b3VsZCBhbHNvIG5vdCByZXBvcnQNCj4gPiBhdXRvLW5lZ290aWF0aW9u L2VuYWJsZWQgaW4gPG9wZXJhdGlvbmFsPi4gWW91IG1heSBoaXQgYXBwbGljYXRpb25zIHRoYXQg bG92ZQ0KPiA+IHRvIGhhdmUgYXV0by1uZWdvdGlhdGlvbi9lbmFibGVkIGF2YWlsYWJsZSBvbiBh bGwgRXRoZXJuZXQgaW50ZXJmYWNlcyBhbmQgdGhlbg0KPiA+IHlvdSBlbmQgaW4gYSBkZWJhdGUg d2hlcmUgdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgdGVsbCB5b3UgdGhhdCBubw0KPiA+IGlu Zm9ybWF0aW9uIGluIDxvcGVyYXRpb25hbD4gbWF5IGhhdmUgbWFueSByZWFzb25zIChpbnN0cnVt ZW50YXRpb24gbm90DQo+ID4gaW1wbGVtZW50ZWQsIGFjY2VzcyBjb250cm9sIHJ1bGVzLCB3aGF0 ZXZlciBhbmQgYnkgcmVwb3J0aW5nIGVuYWJsZWQ9ZmFsc2UNCj4gPiB5b3UgZG8gdGhlbSBhIGZh dm9yKSBidXQgdGhlIHRydWUgYW5zd2VyIGluIHN1Y2ggYSBkZWJhdGUgaXMgb2Z0ZW4gdGhhdA0K PiA+IG1vZGVsaW5nIHRoaW5ncyBhcyBhIGJvb2xlYW4gaXMgc2ltcGxpc3RpYyBzaW5jZSB0aGVy ZSBhcmUgb2Z0ZW4gbW9yZSB0aGFuDQo+ID4gZXhhY3RseSB0d28gc3RhdGVzIChpbiB0aGlzIGNh c2UsIGVuYWJsZWQsIGRpc2FibGVkLCBmYWlsZWQsIG5vdC1hdmFpbGFibGUsIC4uLikuDQo+ID4g U28geW91IHNldHRsZSBvbiBibGFtaW5nIHRoZSBtb2RlbCB3cml0ZXIuIDstKQ0KPiA+DQo+ID4g L2pzDQo+ID4NCj4gPiAtLQ0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcg ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+IEZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLz4NCj4NCg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGlu ZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --_000_3a5eea68b8554cbe9ed3e8bc63652ffchuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHNl ZSB5b3VyIHBvaW50LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QXQgdGhlIGJlZ2lubmluZyBvZiB0aGlzIHRocmVhZCwgSSBoYXZlIGhhZCBhIGRvdWJ0IGFib3V0 IGhvdyB0byByZWNvbmNpbGUgc2VjLiA3LjYuMSBvZiBSRkM3OTUwIHdpdGggc2VjLiA1LjMgb2Yg UkZDODM0Mjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBS ZXF1ZXN0cyB0byByZXRyaWV2ZSBub2RlcyBmcm9tICZsdDtvcGVyYXRpb25hbCZndDsgYWx3YXlz IHJldHVybiB0aGUgdmFsdWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluIHVzZSBpZiB0aGUgbm9k ZSBleGlzdHMsIHJlZ2FyZGxlc3Mgb2YgYW55IGRlZmF1bHQgdmFsdWUgc3BlY2lmaWVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBpbiB0aGUgWUFORyBtb2R1bGUuJm5ic3A7IElmIG5vIHZhbHVlIGlz IHJldHVybmVkIGZvciBhIGdpdmVuIG5vZGUsIHRoZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRo aXMgaW1wbGllcyB0aGF0IHRoZSBub2RlIGlzIG5vdCB1c2VkIGJ5IHRoZSBkZXZpY2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NeSB1bmRlcnN0YW5kaW5nIHRo YXQgdGhlIGNsaWVudCB3aWxsIGFsd2F5cyBnZXQgdGhlIGFwcGxpZWQgdmFsdWUgaW5kZXBlbmRl bnRseSBvbiB3aGV0aGVyIGl0IGlzIDAgb3IgMTAgb3IgYW5vdGhlciB2YWx1ZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFueXdheSwgaXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgaXNzdWUgaXMgbWFpbmx5IGFib3V0IHRoZSBrZXl3b3JkIOKAnGRlZmF1bHTigJ0g c28gbGV0IG1lIHRha2UgYSBzdGVwIGJhY2sgYW5kIHRyeSB0byBkZWZpbmUgdGhlIGlzc3VlIEkg YW0gdHJ5aW5nIHRvIHNvbHZlLCB3aXRob3V0DQogYXNzdW1pbmcgYW55IHNvbHV0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hhdCBJIG5lZWQgaXMgdG8g ZmluZCBhIHNvbHV0aW9uIHRoYXQgYWxsb3dzIGEgY2xpZW50IHRvIHJlcXVlc3QgdGhlIHNlcnZl ciB0byBhcHBseSB0aGUgdmFsdWUgMTAgZm9yIHRoZSBsZWFmIGZvbyBpbiB0aGUgb3BlcmF0aW9u YWwgRFMgd2l0aG91dCDigJxleHBsaWNpdGx54oCdDQogd3JpdGluZyB0aGUgdmFsdWUgMTAgaW4g dGhlIHJ1bm5pbmcgRFMgYnV0IOKAnGltcGxpY2l0bHnigJ0gYnkgd3JpdGluZyBhbm90aGVyIGxl YWYgYmFyIGluIHRoZSBydW5uaW5nIERTLCBldmVuIGlmIHRoZSBsZWFmIGZvbyBoYXMgYSBZQU5H IGRlZmF1bHQgc3RhdGVtZW50IGRlZmluaW5nIDAgYXMgaXRzIGRlZmF1bHQgdmFsdWUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgdGhlIE5N REEgYXJjaGl0ZWN0dXJlIGlzIHF1aXRlIGZsZXhpYmxlIGFuZCBjb3VsZCBiZSBsZXZlcmFnZWQg dG8gcmVzb2x2ZSB0aGlzIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+U3RlcHBpbmcgYXdheSBmcm9tIGRlZmluaW5nIGRlZmF1bHQgdmFsdWVzLCBvbmUg cG9zc2liaWxpdHkgY291bGQgYmUgdGhhdCB0aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIG9mIHRo ZSB2YWx1ZSBvZiBmb28gaXMgZGVmaW5lZCBieSB0aGUgc3lzdGVtIGJlZm9yZSBhcHBseWluZw0K IHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGluIHRoZSBvcGVyYXRpb25hbCBEUywgYXMgYSBz aWRlIGVmZmVjdCBvZiBhcHBseWluZyB0aGUgY29uZmlndXJhdGlvbiBvZiB0aGUgbGVhZiBiYXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Bbm90aGVyIGFsdGVy bmF0aXZlIHdoaWNoIGlzIGp1c3QganVtcGluZyB0byBteSBtaW5kLCBjb3VsZCBiZSB0aGF0IHRo ZSB2YWx1ZSBvZiAxMCBmb3IgdGhlIGxlYWYgZm9vIGlzIHNldCBieSB0aGUgc3lzdGVtIGluIHRo ZSBpbnRlbmRlZCBEUywgYXBwbHlpbmcgYSBzb3J0DQogb2YgdGVtcGxhdGUuIFNob3VsZCBpbiB0 aGlzIGNhc2UgdGhlIGRlZmluaXRpb24gb2YgdGhlIGxlYWYgYmFyIGJlIGludGVycHJldGVkIGFz IGEgdGVtcGxhdGUgY29uZmlndXJhdGlvbiBvciBob3cgc2hvdWxkIHRoZSByZXF1aXJlZCB0ZW1w bGF0ZSBjb25maWd1cmF0aW9uIGJlIHByb3ZpZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Q291bGQgYW55IG9mIHRoaXMgb3B0aW9uIGJlIHVzZWQgdG8gcmVz b2x2ZSB0aGlzIGlzc3VlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SXRhbG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJp ZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gbWVy Y29sZWTDrCAxMCBtYXJ6byAyMDIxIDE1OjE2PGJyPg0KPGI+VG86PC9iPiBJdGFsbyBCdXNpICZs dDtJdGFsby5CdXNpQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs7IG5l dG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gUXVlc3Rpb25z IGFib3V0IGhvdyB0byBhc3NpZ24gZGVmYXVsdCB2YWx1ZXMgd2l0aCBZQU5HPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFy IDEwLCAyMDIxIGF0IDEyOjU0IEFNIEl0YWxvIEJ1c2kgJmx0OzxhIGhyZWY9Im1haWx0bzpJdGFs by5CdXNpQGh1YXdlaS5jb20iPkl0YWxvLkJ1c2lAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmR5LCBKdWVy Z2VuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0g bm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBpc3N1ZSB3aXRoIGEgY2xpZW50IHRoYXQgZG9lcyBu b3QgdW5kZXJzdGFuZCB0aGUgYXVnbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5XaGVuIHRoaXMgY2xpZW50IHdyaXRlcyBpbiB0aGUgcnVubmluZyBE UywgaXQgd2lsbCBub3Qgc2V0IHRoZSBiYXIgYXR0cmlidXRlICh3aGljaCBpcyBhbHNvIGRlZmlu ZWQNCiBpbiB0aGUgYXVnbWVudCBtb2R1bGUpIGFuZCB0aGVyZWZvcmUgdGhlIGRlZmF1bHQgdmFs dWUgMCB3aWxsIGJlIGFwcGxpZWQgYnkgdGhlIHN5c3RlbSwgYXMgZXhwZWN0ZWQgYnkgdGhlIGNs aWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGVu IHRoaXMgY2xpZW50IHJlYWRzIGZyb20gdGhlIG9wZXJhdGlvbmFsIERTIHRoZSBhcHBsaWVkIGNv bmZpZ3VyYXRpb24sIHByb3ZpZGVkIGJ5IGFub3RoZXIgY2xpZW50DQogd2hpY2ggdW5kZXJzdGFu ZHMgdGhlIGF1Z21lbnQsIGl0IHdpbGwgc2VlIHRoYXQgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlv biBmb3IgdGhlIGxlYWYgZm9vIGlzIDEwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgYSB2YWxpZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaWYg dGhlIG90aGVyIGNsaWVudCBoYWQgZXhwbGljaXRseSBjb25maWd1cmVkIHRoZSB2YWx1ZSAxMCBp bg0KIHRoZSBydW5uaW5nIERTLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoZSBvbmx5IGRpZmZlcmVuY2Ugd291bGQgYmUgdGhhdCB3aGVuIHRoZSB2YWx1 ZSAxMCBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgYnkgdGhlIG90aGVyIGNsaWVudCB0aGUNCiBv cmlnaW4gaXMgc2V0IHRvIGludGVuZGVkIHdoaWxlIHdoZW4g4oCcaW1wbGljaXRseeKAnSBjb25m aWd1cmVkIHVzaW5nIHRoZSBhdHRyaWJ1dGUgYmFyLCB0aGUgb3JpZ2luIGNhbiBiZSBzZXQgdG8g c3lzdGVtIChJIHRoaW5rIGl0IHdvdWxkIG5vdCBiZSBjb3JyZWN0IHRvIHNldCB0aGUgb3JpZ2lu IHRvIGRlZmF1bHQgaW4gdGhpcyBjYXNlKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5CVFcsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgbW9zdCBl bGVnYW50L2NsZWFuIGRlc2lnbiBhbmQgdGhhdCB0aGUgYmVzdCBhcHByb2FjaCB3b3VsZCBiZSBu b3QNCiB0byBkZWZpbmUgYW55IGRlZmF1bHQgdmFsdWUgaW4gdGhlIGJhc2UgbW9kZWwuIEkgYW0g anVzdCB3aWxsaW5nIHRvIHVuZGVyc3RhbmQgaWYgYSB3b3JrLWFyb3VuZCBpcyBwb3NzaWJsZSwg d2l0aG91dCBicmVha2luZyBhbnkgY2xpZW50LCB0byBhbGxvdyByZS11c2luZyBhbiBleGlzdGlu ZyBtb2R1bGUgd2hpY2ggaGFzIGFscmVhZHkgZGVmaW5lZCBhIGRlZmF1bHQgdmFsdWUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVhZCBzZWMuIDcuNi4xIGFnYWluLCBlc3BlY2lhbGx5 IHRoaXMgcGFydDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVm b3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFdoZW4gdGhl IGRlZmF1bHQgdmFsdWUgaXMgaW4gdXNlLCB0aGUgc2VydmVyIE1VU1Qgb3BlcmF0aW9uYWxseTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBiZWhhdmUgYXMgaWYgdGhlIGxlYWYgd2FzIHByZXNlbnQgaW4gdGhlIGRhdGEg dHJlZSB3aXRoIHRoZSBkZWZhdWx0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHZhbHVlIGFzIGl0cyB2YWx1ZS48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0iYnJlYWstYmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFn ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Zb3VyIHByb3Bvc2FsIHZpb2xhdGVzIHRoaXMg TVVTVCBiZWNhdXNlIHRoZSBkZWZhdWx0IGlzIGluIHVzZSBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVz PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6cGFnZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdGFs bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxh IG5hbWU9Im1fLTM0MjkzMTc3MTgwMTYxMTQ0NDhfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86 YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZWTDrCA5IG1hcnpvIDIwMjEgMjE6MTI8YnI+DQo8 Yj5Ubzo8L2I+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7OyBJdGFsbyBCdXNpICZsdDs8YSBo cmVmPSJtYWlsdG86SXRhbG8uQnVzaUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+SXRhbG8u QnVzaUBodWF3ZWkuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW25ldG1vZF0gUXVlc3Rpb25zIGFib3V0IGhvdyB0byBhc3NpZ24gZGVmYXVsdCB2YWx1 ZXMgd2l0aCBZQU5HPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBNYXIgOSwgMjAyMSBhdCAxMTo1MiBBTSBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPkNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgYSBkZWZpbml0aW9uIHZpYSBhdWdtZW50 cyBpcyBiYWQgZGVzaWduLjxicj4NCjxicj4NCkEgc3lzdGVtIHRoYXQgZG9lcyBub3QgdW5kZXJz dGFuZCB0aGUgYXVnbWVudCB3aWxsIGJlbGlldmUgdGhlIGRlZmF1bHQ8YnI+DQppcyAwLiBTaW5j ZSB0aGVyZSBpcyBubyB3YXkgdG8gZm9yY2UgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdG88 YnI+DQp1bmRlcnN0YW5kIGEgY2VydGFpbiBhdWdtZW50YXRpb24sIGRpZmZlcmVudCBpbXBsZW1l bnRhdGlvbiB3aWxsPGJyPg0KcmlnaHRmdWxseSBkaXNhZ3JlZSBvbiB0aGUgZGVmYXVsdCB2YWx1 ZSBpbiBlZmZlY3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmRldmlhdGlvbiAvZXg6ZXhhbXBsZS9leDpmb28gezxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IGRlbGV0ZSB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RlZmF1bHQgMDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklNTyBpdCB3YXMgYSBiYWQgaWRlYSB0byBzYXkgZGV2aWF0aW9ucyBN VVNUIE5PVCBhcHBlYXIgaW4gc3RhbmRhcmQgbW9kdWxlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVyZSBpcyBhIHVzZS1jYXNlIGZvciBp dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBvbGQtY2xpZW50IGRvZXMgbm90IGtub3cgYWJvdXQgdGhlIG5ldyBkeW5hbWljIGRl ZmF1bHQgYnV0IGl0IGNvdWxkIGtub3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+dGhhdCB0aGUgb2xkIFlBTkcgZGVmYXVsdCBpcyBub3QgYmVp bmcgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ L2pzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCk9uIE1vbiwgTWFyIDA4LCAyMDIxIGF0IDA4OjE5OjM5UE0gJiM0MzswMDAwLCBJ dGFsbyBCdXNpIHdyb3RlOjxicj4NCiZndDsgSGkgSnVlcmdlbiw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhhbmtzIGFnYWluIGZvciB5b3VyIGNsZWFyIGV4cGxhbmF0aW9uIG9uIHRoaXMgdG9waWM8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZlIGZvdW5kIGEgc2ltaWxhciBidXQgc2xpZ2h0bHkg ZGlmZmVyZW50IGlzc3VlLiBJbiB0aGlzIGNhc2UsIGEgWUFORyBkZWZhdWx0IHN0YXRlbWVudCBl eGlzdHMgaW4gdGhlIGJhc2UgbW9kdWxlIGJ1dCB0aGUgaW50ZW50aW9uIHdpdGggdGhlIGF1Z21l bnRhdGlvbiBpcyB0byAmcXVvdDtvdmVyd3JpdGUmcXVvdDsgdGhlIGRlZmF1bHQgdmFsdWUgb24g dGhlIGJhc2lzIG9mIGFub3RoZXIgYXR0cmlidXRlLCBkZWZpbmVkIGluIHRoZSBtb2R1bGUgd2hp Y2gNCiBhdWdtZW50cyB0aGUgYmFzZSBtb2R1bGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvciBl eGFtcGxlLCBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHN1Y2ggYSBjb2RlIGlzIHZhbGlkOjxicj4N CiZndDsgPGJyPg0KJmd0OyBtb2R1bGUgZXhhbXBsZS1iYXNlIHs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwO2NvbnRhaW5lciBleGFtcGxlIHs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFm IGZvbyB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgdWludDg7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RlZmF1bHQgMDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyB9PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IG1vZHVsZSBleGFtcGxlLWF1Z21lbnQgezxicj4NCiZndDsmbmJz cDsgJm5ic3A7aW1wb3J0IGV4YW1wbGUgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3By ZWZpeCBleDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsgJm5ic3A7YXVnbWVudCAmcXVvdDtleDpleGFtcGxlJnF1b3Q7IHs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtsZWFmIGJhciB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3R5cGUgZW1wdHk7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rlc2Ny aXB0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtX aGVuIHByZXNlbnQsIHRoZSBkZWZhdWx0IHZhbHVlIGZvciBmb28gaXMgMTAuJnF1b3Q7Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO308YnI+DQom Z3Q7IH08YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiB0aGlzIGNhc2UsIHdoZW4g dGhlIGxlYWYgZm9vIGlzIG5vdCBjb25maWd1cmVkIGJ1dCB0aGUgbGVhZiBiYXIgaXMgcHJlc2Vu dCwgdGhlIHZhbHVlIG9mIGZvbyBpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIHNob3VsZCBi ZSAxMCAocmF0aGVyIHRoYW4gMCkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEluIHRoaXMgY2FzZSwg SSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGJldHRlci9jbGVhbmVyIGlmIHRoZSBvcmlnaW4gaXMg bWFya2VkIGFzIHN5c3RlbS48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWF5YmUgYSBiZXR0ZXIgWUFO RyBkZXNjcmlwdGlvbiBmb3IgYmFyIGNvdWxkIGJlOiAmcXVvdDtXaGVuIHByZXNlbnQsIHRoZSBz eXN0ZW0gb3ZlcnJpZGVzIHRoZSBkZWZhdWx0IHZhbHVlIG9mIGZvbyB0byAxMC4mcXVvdDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgV2hhdCBpcyB5b3VyIGFuZC9vciBXRyBvcGluaW9uPzxicj4NCiZn dDsgPGJyPg0KJmd0OyBUaGFua3MgYWdhaW48YnI+DQomZ3Q7IDxicj4NCiZndDsgSXRhbG88YnI+ DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgJmd0OyBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzo8YSBocmVmPSJtYWls dG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPl08YnI+DQomZ3Q7ICZndDsg U2VudDogbWVyY29sZWTDrCAyMCBnZW5uYWlvIDIwMjEgMTc6MDU8YnI+DQomZ3Q7ICZndDsgVG86 IEl0YWxvIEJ1c2kgJmx0OzxhIGhyZWY9Im1haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj5JdGFsby5CdXNpQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0 OyBDYzogJzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5u ZXRtb2RAaWV0Zi5vcmc8L2E+JyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVzdGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0 IHZhbHVlcyB3aXRoPGJyPg0KJmd0OyAmZ3Q7IFlBTkc8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgT24gV2VkLCBKYW4gMjAsIDIwMjEgYXQgMDI6NDE6MzlQTSAmIzQzOzAwMDAsIEl0YWxv IEJ1c2kgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaGF0 IGFib3V0IHRoZSBjYXNlIHRoZSBsZWFmIGlzIG5vdCBjb25kaXRpb25hbCAoYnV0IHN0aWxsIG1h bmRhdG9yeSBmYWxzZTxicj4NCiZndDsgJmd0OyBzaW5jZSBhIFlBTkcgZGVmYXVsdCBzdGF0ZW1l bnQgaXMgZGVmaW5lZCk/PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBN YXkgdGhlIHNlcnZlciBzdGlsbCBkZWNpZGUgbm90IHRvIHVzZS9pbXBsZW1lbnQgdGhpcyBsZWFm IGluIHRoZSBvcGVyYXRpb25hbDxicj4NCiZndDsgJmd0OyBkYXRhc3RvcmU/PGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBGb3IgZXhhbXBsZSwgaW4gYXBwZW5kaXggQy4x IG9mIFJGQzgzNDIsIGF1dG8tbmVnb3RpYXRpb24gaXMgZW5hYmxlZCBieTxicj4NCiZndDsgJmd0 OyBkZWZhdWx0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoYXQgc2hvdWxkIGJlIHRoZSBiZWhhdmlv ciBvZiBhIHN5c3RlbSB3aGljaCBkb2VzIG5vdCBpbXBsZW1lbnQgYXV0by08YnI+DQomZ3Q7ICZn dDsgbmVnb3RpYXRpb24/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmV0dXJuIHRoZSB2YWx1ZSBmYWxz ZSBvciBubyB2YWx1ZSAoaW4gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSk/PGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSGVyZSBhcmUgc29tZSBvZiB0 aGUgcnVsZXMgSSBwZXJzb25hbGx5IGxpa2U6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7IC0gJmx0O29wZXJhdGlvbmFsJmd0OyBpcyB0aGUgZ3JvdW5kIHRydXRoIGFib3V0IHdo YXQgYSBzeXN0ZW0gaGFzIGFuZCBkb2VzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IC0gZG8gbm90IGlt cGxlbWVudCBsZWFmcyB0aGF0IGRvIG5vdCBhcHBseTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBIZW5jZSwgaW50ZXJmYWNlcyBzdXBwb3J0aW5nIGF1dG8tbmVnb3RpYXRpb24gaGF2ZSBl aXRoZXIgYXV0by08YnI+DQomZ3Q7ICZndDsgbmVnb3RpYXRpb24vZW5hYmxlZCA9IHRydWUgb3Ig YXV0by1uZWdvdGlhdGlvbi9lbmFibGVkID0gZmFsc2UgaW48YnI+DQomZ3Q7ICZndDsgJmx0O29w ZXJhdGlvbmFsJmd0Oy4gQW5kIGludGVyZmFjZXMgbm90IHN1cHBvcnRpbmcgYXV0by1uZWdvdGlh dGlvbiBoYXZlIG5vdGhpbmc8YnI+DQomZ3Q7ICZndDsgdG8gcmVwb3J0IGFib3V0IGF1dG8tbmVn b3RpYXRpb24uIFllcywgSSBkbyBub3Qgd2FudCB0byBzZWUgYXV0by08YnI+DQomZ3Q7ICZndDsg bmVnb3RpYXRpb24vZW5hYmxlZCA9IGZhbHNlIG9uIGEgbG9vcGJhY2sgaW50ZXJmYWNlLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBNeSBoaXN0b3JpYyBFdGhlcm5ldCBpbnRlcmZhY2Ug ZnJvbSB0aGUgbGFzdCBjZW50dXJ5IHdvdWxkIGFsc28gbm90IHJlcG9ydDxicj4NCiZndDsgJmd0 OyBhdXRvLW5lZ290aWF0aW9uL2VuYWJsZWQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy4gWW91IG1h eSBoaXQgYXBwbGljYXRpb25zIHRoYXQgbG92ZTxicj4NCiZndDsgJmd0OyB0byBoYXZlIGF1dG8t bmVnb3RpYXRpb24vZW5hYmxlZCBhdmFpbGFibGUgb24gYWxsIEV0aGVybmV0IGludGVyZmFjZXMg YW5kIHRoZW48YnI+DQomZ3Q7ICZndDsgeW91IGVuZCBpbiBhIGRlYmF0ZSB3aGVyZSB0aGUgYXBw bGljYXRpb24gZGV2ZWxvcGVycyB0ZWxsIHlvdSB0aGF0IG5vPGJyPg0KJmd0OyAmZ3Q7IGluZm9y bWF0aW9uIGluICZsdDtvcGVyYXRpb25hbCZndDsgbWF5IGhhdmUgbWFueSByZWFzb25zIChpbnN0 cnVtZW50YXRpb24gbm90PGJyPg0KJmd0OyAmZ3Q7IGltcGxlbWVudGVkLCBhY2Nlc3MgY29udHJv bCBydWxlcywgd2hhdGV2ZXIgYW5kIGJ5IHJlcG9ydGluZyBlbmFibGVkPWZhbHNlPGJyPg0KJmd0 OyAmZ3Q7IHlvdSBkbyB0aGVtIGEgZmF2b3IpIGJ1dCB0aGUgdHJ1ZSBhbnN3ZXIgaW4gc3VjaCBh IGRlYmF0ZSBpcyBvZnRlbiB0aGF0PGJyPg0KJmd0OyAmZ3Q7IG1vZGVsaW5nIHRoaW5ncyBhcyBh IGJvb2xlYW4gaXMgc2ltcGxpc3RpYyBzaW5jZSB0aGVyZSBhcmUgb2Z0ZW4gbW9yZSB0aGFuPGJy Pg0KJmd0OyAmZ3Q7IGV4YWN0bHkgdHdvIHN0YXRlcyAoaW4gdGhpcyBjYXNlLCBlbmFibGVkLCBk aXNhYmxlZCwgZmFpbGVkLCBub3QtYXZhaWxhYmxlLCAuLi4pLjxicj4NCiZndDsgJmd0OyBTbyB5 b3Ugc2V0dGxlIG9uIGJsYW1pbmcgdGhlIG1vZGVsIHdyaXRlci4gOy0pPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IC9qczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4N CiZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NCiZndDsg Jmd0OyBQaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQomZ3Q7 ICZndDsgRmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZl cnNpdHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCjxicj4NCi0tIDxicj4NCkp1ZXJnZW4gU2Nob2Vu d2FlbGRlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55PGJyPg0KRmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cu amFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2Jz LXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3a5eea68b8554cbe9ed3e8bc63652ffchuaweicom_-- From nobody Wed Mar 10 07:34:34 2021 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 CB3AC3A1195 for ; Wed, 10 Mar 2021 07:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56sZElcOrVym for ; Wed, 10 Mar 2021 07:34:29 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC423A118C for ; Wed, 10 Mar 2021 07:34:28 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id l12so28734901edt.3 for ; Wed, 10 Mar 2021 07:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CMiJtJdYOqW6msarcZfHwj9FxiXeLZgMrF7WR+mgzh4=; b=Rf3bdIOXDODUqGqbS8o2juDkhUuDCkUrjS4QhPs7VukB1OxFWhBvKpNHQHC67kDMGe fgz3i5MSJ98XtqAVlT8FOxhBbIACsofdloGCNQ3g8ZkkYvXEmFtoxz8A4HF6D0yP1qAj aOiJ0Q1SjC1qkyK6Yi8B0GrhgAcgspRdlV3aKDrQi93E8NAHTyK0ttOnsbxlbJ8mhR9G g+TCftlII9dAUtH0LAX0Q7VheE3gA7EouiopbPOCCIvO2JfeW+LfQPfiMTv5cWhhKdT7 rG/s0uelLT9pmATUw7LJQRT1anC/CLMGCOcgqPCDlC4s67ZX3EcVYLzHjpKI5ujsVyxu 5sSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CMiJtJdYOqW6msarcZfHwj9FxiXeLZgMrF7WR+mgzh4=; b=suUJ0Iv0Kf+GfYSmSjhGu32Ds1r1xNbJSrc6dxfYvlFPz0NS8X5NjWmEv5P5EI69Kn tHeP4Q/A+gamJi9y15o9vkXqD7tufpTumBpbi66VAdxOze0z6V0YDGzKOZ6Q/34YeIFt +BMZcqVVZCj2lSmc15swKxEC7GoU/u1vJfsMnFTBqsh6IuQKReuxR6IXg932afRxZ3TG M/nzlD7GXyecsfrFi/k2Di1EhC5UKUpTzUkDCX+piRbSTJpy67jz8vqY1FJ2x/90na5t ubO77bSqasQJVzmpPM9ohUjrjEo6nerxDO2cNWWKqR2vtkhs1VdxjUiMtess2yzfFpMv 7OjA== X-Gm-Message-State: AOAM5301rVA4aB7wHURb8jcOSJq2a1AprR20tIrZE7gVX+1cOrajkKkV PiaZ3Mf0+WjTotPAwFIoUFU5kTN6qgrqsEBsq0OQ+g== X-Google-Smtp-Source: ABdhPJz50F254j1N5Bsek6ZgmSzILWWCIzMfjE9O0iTq3nnLYwkKIxjh4Pmj6cDBKJ7C443upKzDX4AFMRyqQpu+p+w= X-Received: by 2002:aa7:cb4d:: with SMTP id w13mr3971735edt.249.1615390467230; Wed, 10 Mar 2021 07:34:27 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> <87h7ljfgwp.fsf@nic.cz> <87eegnf3d8.fsf@nic.cz> In-Reply-To: <87eegnf3d8.fsf@nic.cz> From: William Lupton Date: Wed, 10 Mar 2021 15:34:16 +0000 Message-ID: To: William Lupton , Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f91f2405bd306621" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 15:34:33 -0000 --000000000000f91f2405bd306621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Lada. By my last point I just intended to illustrate that descriptions need to be regarded as normative even if they don't use normative language. On Wed, 10 Mar 2021 at 15:13, Ladislav Lhotka wrote: > William Lupton writes: > > > Lada, all, > > > > Surely a description is the only way to add a normative requirement tha= t > > can't be expressed via YANG statements (including XPath expressions)? > > > > I've always assumed that it's good practice to express what you can usi= ng > > the modeling language, and then use the description to express any > > non-modelable requirements. Obviously there's a problem if the > description > > conflicts with a modeled requirement (and I think it's also good practi= ce > > for the description not to repeat anything that's modeled elsewhere). > > > > I think that RFC 7950 can be interpreted as indicating that the > description > > is more than just informative. I found this in Section 11, and I take > this > > to imply that the description defines the semantics of a definition. > > Even then, it is unclear what effects are permitted with this "more than > informative". In a previous mail I refered to a standard module having a > description that defines a (computed) default. This seems to be acceptabl= e. > > But what about simulating a "when" statement for constraints that cannot > be expressed via XPath? For example: > > description > "This leaf is only valid if the value of foo is prime."; > > I argued in the past that everything that cannot be expressed formally > with YANG statements should be left outside of scope for YANG, at least i= n > terms of data tree validation. > > > > > A "description" statement may be added or changed without changing the > > > > semantics of the definition. > > > > > > For example, if a description says this (this is an example from RFC > 7950), > > then isn't this a _normative_ semantic requirement? > > > > "The amount of local storage that can be used to hold syslog messages." > > Hmm, this seems to state semantics (meaning) of a parameter. What I am > talking about are semantic constraints (business rules) that a valid data > tree is required to satisfy. > > Lada > > > > > > > William > > > > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka > > wrote: > > > >> Juergen Schoenwaelder writes: > >> > >> > A client that has no clue of the annotated leaf can rightfully assum= e > >> > that the default 0 applies. If another client creates this magic lea= f > >> > that changes the default to 10, then there is going to be confusion. > >> > > >> > A definition that says 'default 0' says the default is 0. It does no= t > >> > say the default may be zero or something different depending on > >> > whether the moon shines or other circumstances. I believe you can't > >> > undo a default statement with a description somewhere else. > >> > >> The problem with descriptions is that there seems to be a general > >> agreement that they can somehow supplement the formal YANG statements = in > >> specifying the data model. This has no support in RFC 7950 though: > >> > >> - section 7.21.3 only says that a description is "a human-readable > textual > >> description of this definition" > >> > >> - section 8.1 doesn't include constraints specified in descriptions in > the > >> concept of data tree validity > >> > >> As a result, data model constraints specified in descriptions is a gre= y > >> area, and it is totally unclear how far-reaching they can possibly be. > >> > >> Lada > >> > >> > > >> > /js > >> > > >> > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: > >> >> Andy, Juergen, > >> >> > >> >> I am not sure I understand the issue with a client that does not > >> understand the augment. > >> >> > >> >> When this client writes in the running DS, it will not set the bar > >> attribute (which is also defined in the augment module) and therefore > the > >> default value 0 will be applied by the system, as expected by the > client. > >> >> > >> >> When this client reads from the operational DS the applied > >> configuration, provided by another client which understands the > augment, it > >> will see that the applied configuration for the leaf foo is 10. > >> >> > >> >> This is a valid applied configuration if the other client had > >> explicitly configured the value 10 in the running DS. > >> >> > >> >> The only difference would be that when the value 10 is explicitly > >> configured by the other client the origin is set to intended while whe= n > >> =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, the o= rigin can be set > to > >> system (I think it would not be correct to set the origin to default i= n > >> this case). > >> >> > >> >> BTW, I agree that this is not the most elegant/clean design and tha= t > >> the best approach would be not to define any default value in the base > >> model. I am just willing to understand if a work-around is possible, > >> without breaking any client, to allow re-using an existing module whic= h > has > >> already defined a default value. > >> >> > >> >> Italo > >> >> > >> >> From: Andy Bierman [mailto:andy@yumaworks.com] > >> >> Sent: marted=C3=AC 9 marzo 2021 21:12 > >> >> To: Juergen Schoenwaelder ; > >> Italo Busi ; netmod@ietf.org > >> >> Subject: Re: [netmod] Questions about how to assign default values > with > >> YANG > >> >> > >> >> > >> >> > >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de >> j.schoenwaelder@jacobs-university.de>> wrote: > >> >> Changing the semantics of a definition via augments is bad design. > >> >> > >> >> A system that does not understand the augment will believe the > default > >> >> is 0. Since there is no way to force an existing implementation to > >> >> understand a certain augmentation, different implementation will > >> >> rightfully disagree on the default value in effect. > >> >> > >> >> > >> >> deviation /ex:example/ex:foo { > >> >> delete { > >> >> default 0; > >> >> } > >> >> } > >> >> > >> >> IMO it was a bad idea to say deviations MUST NOT appear in standard > >> modules. > >> >> Here is a use-case for it. > >> >> > >> >> The old-client does not know about the new dynamic default but it > could > >> know > >> >> that the old YANG default is not being used. > >> >> > >> >> > >> >> /js > >> >> > >> >> Andy > >> >> > >> >> > >> >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > >> >> > Hi Juergen, > >> >> > > >> >> > Thanks again for your clear explanation on this topic > >> >> > > >> >> > I have found a similar but slightly different issue. In this case= , > a > >> YANG default statement exists in the base module but the intention wit= h > the > >> augmentation is to "overwrite" the default value on the basis of anoth= er > >> attribute, defined in the module which augments the base module. > >> >> > > >> >> > For example, I am wondering whether such a code is valid: > >> >> > > >> >> > module example-base { > >> >> > container example { > >> >> > leaf foo { > >> >> > type uint8; > >> >> > default 0; > >> >> > } > >> >> > } > >> >> > } > >> >> > > >> >> > module example-augment { > >> >> > import example { > >> >> > prefix ex; > >> >> > } > >> >> > > >> >> > augment "ex:example" { > >> >> > leaf bar { > >> >> > type empty; > >> >> > description > >> >> > "When present, the default value for foo is 10."; > >> >> > } > >> >> > } > >> >> > } > >> >> > > >> >> > > >> >> > In this case, when the leaf foo is not configured but the leaf ba= r > is > >> present, the value of foo in the operational datastore should be 10 > (rather > >> than 0). > >> >> > > >> >> > In this case, I think that it would be better/cleaner if the orig= in > >> is marked as system. > >> >> > > >> >> > Maybe a better YANG description for bar could be: "When present, > the > >> system overrides the default value of foo to 10." > >> >> > > >> >> > What is your and/or WG opinion? > >> >> > > >> >> > Thanks again > >> >> > > >> >> > Italo > >> >> > > >> >> > > -----Original Message----- > >> >> > > From: Juergen Schoenwaelder [mailto: > >> j.schoenwaelder@jacobs-university.de >> j.schoenwaelder@jacobs-university.de>] > >> >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 > >> >> > > To: Italo Busi Italo.Busi@huawei.com > >> >> > >> >> > > Cc: 'netmod@ietf.org' >> > > >> >> > > Subject: Re: [netmod] Questions about how to assign default > values > >> with > >> >> > > YANG > >> >> > > > >> >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > >> >> > > > > >> >> > > > What about the case the leaf is not conditional (but still > >> mandatory false > >> >> > > since a YANG default statement is defined)? > >> >> > > > > >> >> > > > May the server still decide not to use/implement this leaf in > the > >> operational > >> >> > > datastore? > >> >> > > > > >> >> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is > >> enabled by > >> >> > > default. > >> >> > > > What should be the behavior of a system which does not > implement > >> auto- > >> >> > > negotiation? > >> >> > > > Return the value false or no value (in the operational > datastore)? > >> >> > > > > >> >> > > > >> >> > > Here are some of the rules I personally like: > >> >> > > > >> >> > > - is the ground truth about what a system has an= d > >> does > >> >> > > - do not implement leafs that do not apply > >> >> > > > >> >> > > Hence, interfaces supporting auto-negotiation have either auto- > >> >> > > negotiation/enabled =3D true or auto-negotiation/enabled =3D fa= lse in > >> >> > > . And interfaces not supporting auto-negotiation > have > >> nothing > >> >> > > to report about auto-negotiation. Yes, I do not want to see aut= o- > >> >> > > negotiation/enabled =3D false on a loopback interface. > >> >> > > > >> >> > > My historic Ethernet interface from the last century would also > not > >> report > >> >> > > auto-negotiation/enabled in . You may hit > applications > >> that love > >> >> > > to have auto-negotiation/enabled available on all Ethernet > >> interfaces and then > >> >> > > you end in a debate where the application developers tell you > that > >> no > >> >> > > information in may have many reasons > (instrumentation > >> not > >> >> > > implemented, access control rules, whatever and by reporting > >> enabled=3Dfalse > >> >> > > you do them a favor) but the true answer in such a debate is > often > >> that > >> >> > > modeling things as a boolean is simplistic since there are ofte= n > >> more than > >> >> > > exactly two states (in this case, enabled, disabled, failed, > >> not-available, ...). > >> >> > > So you settle on blaming the model writer. ;-) > >> >> > > > >> >> > > /js > >> >> > > > >> >> > > -- > >> >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > >> Germany > >> >> > > Fax: +49 421 200 3103 < > https://www.jacobs-university.de/> > >> >> > > >> >> > >> >> -- > >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >> >> Fax: +49 421 200 3103 > >> >> > >> >> _______________________________________________ > >> >> netmod mailing list > >> >> netmod@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/netmod > >> > > >> > -- > >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny > >> > Fax: +49 421 200 3103 > >> > > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka > >> Head, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > --000000000000f91f2405bd306621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Lada. By my last point=C2=A0I just intended to illu= strate=C2=A0that descriptions need to be regarded as normative even if they= don't use normative language.

On Wed, 10 Mar 2021 at 15:13, Ladislav Lh= otka <ladislav.lhotka@nic.cz> wrote:
Wi= lliam Lupton <wlupton@broadband-forum.org> writes:

> Lada, all,
>
> Surely a description is the only way to add a normative requirement th= at
> can't be expressed via YANG statements (including XPath expression= s)?
>
> I've always assumed that it's good practice to express what yo= u can using
> the modeling language, and then use the description to express any
> non-modelable requirements. Obviously there's a problem if the des= cription
> conflicts with a modeled requirement (and I think it's also good p= ractice
> for the description not to repeat anything that's modeled elsewher= e).
>
> I think that RFC 7950 can be interpreted as indicating that the descri= ption
> is more than just informative. I found this in Section 11, and I take = this
> to imply that the description defines the semantics of a definition.
Even then, it is unclear what effects are permitted with this "more th= an informative". In a previous mail I refered to a standard module hav= ing a description that defines a (computed) default. This seems to be accep= table.

But what about simulating a "when" statement for constraints that= cannot be expressed via XPath? For example:

=C2=A0 description
=C2=A0 =C2=A0 "This leaf is only valid if the value of foo is prime.&q= uot;;

I argued in the past that everything that cannot be expressed formally with= YANG statements should be left outside of scope for YANG, at least in term= s of data tree validation.

>
> A "description" statement may be added or changed without ch= anging the
>
> semantics of the definition.
>
>
> For example, if a description says this (this is an example from RFC 7= 950),
> then isn't this a _normative_ semantic requirement?
>
> "The amount of local storage that can be used to hold syslog mess= ages."

Hmm, this seems to state semantics (meaning) of a parameter. What I am talk= ing about are semantic constraints (business rules) that a valid data tree = is required to satisfy.

Lada

>
>
> William
>
> On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka <ladislav.lhotka@nic.cz>
> wrote:
>
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&= gt; writes:
>>
>> > A client that has no clue of the annotated leaf can rightfull= y assume
>> > that the default 0 applies. If another client creates this ma= gic leaf
>> > that changes the default to 10, then there is going to be con= fusion.
>> >
>> > A definition that says 'default 0' says the default i= s 0. It does not
>> > say the default may be zero or something different depending = on
>> > whether the moon shines or other circumstances. I believe you= can't
>> > undo a default statement with a description somewhere else. >>
>> The problem with descriptions is that there seems to be a general<= br> >> agreement that they can somehow supplement the formal YANG stateme= nts in
>> specifying the data model. This has no support in RFC 7950 though:=
>>
>> - section 7.21.3 only says that a description is "a human-rea= dable textual
>>=C2=A0 =C2=A0description of this definition"
>>
>> - section 8.1 doesn't include constraints specified in descrip= tions in the
>>=C2=A0 =C2=A0concept of data tree validity
>>
>> As a result, data model constraints specified in descriptions is a= grey
>> area, and it is totally unclear how far-reaching they can possibly= be.
>>
>> Lada
>>
>> >
>> > /js
>> >
>> > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: >> >> Andy, Juergen,
>> >>
>> >> I am not sure I understand the issue with a client that d= oes not
>> understand the augment.
>> >>
>> >> When this client writes in the running DS, it will not se= t the bar
>> attribute (which is also defined in the augment module) and theref= ore the
>> default value 0 will be applied by the system, as expected by the = client.
>> >>
>> >> When this client reads from the operational DS the applie= d
>> configuration, provided by another client which understands the au= gment, it
>> will see that the applied configuration for the leaf foo is 10. >> >>
>> >> This is a valid applied configuration if the other client= had
>> explicitly configured the value 10 in the running DS.
>> >>
>> >> The only difference would be that when the value 10 is ex= plicitly
>> configured by the other client the origin is set to intended while= when
>> =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, t= he origin can be set to
>> system (I think it would not be correct to set the origin to defau= lt in
>> this case).
>> >>
>> >> BTW, I agree that this is not the most elegant/clean desi= gn and that
>> the best approach would be not to define any default value in the = base
>> model. I am just willing to understand if a work-around is possibl= e,
>> without breaking any client, to allow re-using an existing module = which has
>> already defined a default value.
>> >>
>> >> Italo
>> >>
>> >> From: Andy Bierman [mailto:andy@yumaworks.com]
>> >> Sent: marted=C3=AC 9 marzo 2021 21:12
>> >> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-unive= rsity.de>;
>> Italo Busi <Italo.Busi@huawei.com>; netmod@ietf.org
>> >> Subject: Re: [netmod] Questions about how to assign defau= lt values with
>> YANG
>> >>
>> >>
>> >>
>> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <= ;
>> j.schoenwaelder@jacobs-university.de<mailto:
>> j.schoenwaelder@jacobs-university.de>> wrote:
>> >> Changing the semantics of a definition via augments is ba= d design.
>> >>
>> >> A system that does not understand the augment will believ= e the default
>> >> is 0. Since there is no way to force an existing implemen= tation to
>> >> understand a certain augmentation, different implementati= on will
>> >> rightfully disagree on the default value in effect.
>> >>
>> >>
>> >> deviation /ex:example/ex:foo {
>> >>=C2=A0 =C2=A0 =C2=A0delete {
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default 0;
>> >>=C2=A0 =C2=A0 =C2=A0 }
>> >> }
>> >>
>> >> IMO it was a bad idea to say deviations MUST NOT appear i= n standard
>> modules.
>> >> Here is a use-case for it.
>> >>
>> >> The old-client does not know about the new dynamic defaul= t but it could
>> know
>> >> that the old YANG default is not being used.
>> >>
>> >>
>> >> /js
>> >>
>> >> Andy
>> >>
>> >>
>> >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrot= e:
>> >> > Hi Juergen,
>> >> >
>> >> > Thanks again for your clear explanation on this topi= c
>> >> >
>> >> > I have found a similar but slightly different issue.= In this case, a
>> YANG default statement exists in the base module but the intention= with the
>> augmentation is to "overwrite" the default value on the = basis of another
>> attribute, defined in the module which augments the base module. >> >> >
>> >> > For example, I am wondering whether such a code is v= alid:
>> >> >
>> >> > module example-base {
>> >> >=C2=A0 =C2=A0container example {
>> >> >=C2=A0 =C2=A0 =C2=A0leaf foo {
>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>> >> >=C2=A0 =C2=A0 =C2=A0}
>> >> >=C2=A0 =C2=A0}
>> >> > }
>> >> >
>> >> > module example-augment {
>> >> >=C2=A0 =C2=A0import example {
>> >> >=C2=A0 =C2=A0 =C2=A0prefix ex;
>> >> >=C2=A0 =C2=A0}
>> >> >
>> >> >=C2=A0 =C2=A0augment "ex:example" {
>> >> >=C2=A0 =C2=A0 =C2=A0leaf bar {
>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When present,= the default value for foo is 10.";
>> >> >=C2=A0 =C2=A0 =C2=A0}
>> >> >=C2=A0 =C2=A0}
>> >> > }
>> >> >
>> >> >
>> >> > In this case, when the leaf foo is not configured bu= t the leaf bar is
>> present, the value of foo in the operational datastore should be 1= 0 (rather
>> than 0).
>> >> >
>> >> > In this case, I think that it would be better/cleane= r if the origin
>> is marked as system.
>> >> >
>> >> > Maybe a better YANG description for bar could be: &q= uot;When present, the
>> system overrides the default value of foo to 10."
>> >> >
>> >> > What is your and/or WG opinion?
>> >> >
>> >> > Thanks again
>> >> >
>> >> > Italo
>> >> >
>> >> > > -----Original Message-----
>> >> > > From: Juergen Schoenwaelder [mailto:
>> j.schoenwaelder@jacobs-university.de<mailto:
>> j.schoenwaelder@jacobs-university.de>]
>> >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05
>> >> > > To: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com
>> >>
>> >> > > Cc: 'netmod@ietf.org<mailto:netmod@ietf.org>' <netmod@ietf.org
>> <mailto:ne= tmod@ietf.org>>
>> >> > > Subject: Re: [netmod] Questions about how to as= sign default values
>> with
>> >> > > YANG
>> >> > >
>> >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo= Busi wrote:
>> >> > > >
>> >> > > > What about the case the leaf is not condit= ional (but still
>> mandatory false
>> >> > > since a YANG default statement is defined)?
>> >> > > >
>> >> > > > May the server still decide not to use/imp= lement this leaf in the
>> operational
>> >> > > datastore?
>> >> > > >
>> >> > > > For example, in appendix C.1 of RFC8342, a= uto-negotiation is
>> enabled by
>> >> > > default.
>> >> > > > What should be the behavior of a system wh= ich does not implement
>> auto-
>> >> > > negotiation?
>> >> > > > Return the value false or no value (in the= operational datastore)?
>> >> > > >
>> >> > >
>> >> > > Here are some of the rules I personally like: >> >> > >
>> >> > >=C2=A0 - <operational> is the ground truth= about what a system has and
>> does
>> >> > >=C2=A0 - do not implement leafs that do not appl= y
>> >> > >
>> >> > > Hence, interfaces supporting auto-negotiation h= ave either auto-
>> >> > > negotiation/enabled =3D true or auto-negotiatio= n/enabled =3D false in
>> >> > > <operational>. And interfaces not support= ing auto-negotiation have
>> nothing
>> >> > > to report about auto-negotiation. Yes, I do not= want to see auto-
>> >> > > negotiation/enabled =3D false on a loopback int= erface.
>> >> > >
>> >> > > My historic Ethernet interface from the last ce= ntury would also not
>> report
>> >> > > auto-negotiation/enabled in <operational>= . You may hit applications
>> that love
>> >> > > to have auto-negotiation/enabled available on a= ll Ethernet
>> interfaces and then
>> >> > > you end in a debate where the application devel= opers tell you that
>> no
>> >> > > information in <operational> may have man= y reasons (instrumentation
>> not
>> >> > > implemented, access control rules, whatever and= by reporting
>> enabled=3Dfalse
>> >> > > you do them a favor) but the true answer in suc= h a debate is often
>> that
>> >> > > modeling things as a boolean is simplistic sinc= e there are often
>> more than
>> >> > > exactly two states (in this case, enabled, disa= bled, failed,
>> not-available, ...).
>> >> > > So you settle on blaming the model writer. ;-)<= br> >> >> > >
>> >> > > /js
>> >> > >
>> >> > > --
>> >> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>> >> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Campus Ring 1 | 28759 Bremen |
>> Germany
>> >> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>=
>> >> >
>> >>
>> >> --
>> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
>> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Campus Ring 1 | 28759 Bremen | Germany
>> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<https://www.jacobs-university.de/>
>> >>
>> >> _______________________________________________
>> >> netmod mailing list
>> >> netm= od@ietf.org<mailto:netmod@ietf.org>
>> >> https://www.ietf.org/mailman/listinfo/= netmod
>> >
>> > --
>> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
>> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
>> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<https://www.jacobs-university.de/>
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/net= mod
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
--000000000000f91f2405bd306621-- From nobody Wed Mar 10 07:40:52 2021 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 B24CC3A11C8 for ; Wed, 10 Mar 2021 07:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBLf9eR96SDL for ; Wed, 10 Mar 2021 07:40:46 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578A93A11CD for ; Wed, 10 Mar 2021 07:40:46 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id k9so34184879lfo.12 for ; Wed, 10 Mar 2021 07:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n8g/2K0PcnYyCWHkVHwGSMH53O+p7K3OC8RGkbKzMTI=; b=IHIzFmFFJNyaxgHlAcPXQz9bsaMzBHO1mJ1Lyfb1la2Em6HxhUyGCgjkZMJeG2IgQc lHlA0BqzJ4a3SA5m0ZrY9Fz2uDCgjEwMMkherxHfLpuDEPblsRtIxXGmUSeHEp4nziF6 YqBjjVEy94yffPxEP5+B6v3PJNh+FLr3BvQtP5b6/fCQey0kxegMiys0/O5oKgUHA42e AN0HYiEHK1U5gesiCpC1zMJeNd/hIAEuefgj9307fP6c/imbk/gPoK7qg/zPd8F/cRuo SbWqQjBQRPzc4dNEMKqM3zxopJ9FU4491NP3w594NFHBdTVSN4q4cCV8X5sOtsyG550m rvQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n8g/2K0PcnYyCWHkVHwGSMH53O+p7K3OC8RGkbKzMTI=; b=Tt4DRbaUArvtmr2I7VzEeh4l2O5wY/O4PvlSth0aksbNxlWP2I2NEackkcW4KYjfF3 2KTrKY40fXXqX3pMOK7dNJsOwDfwP0pIdpjBhqnBz4ksOUMOHe0Mwwvw+BCFnuT99trv Hl0E9EDJkHcTy40UaGea9iZwVfA8yXStQ/gxAo9rQfgS7SiDMsetdg4xDFMh5iLrA+dY +bmwQ6grdQR0IZZQA5GknKsBfd4x5G2CSdcY94IAw0+vA9XCRhJGhVKRnq3OeyYIWhGU A1N6yrNU4FyA/+sD/Yg09ZsWClEecOI1Ota3ZfKbSqLplIxHcdHpgStxJBH4jEWU5u9h YvHg== X-Gm-Message-State: AOAM533Ko11lKCOKzjYzxADs6gmezHn0Cuv4p5UGHF7U6b8Z0sRCxcuj aOL9+IHXMde29efR64z+bTdQzwENzNS6GVapHby+Tw== X-Google-Smtp-Source: ABdhPJwTdNP1BHjZf5sniSPLTHujBdHeD96lP7o/ItppmK5WpfmBS30pfGxb1uZd3ScfMFgR2qOrd1Be2NZTheQvs9Q= X-Received: by 2002:a19:6d07:: with SMTP id i7mr2388698lfc.568.1615390844501; Wed, 10 Mar 2021 07:40:44 -0800 (PST) MIME-Version: 1.0 References: <20210120094737.g5l5pvfzligahrj6@anna.jacobs.jacobs-university.de> <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <20210310100058.y7yrbgd6z3rgmo4s@anna.jacobs.jacobs-university.de> <87h7ljfgwp.fsf@nic.cz> In-Reply-To: From: Andy Bierman Date: Wed, 10 Mar 2021 07:40:33 -0800 Message-ID: To: William Lupton Cc: Juergen Schoenwaelder , Italo Busi , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000075d46b05bd307df6" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 15:40:51 -0000 --00000000000075d46b05bd307df6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2021 at 6:34 AM William Lupton wrote: > Lada, all, > > Surely a description is the only way to add a normative requirement that > can't be expressed via YANG statements (including XPath expressions)? > > description-stmt requirements are normative. RFC 2119 language applies exactly the same as if it were in some text section insted of the YANG module. The issue is that the normative requirements for YANG 1.1 defined in RFC 7950 cannot be negated by a description-stmt. E.g. module bad { leaf turn-off-mandatory { type empty; description "If this leaf is present then all YANG mandatory-stmts are ignored throughout this module."; } This may be a valid description-stmt and YANG leaf but any server that implements it is also violating MUST requirements in RFC 7950. Andy > I've always assumed that it's good practice to express what you can using > the modeling language, and then use the description to express any > non-modelable requirements. Obviously there's a problem if the descriptio= n > conflicts with a modeled requirement (and I think it's also good practice > for the description not to repeat anything that's modeled elsewhere). > > I think that RFC 7950 can be interpreted as indicating that the > description is more than just informative. I found this in Section 11, an= d > I take this to imply that the description defines the semantics of > a definition. > > A "description" statement may be added or changed without changing the > > semantics of the definition. > > > For example, if a description says this (this is an example from RFC > 7950), then isn't this a _normative_ semantic requirement? > > "The amount of local storage that can be used to hold syslog messages." > > > William > > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka > wrote: > >> Juergen Schoenwaelder writes: >> >> > A client that has no clue of the annotated leaf can rightfully assume >> > that the default 0 applies. If another client creates this magic leaf >> > that changes the default to 10, then there is going to be confusion. >> > >> > A definition that says 'default 0' says the default is 0. It does not >> > say the default may be zero or something different depending on >> > whether the moon shines or other circumstances. I believe you can't >> > undo a default statement with a description somewhere else. >> >> The problem with descriptions is that there seems to be a general >> agreement that they can somehow supplement the formal YANG statements in >> specifying the data model. This has no support in RFC 7950 though: >> >> - section 7.21.3 only says that a description is "a human-readable textu= al >> description of this definition" >> >> - section 8.1 doesn't include constraints specified in descriptions in t= he >> concept of data tree validity >> >> As a result, data model constraints specified in descriptions is a grey >> area, and it is totally unclear how far-reaching they can possibly be. >> >> Lada >> >> > >> > /js >> > >> > On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote: >> >> Andy, Juergen, >> >> >> >> I am not sure I understand the issue with a client that does not >> understand the augment. >> >> >> >> When this client writes in the running DS, it will not set the bar >> attribute (which is also defined in the augment module) and therefore th= e >> default value 0 will be applied by the system, as expected by the client= . >> >> >> >> When this client reads from the operational DS the applied >> configuration, provided by another client which understands the augment,= it >> will see that the applied configuration for the leaf foo is 10. >> >> >> >> This is a valid applied configuration if the other client had >> explicitly configured the value 10 in the running DS. >> >> >> >> The only difference would be that when the value 10 is explicitly >> configured by the other client the origin is set to intended while when >> =E2=80=9Cimplicitly=E2=80=9D configured using the attribute bar, the ori= gin can be set to >> system (I think it would not be correct to set the origin to default in >> this case). >> >> >> >> BTW, I agree that this is not the most elegant/clean design and that >> the best approach would be not to define any default value in the base >> model. I am just willing to understand if a work-around is possible, >> without breaking any client, to allow re-using an existing module which = has >> already defined a default value. >> >> >> >> Italo >> >> >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> >> Sent: marted=C3=AC 9 marzo 2021 21:12 >> >> To: Juergen Schoenwaelder ; >> Italo Busi ; netmod@ietf.org >> >> Subject: Re: [netmod] Questions about how to assign default values >> with YANG >> >> >> >> >> >> >> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>> wrote: >> >> Changing the semantics of a definition via augments is bad design. >> >> >> >> A system that does not understand the augment will believe the defaul= t >> >> is 0. Since there is no way to force an existing implementation to >> >> understand a certain augmentation, different implementation will >> >> rightfully disagree on the default value in effect. >> >> >> >> >> >> deviation /ex:example/ex:foo { >> >> delete { >> >> default 0; >> >> } >> >> } >> >> >> >> IMO it was a bad idea to say deviations MUST NOT appear in standard >> modules. >> >> Here is a use-case for it. >> >> >> >> The old-client does not know about the new dynamic default but it >> could know >> >> that the old YANG default is not being used. >> >> >> >> >> >> /js >> >> >> >> Andy >> >> >> >> >> >> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: >> >> > Hi Juergen, >> >> > >> >> > Thanks again for your clear explanation on this topic >> >> > >> >> > I have found a similar but slightly different issue. In this case, = a >> YANG default statement exists in the base module but the intention with = the >> augmentation is to "overwrite" the default value on the basis of another >> attribute, defined in the module which augments the base module. >> >> > >> >> > For example, I am wondering whether such a code is valid: >> >> > >> >> > module example-base { >> >> > container example { >> >> > leaf foo { >> >> > type uint8; >> >> > default 0; >> >> > } >> >> > } >> >> > } >> >> > >> >> > module example-augment { >> >> > import example { >> >> > prefix ex; >> >> > } >> >> > >> >> > augment "ex:example" { >> >> > leaf bar { >> >> > type empty; >> >> > description >> >> > "When present, the default value for foo is 10."; >> >> > } >> >> > } >> >> > } >> >> > >> >> > >> >> > In this case, when the leaf foo is not configured but the leaf bar >> is present, the value of foo in the operational datastore should be 10 >> (rather than 0). >> >> > >> >> > In this case, I think that it would be better/cleaner if the origin >> is marked as system. >> >> > >> >> > Maybe a better YANG description for bar could be: "When present, th= e >> system overrides the default value of foo to 10." >> >> > >> >> > What is your and/or WG opinion? >> >> > >> >> > Thanks again >> >> > >> >> > Italo >> >> > >> >> > > -----Original Message----- >> >> > > From: Juergen Schoenwaelder [mailto: >> j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>] >> >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05 >> >> > > To: Italo Busi > >> >> >> > > Cc: 'netmod@ietf.org' > > >> >> > > Subject: Re: [netmod] Questions about how to assign default value= s >> with >> >> > > YANG >> >> > > >> >> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: >> >> > > > >> >> > > > What about the case the leaf is not conditional (but still >> mandatory false >> >> > > since a YANG default statement is defined)? >> >> > > > >> >> > > > May the server still decide not to use/implement this leaf in >> the operational >> >> > > datastore? >> >> > > > >> >> > > > For example, in appendix C.1 of RFC8342, auto-negotiation is >> enabled by >> >> > > default. >> >> > > > What should be the behavior of a system which does not implemen= t >> auto- >> >> > > negotiation? >> >> > > > Return the value false or no value (in the operational >> datastore)? >> >> > > > >> >> > > >> >> > > Here are some of the rules I personally like: >> >> > > >> >> > > - is the ground truth about what a system has and >> does >> >> > > - do not implement leafs that do not apply >> >> > > >> >> > > Hence, interfaces supporting auto-negotiation have either auto- >> >> > > negotiation/enabled =3D true or auto-negotiation/enabled =3D fals= e in >> >> > > . And interfaces not supporting auto-negotiation hav= e >> nothing >> >> > > to report about auto-negotiation. Yes, I do not want to see auto- >> >> > > negotiation/enabled =3D false on a loopback interface. >> >> > > >> >> > > My historic Ethernet interface from the last century would also >> not report >> >> > > auto-negotiation/enabled in . You may hit >> applications that love >> >> > > to have auto-negotiation/enabled available on all Ethernet >> interfaces and then >> >> > > you end in a debate where the application developers tell you tha= t >> no >> >> > > information in may have many reasons >> (instrumentation not >> >> > > implemented, access control rules, whatever and by reporting >> enabled=3Dfalse >> >> > > you do them a favor) but the true answer in such a debate is ofte= n >> that >> >> > > modeling things as a boolean is simplistic since there are often >> more than >> >> > > exactly two states (in this case, enabled, disabled, failed, >> not-available, ...). >> >> > > So you settle on blaming the model writer. ;-) >> >> > > >> >> > > /js >> >> > > >> >> > > -- >> >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >> > > Fax: +49 421 200 3103 > > >> >> > >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y >> >> Fax: +49 421 200 3103 >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --00000000000075d46b05bd307df6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 10, 2021 at 6:34 AM Willi= am Lupton <wlupton@broadb= and-forum.org> wrote:
Lada, all,

Sure= ly a description is the only way to add a normative requirement that can= 9;t be expressed via YANG statements (including XPath expressions)?



descript= ion-stmt requirements are normative.
RFC 2119 language applies ex= actly the same as if it were in some text section insted of the YANG module= .

The issue is that the normative requirements for= YANG 1.1 defined in RFC 7950 cannot be
negated by a description-= stmt. E.g.

module bad {

= =C2=A0 =C2=A0 leaf turn-off-mandatory {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 type empty;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"If this leaf is present the= n all YANG mandatory-stmts are ignored throughout this module.";
=
=C2=A0 =C2=A0 }

This may be a valid descripti= on-stmt and YANG leaf but any server that implements it is also
v= iolating MUST requirements in RFC 7950.


=
Andy

=C2=A0
I've always = assumed that it's good practice to express what you can using the model= ing language, and then use the description to express any non-modelable req= uirements. Obviously there's a problem if the description conflicts wit= h a modeled requirement (and I think it's also good practice for the de= scription not to repeat anything=C2=A0that's modeled elsewhere).
<= div>
I think that RFC 7950 can be interpreted as indicating t= hat the description is more than just informative. I found this in Section = 11, and I take this to imply that the description defines the semantics of = a=C2=A0definition.

A &=
quot;description" statement may be added or changed without changing t=
he
semantics of the definition.

For example, if a description says this (th= is is an example from RFC 7950), then isn't this a _normative_ semantic= requirement?

"Th=
e amount of local storage that can be used to hold syslog messages."

William

On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka <ladislav.lhotka@nic.cz= > wrote:
= Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> write= s:

> A client that has no clue of the annotated leaf can rightfully assume<= br> > that the default 0 applies. If another client creates this magic leaf<= br> > that changes the default to 10, then there is going to be confusion. >
> A definition that says 'default 0' says the default is 0. It d= oes not
> say the default may be zero or something different depending on
> whether the moon shines or other circumstances. I believe you can'= t
> undo a default statement with a description somewhere else.

The problem with descriptions is that there seems to be a general agreement= that they can somehow supplement the formal YANG statements in specifying = the data model. This has no support in RFC 7950 though:

- section 7.21.3 only says that a description is "a human-readable tex= tual
=C2=A0 description of this definition"

- section 8.1 doesn't include constraints specified in descriptions in = the
=C2=A0 concept of data tree validity

As a result, data model constraints specified in descriptions is a grey are= a, and it is totally unclear how far-reaching they can possibly be.

Lada

>
> /js
>
> On Wed, Mar 10, 2021 at 08:54:18AM +0000, Italo Busi wrote:
>> Andy, Juergen,
>>
>> I am not sure I understand the issue with a client that does not u= nderstand the augment.
>>
>> When this client writes in the running DS, it will not set the bar= attribute (which is also defined in the augment module) and therefore the = default value 0 will be applied by the system, as expected by the client. >>
>> When this client reads from the operational DS the applied configu= ration, provided by another client which understands the augment, it will s= ee that the applied configuration for the leaf foo is 10.
>>
>> This is a valid applied configuration if the other client had expl= icitly configured the value 10 in the running DS.
>>
>> The only difference would be that when the value 10 is explicitly = configured by the other client the origin is set to intended while when =E2= =80=9Cimplicitly=E2=80=9D configured using the attribute bar, the origin ca= n be set to system (I think it would not be correct to set the origin to de= fault in this case).
>>
>> BTW, I agree that this is not the most elegant/clean design and th= at the best approach would be not to define any default value in the base m= odel. I am just willing to understand if a work-around is possible, without= breaking any client, to allow re-using an existing module which has alread= y defined a default value.
>>
>> Italo
>>
>> From: Andy Bierman [mailto:andy@yumaworks.com]
>> Sent: marted=C3=AC 9 marzo 2021 21:12
>> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>>; Italo Busi <Italo.Busi@huawei.com>; netmod@ietf.org
>> Subject: Re: [netmod] Questions about how to assign default values= with YANG
>>
>>
>>
>> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <j.schoen= waelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university= .de>> wrote:
>> Changing the semantics of a definition via augments is bad design.=
>>
>> A system that does not understand the augment will believe the def= ault
>> is 0. Since there is no way to force an existing implementation to=
>> understand a certain augmentation, different implementation will >> rightfully disagree on the default value in effect.
>>
>>
>> deviation /ex:example/ex:foo {
>>=C2=A0 =C2=A0 =C2=A0delete {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 default 0;
>>=C2=A0 =C2=A0 =C2=A0 }
>> }
>>
>> IMO it was a bad idea to say deviations MUST NOT appear in standar= d modules.
>> Here is a use-case for it.
>>
>> The old-client does not know about the new dynamic default but it = could know
>> that the old YANG default is not being used.
>>
>>
>> /js
>>
>> Andy
>>
>>
>> On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote:
>> > Hi Juergen,
>> >
>> > Thanks again for your clear explanation on this topic
>> >
>> > I have found a similar but slightly different issue. In this = case, a YANG default statement exists in the base module but the intention = with the augmentation is to "overwrite" the default value on the = basis of another attribute, defined in the module which augments the base m= odule.
>> >
>> > For example, I am wondering whether such a code is valid:
>> >
>> > module example-base {
>> >=C2=A0 =C2=A0container example {
>> >=C2=A0 =C2=A0 =C2=A0leaf foo {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type uint8;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0default 0;
>> >=C2=A0 =C2=A0 =C2=A0}
>> >=C2=A0 =C2=A0}
>> > }
>> >
>> > module example-augment {
>> >=C2=A0 =C2=A0import example {
>> >=C2=A0 =C2=A0 =C2=A0prefix ex;
>> >=C2=A0 =C2=A0}
>> >
>> >=C2=A0 =C2=A0augment "ex:example" {
>> >=C2=A0 =C2=A0 =C2=A0leaf bar {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When present, the defa= ult value for foo is 10.";
>> >=C2=A0 =C2=A0 =C2=A0}
>> >=C2=A0 =C2=A0}
>> > }
>> >
>> >
>> > In this case, when the leaf foo is not configured but the lea= f bar is present, the value of foo in the operational datastore should be 1= 0 (rather than 0).
>> >
>> > In this case, I think that it would be better/cleaner if the = origin is marked as system.
>> >
>> > Maybe a better YANG description for bar could be: "When = present, the system overrides the default value of foo to 10."
>> >
>> > What is your and/or WG opinion?
>> >
>> > Thanks again
>> >
>> > Italo
>> >
>> > > -----Original Message-----
>> > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacob= s-university.de<mailto:j.schoenwaelder@jacobs-university.de>]<= br> >> > > Sent: mercoled=C3=AC 20 gennaio 2021 17:05
>> > > To: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>=
>> > > Cc: 'netmod@ietf.org<mailto:netmod@ietf.org>' <netmod@ietf.org<mailto:netmod@ietf.org>>
>> > > Subject: Re: [netmod] Questions about how to assign defa= ult values with
>> > > YANG
>> > >
>> > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wro= te:
>> > > >
>> > > > What about the case the leaf is not conditional (bu= t still mandatory false
>> > > since a YANG default statement is defined)?
>> > > >
>> > > > May the server still decide not to use/implement th= is leaf in the operational
>> > > datastore?
>> > > >
>> > > > For example, in appendix C.1 of RFC8342, auto-negot= iation is enabled by
>> > > default.
>> > > > What should be the behavior of a system which does = not implement auto-
>> > > negotiation?
>> > > > Return the value false or no value (in the operatio= nal datastore)?
>> > > >
>> > >
>> > > Here are some of the rules I personally like:
>> > >
>> > >=C2=A0 - <operational> is the ground truth about wh= at a system has and does
>> > >=C2=A0 - do not implement leafs that do not apply
>> > >
>> > > Hence, interfaces supporting auto-negotiation have eithe= r auto-
>> > > negotiation/enabled =3D true or auto-negotiation/enabled= =3D false in
>> > > <operational>. And interfaces not supporting auto-= negotiation have nothing
>> > > to report about auto-negotiation. Yes, I do not want to = see auto-
>> > > negotiation/enabled =3D false on a loopback interface. >> > >
>> > > My historic Ethernet interface from the last century wou= ld also not report
>> > > auto-negotiation/enabled in <operational>. You may= hit applications that love
>> > > to have auto-negotiation/enabled available on all Ethern= et interfaces and then
>> > > you end in a debate where the application developers tel= l you that no
>> > > information in <operational> may have many reasons= (instrumentation not
>> > > implemented, access control rules, whatever and by repor= ting enabled=3Dfalse
>> > > you do them a favor) but the true answer in such a debat= e is often that
>> > > modeling things as a boolean is simplistic since there a= re often more than
>> > > exactly two states (in this case, enabled, disabled, fai= led, not-available, ...).
>> > > So you settle on blaming the model writer. ;-)
>> > >
>> > > /js
>> > >
>> > > --
>> > > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
>> > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
>> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<https://www.jacobs-university.de/>
>> >
>>
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg<mailto:netmo= d@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000075d46b05bd307df6-- From nobody Wed Mar 10 08:15:03 2021 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 4B2F63A126C for ; Wed, 10 Mar 2021 08:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdlUk6Fm3Jmr for ; Wed, 10 Mar 2021 08:14:58 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2082.outbound.protection.outlook.com [40.107.22.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255E23A126B for ; Wed, 10 Mar 2021 08:14:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g3LVnlNOHSnB6x2EMqBPQTt2cL3g/QZQmVzp0N2t2yGLO2buxF7C+VoN/9dooBMIJTsK9v6cE1XpHezfD96OuM3L8ArqWA/mP+0/KsTDioCaJzQf+nuamr21M3yxodRinC4wV/RTK7U6QDWusjrq1H7lfcDNho8b3t2gCmjZvApZlsij0A+fTFd9FlrAhRj5IVIF1oGCwj5ZF3ju1yg+ltFGkhmTwLiH9Clhul12BQUL9hA4buCt2AaG3y1xFxYoRikKwcsQ2zhY5nftU07YoanoAxY7xVWCTv5w79Q2oj+hcm4X8ro2yxP+p88mDvd84lc6SgQ/E5Ezd2C01NcDbQ== 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=SlF/zQRkE5hkybsHszk4nHMi0U2Qv0J7MQWA2z+JV7Q=; b=mgD/W9SBdXz7dF1IcRhzLMCGOoUREfMHzbIptAs2MZHdHMICwWYRhLVe9lGHSKfCXMhEA/sFw0KGVYV02o3HJlQviOpaFvLrDdX/T7wl2ovnLcapWeAKciNZaDp2ZCEKQQaTNYc2QfbTVu3RoMpQ8M0vyALloupmwmfHo01ngX3kNy/3W1yZ60tYflpSfKgWifUvAJH21a7rojFUio8qNvuzS+8IiXlUt7q5Qet6DHD7rXXak/LAL98TAQYB71jHZ5NVnyrObOmmN0Tcc48LNGTPMjS0JCQg63dksAz20uu5zCSngISVkSzQ5EFGl3ZApYRKY/VgjsZRuvbiQ0GMZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SlF/zQRkE5hkybsHszk4nHMi0U2Qv0J7MQWA2z+JV7Q=; b=OXJ/hjX1Tatdb3RlwdE4BBTdpCo+rFsn8i+Jd+26Lcp7sB+zrquulMsAcllItRrPb8WcPRa8Q7wTeGhtbzWny9lCtbH3ZuekCiTJyiEttqrX948jiPj6xcDgdcqSVMbRwLKXVzkM3hGzybBjPpQtvSRS34eYSjLxQIvJMY5RomU= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1187.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:264::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Wed, 10 Mar 2021 16:14:56 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 16:14:55 +0000 Date: Wed, 10 Mar 2021 17:14:54 +0100 From: Juergen Schoenwaelder To: Italo Busi Cc: "netmod@ietf.org" Message-ID: <20210310161454.du65fbe4kot7jrfd@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Italo Busi , "netmod@ietf.org" References: <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: FRYP281CA0007.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::17) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FRYP281CA0007.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.13 via Frontend Transport; Wed, 10 Mar 2021 16:14:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: df2e6ad0-da78-474c-9fd0-08d8e3dfa4e8 X-MS-TrafficTypeDiagnostic: AM9P190MB1187: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1l1yf7Wbhx/Mf0KFDQ7yumJKMOER9R8MtNVZhCjntNP2I5uDD9PLPVAyhan1R9SFF5jc3ExNnmTvnlduCScRfSdLwaDKhW2Yzd2YyBN55+fg0Br+Poo0B7YYvJMNOpScw93pUnSa8S/q+VQvIl8g7QIunaoojg7jTu4mAFoiRwT4efEXwkYzcXDhxvRxABQzXOe7LSxjBOi41n+BII187Dk4t7sh1UATetl8HEDyWXMZe+k5sRwR0JQNjHEyO9kK1hRvkcmAsXRJbffWl6/WhrFcDbrZmkCBo/dOpvlTlBXjydNIq6y126Nh9AuDEuZigDHeSILzMDL+B31aoOsXpfL8yTNaHLmoFJVVGPvHKza1IbuEhEtsm27Ht6piwOfr0bEjKHni/blTtFPuZKFJP3Y9pyuAi2IIrAdW8tEPTZfN/7StMVKRvhnPXHSa6rbG/pDgHmZ20TFCdpP4xthxtvGVopb06uba5Y3dZ4bYTZL/kGS4N+EIj7GR+1fXaP1l3OpyHj/g+GOMPlZCx5/xNAdEiNZ7b18LhCt28PRvvHwnXejql7D+7Xgwof8va7+tS3xm5ufreZ4u+VpXxKKb3Q2keeSxqTLHC3lCgOaYQ0k= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(396003)(376002)(39850400004)(346002)(6496006)(8676002)(6486002)(8936002)(2906002)(1076003)(4326008)(3450700001)(52116002)(6916009)(53546011)(66476007)(66556008)(66946007)(956004)(5660300002)(186003)(83380400001)(16526019)(786003)(26005)(966005)(316002)(86362001)(478600001)(30864003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Q0cyL1I0YmtHUDZ6NWZMekI3MTByMyswSVRMRnRHTFo2OEwxRWNGTFp5ejJh?= =?utf-8?B?MTMycWphcWRrSUgyd2QzMTFoQ0MxVFhtTDZFUWlGbkVjM0hrQ2lncHNmNGpy?= =?utf-8?B?bEU4Sys4ZG43MTZkWGlLT2lGU1lMWklyL1RZeEd4M0t4UEpBNDZVNDA0NEpN?= =?utf-8?B?SS9OdzFIVnhPc1RCazFKeGU2SzV5Q3lxODZuaTNEMU5DNElJd1FzRkVxTVYw?= =?utf-8?B?am1CQm40MFBDV0t6WG9lNHcveEFHMnRsVGo2YXFzZ0NWRVVLSjArK3FKeFdU?= =?utf-8?B?YVJ3QWxrZHg1TFdlQmwycUlVZVQwdXBpNlplYm9zNjNNajlKOElzemgrZEdv?= =?utf-8?B?Z0tNdEYrMzY5Mkh6c0Z0d0phTzVTblZ1c2pjMS9Ub2hhb0NNbHhrRm1HNmxE?= =?utf-8?B?WTVXTkxsRzRsTGZ3SjU1VHFWOTV5Z2lOMXJxd1hmWWRaancxdEFuSDViVERY?= =?utf-8?B?bWNrWVhRSGp4bU1qcklvbTdxc3ovMmUrS2lldGpoTVBRSzhHZXpiUVJpQUhT?= =?utf-8?B?RVp6Y3NQTXU3SzFtY1FoVXNhQnlHYWtLR3N1MlViNHpMQW9SNEljZ2YySTZx?= =?utf-8?B?UVFsZ0tvdW1YL0hOUFZNTFZzd2JoWmgwVERKODNEMU9uSGxGTGRQdnBXTS9y?= =?utf-8?B?Y01kbVJ4Wmc4ODBvKzdqUXM2V21BbWtNeVR3UDhwVFUrMzhVSmlTdlZ6QTZw?= =?utf-8?B?RVBnUUErSThjRGFNV0xTNUdjZlFUeFlVY2VESW9Pd2llRjRMUG5mY2ErcEVz?= =?utf-8?B?VDlNdjlKQTdKMVQ5K1pDWkVRUm9CUGFuSWpDQVFVUk90ODdxTG5aUmk5L0oz?= =?utf-8?B?eFFTYWU5ZTd1RTNWKzM0MWx2UU5peG1QWFB3cnR2YU9wbDdWNmltS3U3WjFS?= =?utf-8?B?YUJ5S3dQL1pqbThXeWt1VDJaejJYV01YU2hNOUhScnhvbDZpUzJsblZ3R2Y0?= =?utf-8?B?M1pPeHlEcXU0NjRSUVlkU1Jqc1F5K0I1ZTljMG80WXE2TkIxd1A4UERiajVz?= =?utf-8?B?OEJDUWNueXJ2UDgrUmp5VytvSG54a3RFK2txUVU3VjVUYytlUndkbWJVM3Rx?= =?utf-8?B?VUlEajl1QVBuUFpkKzZ4R0s5YkNpc080b1l5d3NzSGgxWG03T2JDT2xzZHRt?= =?utf-8?B?bGVqZEFEKys2alBreG9BNVluVHc4TStlMEZBYUJmUStlZy8ySWZFbENKUE5Y?= =?utf-8?B?VFpmYktIcDNDNTJ3NS9mUVJ5Tm1JcFNoU2MwWUN1ODQyZG91UGIzck1jdmFQ?= =?utf-8?B?YnNVa0d3UjQ5T0VHYmdHUnZlWDc2L2QzTEFYK0tpZCtlOFlSazl3Z0RMckhp?= =?utf-8?B?bUo5TmRyaUJXM3IrNnE0ODArYzFGLzVhWWM1NFJCNlFqaXN0cTUvOXo2ek1E?= =?utf-8?B?VXNQOGVqU3dORStVSmZEdzRRdzY4a1IvZVlzT3VSNXlJVURlR1I5ZHpQY1ow?= =?utf-8?B?czF1UHZDVnBMWndLWWRic2VaaFN4eThrVmsvUWZoVFJuTlpGK0h1aVN5d25m?= =?utf-8?B?bjc5bnM1MjBNVldQWHVWa2Qzd3ZCbDg1d2NscGNYN2xXdHYxeEZ6MkNoNWxL?= =?utf-8?B?V1NwazBtbk83Y3EvZ2ZFWnFZR0V1R0hHa2t1UlpMWUdoR1dBQk00SkMvMkN0?= =?utf-8?B?L3BJU1ZKOTNVc2lWVFR0Y3U2NktpOTFuV1hiT3h6M3duTVpITUtpbHljSFZt?= =?utf-8?B?OFM1U2RlY2VkTm1jSnlDTXNnMnNiRUdEWGUzLyt5U0tTNDY4R1d4aHNoMTIv?= =?utf-8?Q?9HuzI6usm7js6dCszI/HPzdtSAJCj+IgODDbhDe?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: df2e6ad0-da78-474c-9fd0-08d8e3dfa4e8 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2021 16:14:55.8319 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: m4StEHKYPbDZ+Up9DYyBTbW3xTLeFkCwHfSpST6jH2tVze4TKBBAMV1T0fI9KbUNILA1G3lp1VSKQTz0No9HjoCuMiSuoiE6beakgzS9kBA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1187 Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 16:15:01 -0000 I do not understand where the problem is. a) If a leaf says my default is 0, then the default is 0 and you can't change that by creating other leafs somewhere else that says something different. b) If a leaf says that is has a default value but the value is determined in some magic way not defined here, then you can add additional leafs that detail the magic for certain contexts The point is that a) tells clients they can safely assume the default value is 0 while b) tells clients that they can assume that there is a default but the exact default value they will not know unless they understand magic. If a data model author thought the default is always 0 and later he/she realizes that in some contexts the default should be something different, then you have to resolve that by creating new leafs (in the current version of YANG) or you declares a non-backwards compatible new version of the definition of the leaf (if the versioning work gets standardized). /js On Wed, Mar 10, 2021 at 03:25:13PM +0000, Italo Busi wrote: > Hi Andy, > > I see your point, > > At the beginning of this thread, I have had a doubt about how to reconcile sec. 7.6.1 of RFC7950 with sec. 5.3 of RFC8342: > > Requests to retrieve nodes from always return the value > in use if the node exists, regardless of any default value specified > in the YANG module. If no value is returned for a given node, then > this implies that the node is not used by the device. > > My understanding that the client will always get the applied value independently on whether it is 0 or 10 or another value. > > Anyway, it seems to me that the issue is mainly about the keyword “default†so let me take a step back and try to define the issue I am trying to solve, without assuming any solution. > > What I need is to find a solution that allows a client to request the server to apply the value 10 for the leaf foo in the operational DS without “explicitly†writing the value 10 in the running DS but “implicitly†by writing another leaf bar in the running DS, even if the leaf foo has a YANG default statement defining 0 as its default value. > > I think that the NMDA architecture is quite flexible and could be leveraged to resolve this issue. > > Stepping away from defining default values, one possibility could be that the applied configuration of the value of foo is defined by the system before applying the intended configuration in the operational DS, as a side effect of applying the configuration of the leaf bar. > > Another alternative which is just jumping to my mind, could be that the value of 10 for the leaf foo is set by the system in the intended DS, applying a sort of template. Should in this case the definition of the leaf bar be interpreted as a template configuration or how should the required template configuration be provided? > > Could any of this option be used to resolve this issue? > > Italo > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: mercoledì 10 marzo 2021 15:16 > To: Italo Busi > Cc: Juergen Schoenwaelder ; netmod@ietf.org > Subject: Re: [netmod] Questions about how to assign default values with YANG > > > > On Wed, Mar 10, 2021 at 12:54 AM Italo Busi > wrote: > Andy, Juergen, > > I am not sure I understand the issue with a client that does not understand the augment. > > When this client writes in the running DS, it will not set the bar attribute (which is also defined in the augment module) and therefore the default value 0 will be applied by the system, as expected by the client. > > When this client reads from the operational DS the applied configuration, provided by another client which understands the augment, it will see that the applied configuration for the leaf foo is 10. > > This is a valid applied configuration if the other client had explicitly configured the value 10 in the running DS. > > The only difference would be that when the value 10 is explicitly configured by the other client the origin is set to intended while when “implicitly†configured using the attribute bar, the origin can be set to system (I think it would not be correct to set the origin to default in this case). > > BTW, I agree that this is not the most elegant/clean design and that the best approach would be not to define any default value in the base model. I am just willing to understand if a work-around is possible, without breaking any client, to allow re-using an existing module which has already defined a default value. > > > Read sec. 7.6.1 again, especially this part: > > When the default value is in use, the server MUST operationally > > behave as if the leaf was present in the data tree with the default > > value as its value. > > > > > > Your proposal violates this MUST because the default is in use according to the rules > > > > > > Italo > > > Andy > > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: martedì 9 marzo 2021 21:12 > To: Juergen Schoenwaelder >; Italo Busi >; netmod@ietf.org > Subject: Re: [netmod] Questions about how to assign default values with YANG > > > > On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder > wrote: > Changing the semantics of a definition via augments is bad design. > > A system that does not understand the augment will believe the default > is 0. Since there is no way to force an existing implementation to > understand a certain augmentation, different implementation will > rightfully disagree on the default value in effect. > > > deviation /ex:example/ex:foo { > delete { > default 0; > } > } > > IMO it was a bad idea to say deviations MUST NOT appear in standard modules. > Here is a use-case for it. > > The old-client does not know about the new dynamic default but it could know > that the old YANG default is not being used. > > > /js > > Andy > > > On Mon, Mar 08, 2021 at 08:19:39PM +0000, Italo Busi wrote: > > Hi Juergen, > > > > Thanks again for your clear explanation on this topic > > > > I have found a similar but slightly different issue. In this case, a YANG default statement exists in the base module but the intention with the augmentation is to "overwrite" the default value on the basis of another attribute, defined in the module which augments the base module. > > > > For example, I am wondering whether such a code is valid: > > > > module example-base { > > container example { > > leaf foo { > > type uint8; > > default 0; > > } > > } > > } > > > > module example-augment { > > import example { > > prefix ex; > > } > > > > augment "ex:example" { > > leaf bar { > > type empty; > > description > > "When present, the default value for foo is 10."; > > } > > } > > } > > > > > > In this case, when the leaf foo is not configured but the leaf bar is present, the value of foo in the operational datastore should be 10 (rather than 0). > > > > In this case, I think that it would be better/cleaner if the origin is marked as system. > > > > Maybe a better YANG description for bar could be: "When present, the system overrides the default value of foo to 10." > > > > What is your and/or WG opinion? > > > > Thanks again > > > > Italo > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: mercoledì 20 gennaio 2021 17:05 > > > To: Italo Busi > > > > Cc: 'netmod@ietf.org' > > > > Subject: Re: [netmod] Questions about how to assign default values with > > > YANG > > > > > > On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > > > > > > > What about the case the leaf is not conditional (but still mandatory false > > > since a YANG default statement is defined)? > > > > > > > > May the server still decide not to use/implement this leaf in the operational > > > datastore? > > > > > > > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by > > > default. > > > > What should be the behavior of a system which does not implement auto- > > > negotiation? > > > > Return the value false or no value (in the operational datastore)? > > > > > > > > > > Here are some of the rules I personally like: > > > > > > - is the ground truth about what a system has and does > > > - do not implement leafs that do not apply > > > > > > Hence, interfaces supporting auto-negotiation have either auto- > > > negotiation/enabled = true or auto-negotiation/enabled = false in > > > . And interfaces not supporting auto-negotiation have nothing > > > to report about auto-negotiation. Yes, I do not want to see auto- > > > negotiation/enabled = false on a loopback interface. > > > > > > My historic Ethernet interface from the last century would also not report > > > auto-negotiation/enabled in . You may hit applications that love > > > to have auto-negotiation/enabled available on all Ethernet interfaces and then > > > you end in a debate where the application developers tell you that no > > > information in may have many reasons (instrumentation not > > > implemented, access control rules, whatever and by reporting enabled=false > > > you do them a favor) but the true answer in such a debate is often that > > > modeling things as a boolean is simplistic since there are often more than > > > exactly two states (in this case, enabled, disabled, failed, not-available, ...). > > > So you settle on blaming the model writer. ;-) > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 10 09:34:54 2021 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 AA0C33A143A for ; Wed, 10 Mar 2021 09:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UBlWtGbJCvZi for ; Wed, 10 Mar 2021 09:34:50 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B9D3A1436 for ; Wed, 10 Mar 2021 09:34:49 -0800 (PST) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DwfGx4p90z67xLN; Thu, 11 Mar 2021 01:30:17 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 18:34:41 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Wed, 10 Mar 2021 18:34:41 +0100 From: Italo Busi To: 'Juergen Schoenwaelder' CC: "netmod@ietf.org" Thread-Topic: [netmod] Questions about how to assign default values with YANG Thread-Index: AdbvCmZgzen+a6G4QWicT/glaRAynP///QGA///e3yCAAEHcAP//waGggACHKYD/tcyd8BK8WnuAAACoPAD//yMQoP/99AcA//vNQxD/95QgAP/vD80Q Date: Wed, 10 Mar 2021 17:34:41 +0000 Message-ID: <53a7042e5b1a47b7a3122c56a7900ac7@huawei.com> References: <2384a8f549c94ea0ac46d6c772fbca43@huawei.com> <20210120114446.ovih63db7vmv7c7s@anna.jacobs.jacobs-university.de> <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> <20210310161454.du65fbe4kot7jrfd@anna.jacobs.jacobs-university.de> In-Reply-To: <20210310161454.du65fbe4kot7jrfd@anna.jacobs.jacobs-university.de> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.173] Content-Type: multipart/alternative; boundary="_000_53a7042e5b1a47b7a3122c56a7900ac7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 17:34:54 -0000 --_000_53a7042e5b1a47b7a3122c56a7900ac7huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVlcmdlbiwNCg0KSSB0aGluayB5b3UgaGF2ZSBnb3QgdGhlIHByb2JsZW06ICJhIGRhdGEgbW9k ZWwgYXV0aG9yIHRob3VnaHQgdGhlIGRlZmF1bHQgaXMgYWx3YXlzIDAgYW5kIGxhdGVyIGhlL3No ZSByZWFsaXplcyB0aGF0IGluIHNvbWUgY29udGV4dHMgdGhlIGRlZmF1bHQgc2hvdWxkIGJlIHNv bWV0aGluZyBkaWZmZXJlbnQiDQoNClVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBjcmVh dGluZyBhIG5ldyBsZWFmIChlLmcuLCBmb28tbmV3KSB3b3VsZCBjb25mdXNlIGFuIGV4aXN0aW5n IGNsaWVudC4NCg0KRm9yIGV4YW1wbGUsIHdpdGhpbiB0aGUgb3BlcmF0aW9uYWwgRFMsIHRoZSB2 YWx1ZSBvZiBmb28gd2lsbCBiZSBzZXQgdG8gMCAoYXMgcGVyIFlBTkcgZGVmYXVsdCBzdGF0ZW1l bnQpIHdoaWxlIHRoZSB2YWx1ZSBvZiBmb28tbmV3IHdpbGwgYmUgc2V0IHRvIDEwLCB3aGljaCBy ZXByZXNlbnRzIHRoZSBhY3R1YWwgdmFsdWUgaW4gdXNlIGJ5IHRoZSBzeXN0ZW0uDQoNCk5vdywg dGhlIGV4aXN0aW5nIGNsaWVudCwgd2hpY2ggaXMgbm90IGF3YXJlIG9mIGZvby1uZXcsIHdoZW4g cmVhZGluZyB0aGUgdmFsdWUgb2YgZm9vIGluIHRoZSBvcGVyYXRpb25hbCBEUyB3aWxsIGluY29y cmVjdGx5IHRoaW5rIHRoYXQgdGhlIGFjdHVhbCB2YWx1ZSBpbiB1c2UgYnkgdGhlIHN5c3RlbSBp cyAwIHJhdGhlciB0aGFuIDEwLg0KDQpBbSBJIG1pc3NpbmcgYW55dGhpbmc/DQoNCkluc3RlYWQs IGlmIHdlIGNhbiBmaW5kIGEgbWFnaWMgd2F5IHRvIGFwcGx5IHRoZSB2YWx1ZSAxMCB0byBmb28g d2l0aGluIHRoZSBvcGVyYXRpb25hbCBEUywgdGhlIGV4aXN0aW5nIGNsaWVudCBjYW4gcmVhZCB0 aGUgdmFsdWUgb2YgZm9vIGluIHRoZSBvcGVyYXRpb25hbCBEUyBhbmQgY29ycmVjdGx5IHVuZGVy c3RhbmQgdGhhdCB0aGUgYWN0dWFsIHZhbHVlIGluIHVzZSBieSB0aGUgc3lzdGVtIGlzIDEwIChl dmVuIGlmIHRoaXMgaXMgbm90IHRoZSBkZWZhdWx0IHZhbHVlIG9mIGZvbykuDQoNCkl0YWxvDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVlcmdlbiBTY2hvZW53YWVs ZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlXQ0KPiBTZW50 OiBtZXJjb2xlZMOsIDEwIG1hcnpvIDIwMjEgMTc6MTUNCj4gVG86IEl0YWxvIEJ1c2kgPEl0YWxv LkJ1c2lAaHVhd2VpLmNvbT4NCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W25ldG1vZF0gUXVlc3Rpb25zIGFib3V0IGhvdyB0byBhc3NpZ24gZGVmYXVsdCB2YWx1ZXMgd2l0 aA0KPiBZQU5HDQo+DQo+IEkgZG8gbm90IHVuZGVyc3RhbmQgd2hlcmUgdGhlIHByb2JsZW0gaXMu DQo+DQo+IGEpIElmIGEgbGVhZiBzYXlzIG15IGRlZmF1bHQgaXMgMCwgdGhlbiB0aGUgZGVmYXVs dCBpcyAwIGFuZCB5b3UgY2FuJ3QNCj4gICAgY2hhbmdlIHRoYXQgYnkgY3JlYXRpbmcgb3RoZXIg bGVhZnMgc29tZXdoZXJlIGVsc2UgdGhhdCBzYXlzDQo+ICAgIHNvbWV0aGluZyBkaWZmZXJlbnQu DQo+DQo+IGIpIElmIGEgbGVhZiBzYXlzIHRoYXQgaXMgaGFzIGEgZGVmYXVsdCB2YWx1ZSBidXQg dGhlIHZhbHVlIGlzDQo+ICAgIGRldGVybWluZWQgaW4gc29tZSBtYWdpYyB3YXkgbm90IGRlZmlu ZWQgaGVyZSwgdGhlbiB5b3UgY2FuIGFkZA0KPiAgICBhZGRpdGlvbmFsIGxlYWZzIHRoYXQgZGV0 YWlsIHRoZSBtYWdpYyBmb3IgY2VydGFpbiBjb250ZXh0cw0KPg0KPiBUaGUgcG9pbnQgaXMgdGhh dCBhKSB0ZWxscyBjbGllbnRzIHRoZXkgY2FuIHNhZmVseSBhc3N1bWUgdGhlIGRlZmF1bHQgdmFs dWUgaXMgMA0KPiB3aGlsZSBiKSB0ZWxscyBjbGllbnRzIHRoYXQgdGhleSBjYW4gYXNzdW1lIHRo YXQgdGhlcmUgaXMgYSBkZWZhdWx0IGJ1dCB0aGUgZXhhY3QNCj4gZGVmYXVsdCB2YWx1ZSB0aGV5 IHdpbGwgbm90IGtub3cgdW5sZXNzIHRoZXkgdW5kZXJzdGFuZCBtYWdpYy4NCj4NCj4gSWYgYSBk YXRhIG1vZGVsIGF1dGhvciB0aG91Z2h0IHRoZSBkZWZhdWx0IGlzIGFsd2F5cyAwIGFuZCBsYXRl ciBoZS9zaGUNCj4gcmVhbGl6ZXMgdGhhdCBpbiBzb21lIGNvbnRleHRzIHRoZSBkZWZhdWx0IHNo b3VsZCBiZSBzb21ldGhpbmcgZGlmZmVyZW50LCB0aGVuDQo+IHlvdSBoYXZlIHRvIHJlc29sdmUg dGhhdCBieSBjcmVhdGluZyBuZXcgbGVhZnMgKGluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgWUFO RykNCj4gb3IgeW91IGRlY2xhcmVzIGEgbm9uLWJhY2t3YXJkcyBjb21wYXRpYmxlIG5ldyB2ZXJz aW9uIG9mIHRoZSBkZWZpbml0aW9uIG9mDQo+IHRoZSBsZWFmIChpZiB0aGUgdmVyc2lvbmluZyB3 b3JrIGdldHMgc3RhbmRhcmRpemVkKS4NCj4NCj4gL2pzDQo+DQo+IE9uIFdlZCwgTWFyIDEwLCAy MDIxIGF0IDAzOjI1OjEzUE0gKzAwMDAsIEl0YWxvIEJ1c2kgd3JvdGU6DQo+ID4gSGkgQW5keSwN Cj4gPg0KPiA+IEkgc2VlIHlvdXIgcG9pbnQsDQo+ID4NCj4gPiBBdCB0aGUgYmVnaW5uaW5nIG9m IHRoaXMgdGhyZWFkLCBJIGhhdmUgaGFkIGEgZG91YnQgYWJvdXQgaG93IHRvIHJlY29uY2lsZQ0K PiBzZWMuIDcuNi4xIG9mIFJGQzc5NTAgd2l0aCBzZWMuIDUuMyBvZiBSRkM4MzQyOg0KPiA+DQo+ ID4gICAgUmVxdWVzdHMgdG8gcmV0cmlldmUgbm9kZXMgZnJvbSA8b3BlcmF0aW9uYWw+IGFsd2F5 cyByZXR1cm4gdGhlIHZhbHVlDQo+ID4gICAgaW4gdXNlIGlmIHRoZSBub2RlIGV4aXN0cywgcmVn YXJkbGVzcyBvZiBhbnkgZGVmYXVsdCB2YWx1ZSBzcGVjaWZpZWQNCj4gPiAgICBpbiB0aGUgWUFO RyBtb2R1bGUuICBJZiBubyB2YWx1ZSBpcyByZXR1cm5lZCBmb3IgYSBnaXZlbiBub2RlLCB0aGVu DQo+ID4gICAgdGhpcyBpbXBsaWVzIHRoYXQgdGhlIG5vZGUgaXMgbm90IHVzZWQgYnkgdGhlIGRl dmljZS4NCj4gPg0KPiA+IE15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgY2xpZW50IHdpbGwgYWx3 YXlzIGdldCB0aGUgYXBwbGllZCB2YWx1ZQ0KPiBpbmRlcGVuZGVudGx5IG9uIHdoZXRoZXIgaXQg aXMgMCBvciAxMCBvciBhbm90aGVyIHZhbHVlLg0KPiA+DQo+ID4gQW55d2F5LCBpdCBzZWVtcyB0 byBtZSB0aGF0IHRoZSBpc3N1ZSBpcyBtYWlubHkgYWJvdXQgdGhlIGtleXdvcmQg4oCcZGVmYXVs dOKAnQ0KPiBzbyBsZXQgbWUgdGFrZSBhIHN0ZXAgYmFjayBhbmQgdHJ5IHRvIGRlZmluZSB0aGUg aXNzdWUgSSBhbSB0cnlpbmcgdG8gc29sdmUsDQo+IHdpdGhvdXQgYXNzdW1pbmcgYW55IHNvbHV0 aW9uLg0KPiA+DQo+ID4gV2hhdCBJIG5lZWQgaXMgdG8gZmluZCBhIHNvbHV0aW9uIHRoYXQgYWxs b3dzIGEgY2xpZW50IHRvIHJlcXVlc3QgdGhlIHNlcnZlciB0bw0KPiBhcHBseSB0aGUgdmFsdWUg MTAgZm9yIHRoZSBsZWFmIGZvbyBpbiB0aGUgb3BlcmF0aW9uYWwgRFMgd2l0aG91dCDigJxleHBs aWNpdGx54oCdDQo+IHdyaXRpbmcgdGhlIHZhbHVlIDEwIGluIHRoZSBydW5uaW5nIERTIGJ1dCDi gJxpbXBsaWNpdGx54oCdIGJ5IHdyaXRpbmcgYW5vdGhlciBsZWFmDQo+IGJhciBpbiB0aGUgcnVu bmluZyBEUywgZXZlbiBpZiB0aGUgbGVhZiBmb28gaGFzIGEgWUFORyBkZWZhdWx0IHN0YXRlbWVu dA0KPiBkZWZpbmluZyAwIGFzIGl0cyBkZWZhdWx0IHZhbHVlLg0KPiA+DQo+ID4gSSB0aGluayB0 aGF0IHRoZSBOTURBIGFyY2hpdGVjdHVyZSBpcyBxdWl0ZSBmbGV4aWJsZSBhbmQgY291bGQgYmUg bGV2ZXJhZ2VkDQo+IHRvIHJlc29sdmUgdGhpcyBpc3N1ZS4NCj4gPg0KPiA+IFN0ZXBwaW5nIGF3 YXkgZnJvbSBkZWZpbmluZyBkZWZhdWx0IHZhbHVlcywgb25lIHBvc3NpYmlsaXR5IGNvdWxkIGJl IHRoYXQNCj4gdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBvZiB0aGUgdmFsdWUgb2YgZm9vIGlz IGRlZmluZWQgYnkgdGhlIHN5c3RlbSBiZWZvcmUNCj4gYXBwbHlpbmcgdGhlIGludGVuZGVkIGNv bmZpZ3VyYXRpb24gaW4gdGhlIG9wZXJhdGlvbmFsIERTLCBhcyBhIHNpZGUgZWZmZWN0IG9mDQo+ IGFwcGx5aW5nIHRoZSBjb25maWd1cmF0aW9uIG9mIHRoZSBsZWFmIGJhci4NCj4gPg0KPiA+IEFu b3RoZXIgYWx0ZXJuYXRpdmUgd2hpY2ggaXMganVzdCBqdW1waW5nIHRvIG15IG1pbmQsIGNvdWxk IGJlIHRoYXQgdGhlDQo+IHZhbHVlIG9mIDEwIGZvciB0aGUgbGVhZiBmb28gaXMgc2V0IGJ5IHRo ZSBzeXN0ZW0gaW4gdGhlIGludGVuZGVkIERTLCBhcHBseWluZyBhDQo+IHNvcnQgb2YgdGVtcGxh dGUuIFNob3VsZCBpbiB0aGlzIGNhc2UgdGhlIGRlZmluaXRpb24gb2YgdGhlIGxlYWYgYmFyIGJl DQo+IGludGVycHJldGVkIGFzIGEgdGVtcGxhdGUgY29uZmlndXJhdGlvbiBvciBob3cgc2hvdWxk IHRoZSByZXF1aXJlZCB0ZW1wbGF0ZQ0KPiBjb25maWd1cmF0aW9uIGJlIHByb3ZpZGVkPw0KPiA+ DQo+ID4gQ291bGQgYW55IG9mIHRoaXMgb3B0aW9uIGJlIHVzZWQgdG8gcmVzb2x2ZSB0aGlzIGlz c3VlPw0KPiA+DQo+ID4gSXRhbG8NCj4gPg0KPiA+IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbV0NCj4gPiBTZW50OiBtZXJjb2xlZMOsIDEwIG1hcnpvIDIwMjEg MTU6MTYNCj4gPiBUbzogSXRhbG8gQnVzaSA8SXRhbG8uQnVzaUBodWF3ZWkuY29tPG1haWx0bzpJ dGFsby5CdXNpQGh1YXdlaS5jb20+Pg0KPiA+IENjOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlPj47DQo+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFF1ZXN0aW9ucyBhYm91dCBo b3cgdG8gYXNzaWduIGRlZmF1bHQgdmFsdWVzDQo+ID4gd2l0aCBZQU5HDQo+ID4NCj4gPg0KPiA+ DQo+ID4gT24gV2VkLCBNYXIgMTAsIDIwMjEgYXQgMTI6NTQgQU0gSXRhbG8gQnVzaQ0KPiA8SXRh bG8uQnVzaUBodWF3ZWkuY29tPG1haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb208bWFpbHRvOkl0 YWxvLkJ1c2lAaHVhd2VpLmNvbTxtYWlsdG86SXRhbG8uQnVzaUBodWF3ZWkuY29tPj4+IHdyb3Rl Og0KPiA+IEFuZHksIEp1ZXJnZW4sDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFu ZCB0aGUgaXNzdWUgd2l0aCBhIGNsaWVudCB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQNCj4gdGhl IGF1Z21lbnQuDQo+ID4NCj4gPiBXaGVuIHRoaXMgY2xpZW50IHdyaXRlcyBpbiB0aGUgcnVubmlu ZyBEUywgaXQgd2lsbCBub3Qgc2V0IHRoZSBiYXIgYXR0cmlidXRlDQo+ICh3aGljaCBpcyBhbHNv IGRlZmluZWQgaW4gdGhlIGF1Z21lbnQgbW9kdWxlKSBhbmQgdGhlcmVmb3JlIHRoZSBkZWZhdWx0 DQo+IHZhbHVlIDAgd2lsbCBiZSBhcHBsaWVkIGJ5IHRoZSBzeXN0ZW0sIGFzIGV4cGVjdGVkIGJ5 IHRoZSBjbGllbnQuDQo+ID4NCj4gPiBXaGVuIHRoaXMgY2xpZW50IHJlYWRzIGZyb20gdGhlIG9w ZXJhdGlvbmFsIERTIHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24sDQo+IHByb3ZpZGVkIGJ5IGFu b3RoZXIgY2xpZW50IHdoaWNoIHVuZGVyc3RhbmRzIHRoZSBhdWdtZW50LCBpdCB3aWxsIHNlZSB0 aGF0DQo+IHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBsZWFmIGZvbyBpcyAxMC4N Cj4gPg0KPiA+IFRoaXMgaXMgYSB2YWxpZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaWYgdGhlIG90 aGVyIGNsaWVudCBoYWQgZXhwbGljaXRseQ0KPiBjb25maWd1cmVkIHRoZSB2YWx1ZSAxMCBpbiB0 aGUgcnVubmluZyBEUy4NCj4gPg0KPiA+IFRoZSBvbmx5IGRpZmZlcmVuY2Ugd291bGQgYmUgdGhh dCB3aGVuIHRoZSB2YWx1ZSAxMCBpcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQNCj4gYnkgdGhlIG90 aGVyIGNsaWVudCB0aGUgb3JpZ2luIGlzIHNldCB0byBpbnRlbmRlZCB3aGlsZSB3aGVuIOKAnGlt cGxpY2l0bHnigJ0NCj4gY29uZmlndXJlZCB1c2luZyB0aGUgYXR0cmlidXRlIGJhciwgdGhlIG9y aWdpbiBjYW4gYmUgc2V0IHRvIHN5c3RlbSAoSSB0aGluayBpdA0KPiB3b3VsZCBub3QgYmUgY29y cmVjdCB0byBzZXQgdGhlIG9yaWdpbiB0byBkZWZhdWx0IGluIHRoaXMgY2FzZSkuDQo+ID4NCj4g PiBCVFcsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgbW9zdCBlbGVnYW50L2NsZWFuIGRl c2lnbiBhbmQgdGhhdCB0aGUgYmVzdA0KPiBhcHByb2FjaCB3b3VsZCBiZSBub3QgdG8gZGVmaW5l IGFueSBkZWZhdWx0IHZhbHVlIGluIHRoZSBiYXNlIG1vZGVsLiBJIGFtDQo+IGp1c3Qgd2lsbGlu ZyB0byB1bmRlcnN0YW5kIGlmIGEgd29yay1hcm91bmQgaXMgcG9zc2libGUsIHdpdGhvdXQgYnJl YWtpbmcgYW55DQo+IGNsaWVudCwgdG8gYWxsb3cgcmUtdXNpbmcgYW4gZXhpc3RpbmcgbW9kdWxl IHdoaWNoIGhhcyBhbHJlYWR5IGRlZmluZWQgYQ0KPiBkZWZhdWx0IHZhbHVlLg0KPiA+DQo+ID4N Cj4gPiBSZWFkIHNlYy4gNy42LjEgYWdhaW4sIGVzcGVjaWFsbHkgdGhpcyBwYXJ0Og0KPiA+DQo+ ID4gICAgV2hlbiB0aGUgZGVmYXVsdCB2YWx1ZSBpcyBpbiB1c2UsIHRoZSBzZXJ2ZXIgTVVTVCBv cGVyYXRpb25hbGx5DQo+ID4NCj4gPiAgICBiZWhhdmUgYXMgaWYgdGhlIGxlYWYgd2FzIHByZXNl bnQgaW4gdGhlIGRhdGEgdHJlZSB3aXRoIHRoZSBkZWZhdWx0DQo+ID4NCj4gPiAgICB2YWx1ZSBh cyBpdHMgdmFsdWUuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFlvdXIgcHJvcG9zYWwg dmlvbGF0ZXMgdGhpcyBNVVNUIGJlY2F1c2UgdGhlIGRlZmF1bHQgaXMgaW4gdXNlDQo+ID4gYWNj b3JkaW5nIHRvIHRoZSBydWxlcw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJdGFsbw0K PiA+DQo+ID4NCj4gPiBBbmR5DQo+ID4NCj4gPg0KPiA+IEZyb206IEFuZHkgQmllcm1hbg0KPiA+ IFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+XQ0K PiA+IFNlbnQ6IG1hcnRlZMOsIDkgbWFyem8gMjAyMSAyMToxMg0KPiA+IFRvOiBKdWVyZ2VuIFNj aG9lbndhZWxkZXINCj4gPiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1h aWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuDQo+ID4gaXZlcnNpdHkuZGU+PjsgSXRhbG8g QnVzaQ0KPiA+IDxJdGFsby5CdXNpQGh1YXdlaS5jb208bWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2Vp LmNvbTxtYWlsdG86SXRhbG8uQnVzaUBodWF3ZWkuY29tPG1haWx0bzpJdGFsby5CdXNpQGh1YXdl aS5jb20+Pj47DQo+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gPiBTdWJqZWN0 OiBSZTogW25ldG1vZF0gUXVlc3Rpb25zIGFib3V0IGhvdyB0byBhc3NpZ24gZGVmYXVsdCB2YWx1 ZXMNCj4gPiB3aXRoIFlBTkcNCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBUdWUsIE1hciA5LCAyMDIx IGF0IDExOjUyIEFNIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiA8ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLTxtYWlsdG86 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+IHVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCj4gPiBD aGFuZ2luZyB0aGUgc2VtYW50aWNzIG9mIGEgZGVmaW5pdGlvbiB2aWEgYXVnbWVudHMgaXMgYmFk IGRlc2lnbi4NCj4gPg0KPiA+IEEgc3lzdGVtIHRoYXQgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGUg YXVnbWVudCB3aWxsIGJlbGlldmUgdGhlIGRlZmF1bHQNCj4gPiBpcyAwLiBTaW5jZSB0aGVyZSBp cyBubyB3YXkgdG8gZm9yY2UgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdG8NCj4gPiB1bmRl cnN0YW5kIGEgY2VydGFpbiBhdWdtZW50YXRpb24sIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiB3 aWxsDQo+ID4gcmlnaHRmdWxseSBkaXNhZ3JlZSBvbiB0aGUgZGVmYXVsdCB2YWx1ZSBpbiBlZmZl Y3QuDQo+ID4NCj4gPg0KPiA+IGRldmlhdGlvbiAvZXg6ZXhhbXBsZS9leDpmb28gew0KPiA+ICAg ICBkZWxldGUgew0KPiA+ICAgICAgICBkZWZhdWx0IDA7DQo+ID4gICAgICB9DQo+ID4gfQ0KPiA+ DQo+ID4gSU1PIGl0IHdhcyBhIGJhZCBpZGVhIHRvIHNheSBkZXZpYXRpb25zIE1VU1QgTk9UIGFw cGVhciBpbiBzdGFuZGFyZA0KPiBtb2R1bGVzLg0KPiA+IEhlcmUgaXMgYSB1c2UtY2FzZSBmb3Ig aXQuDQo+ID4NCj4gPiBUaGUgb2xkLWNsaWVudCBkb2VzIG5vdCBrbm93IGFib3V0IHRoZSBuZXcg ZHluYW1pYyBkZWZhdWx0IGJ1dCBpdA0KPiA+IGNvdWxkIGtub3cgdGhhdCB0aGUgb2xkIFlBTkcg ZGVmYXVsdCBpcyBub3QgYmVpbmcgdXNlZC4NCj4gPg0KPiA+DQo+ID4gL2pzDQo+ID4NCj4gPiBB bmR5DQo+ID4NCj4gPg0KPiA+IE9uIE1vbiwgTWFyIDA4LCAyMDIxIGF0IDA4OjE5OjM5UE0gKzAw MDAsIEl0YWxvIEJ1c2kgd3JvdGU6DQo+ID4gPiBIaSBKdWVyZ2VuLA0KPiA+ID4NCj4gPiA+IFRo YW5rcyBhZ2FpbiBmb3IgeW91ciBjbGVhciBleHBsYW5hdGlvbiBvbiB0aGlzIHRvcGljDQo+ID4g Pg0KPiA+ID4gSSBoYXZlIGZvdW5kIGEgc2ltaWxhciBidXQgc2xpZ2h0bHkgZGlmZmVyZW50IGlz c3VlLiBJbiB0aGlzIGNhc2UsIGEgWUFORw0KPiBkZWZhdWx0IHN0YXRlbWVudCBleGlzdHMgaW4g dGhlIGJhc2UgbW9kdWxlIGJ1dCB0aGUgaW50ZW50aW9uIHdpdGggdGhlDQo+IGF1Z21lbnRhdGlv biBpcyB0byAib3ZlcndyaXRlIiB0aGUgZGVmYXVsdCB2YWx1ZSBvbiB0aGUgYmFzaXMgb2YgYW5v dGhlcg0KPiBhdHRyaWJ1dGUsIGRlZmluZWQgaW4gdGhlIG1vZHVsZSB3aGljaCBhdWdtZW50cyB0 aGUgYmFzZSBtb2R1bGUuDQo+ID4gPg0KPiA+ID4gRm9yIGV4YW1wbGUsIEkgYW0gd29uZGVyaW5n IHdoZXRoZXIgc3VjaCBhIGNvZGUgaXMgdmFsaWQ6DQo+ID4gPg0KPiA+ID4gbW9kdWxlIGV4YW1w bGUtYmFzZSB7DQo+ID4gPiAgIGNvbnRhaW5lciBleGFtcGxlIHsNCj4gPiA+ICAgICBsZWFmIGZv byB7DQo+ID4gPiAgICAgICB0eXBlIHVpbnQ4Ow0KPiA+ID4gICAgICAgZGVmYXVsdCAwOw0KPiA+ ID4gICAgIH0NCj4gPiA+ICAgfQ0KPiA+ID4gfQ0KPiA+ID4NCj4gPiA+IG1vZHVsZSBleGFtcGxl LWF1Z21lbnQgew0KPiA+ID4gICBpbXBvcnQgZXhhbXBsZSB7DQo+ID4gPiAgICAgcHJlZml4IGV4 Ow0KPiA+ID4gICB9DQo+ID4gPg0KPiA+ID4gICBhdWdtZW50ICJleDpleGFtcGxlIiB7DQo+ID4g PiAgICAgbGVhZiBiYXIgew0KPiA+ID4gICAgICAgdHlwZSBlbXB0eTsNCj4gPiA+ICAgICAgIGRl c2NyaXB0aW9uDQo+ID4gPiAgICAgICAgICJXaGVuIHByZXNlbnQsIHRoZSBkZWZhdWx0IHZhbHVl IGZvciBmb28gaXMgMTAuIjsNCj4gPiA+ICAgICB9DQo+ID4gPiAgIH0NCj4gPiA+IH0NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gSW4gdGhpcyBjYXNlLCB3aGVuIHRoZSBsZWFmIGZvbyBpcyBub3QgY29u ZmlndXJlZCBidXQgdGhlIGxlYWYgYmFyIGlzIHByZXNlbnQsDQo+IHRoZSB2YWx1ZSBvZiBmb28g aW4gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBzaG91bGQgYmUgMTAgKHJhdGhlciB0aGFuIDAp Lg0KPiA+ID4NCj4gPiA+IEluIHRoaXMgY2FzZSwgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGJl dHRlci9jbGVhbmVyIGlmIHRoZSBvcmlnaW4gaXMgbWFya2VkDQo+IGFzIHN5c3RlbS4NCj4gPiA+ DQo+ID4gPiBNYXliZSBhIGJldHRlciBZQU5HIGRlc2NyaXB0aW9uIGZvciBiYXIgY291bGQgYmU6 ICJXaGVuIHByZXNlbnQsIHRoZQ0KPiBzeXN0ZW0gb3ZlcnJpZGVzIHRoZSBkZWZhdWx0IHZhbHVl IG9mIGZvbyB0byAxMC4iDQo+ID4gPg0KPiA+ID4gV2hhdCBpcyB5b3VyIGFuZC9vciBXRyBvcGlu aW9uPw0KPiA+ID4NCj4gPiA+IFRoYW5rcyBhZ2Fpbg0KPiA+ID4NCj4gPiA+IEl0YWxvDQo+ID4g Pg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBKdWVy Z2VuIFNjaG9lbndhZWxkZXINCj4gPiA+ID4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlDQo+ID4gPiA+IHJAamFjb2JzLXVu aXZlcnNpdHkuZGU8bWFpbHRvOnJAamFjb2JzLXVuaXZlcnNpdHkuZGU+Pl0NCj4gPiA+ID4gU2Vu dDogbWVyY29sZWTDrCAyMCBnZW5uYWlvIDIwMjEgMTc6MDUNCj4gPiA+ID4gVG86IEl0YWxvIEJ1 c2kNCj4gPiA+ID4gPEl0YWxvLkJ1c2lAaHVhd2VpLmNvbTxtYWlsdG86SXRhbG8uQnVzaUBodWF3 ZWkuY29tPG1haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb208bWFpbHRvOkl0YWxvLkJ1c2lAaHVh d2VpLmNvbT4+Pg0KPiA+ID4gPiBDYzogJ25ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll dGYub3JnPicNCj4gPiA+ID4gPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+Pg0KPiA+ID4g PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlc3Rpb25zIGFib3V0IGhvdyB0byBhc3NpZ24gZGVm YXVsdCB2YWx1ZXMNCj4gPiA+ID4gd2l0aCBZQU5HDQo+ID4gPiA+DQo+ID4gPiA+IE9uIFdlZCwg SmFuIDIwLCAyMDIxIGF0IDAyOjQxOjM5UE0gKzAwMDAsIEl0YWxvIEJ1c2kgd3JvdGU6DQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBXaGF0IGFib3V0IHRoZSBjYXNlIHRoZSBsZWFmIGlzIG5vdCBjb25k aXRpb25hbCAoYnV0IHN0aWxsDQo+ID4gPiA+ID4gbWFuZGF0b3J5IGZhbHNlDQo+ID4gPiA+IHNp bmNlIGEgWUFORyBkZWZhdWx0IHN0YXRlbWVudCBpcyBkZWZpbmVkKT8NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IE1heSB0aGUgc2VydmVyIHN0aWxsIGRlY2lkZSBub3QgdG8gdXNlL2ltcGxlbWVudCB0 aGlzIGxlYWYgaW4NCj4gPiA+ID4gPiB0aGUgb3BlcmF0aW9uYWwNCj4gPiA+ID4gZGF0YXN0b3Jl Pw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRm9yIGV4YW1wbGUsIGluIGFwcGVuZGl4IEMuMSBvZiBS RkM4MzQyLCBhdXRvLW5lZ290aWF0aW9uIGlzDQo+ID4gPiA+ID4gZW5hYmxlZCBieQ0KPiA+ID4g PiBkZWZhdWx0Lg0KPiA+ID4gPiA+IFdoYXQgc2hvdWxkIGJlIHRoZSBiZWhhdmlvciBvZiBhIHN5 c3RlbSB3aGljaCBkb2VzIG5vdCBpbXBsZW1lbnQNCj4gPiA+ID4gPiBhdXRvLQ0KPiA+ID4gPiBu ZWdvdGlhdGlvbj8NCj4gPiA+ID4gPiBSZXR1cm4gdGhlIHZhbHVlIGZhbHNlIG9yIG5vIHZhbHVl IChpbiB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlKT8NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPiBIZXJlIGFyZSBzb21lIG9mIHRoZSBydWxlcyBJIHBlcnNvbmFsbHkgbGlrZToNCj4gPiA+ ID4NCj4gPiA+ID4gIC0gPG9wZXJhdGlvbmFsPiBpcyB0aGUgZ3JvdW5kIHRydXRoIGFib3V0IHdo YXQgYSBzeXN0ZW0gaGFzIGFuZA0KPiA+ID4gPiBkb2VzDQo+ID4gPiA+ICAtIGRvIG5vdCBpbXBs ZW1lbnQgbGVhZnMgdGhhdCBkbyBub3QgYXBwbHkNCj4gPiA+ID4NCj4gPiA+ID4gSGVuY2UsIGlu dGVyZmFjZXMgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUgZWl0aGVyIGF1dG8tDQo+ ID4gPiA+IG5lZ290aWF0aW9uL2VuYWJsZWQgPSB0cnVlIG9yIGF1dG8tbmVnb3RpYXRpb24vZW5h YmxlZCA9IGZhbHNlIGluDQo+ID4gPiA+IDxvcGVyYXRpb25hbD4uIEFuZCBpbnRlcmZhY2VzIG5v dCBzdXBwb3J0aW5nIGF1dG8tbmVnb3RpYXRpb24gaGF2ZQ0KPiA+ID4gPiBub3RoaW5nIHRvIHJl cG9ydCBhYm91dCBhdXRvLW5lZ290aWF0aW9uLiBZZXMsIEkgZG8gbm90IHdhbnQgdG8NCj4gPiA+ ID4gc2VlIGF1dG8tIG5lZ290aWF0aW9uL2VuYWJsZWQgPSBmYWxzZSBvbiBhIGxvb3BiYWNrIGlu dGVyZmFjZS4NCj4gPiA+ID4NCj4gPiA+ID4gTXkgaGlzdG9yaWMgRXRoZXJuZXQgaW50ZXJmYWNl IGZyb20gdGhlIGxhc3QgY2VudHVyeSB3b3VsZCBhbHNvDQo+ID4gPiA+IG5vdCByZXBvcnQgYXV0 by1uZWdvdGlhdGlvbi9lbmFibGVkIGluIDxvcGVyYXRpb25hbD4uIFlvdSBtYXkgaGl0DQo+ID4g PiA+IGFwcGxpY2F0aW9ucyB0aGF0IGxvdmUgdG8gaGF2ZSBhdXRvLW5lZ290aWF0aW9uL2VuYWJs ZWQgYXZhaWxhYmxlDQo+ID4gPiA+IG9uIGFsbCBFdGhlcm5ldCBpbnRlcmZhY2VzIGFuZCB0aGVu IHlvdSBlbmQgaW4gYSBkZWJhdGUgd2hlcmUgdGhlDQo+ID4gPiA+IGFwcGxpY2F0aW9uIGRldmVs b3BlcnMgdGVsbCB5b3UgdGhhdCBubyBpbmZvcm1hdGlvbiBpbg0KPiA+ID4gPiA8b3BlcmF0aW9u YWw+IG1heSBoYXZlIG1hbnkgcmVhc29ucyAoaW5zdHJ1bWVudGF0aW9uIG5vdA0KPiA+ID4gPiBp bXBsZW1lbnRlZCwgYWNjZXNzIGNvbnRyb2wgcnVsZXMsIHdoYXRldmVyIGFuZCBieSByZXBvcnRp bmcNCj4gPiA+ID4gZW5hYmxlZD1mYWxzZSB5b3UgZG8gdGhlbSBhIGZhdm9yKSBidXQgdGhlIHRy dWUgYW5zd2VyIGluIHN1Y2ggYQ0KPiA+ID4gPiBkZWJhdGUgaXMgb2Z0ZW4gdGhhdCBtb2RlbGlu ZyB0aGluZ3MgYXMgYSBib29sZWFuIGlzIHNpbXBsaXN0aWMgc2luY2UNCj4gdGhlcmUgYXJlIG9m dGVuIG1vcmUgdGhhbiBleGFjdGx5IHR3byBzdGF0ZXMgKGluIHRoaXMgY2FzZSwgZW5hYmxlZCwg ZGlzYWJsZWQsDQo+IGZhaWxlZCwgbm90LWF2YWlsYWJsZSwgLi4uKS4NCj4gPiA+ID4gU28geW91 IHNldHRsZSBvbiBibGFtaW5nIHRoZSBtb2RlbCB3cml0ZXIuIDstKQ0KPiA+ID4gPg0KPiA+ID4g PiAvanMNCj4gPiA+ID4NCj4gPiA+ID4gLS0NCj4gPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVy ICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiA+ID4gUGhvbmU6 ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwN Cj4gR2VybWFueQ0KPiA+ID4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+ID4gPg0KPiA+DQo+ID4gLS0NCj4gPiBK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8 IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAg ICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWls aW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+IC0tDQo+IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo= --_000_53a7042e5b1a47b7a3122c56a7900ac7huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SnVlcmdlbiw8L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PkkgdGhpbmsgeW91 IGhhdmUgZ290IHRoZSBwcm9ibGVtOiAmcXVvdDthIGRhdGEgbW9kZWwgYXV0aG9yIHRob3VnaHQg dGhlIGRlZmF1bHQgaXMgYWx3YXlzIDAgYW5kIGxhdGVyIGhlL3NoZSByZWFsaXplcyB0aGF0IGlu IHNvbWUgY29udGV4dHMgdGhlIGRlZmF1bHQgc2hvdWxkIGJlIHNvbWV0aGluZyBkaWZmZXJlbnQm cXVvdDs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2Zv bnQ+PC9kaXY+DQo8ZGl2PlVubGVzcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nLCBjcmVhdGluZyBh IG5ldyBsZWFmIChlLmcuLCBmb28tbmV3KSB3b3VsZCBjb25mdXNlIGFuIGV4aXN0aW5nIGNsaWVu dC48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2PkZvciBleGFtcGxlLCB3aXRoaW4gdGhlIG9wZXJhdGlvbmFsIERTLCB0aGUg dmFsdWUgb2YgZm9vIHdpbGwgYmUgc2V0IHRvIDAgKGFzIHBlciBZQU5HIGRlZmF1bHQgc3RhdGVt ZW50KSB3aGlsZSB0aGUgdmFsdWUgb2YgZm9vLW5ldyB3aWxsIGJlIHNldCB0byAxMCwgd2hpY2gg cmVwcmVzZW50cyB0aGUgYWN0dWFsIHZhbHVlIGluIHVzZSBieSB0aGUgc3lzdGVtLjwvZGl2Pg0K PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48L2E+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5O b3csIHRoZSBleGlzdGluZyBjbGllbnQsIHdoaWNoIGlzIG5vdCBhd2FyZSBvZiBmb28tbmV3LCB3 aGVuIHJlYWRpbmcgdGhlIHZhbHVlIG9mIGZvbyBpbiB0aGUgb3BlcmF0aW9uYWwgRFMgd2lsbCBp bmNvcnJlY3RseSB0aGluayB0aGF0IHRoZSBhY3R1YWwgdmFsdWUgaW4gdXNlIGJ5IHRoZSBzeXN0 ZW0gaXMgMCByYXRoZXIgdGhhbiAxMC48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PkFtIEkgbWlzc2luZyBhbnl0aGluZz88 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pkluc3RlYWQsIGlmIHdlIGNhbiBmaW5kIGEgbWFnaWMgd2F5IHRvIGFwcGx5IHRo ZSB2YWx1ZSAxMCB0byBmb28gd2l0aGluIHRoZSBvcGVyYXRpb25hbCBEUywgdGhlIGV4aXN0aW5n IGNsaWVudCBjYW4gcmVhZCB0aGUgdmFsdWUgb2YgZm9vIGluIHRoZSBvcGVyYXRpb25hbCBEUyBh bmQgY29ycmVjdGx5IHVuZGVyc3RhbmQgdGhhdCB0aGUgYWN0dWFsIHZhbHVlIGluIHVzZSBieSB0 aGUgc3lzdGVtIGlzIDEwIChldmVuIGlmIHRoaXMgaXMgbm90DQp0aGUgZGVmYXVsdCB2YWx1ZSBv ZiBmb28pLjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD48L2Rpdj4NCjxkaXY+SXRhbG88L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08L2Rpdj4NCjxkaXY+Jmd0OyBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgWzxh IGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPm1haWx0 bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+XTwvZGl2Pg0KPGRpdj4m Z3Q7IFNlbnQ6IG1lcmNvbGVkw6wgMTAgbWFyem8gMjAyMSAxNzoxNTwvZGl2Pg0KPGRpdj4mZ3Q7 IFRvOiBJdGFsbyBCdXNpICZsdDtJdGFsby5CdXNpQGh1YXdlaS5jb20mZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsgQ2M6IG5ldG1vZEBpZXRmLm9yZzwvZGl2Pg0KPGRpdj4mZ3Q7IFN1YmplY3Q6IFJlOiBb bmV0bW9kXSBRdWVzdGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlcyB3aXRo PC9kaXY+DQo8ZGl2PiZndDsgWUFORzwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7 IEkgZG8gbm90IHVuZGVyc3RhbmQgd2hlcmUgdGhlIHByb2JsZW0gaXMuPC9kaXY+DQo8ZGl2PiZn dDsgPC9kaXY+DQo8ZGl2PiZndDsgYSkgSWYgYSBsZWFmIHNheXMgbXkgZGVmYXVsdCBpcyAwLCB0 aGVuIHRoZSBkZWZhdWx0IGlzIDAgYW5kIHlvdSBjYW4ndDwvZGl2Pg0KPGRpdj4mZ3Q7ICZuYnNw OyZuYnNwOyBjaGFuZ2UgdGhhdCBieSBjcmVhdGluZyBvdGhlciBsZWFmcyBzb21ld2hlcmUgZWxz ZSB0aGF0IHNheXM8L2Rpdj4NCjxkaXY+Jmd0OyAmbmJzcDsmbmJzcDsgc29tZXRoaW5nIGRpZmZl cmVudC48L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyBiKSBJZiBhIGxlYWYgc2F5 cyB0aGF0IGlzIGhhcyBhIGRlZmF1bHQgdmFsdWUgYnV0IHRoZSB2YWx1ZSBpczwvZGl2Pg0KPGRp dj4mZ3Q7ICZuYnNwOyZuYnNwOyBkZXRlcm1pbmVkIGluIHNvbWUgbWFnaWMgd2F5IG5vdCBkZWZp bmVkIGhlcmUsIHRoZW4geW91IGNhbiBhZGQ8L2Rpdj4NCjxkaXY+Jmd0OyAmbmJzcDsmbmJzcDsg YWRkaXRpb25hbCBsZWFmcyB0aGF0IGRldGFpbCB0aGUgbWFnaWMgZm9yIGNlcnRhaW4gY29udGV4 dHM8L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyBUaGUgcG9pbnQgaXMgdGhhdCBh KSB0ZWxscyBjbGllbnRzIHRoZXkgY2FuIHNhZmVseSBhc3N1bWUgdGhlIGRlZmF1bHQgdmFsdWUg aXMgMDwvZGl2Pg0KPGRpdj4mZ3Q7IHdoaWxlIGIpIHRlbGxzIGNsaWVudHMgdGhhdCB0aGV5IGNh biBhc3N1bWUgdGhhdCB0aGVyZSBpcyBhIGRlZmF1bHQgYnV0IHRoZSBleGFjdDwvZGl2Pg0KPGRp dj4mZ3Q7IGRlZmF1bHQgdmFsdWUgdGhleSB3aWxsIG5vdCBrbm93IHVubGVzcyB0aGV5IHVuZGVy c3RhbmQgbWFnaWMuPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgSWYgYSBkYXRh IG1vZGVsIGF1dGhvciB0aG91Z2h0IHRoZSBkZWZhdWx0IGlzIGFsd2F5cyAwIGFuZCBsYXRlciBo ZS9zaGU8L2Rpdj4NCjxkaXY+Jmd0OyByZWFsaXplcyB0aGF0IGluIHNvbWUgY29udGV4dHMgdGhl IGRlZmF1bHQgc2hvdWxkIGJlIHNvbWV0aGluZyBkaWZmZXJlbnQsIHRoZW48L2Rpdj4NCjxkaXY+ Jmd0OyB5b3UgaGF2ZSB0byByZXNvbHZlIHRoYXQgYnkgY3JlYXRpbmcgbmV3IGxlYWZzIChpbiB0 aGUgY3VycmVudCB2ZXJzaW9uIG9mIFlBTkcpPC9kaXY+DQo8ZGl2PiZndDsgb3IgeW91IGRlY2xh cmVzIGEgbm9uLWJhY2t3YXJkcyBjb21wYXRpYmxlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkZWZpbml0 aW9uIG9mPC9kaXY+DQo8ZGl2PiZndDsgdGhlIGxlYWYgKGlmIHRoZSB2ZXJzaW9uaW5nIHdvcmsg Z2V0cyBzdGFuZGFyZGl6ZWQpLjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IC9q czwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IE9uIFdlZCwgTWFyIDEwLCAyMDIx IGF0IDAzOjI1OjEzUE0gJiM0MzswMDAwLCBJdGFsbyBCdXNpIHdyb3RlOjwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDsgSGkgQW5keSw8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyBJIHNlZSB5b3VyIHBvaW50LDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7IEF0IHRoZSBiZWdpbm5pbmcgb2YgdGhpcyB0aHJlYWQsIEkgaGF2ZSBoYWQgYSBk b3VidCBhYm91dCBob3cgdG8gcmVjb25jaWxlPC9kaXY+DQo8ZGl2PiZndDsgc2VjLiA3LjYuMSBv ZiBSRkM3OTUwIHdpdGggc2VjLiA1LjMgb2YgUkZDODM0Mjo8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBSZXF1ZXN0cyB0byByZXRy aWV2ZSBub2RlcyBmcm9tICZsdDtvcGVyYXRpb25hbCZndDsgYWx3YXlzIHJldHVybiB0aGUgdmFs dWU8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHVzZSBpZiB0aGUg bm9kZSBleGlzdHMsIHJlZ2FyZGxlc3Mgb2YgYW55IGRlZmF1bHQgdmFsdWUgc3BlY2lmaWVkPC9k aXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0aGUgWUFORyBtb2R1bGUu Jm5ic3A7IElmIG5vIHZhbHVlIGlzIHJldHVybmVkIGZvciBhIGdpdmVuIG5vZGUsIHRoZW48L2Rp dj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgaW1wbGllcyB0aGF0IHRo ZSBub2RlIGlzIG5vdCB1c2VkIGJ5IHRoZSBkZXZpY2UuPC9kaXY+DQo8ZGl2PiZndDsgJmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgTXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBjbGllbnQgd2ls bCBhbHdheXMgZ2V0IHRoZSBhcHBsaWVkIHZhbHVlPC9kaXY+DQo8ZGl2PiZndDsgaW5kZXBlbmRl bnRseSBvbiB3aGV0aGVyIGl0IGlzIDAgb3IgMTAgb3IgYW5vdGhlciB2YWx1ZS48L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBBbnl3YXksIGl0IHNlZW1zIHRvIG1l IHRoYXQgdGhlIGlzc3VlIGlzIG1haW5seSBhYm91dCB0aGUga2V5d29yZCDigJxkZWZhdWx04oCd PC9kaXY+DQo8ZGl2PiZndDsgc28gbGV0IG1lIHRha2UgYSBzdGVwIGJhY2sgYW5kIHRyeSB0byBk ZWZpbmUgdGhlIGlzc3VlIEkgYW0gdHJ5aW5nIHRvIHNvbHZlLDwvZGl2Pg0KPGRpdj4mZ3Q7IHdp dGhvdXQgYXNzdW1pbmcgYW55IHNvbHV0aW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4N CjxkaXY+Jmd0OyAmZ3Q7IFdoYXQgSSBuZWVkIGlzIHRvIGZpbmQgYSBzb2x1dGlvbiB0aGF0IGFs bG93cyBhIGNsaWVudCB0byByZXF1ZXN0IHRoZSBzZXJ2ZXIgdG88L2Rpdj4NCjxkaXY+Jmd0OyBh cHBseSB0aGUgdmFsdWUgMTAgZm9yIHRoZSBsZWFmIGZvbyBpbiB0aGUgb3BlcmF0aW9uYWwgRFMg d2l0aG91dCDigJxleHBsaWNpdGx54oCdPC9kaXY+DQo8ZGl2PiZndDsgd3JpdGluZyB0aGUgdmFs dWUgMTAgaW4gdGhlIHJ1bm5pbmcgRFMgYnV0IOKAnGltcGxpY2l0bHnigJ0gYnkgd3JpdGluZyBh bm90aGVyIGxlYWY8L2Rpdj4NCjxkaXY+Jmd0OyBiYXIgaW4gdGhlIHJ1bm5pbmcgRFMsIGV2ZW4g aWYgdGhlIGxlYWYgZm9vIGhhcyBhIFlBTkcgZGVmYXVsdCBzdGF0ZW1lbnQ8L2Rpdj4NCjxkaXY+ Jmd0OyBkZWZpbmluZyAwIGFzIGl0cyBkZWZhdWx0IHZhbHVlLjwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCB0aGUgTk1EQSBhcmNoaXRlY3R1 cmUgaXMgcXVpdGUgZmxleGlibGUgYW5kIGNvdWxkIGJlIGxldmVyYWdlZDwvZGl2Pg0KPGRpdj4m Z3Q7IHRvIHJlc29sdmUgdGhpcyBpc3N1ZS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyBTdGVwcGluZyBhd2F5IGZyb20gZGVmaW5pbmcgZGVmYXVsdCB2YWx1ZXMs IG9uZSBwb3NzaWJpbGl0eSBjb3VsZCBiZSB0aGF0PC9kaXY+DQo8ZGl2PiZndDsgdGhlIGFwcGxp ZWQgY29uZmlndXJhdGlvbiBvZiB0aGUgdmFsdWUgb2YgZm9vIGlzIGRlZmluZWQgYnkgdGhlIHN5 c3RlbSBiZWZvcmU8L2Rpdj4NCjxkaXY+Jmd0OyBhcHBseWluZyB0aGUgaW50ZW5kZWQgY29uZmln dXJhdGlvbiBpbiB0aGUgb3BlcmF0aW9uYWwgRFMsIGFzIGEgc2lkZSBlZmZlY3Qgb2Y8L2Rpdj4N CjxkaXY+Jmd0OyBhcHBseWluZyB0aGUgY29uZmlndXJhdGlvbiBvZiB0aGUgbGVhZiBiYXIuPC9k aXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQW5vdGhlciBhbHRlcm5h dGl2ZSB3aGljaCBpcyBqdXN0IGp1bXBpbmcgdG8gbXkgbWluZCwgY291bGQgYmUgdGhhdCB0aGU8 L2Rpdj4NCjxkaXY+Jmd0OyB2YWx1ZSBvZiAxMCBmb3IgdGhlIGxlYWYgZm9vIGlzIHNldCBieSB0 aGUgc3lzdGVtIGluIHRoZSBpbnRlbmRlZCBEUywgYXBwbHlpbmcgYTwvZGl2Pg0KPGRpdj4mZ3Q7 IHNvcnQgb2YgdGVtcGxhdGUuIFNob3VsZCBpbiB0aGlzIGNhc2UgdGhlIGRlZmluaXRpb24gb2Yg dGhlIGxlYWYgYmFyIGJlPC9kaXY+DQo8ZGl2PiZndDsgaW50ZXJwcmV0ZWQgYXMgYSB0ZW1wbGF0 ZSBjb25maWd1cmF0aW9uIG9yIGhvdyBzaG91bGQgdGhlIHJlcXVpcmVkIHRlbXBsYXRlPC9kaXY+ DQo8ZGl2PiZndDsgY29uZmlndXJhdGlvbiBiZSBwcm92aWRlZD88L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBDb3VsZCBhbnkgb2YgdGhpcyBvcHRpb24gYmUgdXNl ZCB0byByZXNvbHZlIHRoaXMgaXNzdWU/PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7ICZndDsgSXRhbG88L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyBGcm9tOiBBbmR5IEJpZXJtYW4gWzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20iPm1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb208L2E+XTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg U2VudDogbWVyY29sZWTDrCAxMCBtYXJ6byAyMDIxIDE1OjE2PC9kaXY+DQo8ZGl2PiZndDsgJmd0 OyBUbzogSXRhbG8gQnVzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNv bSI+SXRhbG8uQnVzaUBodWF3ZWkuY29tPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IENj OiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZTwvYT4mZ3Q7OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgU3Vi amVjdDogUmU6IFtuZXRtb2RdIFF1ZXN0aW9ucyBhYm91dCBob3cgdG8gYXNzaWduIGRlZmF1bHQg dmFsdWVzPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyB3aXRoIFlBTkc8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7IE9uIFdlZCwgTWFyIDEwLCAyMDIxIGF0IDEyOjU0IEFNIEl0YWxvIEJ1c2k8 L2Rpdj4NCjxkaXY+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNv bSZsdDttYWlsdG86SXRhbG8uQnVzaUBodWF3ZWkuY29tIj5JdGFsby5CdXNpQGh1YXdlaS5jb20m bHQ7bWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8L2Rpdj4N CjxkaXY+Jmd0OyAmZ3Q7IEFuZHksIEp1ZXJnZW4sPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGlzc3VlIHdp dGggYSBjbGllbnQgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5kPC9kaXY+DQo8ZGl2PiZndDsgdGhl IGF1Z21lbnQuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgV2hl biB0aGlzIGNsaWVudCB3cml0ZXMgaW4gdGhlIHJ1bm5pbmcgRFMsIGl0IHdpbGwgbm90IHNldCB0 aGUgYmFyIGF0dHJpYnV0ZTwvZGl2Pg0KPGRpdj4mZ3Q7ICh3aGljaCBpcyBhbHNvIGRlZmluZWQg aW4gdGhlIGF1Z21lbnQgbW9kdWxlKSBhbmQgdGhlcmVmb3JlIHRoZSBkZWZhdWx0PC9kaXY+DQo8 ZGl2PiZndDsgdmFsdWUgMCB3aWxsIGJlIGFwcGxpZWQgYnkgdGhlIHN5c3RlbSwgYXMgZXhwZWN0 ZWQgYnkgdGhlIGNsaWVudC48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyBXaGVuIHRoaXMgY2xpZW50IHJlYWRzIGZyb20gdGhlIG9wZXJhdGlvbmFsIERTIHRoZSBh cHBsaWVkIGNvbmZpZ3VyYXRpb24sPC9kaXY+DQo8ZGl2PiZndDsgcHJvdmlkZWQgYnkgYW5vdGhl ciBjbGllbnQgd2hpY2ggdW5kZXJzdGFuZHMgdGhlIGF1Z21lbnQsIGl0IHdpbGwgc2VlIHRoYXQ8 L2Rpdj4NCjxkaXY+Jmd0OyB0aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIGZvciB0aGUgbGVhZiBm b28gaXMgMTAuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgVGhp cyBpcyBhIHZhbGlkIGFwcGxpZWQgY29uZmlndXJhdGlvbiBpZiB0aGUgb3RoZXIgY2xpZW50IGhh ZCBleHBsaWNpdGx5PC9kaXY+DQo8ZGl2PiZndDsgY29uZmlndXJlZCB0aGUgdmFsdWUgMTAgaW4g dGhlIHJ1bm5pbmcgRFMuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsgVGhlIG9ubHkgZGlmZmVyZW5jZSB3b3VsZCBiZSB0aGF0IHdoZW4gdGhlIHZhbHVlIDEwIGlz IGV4cGxpY2l0bHkgY29uZmlndXJlZDwvZGl2Pg0KPGRpdj4mZ3Q7IGJ5IHRoZSBvdGhlciBjbGll bnQgdGhlIG9yaWdpbiBpcyBzZXQgdG8gaW50ZW5kZWQgd2hpbGUgd2hlbiDigJxpbXBsaWNpdGx5 4oCdPC9kaXY+DQo8ZGl2PiZndDsgY29uZmlndXJlZCB1c2luZyB0aGUgYXR0cmlidXRlIGJhciwg dGhlIG9yaWdpbiBjYW4gYmUgc2V0IHRvIHN5c3RlbSAoSSB0aGluayBpdDwvZGl2Pg0KPGRpdj4m Z3Q7IHdvdWxkIG5vdCBiZSBjb3JyZWN0IHRvIHNldCB0aGUgb3JpZ2luIHRvIGRlZmF1bHQgaW4g dGhpcyBjYXNlKS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBC VFcsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgbW9zdCBlbGVnYW50L2NsZWFuIGRlc2ln biBhbmQgdGhhdCB0aGUgYmVzdDwvZGl2Pg0KPGRpdj4mZ3Q7IGFwcHJvYWNoIHdvdWxkIGJlIG5v dCB0byBkZWZpbmUgYW55IGRlZmF1bHQgdmFsdWUgaW4gdGhlIGJhc2UgbW9kZWwuIEkgYW08L2Rp dj4NCjxkaXY+Jmd0OyBqdXN0IHdpbGxpbmcgdG8gdW5kZXJzdGFuZCBpZiBhIHdvcmstYXJvdW5k IGlzIHBvc3NpYmxlLCB3aXRob3V0IGJyZWFraW5nIGFueTwvZGl2Pg0KPGRpdj4mZ3Q7IGNsaWVu dCwgdG8gYWxsb3cgcmUtdXNpbmcgYW4gZXhpc3RpbmcgbW9kdWxlIHdoaWNoIGhhcyBhbHJlYWR5 IGRlZmluZWQgYTwvZGl2Pg0KPGRpdj4mZ3Q7IGRlZmF1bHQgdmFsdWUuPC9kaXY+DQo8ZGl2PiZn dDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFJlYWQg c2VjLiA3LjYuMSBhZ2FpbiwgZXNwZWNpYWxseSB0aGlzIHBhcnQ6PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiB0aGUgZGVm YXVsdCB2YWx1ZSBpcyBpbiB1c2UsIHRoZSBzZXJ2ZXIgTVVTVCBvcGVyYXRpb25hbGx5PC9kaXY+ DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsg YmVoYXZlIGFzIGlmIHRoZSBsZWFmIHdhcyBwcmVzZW50IGluIHRoZSBkYXRhIHRyZWUgd2l0aCB0 aGUgZGVmYXVsdDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHZhbHVlIGFzIGl0cyB2YWx1ZS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgWW91 ciBwcm9wb3NhbCB2aW9sYXRlcyB0aGlzIE1VU1QgYmVjYXVzZSB0aGUgZGVmYXVsdCBpcyBpbiB1 c2U8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IGFjY29yZGluZyB0byB0aGUgcnVsZXM8L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDsgSXRhbG88L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQW5keTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4N CjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBGcm9tOiBBbmR5IEJpZXJtYW48 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29t Jmx0O21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7Ij5tYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tJmx0O21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PC9hPl08L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7IFNlbnQ6IG1hcnRlZMOsIDkgbWFyem8gMjAyMSAyMToxMjwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmx0 O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZsdDttYWlsdG86ai5zY2hvZW53 YWVsZGVyQGphY29icy11bjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgaXZlcnNpdHkuZGUmZ3Q7Jmd0 OzsgSXRhbG8gQnVzaTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpJ dGFsby5CdXNpQGh1YXdlaS5jb20mbHQ7bWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNvbSI+SXRh bG8uQnVzaUBodWF3ZWkuY29tJmx0O21haWx0bzpJdGFsby5CdXNpQGh1YXdlaS5jb208L2E+Jmd0 OyZndDs7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYu b3JnJmx0O21haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZyZsdDttYWlsdG86 bmV0bW9kQGlldGYub3JnPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJl OiBbbmV0bW9kXSBRdWVzdGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlczwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgd2l0aCBZQU5HPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyBPbiBUdWUsIE1hciA5LCAyMDIxIGF0IDExOjUyIEFNIEp1ZXJnZW4gU2Nob2Vud2FlbGRl cjwvZGl2Pg0KPGRpdj4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlJmx0O21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGUiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZsdDttYWlsdG86 ai5zY2hvZW53YWVsZGVyQGphY29icy08L2E+PC9kaXY+DQo8ZGl2PiZndDsgdW5pdmVyc2l0eS5k ZSZndDsmZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQ2hhbmdpbmcgdGhlIHNlbWFu dGljcyBvZiBhIGRlZmluaXRpb24gdmlhIGF1Z21lbnRzIGlzIGJhZCBkZXNpZ24uPC9kaXY+DQo8 ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQSBzeXN0ZW0gdGhhdCBkb2VzIG5v dCB1bmRlcnN0YW5kIHRoZSBhdWdtZW50IHdpbGwgYmVsaWV2ZSB0aGUgZGVmYXVsdDwvZGl2Pg0K PGRpdj4mZ3Q7ICZndDsgaXMgMC4gU2luY2UgdGhlcmUgaXMgbm8gd2F5IHRvIGZvcmNlIGFuIGV4 aXN0aW5nIGltcGxlbWVudGF0aW9uIHRvPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyB1bmRlcnN0YW5k IGEgY2VydGFpbiBhdWdtZW50YXRpb24sIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbiB3aWxsPC9k aXY+DQo8ZGl2PiZndDsgJmd0OyByaWdodGZ1bGx5IGRpc2FncmVlIG9uIHRoZSBkZWZhdWx0IHZh bHVlIGluIGVmZmVjdC48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgZGV2aWF0aW9uIC9leDpleGFtcGxlL2V4OmZvbyB7PC9k aXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWxldGUgezwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZGVmYXVsdCAwOzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgfTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IElNTyBpdCB3YXMgYSBiYWQgaWRlYSB0byBzYXkgZGV2aWF0 aW9ucyBNVVNUIE5PVCBhcHBlYXIgaW4gc3RhbmRhcmQ8L2Rpdj4NCjxkaXY+Jmd0OyBtb2R1bGVz LjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgSGVyZSBpcyBhIHVzZS1jYXNlIGZvciBpdC48L2Rpdj4N CjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBUaGUgb2xkLWNsaWVudCBkb2Vz IG5vdCBrbm93IGFib3V0IHRoZSBuZXcgZHluYW1pYyBkZWZhdWx0IGJ1dCBpdDwvZGl2Pg0KPGRp dj4mZ3Q7ICZndDsgY291bGQga25vdyB0aGF0IHRoZSBvbGQgWUFORyBkZWZhdWx0IGlzIG5vdCBi ZWluZyB1c2VkLjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9k aXY+DQo8ZGl2PiZndDsgJmd0OyAvanM8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsgJmd0OyBBbmR5PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IE9uIE1vbiwgTWFyIDA4LCAyMDIxIGF0IDA4OjE5OjM5 UE0gJiM0MzswMDAwLCBJdGFsbyBCdXNpIHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0 OyBIaSBKdWVyZ2VuLDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgJmd0OyBUaGFua3MgYWdhaW4gZm9yIHlvdXIgY2xlYXIgZXhwbGFuYXRpb24gb24gdGhp cyB0b3BpYzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg Jmd0OyBJIGhhdmUgZm91bmQgYSBzaW1pbGFyIGJ1dCBzbGlnaHRseSBkaWZmZXJlbnQgaXNzdWUu IEluIHRoaXMgY2FzZSwgYSBZQU5HPC9kaXY+DQo8ZGl2PiZndDsgZGVmYXVsdCBzdGF0ZW1lbnQg ZXhpc3RzIGluIHRoZSBiYXNlIG1vZHVsZSBidXQgdGhlIGludGVudGlvbiB3aXRoIHRoZTwvZGl2 Pg0KPGRpdj4mZ3Q7IGF1Z21lbnRhdGlvbiBpcyB0byAmcXVvdDtvdmVyd3JpdGUmcXVvdDsgdGhl IGRlZmF1bHQgdmFsdWUgb24gdGhlIGJhc2lzIG9mIGFub3RoZXI8L2Rpdj4NCjxkaXY+Jmd0OyBh dHRyaWJ1dGUsIGRlZmluZWQgaW4gdGhlIG1vZHVsZSB3aGljaCBhdWdtZW50cyB0aGUgYmFzZSBt b2R1bGUuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAm Z3Q7IEZvciBleGFtcGxlLCBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHN1Y2ggYSBjb2RlIGlzIHZh bGlkOjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0 OyBtb2R1bGUgZXhhbXBsZS1iYXNlIHs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsm bmJzcDsgY29udGFpbmVyIGV4YW1wbGUgezwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIGZvbyB7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDg7PC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl ZmF1bHQgMDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyB9PC9kaXY+DQo8ZGl2 PiZndDsgJmd0OyAmZ3Q7IH08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7ICZndDsgbW9kdWxlIGV4YW1wbGUtYXVnbWVudCB7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IGltcG9ydCBleGFtcGxlIHs8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJlZml4IGV4OzwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyB9PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9k aXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7IGF1Z21lbnQgJnF1b3Q7ZXg6ZXhh bXBsZSZxdW90OyB7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGxlYWYgYmFyIHs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBlbXB0eTs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248L2Rp dj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7V2hlbiBwcmVzZW50LCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3Ig Zm9vIGlzIDEwLiZxdW90Ozs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyB9PC9k aXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7IH08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDs8L2Rp dj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgSW4gdGhp cyBjYXNlLCB3aGVuIHRoZSBsZWFmIGZvbyBpcyBub3QgY29uZmlndXJlZCBidXQgdGhlIGxlYWYg YmFyIGlzIHByZXNlbnQsPC9kaXY+DQo8ZGl2PiZndDsgdGhlIHZhbHVlIG9mIGZvbyBpbiB0aGUg b3BlcmF0aW9uYWwgZGF0YXN0b3JlIHNob3VsZCBiZSAxMCAocmF0aGVyIHRoYW4gMCkuPC9kaXY+ DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7IEluIHRoaXMg Y2FzZSwgSSB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGJldHRlci9jbGVhbmVyIGlmIHRoZSBvcmln aW4gaXMgbWFya2VkPC9kaXY+DQo8ZGl2PiZndDsgYXMgc3lzdGVtLjwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyBNYXliZSBhIGJldHRlciBZQU5H IGRlc2NyaXB0aW9uIGZvciBiYXIgY291bGQgYmU6ICZxdW90O1doZW4gcHJlc2VudCwgdGhlPC9k aXY+DQo8ZGl2PiZndDsgc3lzdGVtIG92ZXJyaWRlcyB0aGUgZGVmYXVsdCB2YWx1ZSBvZiBmb28g dG8gMTAuJnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyAmZ3Q7IFdoYXQgaXMgeW91ciBhbmQvb3IgV0cgb3Bpbmlvbj88L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgVGhhbmtzIGFnYWluPC9kaXY+ DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7IEl0YWxvPC9k aXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBbPGEgaHJlZj0iIj48L2E+bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy c2l0eS5kZSZsdDttYWlsdG86ai5zY2hvZW53YWVsZGU8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YSBocmVmPSJtYWlsdG86ckBqYWNvYnMtdW5pdmVyc2l0eS5kZSI+ckBqYWNvYnMt dW5pdmVyc2l0eS5kZTwvYT4mZ3Q7XTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNl bnQ6IG1lcmNvbGVkw6wgMjAgZ2VubmFpbyAyMDIxIDE3OjA1PC9kaXY+DQo8ZGl2PiZndDsgJmd0 OyAmZ3Q7ICZndDsgVG86IEl0YWxvIEJ1c2k8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkl0YWxvLkJ1c2lAaHVhd2VpLmNvbSZsdDttYWlsdG86SXRh bG8uQnVzaUBodWF3ZWkuY29tIj5JdGFsby5CdXNpQGh1YXdlaS5jb20mbHQ7bWFpbHRvOkl0YWxv LkJ1c2lAaHVhd2VpLmNvbTwvYT4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IENjOiAnbmV0bW9kQGlldGYub3JnJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v cmciPm1haWx0bzpuZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0Oyc8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyZsdDttYWlsdG86 bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmcmbHQ7bWFpbHRvOm5ldG1vZEBpZXRmLm9y ZzwvYT4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJl OiBbbmV0bW9kXSBRdWVzdGlvbnMgYWJvdXQgaG93IHRvIGFzc2lnbiBkZWZhdWx0IHZhbHVlczwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdpdGggWUFORzwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgT24gV2VkLCBK YW4gMjAsIDIwMjEgYXQgMDI6NDE6MzlQTSAmIzQzOzAwMDAsIEl0YWxvIEJ1c2kgd3JvdGU6PC9k aXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgV2hhdCBhYm91dCB0aGUgY2FzZSB0aGUgbGVhZiBpcyBub3QgY29uZGl0 aW9uYWwgKGJ1dCBzdGlsbDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgbWFu ZGF0b3J5IGZhbHNlPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgc2luY2UgYSBZQU5H IGRlZmF1bHQgc3RhdGVtZW50IGlzIGRlZmluZWQpPzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE1heSB0aGUg c2VydmVyIHN0aWxsIGRlY2lkZSBub3QgdG8gdXNlL2ltcGxlbWVudCB0aGlzIGxlYWYgaW48L2Rp dj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBvcGVyYXRpb25hbDwvZGl2Pg0K PGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRhdGFzdG9yZT88L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBGb3Ig ZXhhbXBsZSwgaW4gYXBwZW5kaXggQy4xIG9mIFJGQzgzNDIsIGF1dG8tbmVnb3RpYXRpb24gaXM8 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGVuYWJsZWQgYnk8L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBkZWZhdWx0LjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgV2hhdCBzaG91bGQgYmUgdGhlIGJlaGF2aW9yIG9mIGEgc3lzdGVtIHdoaWNo IGRvZXMgbm90IGltcGxlbWVudDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg YXV0by08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBuZWdvdGlhdGlvbj88L2Rpdj4N CjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJldHVybiB0aGUgdmFsdWUgZmFsc2Ugb3Ig bm8gdmFsdWUgKGluIHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUpPzwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhlcmUgYXJlIHNvbWUgb2YgdGhlIHJ1bGVzIEkg cGVyc29uYWxseSBsaWtlOjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgLSAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IGlzIHRo ZSBncm91bmQgdHJ1dGggYWJvdXQgd2hhdCBhIHN5c3RlbSBoYXMgYW5kPC9kaXY+DQo8ZGl2PiZn dDsgJmd0OyAmZ3Q7ICZndDsgZG9lczwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5i c3A7IC0gZG8gbm90IGltcGxlbWVudCBsZWFmcyB0aGF0IGRvIG5vdCBhcHBseTwvZGl2Pg0KPGRp dj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgSGVu Y2UsIGludGVyZmFjZXMgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmUgZWl0aGVyIGF1 dG8tPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgbmVnb3RpYXRpb24vZW5hYmxlZCA9 IHRydWUgb3IgYXV0by1uZWdvdGlhdGlvbi9lbmFibGVkID0gZmFsc2UgaW48L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiBBbmQgaW50ZXJmYWNlcyBu b3Qgc3VwcG9ydGluZyBhdXRvLW5lZ290aWF0aW9uIGhhdmU8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyBub3RoaW5nIHRvIHJlcG9ydCBhYm91dCBhdXRvLW5lZ290aWF0aW9uLiBZZXMs IEkgZG8gbm90IHdhbnQgdG88L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBzZWUgYXV0 by0gbmVnb3RpYXRpb24vZW5hYmxlZCA9IGZhbHNlIG9uIGEgbG9vcGJhY2sgaW50ZXJmYWNlLjwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7 ICZndDsgTXkgaGlzdG9yaWMgRXRoZXJuZXQgaW50ZXJmYWNlIGZyb20gdGhlIGxhc3QgY2VudHVy eSB3b3VsZCBhbHNvPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgbm90IHJlcG9ydCBh dXRvLW5lZ290aWF0aW9uL2VuYWJsZWQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy4gWW91IG1heSBo aXQ8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBhcHBsaWNhdGlvbnMgdGhhdCBsb3Zl IHRvIGhhdmUgYXV0by1uZWdvdGlhdGlvbi9lbmFibGVkIGF2YWlsYWJsZTwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7IG9uIGFsbCBFdGhlcm5ldCBpbnRlcmZhY2VzIGFuZCB0aGVuIHlv dSBlbmQgaW4gYSBkZWJhdGUgd2hlcmUgdGhlPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZn dDsgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0ZWxsIHlvdSB0aGF0IG5vIGluZm9ybWF0aW9uIGlu PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O29wZXJhdGlvbmFsJmd0OyBtYXkg aGF2ZSBtYW55IHJlYXNvbnMgKGluc3RydW1lbnRhdGlvbiBub3Q8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7ICZndDsgJmd0OyBpbXBsZW1lbnRlZCwgYWNjZXNzIGNvbnRyb2wgcnVsZXMsIHdoYXRldmVy IGFuZCBieSByZXBvcnRpbmc8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBlbmFibGVk PWZhbHNlIHlvdSBkbyB0aGVtIGEgZmF2b3IpIGJ1dCB0aGUgdHJ1ZSBhbnN3ZXIgaW4gc3VjaCBh PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsgZGViYXRlIGlzIG9mdGVuIHRoYXQgbW9k ZWxpbmcgdGhpbmdzIGFzIGEgYm9vbGVhbiBpcyBzaW1wbGlzdGljIHNpbmNlPC9kaXY+DQo8ZGl2 PiZndDsgdGhlcmUgYXJlIG9mdGVuIG1vcmUgdGhhbiBleGFjdGx5IHR3byBzdGF0ZXMgKGluIHRo aXMgY2FzZSwgZW5hYmxlZCwgZGlzYWJsZWQsPC9kaXY+DQo8ZGl2PiZndDsgZmFpbGVkLCBub3Qt YXZhaWxhYmxlLCAuLi4pLjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNvIHlvdSBz ZXR0bGUgb24gYmxhbWluZyB0aGUgbW9kZWwgd3JpdGVyLiA7LSk8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IC9qczwvZGl2Pg0K PGRpdj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7ICZndDsg LS08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAm Z3Q7ICZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4g fDwvZGl2Pg0KPGRpdj4mZ3Q7IEdlcm1hbnk8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyBGYXg6Jm5ic3A7Jm5ic3A7ICYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5q YWNvYnMtdW5pdmVyc2l0eS5kZS8iPmh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwv YT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgLS08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IEp1ZXJnZW4gU2No b2Vud2FlbGRlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7IFBob25lOiAmIzQzOzQ5IDQyMSAyMDAgMzU4NyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueTwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgRmF4OiZuYnNwOyZuYnNwOyAmIzQzOzQ5 IDQyMSAyMDAgMzEwMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5odHRw czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0 PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnJmx0 O21haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZyZsdDttYWlsdG86bmV0bW9k QGlldGYub3JnPC9hPiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxk aXY+Jmd0OyAtLTwvZGl2Pg0KPGRpdj4mZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L2Rpdj4NCjxkaXY+Jmd0OyBQaG9uZTogJiM0Mzs0 OSA0MjEgMjAwIDM1ODcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8L2Rpdj4NCjxkaXY+ Jmd0OyBGYXg6Jm5ic3A7Jm5ic3A7ICYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8iPmh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl LzwvYT4mZ3Q7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 PC9mb250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53a7042e5b1a47b7a3122c56a7900ac7huaweicom_-- From nobody Wed Mar 10 10:29:01 2021 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 80C1E3A1552 for ; Wed, 10 Mar 2021 10:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2QLsCqs6C-iH for ; Wed, 10 Mar 2021 10:28:55 -0800 (PST) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490D93A1547 for ; Wed, 10 Mar 2021 10:28:55 -0800 (PST) Received: by mail-pg1-f171.google.com with SMTP id p21so11947706pgl.12 for ; Wed, 10 Mar 2021 10:28:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KLp2KZLjL1NfUqgjldJHkxO5kAVv3lUQiaO5PFw67Hg=; b=Jenm4lK7ZYG1aj0Rj7yCMlAgJPdd2zE1Vi1KMI6zcD7EPCIKb1cBt37D12oIr+lmg2 KfpBmikHwHUH89swK4XPU6MPbL34EB7EzrpWd63jQq2gtzTrJ7cKdt25GbwJM4YRqVbY CUokUYy3D8Ng0GxRUq2Qwelzt5PLN8htBQrog2ufpnJ5n1i7pQlulP8rsLgMYp3XiqXs lIFBSH7gE75uDos76TA52ZUCuHGrORxG6IpCDc5UkMJ+3pM1xVly8cIw4+OYSP+ViJj1 a+3tJ7yzjc+ov+z1TKiCnaHrz/FGm9cmwpRsBEaKmfGsDrDtyHlRvyUIhBOjjGxyzb/S lY9A== X-Gm-Message-State: AOAM530mOKQOOFWAPxElOwTBP8FNmJ1JgaVeaM9xPOeaLIwQVnmLVUoz Qg9KxMu5fhh6YMEY4aeuWSAWRVQ2f8BDbA== X-Google-Smtp-Source: ABdhPJw9AJDUNtUmyko/DiFOwnUFqIKk0fr4zzkP38lNmN/NZmj8sc9KwBNQXemGxMcxGNZW2kiKlg== X-Received: by 2002:a63:c1d:: with SMTP id b29mr3931905pgl.9.1615400934654; Wed, 10 Mar 2021 10:28:54 -0800 (PST) Received: from ?IPv6:2601:646:9300:791:1da:1542:7299:6b2d? ([2601:646:9300:791:1da:1542:7299:6b2d]) by smtp.gmail.com with ESMTPSA id g12sm202124pfh.153.2021.03.10.10.28.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Mar 2021 10:28:54 -0800 (PST) To: netmod@ietf.org References: <20210310084324.xkr4xbsainfnxrvr@anna.jacobs.jacobs-university.de> From: Randy Presuhn Message-ID: Date: Wed, 10 Mar 2021 10:28:53 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210310084324.xkr4xbsainfnxrvr@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 18:29:00 -0000 Hi - On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: > Dear Qin, > > I believe this work repeats failures of the past but since the WG > agreed to entertain this, I will keep my mouth shut. I suggest you do > not spend your energy to convince the that this work is viable since > it is rather unlikely that I will change my mind. I'm inclined to agree with Juergen. I participated in policy-based management work in ISO/ITU projects starting in the late 1980's, culminating in System Management: Management Domain and Management Policy Management Function (ISO/IEC 10164-19) as well as the later projects in the IETF and DMTF. Whether the problems are in the architecture, the specification, or implementation, there's an ample body of experience suggesting that this stuff is hard to get right, and to the extent that a proposal resembles any of the previous work, one would be well- advised to learn from the ways in which that previous work has crashed and burned, or in some cases never really left the ground. Have fun, and good luck. > YANG is for me _not_ a suitable policy language, it is at best a > language to carry policies written in a suitable policy language (and > I am not even sure about this). All attempts in the past to reach > agreement on a common usable standard policy language leading up to > interoperable implementations failed. The reasons are manifold but > strong (I think), standards-based interoperability at a generic policy > language abstraction layer is for me a myths. Complete agreement with Juergen. One *might* use YANG to describe the structure of policies, but it would be cumbersome for representing policy semantics. The current trend in YANG-land embracing ever- increasing deviation from "standardized" models means that standards- based interoperability is getting harder, rather than easier, when it comes to machine reasoning about the semantics of "related" models. > Please don't take this personal in any way. I just do not believe into > this work but I am happy to be proven wrong. Ditto, kinda. I still think policy / intent-based management is a laudable goal. But it's really hard, and there are many factors in both the IETF's technology toolkit as well as its standardization process that compound the difficulty of the problem itself. Randy From nobody Wed Mar 10 10:33:48 2021 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 B75993A1555 for ; Wed, 10 Mar 2021 10:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDX6ElZiFMRk for ; Wed, 10 Mar 2021 10:33:44 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E103A1552 for ; Wed, 10 Mar 2021 10:33:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YFB5Vqeea+/yxLjM+QWOiprRJjgRiX905LgZkpAIY069yqrYWMi060UHzNk38CGDswV0KoPje7s7ECOamNnNiI6bqR1Z8o/fvHp26Lso2DWGa9GzSeiZ8ul+9cPkJ02H0m2uNxdr8Vdf5FC5oo8eVwZGnvY5JyEQD2Et6X+joISKgnbg8amb10z7PiVComeSEHCaMYxyARFi/SoHuPEXOoET107rxo27D5so4jmUOnPXI2KLQcMSc2QiX4WVzaYl5VRca/Hz7cwONdwz64wAFq4bk6XWtVpSEeJ9Wf23mZbZhb9JjDKUaSi7bwhf4IO/h5VL48b2Salg2w++wWreVA== 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=cK8Dk7I6t9C4v7mS70l5McTCLzP6c7t7L43llgVDhNQ=; b=JzmaQHZovg0fnWAy+PXnXpmQ+Iw1vGkGfdyyW/OWwOiofHFv4GO2TRhUUOXVjYXAQjF/miyz4b6mZv4acO3bQN29wayiejTkVsvkiu1djwC1SL4E5jy1NfmdRlRpi3AtwxDA1jOqVJoCVAqaoinsxOSaucszWr24/rmgT40S4OUYKk904jxLsYu/De80r1R92+PKm537rKtWcfhLnKNHOkmoPG++eL2F5FBpsa1eqDH/sM4Z5xqrtDJzUWOjyppBmyOIp/cvLngu0UWkXFxAUv/E0ESWkomayovnsuqDVxzoF4iXn6jNKZfMKRTqKv/UUL74iK5de++DctgAomHfDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cK8Dk7I6t9C4v7mS70l5McTCLzP6c7t7L43llgVDhNQ=; b=TrxE2udw14yTE2Ca4JzfRXqHXbd4Ze/XglNpqgvkUFOS4Bi7lUhT7kSd/CvFjRSyhyy+UcmBRQz3BmtJXsAn/AvSeycNurhz8rhBMoGv7aJZ8WULNQZ2fiyJ+WR93sXC9pBobMC4SIzYE/WNNKixM6b+lKQ+9eSsoRdq3tgdBY8= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1346.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.19; Wed, 10 Mar 2021 18:33:39 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 18:33:39 +0000 Date: Wed, 10 Mar 2021 19:33:38 +0100 From: Juergen Schoenwaelder To: Italo Busi Cc: "netmod@ietf.org" Message-ID: <20210310183338.bdkozhpsu67rp7u5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Italo Busi , "netmod@ietf.org" References: <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> <20210310161454.du65fbe4kot7jrfd@anna.jacobs.jacobs-university.de> <53a7042e5b1a47b7a3122c56a7900ac7@huawei.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53a7042e5b1a47b7a3122c56a7900ac7@huawei.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR05CA0086.eurprd05.prod.outlook.com (2603:10a6:208:136::26) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR05CA0086.eurprd05.prod.outlook.com (2603:10a6:208:136::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Wed, 10 Mar 2021 18:33:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0811461-339a-4708-e0bc-08d8e3f3065f X-MS-TrafficTypeDiagnostic: AM9P190MB1346: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zavyWqsTUogzoBu4Sa2rt5lCwVv2uhUbvpHUTxS/qTBLyztzFbePkI73OAf/yaZUH6uTgklhziSNGajwb4t+OXmAnotljryvYe6sinqy3GRL5o3YDwKoIX+R9fyup7o3MECtTd00+BPLwWx8W8bBTwYMt7nrJJiFafsW+UszEowkrQJa4WxzRYM9H0CnnSlTosiK9pMW3Aq2trd8tbrPB8KJiyD73kvd/ln7xeL10GaI/RXHWEEQ4z2F0NSU0kOG744YGIx5Y77AmvaueT0ZZhQwzwV/pZ3+o4Xj6sEy9dIBJcdaUz17zjKPgVuBAUTwooagPGsJ1Z5jj9qn78YBvxHoLRfXg001+QoV+wYCVSxxrLxHvM+5WA2uC6Jo/s50lef5NykaN5DeSoSkAfn0MKFGuNfeyfNOQNtJRgZdUCVMYV3+ULJSkSm32KaFrT1lCRzYR6RLFJlDrJRMQMvNsWe7Vh1Hb10mU4RVO/RyzqunKj0NArnOt9Rbox1aEglGfXo60+4rfDpD/zo8qT8TP+x4aRHOBDQJzea7mGTVzq7JrOTz7ASir3Y7lSNnWbN8DDI2W1wCxHj0RM995JpqObqqmW+7MrvCF35MBkX3i/A= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(346002)(136003)(396003)(376002)(366004)(3450700001)(1076003)(6486002)(5660300002)(52116002)(478600001)(8936002)(8676002)(6916009)(186003)(83380400001)(86362001)(16526019)(956004)(66476007)(2906002)(66556008)(4326008)(66946007)(6496006)(316002)(786003)(26005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?DktM4/X3+Nwzqm3rNMp/PkFgW/JpaeQuovJvW0mxgl8lXsMw90yuuxOYMMaR?= =?us-ascii?Q?QfKlFaBTdIvSo6zOgdoSPLbuGbw7lgsiG6Pgt5J6pSM89VgIkGTjcr7PawXd?= =?us-ascii?Q?3YUkWVBTd2SjFm2SGUlE8XyfKEOmAzkOblxG6kMdkUevt+K7tazy5MKWneat?= =?us-ascii?Q?7wpYseSL3Yd94Twbu0EfWOtW5w5yEMBPh4F5vP8J15NcGnWT1MRKp4SvhJNr?= =?us-ascii?Q?MkKoMaeSCBJNxRPOx1pfCZGjvZOtRUaJ4aR/WtM1ApNr/oLCzxe+/FXPzBku?= =?us-ascii?Q?o+fPGSBj1OgWvFualna4x8kIVdcwqBIwgaNgusG0DqE7uCZ1sr4krkfEmJ3E?= =?us-ascii?Q?AbucX6YCh8SyZYtnQRpsCRXQazCMmVC3fS4LCEHtm2uNqR0QaByYDbN6tIxd?= =?us-ascii?Q?N2pX/CRgnI9Lo92WHjo6Qu5d0qAKWqWgMKxuG8rvEeTSqmZPbx6J4KyqQ+Hc?= =?us-ascii?Q?YqMTxmeDkJuKPvYwVQxSfCqDKUFWWR5W88ArO1xm7IVFklh9z7fw5F+tMCY8?= =?us-ascii?Q?YimyhF85QnSITzz7HyRohzDjwicOUMiVsSkTftVOa3ZICKshe13WoJAfABy5?= =?us-ascii?Q?CKKgOJiVUE4ig8EZxZVR/phRV4gUL14yRHzWyo3+W8GvEP8vpFUysDPEHoma?= =?us-ascii?Q?iVTbM3zUADVZI6cbAHjiefMDW55xlY4RUsmdGKclAnFm6pLbpyFJt/RDUQpN?= =?us-ascii?Q?coNpOwWZQ1PDFNQFpYqk4RFPeyc9mpbnDOO8IblWISTR3brA6sCXv4/4Ur7m?= =?us-ascii?Q?8FbNy8RUXeSlDN7d3+CGXNI1ZROgUKUMzCmcg39z6nsqg93H9BznlKyAoE+9?= =?us-ascii?Q?SBniwdNzLdimpiJkRS58g/rEuJ8ZqiNu97yZVIrjAyP8RJXHRak6LXlpkwZW?= =?us-ascii?Q?WRv6xZ4IxRSQ1wi0G+Xqo0ynKQ/26B2Ab32NvrGDBtGcGOOYykNiO1cw+Yoo?= =?us-ascii?Q?Q6fiwiHSsx02YuI0+EwJ4sBUAnbWWcPk9NUuwBUz/M1MelnLtfP1zvv5lMta?= =?us-ascii?Q?w7pLIVg2JHPREc2yqIzE1omLeVKTdDqjGeLz8iVcgnor4hi/ydiK/twfWXhf?= =?us-ascii?Q?6i7jLUuSGBuhTl8IWn8j+JpRqIycV4VeHXO8HXqLLJAPsoge5v67YmBf1A+V?= =?us-ascii?Q?M/K+Jf7VzfLZCm5PY8aItaT784iAaiTnsv6G2ye8iQSJ97IEAYDxHlPDBGpI?= =?us-ascii?Q?L+FeiID6oZbzrjRZfTZ7UONgIJ3cz5y2jodWOXEO3lok+9I9JRuVDfL4swYH?= =?us-ascii?Q?+DSpXdbLXw9B5TDUfQ5tgEExB5YSol4Zc1I7XGrt1+lWAYB/oc08xfO01ccA?= =?us-ascii?Q?rVxeQkE6QxvvKqzz2y16JnCg?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: e0811461-339a-4708-e0bc-08d8e3f3065f X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2021 18:33:39.8003 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: E7YV0m2ixEOod3FfrQZ6s+2HBj5EDfarsBgm/pTC6sV6Gs1oquhbYFMoUSzzXwheQ/DRBNJC5U21uUCMhL47qdKRx2nsuZdGlVPs4wlGc+Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1346 Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 18:33:47 -0000 On Wed, Mar 10, 2021 at 05:34:41PM +0000, Italo Busi wrote: > Juergen, > > I think you have got the problem: "a data model author thought the default is always 0 and later he/she realizes that in some contexts the default should be something different" > > Unless I am missing something, creating a new leaf (e.g., foo-new) would confuse an existing client. No, it does not confuse the client, the client will ignore it. > For example, within the operational DS, the value of foo will be set to 0 (as per YANG default statement) while the value of foo-new will be set to 10, which represents the actual value in use by the system. Yes, a new implementation will have to declare that it does not implement foo. > Now, the existing client, which is not aware of foo-new, when reading the value of foo in the operational DS will incorrectly think that the actual value in use by the system is 0 rather than 10. A client reading knows the value in use. But clients do not have to real operational. > Am I missing anything? > > Instead, if we can find a magic way to apply the value 10 to foo within the operational DS, the existing client can read the value of foo in the operational DS and correctly understand that the actual value in use by the system is 10 (even if this is not the default value of foo). In general, you can't assume that clients read operational. I can't judge the specific circumstances but in traditional NC/RC, a default statement can be interpreted as "assume the default value is in force if this lead is not configured" (unless the client uses RFC 6243 report-all). If all clients are in an NMDA world, the issue is much smaller - it is reduced to "does the client believe the server has a bug or not". But even then, I continue to believe that a leaf changing the semantics of another leaf is bad design. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 10 11:24:50 2021 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 9347E3A1645 for ; Wed, 10 Mar 2021 11:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GRX_L6IUTa1q for ; Wed, 10 Mar 2021 11:24:46 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0BB3A163F for ; Wed, 10 Mar 2021 11:24:46 -0800 (PST) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Dwhjt6KPpz67nbJ; Thu, 11 Mar 2021 03:20:18 +0800 (CST) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 10 Mar 2021 20:24:43 +0100 Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2106.013; Wed, 10 Mar 2021 20:24:42 +0100 From: Italo Busi To: 'Juergen Schoenwaelder' CC: "netmod@ietf.org" Thread-Topic: [netmod] Questions about how to assign default values with YANG Thread-Index: AdbvCmZgzen+a6G4QWicT/glaRAynP///QGA///e3yCAAEHcAP//waGggACHKYD/tcyd8BK8WnuAAACoPAD//yMQoP/99AcA//vNQxD/95QgAP/vD80Q/94RSgD/vA358A== Date: Wed, 10 Mar 2021 19:24:42 +0000 Message-ID: <94eaf06f5bb9463081f0129a4aec7b99@huawei.com> References: <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> <20210310161454.du65fbe4kot7jrfd@anna.jacobs.jacobs-university.de> <53a7042e5b1a47b7a3122c56a7900ac7@huawei.com> <20210310183338.bdkozhpsu67rp7u5@anna.jacobs.jacobs-university.de> In-Reply-To: <20210310183338.bdkozhpsu67rp7u5@anna.jacobs.jacobs-university.de> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.173] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 19:24:49 -0000 Hi Jurgen, Now I can understand your concerns :) > If all clients are in an > NMDA world, the issue is much smaller - it is reduced to "does the client > believe the server has a bug or not".=20 Yes, I was assuming that all the clients and the server were NMDA-compliant= . It seems worthwhile spelling out this requirement more explicitly when de= fining the work-around. I think that the solution would also work if the client and the server foll= ows the guidelines of section 2 of draft-dsdt-nmda-guidelines-01: in this c= ase the behavior of the NMDA module in the running DS would be fully compli= ant with RFC8342, while the non-NMDA module would be an exact copy of the o= perational DS (the client needs to read within this module to get the in-us= e value). Otherwise, I am not sure how can an non-NMDA client properly operate over a= n NMDA server: the values reported by the server in the running DS do not n= ecessarily represent the values in use by the system. > But even then, I continue to believe that > a leaf changing the semantics of another leaf is bad design. I agree: I am just looking for a reasonable work-around that could work whe= n it is not possible to remove an existing YANG default statement. The lesson-learnt from this discussion is that more care has to be taken wh= en defining YANG default statements. Italo > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: mercoled=EC 10 marzo 2021 19:34 > To: Italo Busi > Cc: netmod@ietf.org > Subject: Re: [netmod] Questions about how to assign default values with > YANG >=20 > On Wed, Mar 10, 2021 at 05:34:41PM +0000, Italo Busi wrote: > > Juergen, > > > > I think you have got the problem: "a data model author thought the defa= ult > is always 0 and later he/she realizes that in some contexts the default s= hould > be something different" > > > > Unless I am missing something, creating a new leaf (e.g., foo-new) woul= d > confuse an existing client. >=20 > No, it does not confuse the client, the client will ignore it. >=20 > > For example, within the operational DS, the value of foo will be set to= 0 (as > per YANG default statement) while the value of foo-new will be set to 10, > which represents the actual value in use by the system. >=20 > Yes, a new implementation will have to declare that it does not implement > foo. >=20 > > Now, the existing client, which is not aware of foo-new, when reading t= he > value of foo in the operational DS will incorrectly think that the actual= value > in use by the system is 0 rather than 10. >=20 > A client reading knows the value in use. But clients do not= have > to real operational. >=20 > > Am I missing anything? > > > > Instead, if we can find a magic way to apply the value 10 to foo within= the > operational DS, the existing client can read the value of foo in the oper= ational > DS and correctly understand that the actual value in use by the system is= 10 > (even if this is not the default value of foo). >=20 > In general, you can't assume that clients read operational. I can't judge= the > specific circumstances but in traditional NC/RC, a default statement can = be > interpreted as "assume the default value is in force if this lead is not > configured" (unless the client uses RFC 6243 report-all). If all clients = are in an > NMDA world, the issue is much smaller - it is reduced to "does the client > believe the server has a bug or not". But even then, I continue to believ= e that > a leaf changing the semantics of another leaf is bad design. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Mar 10 11:46:49 2021 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 8840D3A1678 for ; Wed, 10 Mar 2021 11:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqBj70dCWoqO for ; Wed, 10 Mar 2021 11:46:43 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D897F3A1684 for ; Wed, 10 Mar 2021 11:46:42 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id q14so27192075ljp.4 for ; Wed, 10 Mar 2021 11:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XdUY/TeztA0IAErLqvfUQvYGECGzs9nHgDp4jcNkH4c=; b=mDIdQtTZFO5a/JGudCXRdHGWIVsW3jpERPVlJhPUmebln/2asbNwN4AlhoTLu1cjC0 SzV/zsgQQ/e6g0umFT4YFTcL8LaZmBIy3fI0bgTYH2uqnVSLwM34x2Ih7AYyCoKsAOlk 8U3/fH5aR7ELYWIUdde6eJyU/YR2xd+GRyBmuNvFSVewyIm4kO2PmRiOsO56ZYdkBNKj YcPUpbJ8O9tKOlj7HbHFY+nLqSppWh0WMsVKP/SNoDrUT/ZapownXvdpGpBzJuOsXwYt Esx0OO93zqGcMBEk5doHSZjLdqb3zbYDiLGZYr+yTnexKoXJPPYtrvXerl1baRgxzuqf /5NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XdUY/TeztA0IAErLqvfUQvYGECGzs9nHgDp4jcNkH4c=; b=WeirDmlD8E9+3IgM98AvZT3igvl9crRoqDVLG5EOiiDuZnJOSpJo52SvMitFuPOI/R Fs6hHuPD9v1QKX5GIMPHtl9EuaGnGwXaJpbj/Jt7phO70MVyx10HMwa6Wg7YFQwRhI5y oHUt8c/NLZi/W2W6ZkxEnwevF8DcnE46r+udT7hSa8AigQw7xXYGWWK+ZWs4bMEwhTAm +KI69rnEGGNX/geh1Y7DGmHaaYfxRjT3/N7f6R7jHrqGoAka4D2BgHG24zePN0Ds/bbN VZgLVQh1LJPAezd3DGpwdl2u50ORU4bH+nVLgFwdkkbu567wnR8N2x/3Fcsf6Xm+IPaM c+Fg== X-Gm-Message-State: AOAM533BQ3TmtCma/5YDMMt5qR41ImfJJqOt9OEKT0ic/kHZswyA9VN5 0eQ6pXPpcVOqChLN/QtgnaCfuJaVpUGKpQ3+fczKpg== X-Google-Smtp-Source: ABdhPJyv3uzI7wnd9X77AMA6wbHeZRIkrdXVy/nU0/fcjBHkmejB6wtKucsfJNfnpYg0nxs3NSl1NtxHb4rG3U29xeM= X-Received: by 2002:a2e:9157:: with SMTP id q23mr2835704ljg.298.1615405600229; Wed, 10 Mar 2021 11:46:40 -0800 (PST) MIME-Version: 1.0 References: <0ed5638881af42148720dd7f4843c3e6@huawei.com> <20210120160517.hsg5dnpidvrprtso@anna.jacobs.jacobs-university.de> <521a9ccd02e14d178a6e62971b4809ea@huawei.com> <20210309195241.k5lfmdnw2zqq6b4o@anna.jacobs.jacobs-university.de> <3a5eea68b8554cbe9ed3e8bc63652ffc@huawei.com> <20210310161454.du65fbe4kot7jrfd@anna.jacobs.jacobs-university.de> <53a7042e5b1a47b7a3122c56a7900ac7@huawei.com> <20210310183338.bdkozhpsu67rp7u5@anna.jacobs.jacobs-university.de> <94eaf06f5bb9463081f0129a4aec7b99@huawei.com> In-Reply-To: <94eaf06f5bb9463081f0129a4aec7b99@huawei.com> From: Andy Bierman Date: Wed, 10 Mar 2021 11:46:29 -0800 Message-ID: To: Italo Busi Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f85edd05bd33eca2" Archived-At: Subject: Re: [netmod] Questions about how to assign default values with YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 19:46:46 -0000 --000000000000f85edd05bd33eca2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2021 at 11:24 AM Italo Busi wrote: > Hi Jurgen, > > Now I can understand your concerns :) > > > If all clients are in an > > NMDA world, the issue is much smaller - it is reduced to "does the clie= nt > > believe the server has a bug or not". > > Yes, I was assuming that all the clients and the server were > NMDA-compliant. It seems worthwhile spelling out this requirement more > explicitly when defining the work-around. > > I think that the solution would also work if the client and the server > follows the guidelines of section 2 of draft-dsdt-nmda-guidelines-01: in > this case the behavior of the NMDA module in the running DS would be full= y > compliant with RFC8342, while the non-NMDA module would be an exact copy = of > the operational DS (the client needs to read within this module to get th= e > in-use value). > > Otherwise, I am not sure how can an non-NMDA client properly operate over > an NMDA server: the values reported by the server in the running DS do no= t > necessarily represent the values in use by the system. > > > But even then, I continue to believe that > > a leaf changing the semantics of another leaf is bad design. > > I agree: I am just looking for a reasonable work-around that could work > when it is not possible to remove an existing YANG default statement. > > The lesson-learnt from this discussion is that more care has to be taken > when defining YANG default statements. > > Or the lesson could be that the concept and implementation of YANG module conformance is still "under construction". You want to deviate from the old conformance and require a new conformance instead. In SMIv2, model conformance can be per use-case, not just per-module and explicit conformance statements are used, instead of conformance implied by the YANG statements themselves. In this case, conformance to the new module is desired (without the YANG default) instead of conformance to the old module (with the YANG default). A server cannot advertise both modules, unless it also declares that it deviates from the old module conformance. (deviate delete default) A new client finds the new module + the old module + the deviation. An old client finds the old module and the deviation (if YANG compliant). An old client thinks the server is deviating from the old module conformanc= e (because that is exactly what is happening). Andy > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e > ] > > Sent: mercoled=C3=AC 10 marzo 2021 19:34 > > To: Italo Busi > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Questions about how to assign default values with > > YANG > > > > On Wed, Mar 10, 2021 at 05:34:41PM +0000, Italo Busi wrote: > > > Juergen, > > > > > > I think you have got the problem: "a data model author thought the > default > > is always 0 and later he/she realizes that in some contexts the default > should > > be something different" > > > > > > Unless I am missing something, creating a new leaf (e.g., foo-new) > would > > confuse an existing client. > > > > No, it does not confuse the client, the client will ignore it. > > > > > For example, within the operational DS, the value of foo will be set > to 0 (as > > per YANG default statement) while the value of foo-new will be set to 1= 0, > > which represents the actual value in use by the system. > > > > Yes, a new implementation will have to declare that it does not impleme= nt > > foo. > > > > > Now, the existing client, which is not aware of foo-new, when reading > the > > value of foo in the operational DS will incorrectly think that the > actual value > > in use by the system is 0 rather than 10. > > > > A client reading knows the value in use. But clients do > not have > > to real operational. > > > > > Am I missing anything? > > > > > > Instead, if we can find a magic way to apply the value 10 to foo > within the > > operational DS, the existing client can read the value of foo in the > operational > > DS and correctly understand that the actual value in use by the system > is 10 > > (even if this is not the default value of foo). > > > > In general, you can't assume that clients read operational. I can't > judge the > > specific circumstances but in traditional NC/RC, a default statement ca= n > be > > interpreted as "assume the default value is in force if this lead is no= t > > configured" (unless the client uses RFC 6243 report-all). If all client= s > are in an > > NMDA world, the issue is much smaller - it is reduced to "does the clie= nt > > believe the server has a bug or not". But even then, I continue to > believe that > > a leaf changing the semantics of another leaf is bad design. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000f85edd05bd33eca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 10, 2021 at 11:24 AM Ital= o Busi <Italo.Busi@huawei.com> wrote:
Hi= Jurgen,

Now I can understand your concerns :)

> If all clients are in an
> NMDA world, the issue is much smaller - it is reduced to "does th= e client
> believe the server has a bug or not".

Yes, I was assuming that all the clients and the server were NMDA-compliant= . It seems worthwhile spelling out this requirement more explicitly when de= fining the work-around.

I think that the solution would also work if the client and the server foll= ows the guidelines of section 2 of draft-dsdt-nmda-guidelines-01: in this c= ase the behavior of the NMDA module in the running DS would be fully compli= ant with RFC8342, while the non-NMDA module would be an exact copy of the o= perational DS (the client needs to read within this module to get the in-us= e value).

Otherwise, I am not sure how can an non-NMDA client properly operate over a= n NMDA server: the values reported by the server in the running DS do not n= ecessarily represent the values in use by the system.

> But even then, I continue to believe that
> a leaf changing the semantics of another leaf is bad design.

I agree: I am just looking for a reasonable work-around that could work whe= n it is not possible to remove an existing YANG default statement.

The lesson-learnt from this discussion is that more care has to be taken wh= en defining YANG default statements.


is still "un= der construction". You want to deviate from the old conformance and
require a new conformance instead.

In SMIv= 2, model conformance can be per use-case, not just per-module
and= explicit conformance statements are used, instead of conformance implied b= y the
YANG statements themselves.

In thi= s case, conformance=C2=A0to the new module is desired (without the YANG def= ault)
instead of conformance=C2=A0to the old module (with the YAN= G default). A server cannot
advertise both modules, unless it als= o declares that it deviates from the old module conformance.
(dev= iate delete default)

A new client finds the new mo= dule=C2=A0+ the old module=C2=A0+ the deviation.
An old client fi= nds the old module and the deviation (if YANG compliant).
An old = client thinks the server is deviating from the old module conformance
=
(because that is exactly what is happening).

=
Andy
=C2=A0

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]
> Sent: mercoled=C3=AC 10 marzo 2021 19:34
> To: Italo Busi <Italo.Busi@huawei.com>
> Cc: netmod@ietf.o= rg
> Subject: Re: [netmod] Questions about how to assign default values wit= h
> YANG
>
> On Wed, Mar 10, 2021 at 05:34:41PM +0000, Italo Busi wrote:
> > Juergen,
> >
> > I think you have got the problem: "a data model author thoug= ht the default
> is always 0 and later he/she realizes that in some contexts the defaul= t should
> be something different"
> >
> > Unless I am missing something, creating a new leaf (e.g., foo-new= ) would
> confuse an existing client.
>
> No, it does not confuse the client, the client will ignore it.
>
> > For example, within the operational DS, the value of foo will be = set to 0 (as
> per YANG default statement) while the value of foo-new will be set to = 10,
> which represents the actual value in use by the system.
>
> Yes, a new implementation will have to declare that it does not implem= ent
> foo.
>
> > Now, the existing client, which is not aware of foo-new, when rea= ding the
> value of foo in the operational DS will incorrectly think that the act= ual value
> in use by the system is 0 rather than 10.
>
> A client reading <operational> knows the value in use. But clien= ts do not have
> to real operational.
>
> > Am I missing anything?
> >
> > Instead, if we can find a magic way to apply the value 10 to foo = within the
> operational DS, the existing client can read the value of foo in the o= perational
> DS and correctly understand that the actual value in use by the system= is 10
> (even if this is not the default value of foo).
>
> In general, you can't assume that clients read operational. I can&= #39;t judge the
> specific circumstances but in traditional NC/RC, a default statement c= an be
> interpreted as "assume the default value is in force if this lead= is not
> configured" (unless the client uses RFC 6243 report-all). If all = clients are in an
> NMDA world, the issue is much smaller - it is reduced to "does th= e client
> believe the server has a bug or not". But even then, I continue t= o believe that
> a leaf changing the semantics of another leaf is bad design.
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000f85edd05bd33eca2-- From nobody Mon Mar 15 10:26:48 2021 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 846AD3A17F7; Mon, 15 Mar 2021 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=kp925+71; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FR5ICfA7 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 NTEKfdYPJh1N; Mon, 15 Mar 2021 10:26:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46F43A17F5; Mon, 15 Mar 2021 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65036; q=dns/txt; s=iport; t=1615829202; x=1617038802; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YErfdz4E7p5n9FDp0VJNJXIfB/P+7hWs62OvO4oW+xg=; b=kp925+714kPYVYW4JMqi83FMn1PeDq6LQ4js7UUXZhSKX8xh1bIML+oS Nf29d7jF8mqCs6N3iq3j7eDl/Wt8RwFRe+3L0Q3RjYgLzWL0KUrvIPNn6 Cxvxnj4kn5y1GOxJuICJxuJfL4J/x4pR/UMR3kegBz8gVhFq2xep0JtpT U=; IronPort-PHdr: =?us-ascii?q?A9a23=3ANpAAsBAgDaHn9M190C3OUyQVlBdPi93PFgcI9?= =?us-ascii?q?poqja5Pea2//pPkeVbS/uhpkEShdZTG7vtbjPDVqObrXmlTqZqCsXVXdptKW?= =?us-ascii?q?ldFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBs2C35CEVA?= =?us-ascii?q?BbkcwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6y?= =?us-ascii?q?wDCpT1DfOEFrV4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AgeomCa6MfYsz2E+T/gPXwZqFI+orLtY04l?= =?us-ascii?q?Q7vn1ZYSd+NuSFisGjm+ka3xfoiDAXHEotg8yEJbPoexLh3LZPy800Ma25VA?= =?us-ascii?q?fr/FGpIoZr8Jf4z1TbdRHW3tV2kZ1te60WMrLNJHBxh8ri/U2cG9Ev3NGI/M?= =?us-ascii?q?mT9Jjj5l1GJDsaDJ1IxQF/FwqdDwlSTA5JGZI2GPOnl7R6jhCnfmkaadn+O2?= =?us-ascii?q?kdU4H41pP2vb/FQTpDPR4o7wGSkSilgYSbLzG01goTOgk/uosK3nPCl2XCl8?= =?us-ascii?q?CemtG9jiTRzmrCq6lR8eGRtudrIOyppowrJi73igCuDb4RGoGqmDwuuumg5B?= =?us-ascii?q?ILvbD30m0dFv9+4X/QYW25yCGFs2KLvVpeiA6B9XaijXTuusD/Tj4hYvAx+L?= =?us-ascii?q?5xSAfT6EYrobhHocR29l+ZrJZeAFfhmynw9rHzJmlXv3e0unYrnKoviWVeW+?= =?us-ascii?q?IlGcZshLEYlXkldKsoLWbf0sQKAeNuBMbT6LJ9alWBdU3UuWFp3ZiFQmkzNg?= =?us-ascii?q?3ueDlDhuWllxxt2FxpxUoRw8IS2l0a8ogmdpVC7+PYdox1ibB1SNMMZ64VPp?= =?us-ascii?q?ZDfeKHTkj2BT7cOmObJlrqUIsdPWjWlpLx6LIpoManZYIP15l3vJjaSltXuS?= =?us-ascii?q?oTdivVeI+z9awO1iqIbHS2XDzrxM0bzYN+oKfASL3iNjDGR0spl8emvvUDEs?= =?us-ascii?q?zWU/u+I/ttcrveBFqrPbwM8xz1WpFUJ3VbetYSoMwHV1WHpd+OKoCCjJ2dTN?= =?us-ascii?q?/jYJ7WVRo0UGL2BXUOGBLpIt9b00ytUnjkxBzYW3bnfF3j7Yt9eZKqudQ7+c?= =?us-ascii?q?woDMlhowIVgVO26oWgMjtZqJE7e0N4PffgiaO0pW6/+G7S9GV3Mh9BDkJYiY?= =?us-ascii?q?+QFk9ilEsvCQfZYLwDs9KQdSR5x32cPCJySMvQDUpCvVht4Lm2KJaR3CgmDN?= =?us-ascii?q?qiPguh/iIujUPPa61ZtryI5M/jdJ99M40vX7ZpEx7XUzZvnxxxlWtFYAgYZ0?= =?us-ascii?q?PWGz/0k5+5hJgMCOy3TaglvC6bZepv7VPWrwG1uNwmTHpzZU/ebeenxSIVAw?= =?us-ascii?q?dyqnI02akFm7aEkSuoMgIE8ZQFGWwJTn+WDrJABBmCf6NOlNnQCVpNZFbPoy?= =?us-ascii?q?CGgBcufWev0EMeigXaXHCpUMCOJEZBsXZF1auvyndITyG2ekJ9bW0Si/wmKU?= =?us-ascii?q?3Ppmtz3eiXZqC6zmuWbR8YzvsANSzeCAFiUT9G1pS50gWYly2FEmhjzpIyPv?= =?us-ascii?q?bFBLBmaL3L3GixQbf42J0uDrtR/Jx/MsrpvfJOWeWDexWNJDeQMZJj5yWF4n?= =?us-ascii?q?IkMjJzsn8qjLfh3wDk9nGx2Do6DeDJKFprA7EdLNf01Rmve9+YlJF4h8kyp+?= =?us-ascii?q?2+LyH4bcOH07jea3pbMQzIyFTGOd0AuNRRp+Y/pbFzF57UXX/B02xGxgw3KI?= =?us-ascii?q?PxmFkFSKp27bjdMuZUDoAvUjMc+kBsmMWELUMtvACzGOM4cF03h3LQPt+C4d?= =?us-ascii?q?Pz2PISK1zEoBG1NUiU8iVb8fuAQjCK0qQCDbksZWtRc0ox5R1Zjay/XpyVDB?= =?us-ascii?q?/vce5N/FC3aCDgNLBcTbWIArUWoFJx5cqSk+qeair/30TRsFJAU9Zz2nfiRd?= =?us-ascii?q?n3BgSGXfNM+Zi9P1+Hh6Ox+s69jDvtU1KAGg0lrJwAcVZVd9hJjzkpkZY+3S?= =?us-ascii?q?ezQLHmu05NqSoq3Rh30lr2npW86GjVHUtaIRTUj5VfUz5UKGWJh63+gJ+l/W?= =?us-ascii?q?W45iNE15nFHFpRed8LG8F4dPmEExtT?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDEl09g/51dJa1QChsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQGCD4EjMCMuB3ZaNjEKhDeDSAOFOYhBA4EHiSCPBIJ?= =?us-ascii?q?TA1QLAQEBDQEBKAoCBAEBhE0CF4FgAiU4EwIDAQELAQEFAQEBAgEGBHGFYQ2?= =?us-ascii?q?GRAEBAQEDGgMGChMBATcBDwIBCBEBAwEBIQEGAwICAh8RFAMGCAIEDgUIE4J?= =?us-ascii?q?WgX5XAy8BAwuiEQKKHneBMoMEAQEGhR8NC4IUAwaBOYJ2hAcBAYEMhTgmHIF?= =?us-ascii?q?KQoERQ4IjNT6CHkICAhaBGgQRGisJgmA1giuBWAFrBgEXJgILARgEQwoGIAI?= =?us-ascii?q?tLB0cLxkIDgMhAwwIkEojgmZCh1ExjDiQPjlbCoMClw+FUYM+ilyVe5gdizO?= =?us-ascii?q?OcS0ehDwCAgICBAUCDgEBBoFrIyqBLXAVgyRQFwINjh+Db4pZczgCBgEJAQE?= =?us-ascii?q?DCXyLKAImB4EHATFdAQE?= X-IronPort-AV: E=Sophos;i="5.81,251,1610409600"; d="scan'208,217";a="847813934" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Mar 2021 17:26:37 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 12FHQbki030710 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 15 Mar 2021 17:26:37 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 15 Mar 2021 12:26:36 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 15 Mar 2021 12:26:36 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Mar 2021 13:26:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i1uuI1rYdAAjSjpOJK0twwFA2FwV7ocs+GR0V41mwSwHDfKD+ZRoaxZAQ8hU4iPkXIj4HSgBf1H3yvEwBE4tVoWkCQRcqU7jr+Pibz0GQ+OtGirVzIm069nrH09KyWf97dOqqW/Gm7flsgrz1kVjdLOWSd5VjW7k7QFlaOCUxDc2ORqCaGauKXLDiRRD53eBV/LBQf7rbH1f41YWxUiKcpUY4vJflClN5xbKnXRo8m8Lkd/aBpninKVvES4b0UM/o0rmxinX7FFuV1xWFBbWEE2OgC7g+W1WdtjdjfN2/hnNDPpJAPq/6IhY3/9nBkPZjnc3TwBW5pLIz7YDhomLuw== 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=YErfdz4E7p5n9FDp0VJNJXIfB/P+7hWs62OvO4oW+xg=; b=hjPrXoQCmYRXL/OqsYOc1rWQYMvFHevhLD37Y7PoWyX3gcJOKCilg96qfVdtY913tzcCK3qaUSBXgAaL01BhVK9vnKtw3XHGSiyDazyWMFJBC89cZUBIfTDc606NcslrsifQTBW+lmnbW9hS8VJD9ygxrRhHyqCBMqWRpvsOS8A2lK5HT922zeYubhHshKXXRyCF+b16AZQyGUXqj5WRcXRpBfOmbx9SiZ8d5gpVot5hoX7JJTVoG/+NwkJr3byKOz0Lw7ayTGQeAeoYvHerkuRx9CzQyAQwQJzYWhOJL12301jEng2OoKfuGM6iaBpcQQsMUZO/IoxKCN78wynXoQ== 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=YErfdz4E7p5n9FDp0VJNJXIfB/P+7hWs62OvO4oW+xg=; b=FR5ICfA7HtlBp8GnaXQzgrAXdh5EL/w8U0CQapstwM/a/5jE2brdO3XvWRSXXt7SVJqIZHvegRAjpqkFW2r+RZ7udugB6Dd6WrIvh6Azt4HrALMd68LbBWfZ27Fd+EIsiLvepILKfgjNbFcAexIHt1WQ7Tf14F8YJLzCgK3tGxc= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4613.namprd11.prod.outlook.com (2603:10b6:208:26d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Mon, 15 Mar 2021 17:26:34 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3933.032; Mon, 15 Mar 2021 17:26:34 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: NetMod WG Chairs , joel jaeggli , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-nmda-diff-07 Thread-Index: Adat+a/3DPT1aCJSTfuydcCuPD9V4wAX4/YAAAExU4AAtpAc8BgpU+wAAAMUy5AAAXn4AAHzy1Vg Date: Mon, 15 Mar 2021 17:26:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.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: 82480662-52ec-47a1-e467-08d8e7d77b1e x-ms-traffictypediagnostic: MN2PR11MB4613: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ybRig+/S1dHoWO/d2oHCHDhJHCNOoh/YukFetQek6ynuc6w3DzwKDDqQlkYmWdTTq8VXENHdOsb8hGAlEb24vzOslsYO8blS5H6/2PlbG80srMh7ohPJw8QZks/DImlUaLJW01DUV8GiUe/u5NN+qm89UjBQJntWU7D7ZUtXOvfQ/Ux6Sk00wJir/lj/wKH10tjp2Yzgj1/KX/3JMwFPWddys39vx0Gmkvl90xQWyl0uub/lPLj3s0lJNSOsn7VjrcjlZuWgioTDJ5aJUDqewXuJwuKyMfo7bCQTQvh/LpNoVHkuM/+3Tql+1BH0UMYPQZFyYFPrCnrDkIZnO6zb2flrET04gpW/TkHrATS9agKQwJoG6xENgwp5s2V2aVh398CECcKL6DZAkxpAoB7CFBFrZrjMChvDeQh0Y8Ugjm0sFMtJkgrQM8Zv7zhQ3/rMpa0QQZWq0I96w7howCC+bDHFOZNR9l147gHcUfneedcfMSx+5sl6cAJmInyBqPtIx8z3mNNY+h4noNcZL7ShCfRt6PE/jd+c7WYZuTM0BEAn71lk+s4V90qwoUeuWbitwmpnoQA3ddinnEnZiZCQ+C++WIyByoJtKsZKqeJYMVZKAX27W4ajPiZsT+9bPe4f2jCuq0PqcEoPsJJcd80qHA== 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:(376002)(136003)(39860400002)(346002)(396003)(366004)(55016002)(9686003)(33656002)(26005)(71200400001)(76116006)(6916009)(2906002)(186003)(66446008)(86362001)(64756008)(66476007)(66556008)(54906003)(52536014)(6506007)(53546011)(8936002)(8676002)(4326008)(9326002)(5660300002)(7696005)(30864003)(478600001)(83380400001)(316002)(166002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VnNFS1BXTXVybElKdXJJdEcxbkVxUW5OMmhldmJId1N3dkpVN1FUcWo0REJD?= =?utf-8?B?QkhMZU51RlZiUkhLbzVFVWpZcG8yQkJkZ1Y5YTNHLzM2VGdRTGdvaTRQVkdw?= =?utf-8?B?RHg0Ly9oalZYa3RJNlBhQUR1ME9IK284T3RFaEwrcXF3OXltL0grYnpFQ21k?= =?utf-8?B?WlNnOVdmNXFsa00rTTJ1TWhrdlF1NC82NlRPc2l6Titld1FRamJaNGdjdTBZ?= =?utf-8?B?bVpNMHN5ZGE2SW0yT3lPYWRsSVJxLzZQMEZwU3hUVHhkTGo4ak13QVNUcUNL?= =?utf-8?B?dzhvdW16WWZGVkNiQVlyc0FJL25NWUxsUy9oU0RabWRJOUdyY1RvaHYyUmtK?= =?utf-8?B?UGp4R0tvVWFIcUtkcFJMUXNqY1ZKbDRwdExvVjJtQy82c1YzWFdrcmIxaU1L?= =?utf-8?B?SzZoOWgvNFcvYjRkNUlqd05CUXZITmRndHN2T2xaeXh5Qk5Nc1FhOHRHWHNB?= =?utf-8?B?cGtoN0EzMzkzVDJ6TTVOalpzWDJ0dTB0Qm84MDRiYVBneEN5VEZINGU0ZVEv?= =?utf-8?B?UHdPV05zWSsrYkZSZmlXdFQwaTRHVWQvcUx2cEM1dlNrdm94L2pnQUdaOVZ4?= =?utf-8?B?d2pGVzBlSWZIWTRGUVdkNTlQRm5WZXNMYWdNY01TQ3BocXd0blk5aVRSdmJ1?= =?utf-8?B?d21rRkNyMjdzYmJwNWRydG5mcmtOelNocXNRNlRKUkZFNWRYOXZmdndJL3J1?= =?utf-8?B?WW9yakg0U2VnVFUwVXBGb2ZnZVpjOVNlVE53OGo0akRMMStJV3dsMStIYzBF?= =?utf-8?B?VUxZQ0NlRmFFSHhlTTlTaEFOQmNZcTJxNi9jQnFmeGhLTXVORjVCMEhRZ1Fu?= =?utf-8?B?MDRQZEgxUHZJeUxud2RDRWZzeTJwSmZJRHBwVXhyM3dQYzljaW9TSWdQL29N?= =?utf-8?B?TElNcGJoTDFhN1dXYStRVlQyMTlBWStoZ0o0SGQ2emVRVUl1MVRsU3ByWEFX?= =?utf-8?B?WEpQRFhBMkRhOGZGaGJrcjExaWtFbkFOdG5TYy9jY3hlNkZtaks2cjYrN2J3?= =?utf-8?B?eXdQNUN1dE00cmlTRkRGYUdNZE5yOEpNQjBPaTRSN01wRW5aV2xXYlNaMWxo?= =?utf-8?B?YzkwY1oyZStka2QrQk5zaUM1T0dIaUc4QWs0L2M5MDFUQTNDdEhiY3J1TWpZ?= =?utf-8?B?YzdhWm01UW1BcnBMM1Rsa3JucVJIQVJwa3EwaWZzbUFwVUNscy9OZHJvem5V?= =?utf-8?B?NXBBZlFZMTZPR1NPb05BUUxtQmxxQmJJQVpvQi93RWlFanIxUi8zWHZQcVhU?= =?utf-8?B?dGJjTXA3b29GQnhpN3BDY0JveHVYYTIreU5LZU45bkNwTVJNRldrZXFFZUt5?= =?utf-8?B?d08xMmREOVQveDFCRlRJM1JKeGwrMjY5aVhBalFUSzZ5UHlQQ2J3Ymg3Vkgw?= =?utf-8?B?WEZVOUUzTWVuWnY0U0FaL2R4eExkdC93OXBYSkVoQkxaYkh5RnZTUmkvb1FC?= =?utf-8?B?d2NVdVNJaXk1dTV5alp4MytvNFY2MDJxdnpxMzRkZEpDRU1VOEVxWDUyeWFB?= =?utf-8?B?S0wrN3FHa0ZNc052R0FSU3dJM1hmUkFTb1dpcE52R2J3SnNRZWtoT1RMOW1H?= =?utf-8?B?cnhiL0ZiUnM3S1h1R1crUlBxT3lsUDdVOUpyby9xWmRkdDJWTDl0b2R3dm1N?= =?utf-8?B?dlF5eWNtaE5iczdoMnFQZ3FObHd5R00yVlhuS0NGK0dMMnQvYVFyc0R5aTBh?= =?utf-8?B?eUZJa2x1c05vQTJxYklTZW9abWs4T2ZBWTVoREs1UU1teTY1cWdtME9XTGtM?= =?utf-8?Q?VLpYdqK/2ZFEXz1rmont1/FqBPv8lmS3aRFbp/I?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43666C3BEDECF2BFA6473FDBB56C9MN2PR11MB4366namp_" 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: 82480662-52ec-47a1-e467-08d8e7d77b1e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2021 17:26:34.1332 (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: Uct3msIwIyk5DYqzMNaGxqhUf2S9NAKJGkG+4a0/WjVQbkXBF+8BXFQwRgMpo7ae4A71YbPt5DYv4O+EnmxVpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4613 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 17:26:47 -0000 --_000_MN2PR11MB43666C3BEDECF2BFA6473FDBB56C9MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KRllJLCB0aGlzIGlzc3VlIHdhcyBkaXNjdXNzZWQgaW4gdGhlIE5ldG1vZCBz ZXNzaW9uIG9uIEZyaWRheS4NCg0KTXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIGNoYWlycyBwb3Np dGlvbiBpcyAoaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1nbExjcFE5a3B2MCwgc3Rh cnRzIGF0IDYuMTApIGlzIDogQXMgbG9uZyBhcyB0aGUgV0cgaXMgY29waWVkIG9uIG15IEFEIHJl dmlldyBjb21tZW50cyBhbmQgcHJvcG9zZWQgY2hhbmdlcyAod2hpY2ggdGhleSBoYXZlIGJlZW4p LCB0aGVuIHRoZSBXRyBoYXMgdGhlIG9wcG9ydHVuaXR5IHRvIGNvbW1lbnQgb3Igb2JqZWN0IHRv IHRoZSBwcm9wb3NlZCBjaGFuZ2VzIGlmIHRoZXkgd2lzaCwgYW5kIGxhY2sgb2YgY29tbWVudCBm cm9tIHRoZSBXRyBpcyB0YWtlbiBhcyBhIHRhY2l0IGFjY2VwdGFuY2Ugb2YgdGhlIHByb3Bvc2Vk IGNoYW5nZXMuDQoNCkdpdmVuIHRoaXMsIEkgdGhpbmsgdGhhdCB0aGUgYXV0aG9ycyBjYW4gYXBw bHkgdGhlIG1hcmsgdXBzIGJhc2VkIG9uIHRoZSBhZ3JlZW1lbnRzIGJlbG93IChhbmQgbXkgb3Jp Z2luYWwgbml0cyksIHJlcHVibGlzaCwgYW5kIHRoZW4gaG9wZWZ1bGx5IHdlIHNob3VsZCBiZSBy ZWFkeSB0byBwcm9ncmVzcyB0aGlzIHRvIElFVEYgTEMuDQoNClJlZ2FyZHMsDQpSb2INCg0KDQpG cm9tOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NClNlbnQ6IDA1IE1hcmNoIDIw MjEgMTg6NDYNClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQpD YzogTmV0TW9kIFdHIENoYWlycyA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz47IGpvZWwgamFlZ2ds aSA8am9lbGphQGdtYWlsLmNvbT47IGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0 Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEFEIHJldmlldyBvZiBkcmFmdC1p ZXRmLW5ldG1vZC1ubWRhLWRpZmYtMDcNCg0KDQoNCk9uIEZyaSwgTWFyIDUsIDIwMjEgYXQgMTA6 MTggQU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2ls dG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwNCg0KSeKAmW0gbm90IHN1cmUgd2hpY2gg b25lIHlvdSB0aGluayBpcyBzIGEgZGVzaWduIGNoYW5nZTogIERvIHlvdSBtZWFuIGlzc3VlIDMg b3IgaXNzdWUgNCBiZWxvdz8NCg0KSSBzZWUgdGhhdCBteSByZXNwb25zZSB0byBpc3N1ZSA0IG1h eSBub3QgaGF2ZSBiZWVuIGNsZWFyLCBzbyB0byBjbGFyaWZ5Og0KDQpCeSDigJxva2F54oCdLCBJ IG1lYW50LCB0aGF0IEkgYW0gb2theSB3aXRoIGhvdyBpdCBpcyB3cml0dGVuIGluIHRoZSBjdXJy ZW50IGRyYWZ0LiAgTXkgcHJlc3VtcHRpb24gaXMgdGhhdCB0aGlzIGNvdWxkIGJlIGFkZHJlc3Nl ZCBhcyBhIGZ1dHVyZSB2ZXJzaW9uIG9mIHRoZSBtb2R1bGUgaWYgdGhpcyB0dXJucyBvdXQgYmUg YW4gaXNzdWUsIG9yIHZlbmRvcnMgY2FuIGRlZmluZSB0aGVpciBvd24gYXVnbWVudGF0aW9uIGlm IG5lZWRlZC4NCg0KSWYgeW91IHRoaW5rIGlzc3VlIDMgaXMgYSBkZXNpZ24gY2hhbmdlIHRoYXQg cmVxdWlyZXMgV0cgY29uc2Vuc3VzIHRoYXQgSSB3aWxsIGxlYXZlIGl0IHRvIHRoZSBXRyBjaGFp cnMgdG8gZGVjaWRlIGlmIHRoZXkgd2lzaCB0byBpc3N1ZSBhIGNvbnNlbnN1cyBjYWxsIGZvciBp dC4NCg0KDQoNClRoZSBjaGFuZ2U6DQoNCiAgIEN1cnJlbnQ6IGRlZmF1bHQgaXMgdG8gaW5jbHVk ZSBvcmlnaW4gYXR0cmlidXRlcyBhbmQgY2xpZW50IGFkZHMgZXhjbHVkZS1vcmlnaW4gbGVhZiB0 byB0dXJuIHRoaXMgb2ZmDQogICBQcm9wb3NlZDogZGVmYXVsdCBpcyB0byBleGNsdWRlIG9yaWdp biBhdHRyaWJ1dGVzIGFuZCBjbGllbnQgYWRkcyByZXBvcnQtb3JpZ2luIGxlYWYgdG8gdHVybiB0 aGlzIG9uDQogICAgQWxzbywgcmVwb3J0LW9yaWdpbiBoYXMgYW4gaWYtZmVhdHVyZSBiZWNhdXNl IG9yaWdpbiBzdXBwb3J0IGluIE5NREEgaXMgb3B0aW9uYWwuDQoNCkkgaGF2ZSBubyBvYmplY3Rp b25zIHRvIHRoaXMgcHJvcG9zYWwuDQpNeSBwb2ludCBhbGwgYWxvbmcgaGFzIGJlZW4gdGhhdCB0 aGlzIGlzIG5vdCBteSBkZWNpc2lvbiB0byBtYWtlLCBpdCBpcyBhIFdHIGRlY2lzaW9uLg0KSXQg ZG9lcyBub3Qgc2VlbSB0aGF0IHRoZXJlIGFyZSBhbnkgb2JqZWN0aW9ucyB0byBtYWtpbmcgdGhp cyBjaGFuZ2UuDQoNCg0KUmVnYXJkcywNClJvYg0KDQoNCkFuZHkNCg0KDQpGcm9tOiBBbmR5IEJp ZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NClNl bnQ6IDA1IE1hcmNoIDIwMjEgMTY6MzYNClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRv bkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4NCkNjOiBqb2VsIGphZWdnbGkg PGpvZWxqYUBnbWFpbC5jb208bWFpbHRvOmpvZWxqYUBnbWFpbC5jb20+PjsgZHJhZnQtaWV0Zi1u ZXRtb2Qtbm1kYS1kaWZmLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1uZXRtb2Qtbm1k YS1kaWZmLmFsbEBpZXRmLm9yZz47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldG1vZC1ubWRhLWRp ZmYtMDcNCg0KDQoNCk9uIEZyaSwgTWFyIDUsIDIwMjEgYXQgNTo1OCBBTSBSb2IgV2lsdG9uIChy d2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3Jv dGU6DQpIaSBBbmR5LCBhdXRob3JzLA0KDQoNCg0KSSB0aGluayB5b3UgbWVhbiB0byBhZGRyZXNz IHRoaXMgdG8gdGhlIFdHIHNpbmNlIHRoZSByZWRlc2lnbiBpc3N1ZXMgbmVlZCBXRyBhcHByb3Zh bC4NCkkgaGF2ZSBubyBvYmplY3Rpb25zIHRvIGFueSBjaGFuZ2VzLg0KDQoNCkFuZHkNCg0KU29y cnkgZm9yIHRoZSBsb25nIGRlbGF5IGluIHJlcGx5aW5nLg0KDQpQbGVhc2Ugc2VlIFtSV10gaW5s aW5lIGJlbG93IOKApg0KDQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t PG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+Pg0KU2VudDogMzAgT2N0b2JlciAyMDIwIDAxOjQz DQpUbzogam9lbCBqYWVnZ2xpIDxqb2VsamFAZ21haWwuY29tPG1haWx0bzpqb2VsamFAZ21haWwu Y29tPj4NCkNjOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRv OnJ3aWx0b25AY2lzY28uY29tPj47IGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0Zi5vcmc+OyBu ZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBBRCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLTA3DQoNCg0KDQpPbiBUaHUsIE9j dCAyOSwgMjAyMCBhdCA2OjA5IFBNIGpvZWwgamFlZ2dsaSA8am9lbGphQGdtYWlsLmNvbTxtYWls dG86am9lbGphQGdtYWlsLmNvbT4+IHdyb3RlOg0KUm9iLA0KDQpUaGVzZSBzZWVtIGxpa2UgcmVh c29uYWJsZSBzdWdnZXN0aW9ucy4NCg0KTGV0cyBzZWUgd2hhdCB0aGUgYXV0aG9ycyBzYXkuDQoN ClRoYW5rcyBmb3IgdGhpcw0Kam9lbA0KDQpPbiBUaHUsIE9jdCAyOSwgMjAyMCBhdCA2OjQ3IEFN IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBj aXNjby5jb20+PiB3cm90ZToNCkhpLA0KDQpIZXJlIGlzIG15IEFEIHJldmlldyBmb3IgZHJhZnQt aWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLTA3LiAgQXBvbG9naWVzIGZvciB0aGUgZGVsYXkuDQoNClRo YW5rIHlvdSBmb3Igd3JpdGluZyB0aGlzIGRvY3VtZW50LCBJIHRoaW5rIHRoYXQgaXQgaXMgdXNl ZnVsLCBhbmQgbG9va3MgbGlrZSBpdCBpcyBpbiBnb29kIHNoYXBlLg0KDQoNCk1haW4gY29tbWVu dHM6DQoNCjEuIFNob3VsZCB0aGVyZSBiZSBhbnkgdGV4dCBhYm91dCBob3cgdG8gZmluZCBvdXQg d2hhdCBkYXRhc3RvcmVzIGFyZSBzdXBwb3J0ZWQgYnkgYSBkZXZpY2U/ICBFLmcuLCBwb2ludGlu ZyB0aGVtIHRvIGVpdGhlciBZQU5HIGxpYnJhcnksIG9yIHByb3RvY29sIHNwZWNpZmljIG1lY2hh bmlzbXMgaW4gdGhlIGNhc2Ugb2YgUkVTVENPTkYuDQoNCkRvIHlvdSBoYXZlIGEgc2VjdGlvbiBp biBtaW5kIGFuZCBzdWdnZXN0ZWQgdGV4dD8NCltSV10NClBlcmhhcHMgc29tZXdoZXJlIGluIHNl Y3Rpb24gNCwgZWl0aGVyIGFzIHBhcnQgb2YgdGhlIGRlc2NyaXB0aW9uIG9mIHNvdXJjZSwgb3Ig cGVyaGFwcyBiZWZvcmUgdGhlIHBhcmFtZXRlcnMgYXJlIGRlc2NyaWJlZC4NCg0KUHJvcG9zZWQg dGV4dDoNCuKAnEEgY2xpZW50IGNhbiBkaXNjb3ZlciB3aGljaCBkYXRhc3RvcmVzIGEgc2VydmVy IHN1cHBvcnRzIGJ5IHJlYWRpbmcgWUFORyBsaWJyYXJ5IFtSRkMgODUyNV0gZnJvbSB0aGUgb3Bl cmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLuKAnQ0KDQoNCg0KMi4gSXQgbWlnaHQgYmUgaGVscGZ1 bCB0byBhZGQgYSBjb21tZW50IGFib3V0IHBvdGVudGlhbCBpc3N1ZXMgdGhhdCBjb3VsZCBhcmlz ZSBieSBjb21wYXJpbmcgPHJ1bm5pbmc+IHRvIDxvcGVyYXRpb25hbD4sIGkuZS4sIGFkZGl0aW9u YWwgZGlmZmVyZW5jZXMgY291bGQgYmUgcmVwb3J0ZWQgZHVlIHRvIGluYWN0aXZlIGNvbmZpZ3Vy YXRpb24gYW5kIHRlbXBsYXRlIHByb2Nlc3NpbmcgYmV0d2VlbiA8cnVubmluZz4gYW5kIDxvcGVy YXRpb25hbD4uDQoNCkRvIHlvdSBoYXZlIGEgc2VjdGlvbiBpbiBtaW5kIGFuZCBzdWdnZXN0ZWQg dGV4dD8NCllvdSBtZWFuIGlmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIDxydW5uaW5n PiBhbmQgPGludGVuZGVkPg0KdGhlbiBhIGRpZmYgYmV0d2VlbiA8cnVubmluZz4gYW5kIDxvcGVy YXRpb25hbD4gd2lsbCBub3QgYmUgdGhlIHNhbWUNCmFzIGEgZGlmZiBiZXR3ZWVuIDxpbnRlbmRl ZD4gYW5kIDxvcGVyYXRpb25hbD4uPw0KDQpbUlddDQpNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBp ZiB5b3UgaGF2ZSB0ZW1wbGF0ZSBleHBhbnNpb24gdGhlbiBjb21wYXJpbmcgPHJ1bm5pbmc+IGFu ZCA8b3BlcmF0aW9uYWw+IG1heSBub3QgcmVhbGx5IGdpdmUgYSBtZWFuaW5nZnVsIGNvbXBhcmlz b24sIHNpbmNlIDxydW5uaW5nPiBpcyBwcmUtdGVtcGxhdGUgZXhwYW5zaW9uLCBhbmQgPG9wZXJh dGlvbmFsPiAoYW5kIDxpbnRlbmRlZD4pIGFyZSBib3RoIHBvc3QgdGVtcGxhdGUgZXhwYW5zaW9u Lg0KDQpJIHdvdWxkIHN1Z2dlc3QgcHV0dGluZyBzb21lIHRleHQgaW4gc2VjdGlvbiA0IG9yIHBl cmhhcHMgdGhlIFlBTkcgbW9kdWxlLg0KDQpQZXJoYXBzIHNvbWUgdGV4dCwgc29tZXRoaW5nIGxp a2U6DQoNCiAg4oCcQ2xpZW50cyBzaG91bGQgdG8gYmUgYXdhcmUgdGhhdCBjb21wYXJpbmcgPHJ1 bm5pbmc+IHRvIDxvcGVyYXRpb25hbD4gd2lsbCByZXBvcnQgZGlmZmVyZW5jZXMgZHVlIHRvIGFu eSBjb25maWd1cmF0aW9uIHRyYW5zZm9ybWF0aW9uIChlLmcuLCBpbmFjdGl2ZSBjb25maWd1cmF0 aW9uLCBvciB0aGUgZXhwYW5zaW9uIG9mIHRlbXBsYXRlcykgYmV0d2VlbiB0aGUgPHJ1bm5pbmc+ IGFuZCA8aW50ZW5kZWQ+IGRhdGFzdG9yZXMuICBJbiB0aGVzZSBzY2VuYXJpb3MsIGNsaWVudHMg bWF5IGdldCBhIG1vcmUgdXNlZnVsIHJlc3VsdCBieSBjb21wYXJpbmcgdGhlIDxpbnRlbmRlZD4g YW5kIDxvcGVyYXRpb25hbD4gZGF0YXN0b3JlcyBpbnN0ZWFkLuKAnQ0KDQoNCg0KDQozLiBJIHdv dWxkIHByZWZlciBpZiAnZXhjbHVkZT1vcmlnaW4nIHdhcyBpbiB0aGUgcmV2ZXJzZSBzZW5zZSBh bmQgcGVyaGFwcyBjYWxsZWQgJ3JlcG9ydC1vcmlnaW4nIGluc3RlYWQuICBXaXRoIHRoZSByZXZl cnNlIHNlbnNlIGl0IHNlZW1zIHRvIGJlIHNhZmVyIGlmIG5ldyBkYXRhc3RvcmVzIGFyZSBkZWZp bmVkLCB3aGVyZSBvdGhlcndpc2UgdGhlIGJlaGF2aW91ciBjb3VsZCBlbmQgYmVpbmcgdW5kZXIg c3BlY2lmaWVkLg0KDQoNCklNTyB0aGUgV0cgYWxyZWFkeSBkZXNpZ25lZCB0aGUgZmVhdHVyZXMg c28gaWYgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGhhdmUgY2hhbmdlZA0KdGhlbiB0aGUg ZHJhZnQgc2hvdWxkIGdvIGJhY2sgdG8gdGhlIFdHIGZvciBjaGFuZ2VzIGFuZCBuZXcgV0cgY29u c2Vuc3VzIGNhbGxzLg0KW1JXXQ0KDQpJIGRvbuKAmXQgc2VlIHRoaXMgYXMgcmVhbGx5IGNoYW5n aW5nIHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cywgYnV0IGp1c3QgY2hhbmdpbmcgdGhlIGRl ZmF1bHQgc2Vuc2UgYW5kIG5hbWUgb2YgYW4gQVBJIHBhcmFtZXRlci4gIEFsdGhvdWdoLCBnaXZl biBteSBjb21tZW50cyBiZWxvdyDigJx3aXRoLW9yaWdpbuKAnSBtaWdodCBiZSBiZXR0ZXIgdGhh biDigJxyZXBvcnQtb3JpZ2lu4oCdLg0KDQpJbiBSRkMgODUyNiwgdGhlIOKAnHdpdGgtb3JpZ2lu 4oCdIHBhcmFtZXRlciBpcyBvZmYgYnkgZGVmYXVsdCwgYW5kIG9yaWdpbiBtZXRhZGF0YSBpcyBv bmx5IGluY2x1ZGVkIHdoZW4gdGhlIHBhcmFtZXRlciBpcyBpbmNsdWRlZC4gIFRoaXMga2V5d29y ZCBpcyBhbHNvIHVuZGVyIGEgZmVhdHVyZS4NCg0KU28sIGNoYW5naW5nIHRoZSBwYXJhbWV0ZXIg bmFtZSB0byDigJx3aXRoLW9yaWdpbuKAnSBhbmQgcHV0dGluZyBpdCB1bmRlciDigJ1pZi1mZWF0 dXJlIGlldGYtbmV0Y29uZi1ubWRhOm9yaWdpbuKAnSwgYW5kIG1ha2luZyB0aGUgZGVmYXVsdCBv ZmYsIHdvdWxkIG1ha2UgdGhlIGRlZmluaXRpb24gbW9yZSBjb25zaXN0ZW50IHdpdGggUkZDIDg1 MjYuDQoNCg0KDQo0LiBTaG91bGQgdGhlcmUgYmUgYW4gb3B0aW9uIHRvIGZpbHRlciBvbiBvcmln aW4gbWV0YWRhdGE/ICBFLmcuLCBvbmx5IGluY2x1ZGUgdmFsdWVzIHRoYXQgY29tZSBmcm9tIGlu dGVuZGVkLiAgT3RoZXJ3aXNlLCB0aGluZ3MgbGlrZSBJUCBhZGRyZXNzZXMgbGVhcm5lZCBmcm9t IERIQ1AgbWF5IGFsd2F5cyB0dXJuIHVwIGFzIGRpZmZlcmVuY2VzLg0KDQpJTU8gdGhlIFdHIGFs cmVhZHkgZGVzaWduZWQgdGhlIGZlYXR1cmVzIHNvIGlmIHRoZSBmdW5jdGlvbmFsIHJlcXVpcmVt ZW50cyBoYXZlIGNoYW5nZWR0aGVuIHRoZSBkcmFmdCBzaG91bGQgZ28gYmFjayB0byB0aGUgV0cg Zm9yIGNoYW5nZXMgYW5kIG5ldyBXRyBjb25zZW5zdXMgY2FsbHMuDQoNCltSV10NCg0KT2theS4N Cg0KUmVnYXJkcywNClJvYg0KDQoNCg0KNS4gSSdtIG5vdCB0aGF0IGtlZW4gb24gdGhlICJQb3Nz aWJsZSBGdXR1cmUgRXh0ZW5zaW9ucyIgc2VjdGlvbiBvZiBhbiBSRkMuICBQZXJzb25hbGx5LCBJ IHdvdWxkIHByZWZlciB0aGF0IHRoaXMgc2VjdGlvbiBpcyBkZWxldGVkLCBidXQgaWYgeW91IHdp c2ggdG8gcmV0YWluIGl0LCB0aGVuIHBsZWFzZSBjYW4geW91IG1vdmUgaXQgdG8gYW4gYXBwZW5k aXguDQoNCk9LIHdpdGggbWUgdG8gcmVtb3ZlIGl0DQoNCg0KDQpBbmR5DQoNCg0KDQpJJ3ZlIGFs c28gaW5jbHVkZWQgc29tZSBtaW5vciBjb21tZW50cyBpbmxpbmUgYmVsb3csIGFuZCBzb21lIG5p dHMgYXQgdGhlIGVuZDoNCg0KICAgIEFic3RyYWN0DQoNCiAgICAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYW4gUlBDIG9wZXJhdGlvbiB0byBjb21wYXJlIG1hbmFnZW1lbnQNCiAgICAgICBkYXRh c3RvcmVzIHRoYXQgY29tcGx5IHdpdGggdGhlIE5NREEgYXJjaGl0ZWN0dXJlLg0KDQpUaGUgYWJz dHJhY3QgaXMgcGVyaGFwcyBzb21ld2hhdCB0ZXJzZS4gIFBlcmhhcHM6DQoNCiAgICBUaGlzIGRv Y3VtZW50IGRlZmluZXMgYSBZQU5HIFJQQyBvcGVyYXRpb24gdG8gY29tcGFyZSB0aGUNCiAgICBj b250ZW50cyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZGF0YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRo DQogICAgdGhlIE5NREEgYXJjaGl0ZWN0dXJlIGFuZCByZXR1cm4gdGhlIGRpZmZlcmVuY2VzIGlu IHRoZQ0KICAgIFlBTkctUGF0Y2ggZm9ybWF0Lg0KDQoNCiAgICAxLiAgSW50cm9kdWN0aW9uDQoN CiAgICAgICBUaGUgcmV2aXNlZCBOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVj dHVyZSAoTk1EQSkNCiAgICAgICBbUkZDODM0Ml0gaW50cm9kdWNlcyBhIHNldCBvZiBuZXcgZGF0 YXN0b3JlcyB0aGF0IGVhY2ggaG9sZCBZQU5HLQ0KICAgICAgIGRlZmluZWQgZGF0YSBbUkZDNzk1 MF0gYW5kIHJlcHJlc2VudCBhIGRpZmZlcmVudCAidmlld3BvaW50IiBvbiB0aGUNCiAgICAgICBk YXRhIHRoYXQgaXMgbWFpbnRhaW5lZCBieSBhIHNlcnZlci4gIE5ldyBZQU5HIGRhdGFzdG9yZXMg dGhhdCBhcmUNCiAgICAgICBpbnRyb2R1Y2VkIGluY2x1ZGUgPGludGVuZGVkPiwgd2hpY2ggY29u dGFpbnMgdmFsaWRhdGVkIGNvbmZpZ3VyYXRpb24NCiAgICAgICBkYXRhIHRoYXQgYSBjbGllbnQg YXBwbGljYXRpb24gaW50ZW5kcyB0byBiZSBpbiBlZmZlY3QsIGFuZA0KICAgICAgIDxvcGVyYXRp b25hbD4sIHdoaWNoIGNvbnRhaW5zIGF0IGxlYXN0IGNvbmNlcHR1YWxseSBvcGVyYXRpb25hbCBz dGF0ZQ0KICAgICAgIGRhdGEgKHN1Y2ggYXMgc3RhdGlzdGljcykgYXMgd2VsbCBhcyBjb25maWd1 cmF0aW9uIGRhdGEgdGhhdCBpcw0KICAgICAgIGFjdHVhbGx5IGluIGVmZmVjdC4NCg0KSSB3b3Vs ZCBzdWdnZXN0IGRlbGV0aW5nICJhdCBsZWFzdCBjb25jZXB0dWFsbHkiLCBzaW5jZSB0aGUgPG9w ZXJhdGlvbmFsPg0KZGF0YXN0b3JlIGRvZXMgY29udGFpbiBhbGwgb3BlcmF0aW9uYWwgc3RhdGUs IGJ1dCBpdCBtYXkgYmUgaW1wbGVtZW50ZWQgYXMgYSB2aXJ0dWFsIGNvbnN0cnVjdCB0aGF0IHNw YW5zIG11bHRpcGxlIG5vZGVzIChlLmcuLCBsaW5lY2FyZHMpIGFuZCBwcm9jZXNzZXMuDQoNCg0K ICAgICAgIE5NREEgaW50cm9kdWNlcyBpbiBlZmZlY3QgYSBjb25jZXB0IG9mICJsaWZlY3ljbGUi IGZvciBtYW5hZ2VtZW50DQogICAgICAgZGF0YSwgYWxsb3dpbmcgdG8gY2xlYXJseSBkaXN0aW5n dWlzaCBiZXR3ZWVuIGRhdGEgdGhhdCBpcyBwYXJ0IG9mIGENCiAgICAgICBjb25maWd1cmF0aW9u IHRoYXQgd2FzIHN1cHBsaWVkIGJ5IGEgdXNlciwgY29uZmlndXJhdGlvbiBkYXRhIHRoYXQNCiAg ICAgICBoYXMgYWN0dWFsbHkgYmVlbiBzdWNjZXNzZnVsbHkgYXBwbGllZCBhbmQgdGhhdCBpcyBw YXJ0IG9mIHRoZQ0KICAgICAgIG9wZXJhdGlvbmFsIHN0YXRlLCBhbmQgb3ZlcmFsbCBvcGVyYXRp b25hbCBzdGF0ZSB0aGF0IGluY2x1ZGVzIGJvdGgNCiAgICAgICBhcHBsaWVkIGNvbmZpZ3VyYXRp b24gZGF0YSBhcyB3ZWxsIGFzIHN0YXR1cyBhbmQgc3RhdGlzdGljcy4NCg0KImFsbG93aW5nIHRv IGNsZWFybHkgZGlzdGluZ3Vpc2giID0+IGRpc3Rpbmd1aXNoaW5nIg0KInN0YXR1cyBhbmQgc3Rh dGlzdGljcyIgPT4gInN0YXR1cyBpbmZvcm1hdGlvbiBhbmQgc3RhdGlzdGljcyINCg0KDQogICAg ICAgQXMgYSByZXN1bHQsIGRhdGEgZnJvbSB0aGUgc2FtZSBtYW5hZ2VtZW50IG1vZGVsIGNhbiBi ZSByZWZsZWN0ZWQgaW4NCiAgICAgICBtdWx0aXBsZSBkYXRhc3RvcmVzLiAgQ2xpZW50cyBuZWVk IHRvIHNwZWNpZnkgdGhlIHRhcmdldCBkYXRhc3RvcmUgdG8NCiAgICAgICBiZSBzcGVjaWZpYyBh Ym91dCB3aGljaCB2aWV3cG9pbnQgb2YgdGhlIGRhdGEgdGhleSB3YW50IHRvIGFjY2Vzcy4NCiAg ICAgICBUaGlzIHdheSwgYW4gYXBwbGljYXRpb24gY2FuIGRpZmZlcmVudGlhdGUgd2hldGhlciB0 aGV5IGFyZSAoZm9yDQogICAgICAgZXhhbXBsZSkgaW50ZXJlc3RlZCBpbiB0aGUgY29uZmlndXJh dGlvbiB0aGF0IGhhcyBiZWVuIGFwcGxpZWQgYW5kIGlzDQogICAgICAgYWN0dWFsbHkgaW4gZWZm ZWN0LCBvciBpbiB0aGUgY29uZmlndXJhdGlvbiB0aGF0IHdhcyBzdXBwbGllZCBieSBhDQogICAg ICAgY2xpZW50IGFuZCB0aGF0IGlzIHN1cHBvc2VkIHRvIGJlIGluIGVmZmVjdC4NCg0KUGVyaGFw cyByZXdvcmQgdGhlIGxhc3Qgc2VudGVuY2UgdG8gbWF0Y2ggdGhlIGxvZ2ljYWwgZGF0YSBmbG93 IGluIHRoZSBzZXJ2ZXI6DQoNCiAgIEZvciBleGFtcGxlLCBhIGNsaWVudCBhcHBsaWNhdGlvbiBj YW4gZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZXkgYXJlDQogICBpbnRlcmVzdGVkIGluIHRoZSBj b25maWd1cmF0aW9uIHN1cHBsaWVkIHRvIGEgc2VydmVyIGFuZCB0aGF0IGlzDQogICBzdXBwb3Nl ZCB0byBiZSBpbiBlZmZlY3QsIG9yIHRoZSBjb25maWd1cmF0aW9uIHRoYXQgaGFzIGJlZW4gYXBw bGllZCBhbmQgaXMNCiAgIGFjdHVhbGx5IGluIGVmZmVjdCBvbiB0aGUgc2VydmVyLg0KDQoNCiAg ICAgICBXaGVuIGNvbmZpZ3VyYXRpb24gdGhhdCBpcyBpbiBlZmZlY3QgaXMgZGlmZmVyZW50IGZy b20gY29uZmlndXJhdGlvbg0KICAgICAgIHRoYXQgd2FzIGFwcGxpZWQsIG1hbnkgaXNzdWVzIGNh biByZXN1bHQuICBJdCBiZWNvbWVzIG1vcmUgZGlmZmljdWx0DQogICAgICAgdG8gb3BlcmF0ZSB0 aGUgbmV0d29yayBwcm9wZXJseSBkdWUgdG8gbGltaXRlZCB2aXNpYmlsaXR5IG9mIGFjdHVhbA0K ICAgICAgIHN0YXR1cyB3aGljaCBtYWtlcyBpdCBtb3JlIGRpZmZpY3VsdCB0byBhbmFseXplIGFu ZCB1bmRlcnN0YW5kIHdoYXQNCiAgICAgICBpcyBnb2luZyBvbiBpbiB0aGUgbmV0d29yay4gIFNl cnZpY2VzIG1heSBiZSBuZWdhdGl2ZWx5IGFmZmVjdGVkIChmb3INCiAgICAgICBleGFtcGxlLCBi cmVha2luZyBhIHNlcnZpY2UgaW5zdGFuY2UgcmVzdWx0aW5nIGluIHNlcnZpY2UgaXMgbm90DQog ICAgICAgcHJvcGVybHkgZGVsaXZlcmVkIHRvIGEgY3VzdG9tZXIpIGFuZCBuZXR3b3JrIHJlc291 cmNlcyBiZQ0KICAgICAgIG1pc2FsbG9jYXRlZC4NCg0KUGVyaGFwcyBjaGFuZ2UgImFjdHVhbCBz dGF0dXMiIHRvICJhY3R1YWwgb3BlcmF0aW9uYWwgc3RhdHVzIi4NCg0KSSBhbHNvIHN1Z2dlc3Qg Y2hhbmdpbmcgdGhlIGxhc3Qgc2VudGVuY2UgdG86DQoNCiAgICBTZXJ2aWNlcyBtYXkgYmUgbmVn YXRpdmVseSBhZmZlY3RlZCAoZS5nLiwgZGVncmFkaW5nIG9yIGJyZWFraW5nIGEgY3VzdG9tZXIg c2VydmljZSkgb3IgbmV0d29yayByZXNvdXJjZXMgbWF5IGJlIG1pc2FsbG9jYXRlZC4NCg0KDQog ICAgICAgIDMuIERlZmluaXRpb25zOg0KDQpJdCBzaG91bGQgcHJvYmFibHkgZGVmaW5lIHRoYXQg PGludGVuZGVkPiwgPG9wZXJhdGlvbmFsPiwgKGFuZCBwZXJoYXBzIDxydW5uaW5nPikgYXJlIHVz ZWQgdG8gaW5kaWNhdGUgbmFtZXMgb2YgZGF0YXN0b3Jlcy4NCg0KSXQgc2hvdWxkIGFsc28gZXhw bGFpbiB0aGF0IDxjb21wYXJlPiBpcyB1c2VkIGFzIHRoZSBuYW1lIG9mIGEgWUFORyBSUEMuDQoN Cg0KICAgIDQuICBEYXRhIE1vZGVsIE92ZXJ2aWV3DQoNCiAgICAgICBBdCB0aGUgY29yZSBvZiB0 aGUgc29sdXRpb24gaXMgYSBuZXcgbWFuYWdlbWVudCBvcGVyYXRpb24sIDxjb21wYXJlPiwNCiAg ICAgICB0aGF0IGFsbG93cyB0byBjb21wYXJlIHR3byBkYXRhc3RvcmVzIGZvciB0aGUgc2FtZSBk YXRhLg0KDQpTdWdnZXN0IHJld29yZGluZyB0aGlzIGZpcnN0IHNlbnRlbmNlIHRvOg0KDQogIFRo ZSBjb3JlIG9mIHRoZSBzb2x1dGlvbiBpcyBhIG5ldyBtYW5hZ2VtZW50IG9wZXJhdGlvbiwgPGNv bXBhcmU+LA0KICB0aGF0IGNvbXBhcmVzIHRoZSBkYXRhIHRyZWUgY29udGVudHMgb2YgdHdvIGRh dGFzdG9yZXMuDQoNCiAgICAgICBvICB0YXJnZXQ6IFRoZSB0YXJnZXQgaWRlbnRpZmllcyB0aGUg ZGF0YXN0b3JlIHRvIGNvbXBhcmUgYWdhaW5zdCB0aGUNCiAgICAgICAgICBzb3VyY2UuDQoNClN1 Z2dlc3QgYWRkaW5nIGFuIGV4YW1wbGUgIiwgZS5nLiwgPG9wZXJhdGlvbmFsPi4iDQoNCiAgICAg ICBvICBmaWx0ZXItc3BlYzogVGhpcyBpcyBhIGNob2ljZSBiZXR3ZWVuIGRpZmZlcmVudCBmaWx0 ZXIgY29uc3RydWN0cw0KICAgICAgICAgIHRvIGlkZW50aWZ5IHRoZSBwb3J0aW9ucyBvZiB0aGUg ZGF0YXN0b3JlIHRvIGJlIHJldHJpZXZlZC4gIEl0DQogICAgICAgICAgYWN0cyBhcyBhIG5vZGUg c2VsZWN0b3IgdGhhdCBzcGVjaWZpZXMgd2hpY2ggZGF0YSBub2RlcyBhcmUgd2l0aGluDQogICAg ICAgICAgdGhlIHNjb3BlIG9mIHRoZSBjb21wYXJpc29uIGFuZCB3aGljaCBub2RlcyBhcmUgb3V0 c2lkZSB0aGUgc2NvcGUNCg== --_000_MN2PR11MB43666C3BEDECF2BFA6473FDBB56C9MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GWUksIHRoaXMgaXNz dWUgd2FzIGRpc2N1c3NlZCBpbiB0aGUgTmV0bW9kIHNlc3Npb24gb24gRnJpZGF5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5N eSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgY2hhaXJzIHBvc2l0aW9uIGlzICg8YSBocmVmPSJodHRw czovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PWdsTGNwUTlrcHYwIj5odHRwczovL3d3dy55b3V0 dWJlLmNvbS93YXRjaD92PWdsTGNwUTlrcHYwPC9hPiwgc3RhcnRzIGF0IDYuMTApIGlzIDogQXMg bG9uZyBhcyB0aGUgV0cgaXMgY29waWVkDQogb24gbXkgQUQgcmV2aWV3IGNvbW1lbnRzIGFuZCBw cm9wb3NlZCBjaGFuZ2VzICh3aGljaCB0aGV5IGhhdmUgYmVlbiksIHRoZW4gdGhlIFdHIGhhcyB0 aGUgb3Bwb3J0dW5pdHkgdG8gY29tbWVudCBvciBvYmplY3QgdG8gdGhlIHByb3Bvc2VkIGNoYW5n ZXMgaWYgdGhleSB3aXNoLCBhbmQgbGFjayBvZiBjb21tZW50IGZyb20gdGhlIFdHIGlzIHRha2Vu IGFzIGEgdGFjaXQgYWNjZXB0YW5jZSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R2l2 ZW4gdGhpcywgSSB0aGluayB0aGF0IHRoZSBhdXRob3JzIGNhbiBhcHBseSB0aGUgbWFyayB1cHMg YmFzZWQgb24gdGhlIGFncmVlbWVudHMgYmVsb3cgKGFuZCBteSBvcmlnaW5hbCBuaXRzKSwgcmVw dWJsaXNoLCBhbmQgdGhlbiBob3BlZnVsbHkgd2Ugc2hvdWxkIGJlIHJlYWR5IHRvIHByb2dyZXNz IHRoaXMgdG8gSUVURiBMQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5keSBCaWVybWFu ICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMDUgTWFyY2gg MjAyMSAxODo0Njxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0 b25AY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0TW9kIFdHIENoYWlycyAmbHQ7bmV0 bW9kLWNoYWlyc0BpZXRmLm9yZyZndDs7IGpvZWwgamFlZ2dsaSAmbHQ7am9lbGphQGdtYWlsLmNv bSZndDs7IGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0Zi5vcmc7IG5ldG1vZEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bmV0bW9kLW5tZGEtZGlmZi0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1hciA1LCAyMDIxIGF0IDEwOjE4IEFNIFJvYiBX aWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3 aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQW5keSw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIG5vdCBzdXJlIHdoaWNoIG9uZSB5b3Ug dGhpbmsgaXMgcyBhIGRlc2lnbiBjaGFuZ2U6Jm5ic3A7IERvIHlvdSBtZWFuIGlzc3VlIDMgb3Ig aXNzdWUgNCBiZWxvdz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgc2VlIHRoYXQgbXkg cmVzcG9uc2UgdG8gaXNzdWUgNCBtYXkgbm90IGhhdmUgYmVlbiBjbGVhciwgc28gdG8gY2xhcmlm eTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ5IOKAnG9rYXnigJ0sIEkgbWVhbnQsIHRo YXQgSSBhbSBva2F5IHdpdGggaG93IGl0IGlzIHdyaXR0ZW4gaW4gdGhlIGN1cnJlbnQgZHJhZnQu Jm5ic3A7IE15IHByZXN1bXB0aW9uIGlzIHRoYXQgdGhpcyBjb3VsZCBiZSBhZGRyZXNzZWQgYXMg YSBmdXR1cmUgdmVyc2lvbiBvZiB0aGUgbW9kdWxlIGlmIHRoaXMgdHVybnMgb3V0DQogYmUgYW4g aXNzdWUsIG9yIHZlbmRvcnMgY2FuIGRlZmluZSB0aGVpciBvd24gYXVnbWVudGF0aW9uIGlmIG5l ZWRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHlvdSB0aGluayBpc3N1ZSAzIGlz IGEgZGVzaWduIGNoYW5nZSB0aGF0IHJlcXVpcmVzIFdHIGNvbnNlbnN1cyB0aGF0IEkgd2lsbCBs ZWF2ZSBpdCB0byB0aGUgV0cgY2hhaXJzIHRvIGRlY2lkZSBpZiB0aGV5IHdpc2ggdG8gaXNzdWUg YSBjb25zZW5zdXMgY2FsbCBmb3IgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNoYW5nZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO0N1cnJlbnQ6IGRlZmF1bHQgaXMgdG8gaW5jbHVkZSBvcmlnaW4gYXR0cmlidXRlcyBh bmQgY2xpZW50IGFkZHMgZXhjbHVkZS1vcmlnaW4gbGVhZiB0byB0dXJuIHRoaXMgb2ZmPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7UHJvcG9zZWQ6IGRlZmF1bHQgaXMgdG8gZXhjbHVkZSBvcmlnaW4gYXR0cmlidXRlcyBhbmQg Y2xpZW50IGFkZHMgcmVwb3J0LW9yaWdpbiBsZWFmIHRvIHR1cm4gdGhpcyBvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBB bHNvLCByZXBvcnQtb3JpZ2luIGhhcyBhbiBpZi1mZWF0dXJlIGJlY2F1c2Ugb3JpZ2luIHN1cHBv cnQgaW4gTk1EQSBpcyBvcHRpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIG5vIG9iamVjdGlvbnMgdG8gdGhpcyBwcm9wb3Nh bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15 IHBvaW50IGFsbCBhbG9uZyBoYXMgYmVlbiB0aGF0IHRoaXMgaXMgbm90IG15IGRlY2lzaW9uIHRv IG1ha2UsIGl0IGlzIGEgV0cgZGVjaXNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBkb2VzIG5vdCBzZWVtIHRoYXQgdGhlcmUgYXJlIGFu eSBvYmplY3Rpb25zIHRvIG1ha2luZyB0aGlzIGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Um9iPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5 QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0 Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDA1IE1hcmNoIDIwMjEgMTY6MzY8YnI+DQo8Yj5Ubzo8L2I+ IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBqb2VsIGphZWdnbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2VsamFAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+am9lbGphQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5kcmFmdC1pZXRmLW5ldG1vZC1ubWRhLWRpZmYuYWxsQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9 Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRt b2Qtbm1kYS1kaWZmLTA3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBNYXIgNSwgMjAyMSBhdCA1OjU4IEFNIFJv YiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBBbmR5LCBh dXRob3JzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgeW91IG1lYW4gdG8gYWRkcmVzcyB0aGlz IHRvIHRoZSBXRyBzaW5jZSB0aGUgcmVkZXNpZ24gaXNzdWVzIG5lZWQgV0cgYXBwcm92YWwuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2 ZSBubyBvYmplY3Rpb25zIHRvIGFueSBjaGFuZ2VzLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNv cnJ5IGZvciB0aGUgbG9uZyBkZWxheSBpbiByZXBseWluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlBsZWFzZSBzZWUgW1JXXSBpbmxpbmUgYmVsb3cg4oCmPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gQW5keSBCaWVybWFuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbmR5QHl1bWF3b3Jrcy5j b208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4g MzAgT2N0b2JlciAyMDIwIDAxOjQzPGJyPg0KPGI+VG86PC9iPiBqb2VsIGphZWdnbGkgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86am9lbGphQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIGxhbmc9IkVOLVVTIj5qb2VsamFAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJFTi1VUyI+cndpbHRvbkBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW5ldG1vZC1ubWRh LWRpZmYuYWxsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmRy YWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi5hbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLVVTIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEFEIHJldmlldyBv ZiBkcmFmdC1pZXRmLW5ldG1vZC1ubWRhLWRpZmYtMDc8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIE9jdCAyOSwg MjAyMCBhdCA2OjA5IFBNIGpvZWwgamFlZ2dsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2VsamFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJv YiwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZXNlIHNlZW0gbGlrZSByZWFzb25hYmxlIHN1Z2dlc3Rpb25zLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TGV0cyBzZWUgd2hhdCB0aGUgYXV0aG9ycyBzYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIHRoaXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+am9lbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgT2N0IDI5 LCAyMDIwIGF0IDY6NDcgQU0gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9Im1haWx0 bzpyd2lsdG9uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8 YnI+DQpIZXJlIGlzIG15IEFEIHJldmlldyBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZm LTA3LiZuYnNwOyBBcG9sb2dpZXMgZm9yIHRoZSBkZWxheS48YnI+DQo8YnI+DQpUaGFuayB5b3Ug Zm9yIHdyaXRpbmcgdGhpcyBkb2N1bWVudCwgSSB0aGluayB0aGF0IGl0IGlzIHVzZWZ1bCwgYW5k IGxvb2tzIGxpa2UgaXQgaXMgaW4gZ29vZCBzaGFwZS48YnI+DQo8YnI+DQo8YnI+DQpNYWluIGNv bW1lbnRzOjxicj4NCjxicj4NCjEuIFNob3VsZCB0aGVyZSBiZSBhbnkgdGV4dCBhYm91dCBob3cg dG8gZmluZCBvdXQgd2hhdCBkYXRhc3RvcmVzIGFyZSBzdXBwb3J0ZWQgYnkgYSBkZXZpY2U/Jm5i c3A7IEUuZy4sIHBvaW50aW5nIHRoZW0gdG8gZWl0aGVyIFlBTkcgbGlicmFyeSwgb3IgcHJvdG9j b2wgc3BlY2lmaWMgbWVjaGFuaXNtcyBpbiB0aGUgY2FzZSBvZiBSRVNUQ09ORi48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG8geW91IGhhdmUgYSBzZWN0aW9uIGluIG1p bmQgYW5kIHN1Z2dlc3RlZCB0ZXh0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48aT5bUlddDQo8L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48aT5QZXJoYXBzIHNvbWV3aGVyZSBpbiBzZWN0aW9uIDQsIGVpdGhlciBhcyBw YXJ0IG9mIHRoZSBkZXNjcmlwdGlvbiBvZiBzb3VyY2UsIG9yIHBlcmhhcHMgYmVmb3JlIHRoZSBw YXJhbWV0ZXJzIGFyZSBkZXNjcmliZWQuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+UHJvcG9zZWQgdGV4dDo8L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjE2LjVwdCI+DQo8Yj48aT7i gJxBIGNsaWVudCBjYW4gZGlzY292ZXIgd2hpY2ggZGF0YXN0b3JlcyBhIHNlcnZlciBzdXBwb3J0 cyBieSByZWFkaW5nIFlBTkcgbGlicmFyeSBbUkZDIDg1MjVdIGZyb20gdGhlIG9wZXJhdGlvbmFs IHN0YXRlIGRhdGFzdG9yZS7igJ08L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjIuIEl0IG1pZ2h0IGJlIGhlbHBmdWwgdG8gYWRkIGEgY29tbWVudCBhYm91dCBw b3RlbnRpYWwgaXNzdWVzIHRoYXQgY291bGQgYXJpc2UgYnkgY29tcGFyaW5nICZsdDtydW5uaW5n Jmd0OyB0byAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LCBpLmUuLCBhZGRpdGlvbmFsIGRpZmZlcmVuY2Vz IGNvdWxkIGJlIHJlcG9ydGVkIGR1ZSB0byBpbmFjdGl2ZQ0KIGNvbmZpZ3VyYXRpb24gYW5kIHRl bXBsYXRlIHByb2Nlc3NpbmcgYmV0d2VlbiAmbHQ7cnVubmluZyZndDsgYW5kICZsdDtvcGVyYXRp b25hbCZndDsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvIHlvdSBo YXZlIGEgc2VjdGlvbiBpbiBtaW5kIGFuZCBzdWdnZXN0ZWQgdGV4dD88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91IG1lYW4gaWYgdGhlcmUg YXJlIGRpZmZlcmVuY2VzIGJldHdlZW4gJmx0O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7aW50ZW5kZWQm Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PnRoZW4gYSBkaWZmIGJldHdlZW4gJmx0O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7b3BlcmF0aW9uYWwm Z3Q7IHdpbGwgbm90IGJlIHRoZSBzYW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPmFzIGEgZGlmZiBiZXR3ZWVuICZsdDtpbnRlbmRlZCZndDsg YW5kICZsdDtvcGVyYXRpb25hbCZndDsuPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PGk+W1JXXQ0KPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PGk+TXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgaWYgeW91IGhhdmUgdGVtcGxhdGUgZXhwYW5z aW9uIHRoZW4gY29tcGFyaW5nICZsdDtydW5uaW5nJmd0OyBhbmQgJmx0O29wZXJhdGlvbmFsJmd0 OyBtYXkgbm90IHJlYWxseSBnaXZlIGEgbWVhbmluZ2Z1bCBjb21wYXJpc29uLCBzaW5jZSAmbHQ7 cnVubmluZyZndDsgaXMgcHJlLXRlbXBsYXRlDQogZXhwYW5zaW9uLCBhbmQgJmx0O29wZXJhdGlv bmFsJmd0OyAoYW5kICZsdDtpbnRlbmRlZCZndDspIGFyZSBib3RoIHBvc3QgdGVtcGxhdGUgZXhw YW5zaW9uLjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxpPkkgd291bGQgc3VnZ2VzdCBwdXR0aW5nIHNvbWUgdGV4dCBpbiBzZWN0aW9uIDQgb3Ig cGVyaGFwcyB0aGUgWUFORyBtb2R1bGUuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+UGVyaGFwcyBzb21lIHRleHQsIHNvbWV0aGluZyBsaWtl Og0KPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+ Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PGk+Jm5ic3A7IOKAnENsaWVudHMgc2hvdWxkIHRvIGJlIGF3YXJlIHRoYXQgY29tcGFyaW5nICZs dDtydW5uaW5nJmd0OyB0byAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IHdpbGwgcmVwb3J0IGRpZmZlcmVu Y2VzIGR1ZSB0byBhbnkgY29uZmlndXJhdGlvbiB0cmFuc2Zvcm1hdGlvbiAoZS5nLiwgaW5hY3Rp dmUgY29uZmlndXJhdGlvbiwgb3IgdGhlDQogZXhwYW5zaW9uIG9mIHRlbXBsYXRlcykgYmV0d2Vl biB0aGUgJmx0O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7aW50ZW5kZWQmZ3Q7IGRhdGFzdG9yZXMuJm5i c3A7IEluIHRoZXNlIHNjZW5hcmlvcywgY2xpZW50cyBtYXkgZ2V0IGEgbW9yZSB1c2VmdWwgcmVz dWx0IGJ5IGNvbXBhcmluZyB0aGUgJmx0O2ludGVuZGVkJmd0OyBhbmQgJmx0O29wZXJhdGlvbmFs Jmd0OyBkYXRhc3RvcmVzIGluc3RlYWQu4oCdPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4zLiBJIHdvdWxkIHByZWZlciBpZiAnZXhjbHVkZT1vcmlnaW4nIHdhcyBpbiB0 aGUgcmV2ZXJzZSBzZW5zZSBhbmQgcGVyaGFwcyBjYWxsZWQgJ3JlcG9ydC1vcmlnaW4nIGluc3Rl YWQuJm5ic3A7IFdpdGggdGhlIHJldmVyc2Ugc2Vuc2UgaXQgc2VlbXMgdG8gYmUgc2FmZXIgaWYg bmV3IGRhdGFzdG9yZXMgYXJlIGRlZmluZWQsDQogd2hlcmUgb3RoZXJ3aXNlIHRoZSBiZWhhdmlv dXIgY291bGQgZW5kIGJlaW5nIHVuZGVyIHNwZWNpZmllZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPklNTyB0aGUgV0cgYWxyZWFkeSBkZXNpZ25lZCB0aGUgZmVh dHVyZXMgc28gaWYgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGhhdmUgY2hhbmdlZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGVuIHRo ZSBkcmFmdCBzaG91bGQgZ28gYmFjayB0byB0aGUgV0cgZm9yIGNoYW5nZXMgYW5kIG5ldyBXRyBj b25zZW5zdXMgY2FsbHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxpPltSV10NCjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxpPkkgZG9u4oCZdCBzZWUgdGhpcyBhcyByZWFsbHkgY2hhbmdpbmcgdGhlIGZ1bmN0 aW9uYWwgcmVxdWlyZW1lbnRzLCBidXQganVzdCBjaGFuZ2luZyB0aGUgZGVmYXVsdCBzZW5zZSBh bmQgbmFtZSBvZiBhbiBBUEkgcGFyYW1ldGVyLiZuYnNwOyBBbHRob3VnaCwgZ2l2ZW4gbXkgY29t bWVudHMgYmVsb3cg4oCcd2l0aC1vcmlnaW7igJ0NCiBtaWdodCBiZSBiZXR0ZXIgdGhhbiDigJxy ZXBvcnQtb3JpZ2lu4oCdLjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxpPkluIFJGQyA4NTI2LCB0aGUg4oCcd2l0aC1vcmlnaW7igJ0gcGFyYW1l dGVyIGlzIG9mZiBieSBkZWZhdWx0LCBhbmQgb3JpZ2luIG1ldGFkYXRhIGlzIG9ubHkgaW5jbHVk ZWQgd2hlbiB0aGUgcGFyYW1ldGVyIGlzIGluY2x1ZGVkLiZuYnNwOyBUaGlzIGtleXdvcmQgaXMg YWxzbyB1bmRlciBhIGZlYXR1cmUuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PGk+U28sIGNoYW5naW5nIHRoZSBwYXJhbWV0ZXIgbmFtZSB0byDi gJx3aXRoLW9yaWdpbuKAnSBhbmQgcHV0dGluZyBpdCB1bmRlciDigJ1pZi1mZWF0dXJlIGlldGYt bmV0Y29uZi1ubWRhOm9yaWdpbuKAnSwgYW5kIG1ha2luZyB0aGUgZGVmYXVsdCBvZmYsIHdvdWxk IG1ha2UgdGhlIGRlZmluaXRpb24gbW9yZSBjb25zaXN0ZW50DQogd2l0aCBSRkMgODUyNi48L2k+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGJyPg0KNC4gU2hvdWxkIHRoZXJlIGJlIGFuIG9wdGlvbiB0byBmaWx0ZXIgb24gb3JpZ2lu IG1ldGFkYXRhPyZuYnNwOyBFLmcuLCBvbmx5IGluY2x1ZGUgdmFsdWVzIHRoYXQgY29tZSBmcm9t IGludGVuZGVkLiZuYnNwOyBPdGhlcndpc2UsIHRoaW5ncyBsaWtlIElQIGFkZHJlc3NlcyBsZWFy bmVkIGZyb20gREhDUCBtYXkgYWx3YXlzIHR1cm4gdXAgYXMgZGlmZmVyZW5jZXMuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklNTyB0aGUgV0cgYWxyZWFkeSBkZXNpZ25l ZCB0aGUgZmVhdHVyZXMgc28gaWYgdGhlIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGhhdmUgY2hh bmdlZHRoZW4gdGhlIGRyYWZ0IHNob3VsZCBnbyBiYWNrIHRvIHRoZSBXRyBmb3IgY2hhbmdlcyBh bmQgbmV3IFdHIGNvbnNlbnN1cyBjYWxscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxpPltSV10NCjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxpPiZuYnNwOzwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPk9rYXkuPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+Jm5ic3A7PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+UmVnYXJkcyw8L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT5Sb2I8L2k+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KNS4gSSdtIG5vdCB0aGF0IGtlZW4gb24gdGhl ICZxdW90O1Bvc3NpYmxlIEZ1dHVyZSBFeHRlbnNpb25zJnF1b3Q7IHNlY3Rpb24gb2YgYW4gUkZD LiZuYnNwOyBQZXJzb25hbGx5LCBJIHdvdWxkIHByZWZlciB0aGF0IHRoaXMgc2VjdGlvbiBpcyBk ZWxldGVkLCBidXQgaWYgeW91IHdpc2ggdG8gcmV0YWluIGl0LCB0aGVuIHBsZWFzZSBjYW4geW91 IG1vdmUgaXQgdG8gYW4gYXBwZW5kaXguPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9LIHdpdGggbWUgdG8gcmVtb3ZlIGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCkkndmUgYWxz byBpbmNsdWRlZCBzb21lIG1pbm9yIGNvbW1lbnRzIGlubGluZSBiZWxvdywgYW5kIHNvbWUgbml0 cyBhdCB0aGUgZW5kOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQWJzdHJhY3Q8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gUlBD IG9wZXJhdGlvbiB0byBjb21wYXJlIG1hbmFnZW1lbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtkYXRhc3RvcmVzIHRoYXQgY29tcGx5IHdpdGggdGhlIE5NREEgYXJjaGl0ZWN0dXJl Ljxicj4NCjxicj4NClRoZSBhYnN0cmFjdCBpcyBwZXJoYXBzIHNvbWV3aGF0IHRlcnNlLiZuYnNw OyBQZXJoYXBzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgWUFORyBSUEMgb3BlcmF0aW9uIHRvIGNvbXBhcmUgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBj b250ZW50cyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZGF0YXN0b3JlcyB0aGF0IGNvbXBseSB3aXRo PGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgTk1EQSBhcmNoaXRlY3R1cmUgYW5kIHJldHVybiB0aGUg ZGlmZmVyZW5jZXMgaW4gdGhlIDxicj4NCiZuYnNwOyAmbmJzcDsgWUFORy1QYXRjaCBmb3JtYXQu PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAxLiZuYnNwOyBJbnRyb2R1Y3Rpb248YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgcmV2aXNlZCBOZXR3b3JrIE1h bmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSAoTk1EQSk8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtbUkZDODM0Ml0gaW50cm9kdWNlcyBhIHNldCBvZiBuZXcgZGF0YXN0b3Jl cyB0aGF0IGVhY2ggaG9sZCBZQU5HLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rl ZmluZWQgZGF0YSBbUkZDNzk1MF0gYW5kIHJlcHJlc2VudCBhIGRpZmZlcmVudCAmcXVvdDt2aWV3 cG9pbnQmcXVvdDsgb24gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YSB0 aGF0IGlzIG1haW50YWluZWQgYnkgYSBzZXJ2ZXIuJm5ic3A7IE5ldyBZQU5HIGRhdGFzdG9yZXMg dGhhdCBhcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnRyb2R1Y2VkIGluY2x1 ZGUgJmx0O2ludGVuZGVkJmd0Oywgd2hpY2ggY29udGFpbnMgdmFsaWRhdGVkIGNvbmZpZ3VyYXRp b248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhIHRoYXQgYSBjbGllbnQgYXBw bGljYXRpb24gaW50ZW5kcyB0byBiZSBpbiBlZmZlY3QsIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDtvcGVyYXRpb25hbCZndDssIHdoaWNoIGNvbnRhaW5zIGF0IGxlYXN0 IGNvbmNlcHR1YWxseSBvcGVyYXRpb25hbCBzdGF0ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RhdGEgKHN1Y2ggYXMgc3RhdGlzdGljcykgYXMgd2VsbCBhcyBjb25maWd1cmF0aW9u IGRhdGEgdGhhdCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FjdHVhbGx5IGlu IGVmZmVjdC48YnI+DQo8YnI+DQpJIHdvdWxkIHN1Z2dlc3QgZGVsZXRpbmcgJnF1b3Q7YXQgbGVh c3QgY29uY2VwdHVhbGx5JnF1b3Q7LCBzaW5jZSB0aGUgJmx0O29wZXJhdGlvbmFsJmd0Ozxicj4N CmRhdGFzdG9yZSBkb2VzIGNvbnRhaW4gYWxsIG9wZXJhdGlvbmFsIHN0YXRlLCBidXQgaXQgbWF5 IGJlIGltcGxlbWVudGVkIGFzIGEgdmlydHVhbCBjb25zdHJ1Y3QgdGhhdCBzcGFucyBtdWx0aXBs ZSBub2RlcyAoZS5nLiwgbGluZWNhcmRzKSBhbmQgcHJvY2Vzc2VzLjxicj4NCjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05NREEgaW50cm9kdWNlcyBpbiBlZmZlY3QgYSBj b25jZXB0IG9mICZxdW90O2xpZmVjeWNsZSZxdW90OyBmb3IgbWFuYWdlbWVudDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RhdGEsIGFsbG93aW5nIHRvIGNsZWFybHkgZGlzdGluZ3Vp c2ggYmV0d2VlbiBkYXRhIHRoYXQgaXMgcGFydCBvZiBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y29uZmlndXJhdGlvbiB0aGF0IHdhcyBzdXBwbGllZCBieSBhIHVzZXIsIGNvbmZp Z3VyYXRpb24gZGF0YSB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aGFzIGFj dHVhbGx5IGJlZW4gc3VjY2Vzc2Z1bGx5IGFwcGxpZWQgYW5kIHRoYXQgaXMgcGFydCBvZiB0aGU8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvcGVyYXRpb25hbCBzdGF0ZSwgYW5kIG92 ZXJhbGwgb3BlcmF0aW9uYWwgc3RhdGUgdGhhdCBpbmNsdWRlcyBib3RoPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YXBwbGllZCBjb25maWd1cmF0aW9uIGRhdGEgYXMgd2VsbCBhcyBz dGF0dXMgYW5kIHN0YXRpc3RpY3MuPGJyPg0KPGJyPg0KJnF1b3Q7YWxsb3dpbmcgdG8gY2xlYXJs eSBkaXN0aW5ndWlzaCZxdW90OyA9Jmd0OyBkaXN0aW5ndWlzaGluZyZxdW90Ozxicj4NCiZxdW90 O3N0YXR1cyBhbmQgc3RhdGlzdGljcyZxdW90OyA9Jmd0OyAmcXVvdDtzdGF0dXMgaW5mb3JtYXRp b24gYW5kIHN0YXRpc3RpY3MmcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtBcyBhIHJlc3VsdCwgZGF0YSBmcm9tIHRoZSBzYW1lIG1hbmFnZW1lbnQgbW9k ZWwgY2FuIGJlIHJlZmxlY3RlZCBpbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO211 bHRpcGxlIGRhdGFzdG9yZXMuJm5ic3A7IENsaWVudHMgbmVlZCB0byBzcGVjaWZ5IHRoZSB0YXJn ZXQgZGF0YXN0b3JlIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgc3BlY2lm aWMgYWJvdXQgd2hpY2ggdmlld3BvaW50IG9mIHRoZSBkYXRhIHRoZXkgd2FudCB0byBhY2Nlc3Mu PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyB3YXksIGFuIGFwcGxpY2F0aW9u IGNhbiBkaWZmZXJlbnRpYXRlIHdoZXRoZXIgdGhleSBhcmUgKGZvcjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2V4YW1wbGUpIGludGVyZXN0ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24g dGhhdCBoYXMgYmVlbiBhcHBsaWVkIGFuZCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2FjdHVhbGx5IGluIGVmZmVjdCwgb3IgaW4gdGhlIGNvbmZpZ3VyYXRpb24gdGhhdCB3YXMg c3VwcGxpZWQgYnkgYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NsaWVudCBhbmQg dGhhdCBpcyBzdXBwb3NlZCB0byBiZSBpbiBlZmZlY3QuPGJyPg0KPGJyPg0KUGVyaGFwcyByZXdv cmQgdGhlIGxhc3Qgc2VudGVuY2UgdG8gbWF0Y2ggdGhlIGxvZ2ljYWwgZGF0YSBmbG93IGluIHRo ZSBzZXJ2ZXI6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0ZvciBleGFtcGxlLCBhIGNsaWVudCBh cHBsaWNhdGlvbiBjYW4gZGlmZmVyZW50aWF0ZSB3aGV0aGVyIHRoZXkgYXJlPGJyPg0KJm5ic3A7 ICZuYnNwO2ludGVyZXN0ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3VwcGxpZWQgdG8gYSBzZXJ2 ZXIgYW5kIHRoYXQgaXM8YnI+DQombmJzcDsgJm5ic3A7c3VwcG9zZWQgdG8gYmUgaW4gZWZmZWN0 LCBvciB0aGUgY29uZmlndXJhdGlvbiB0aGF0IGhhcyBiZWVuIGFwcGxpZWQgYW5kIGlzPGJyPg0K Jm5ic3A7ICZuYnNwO2FjdHVhbGx5IGluIGVmZmVjdCBvbiB0aGUgc2VydmVyLjxicj4NCjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doZW4gY29uZmlndXJhdGlvbiB0aGF0 IGlzIGluIGVmZmVjdCBpcyBkaWZmZXJlbnQgZnJvbSBjb25maWd1cmF0aW9uPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCB3YXMgYXBwbGllZCwgbWFueSBpc3N1ZXMgY2FuIHJl c3VsdC4mbmJzcDsgSXQgYmVjb21lcyBtb3JlIGRpZmZpY3VsdDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3RvIG9wZXJhdGUgdGhlIG5ldHdvcmsgcHJvcGVybHkgZHVlIHRvIGxpbWl0 ZWQgdmlzaWJpbGl0eSBvZiBhY3R1YWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtz dGF0dXMgd2hpY2ggbWFrZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8gYW5hbHl6ZSBhbmQgdW5kZXJz dGFuZCB3aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXMgZ29pbmcgb24gaW4g dGhlIG5ldHdvcmsuJm5ic3A7IFNlcnZpY2VzIG1heSBiZSBuZWdhdGl2ZWx5IGFmZmVjdGVkIChm b3I8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleGFtcGxlLCBicmVha2luZyBhIHNl cnZpY2UgaW5zdGFuY2UgcmVzdWx0aW5nIGluIHNlcnZpY2UgaXMgbm90PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cHJvcGVybHkgZGVsaXZlcmVkIHRvIGEgY3VzdG9tZXIpIGFuZCBu ZXR3b3JrIHJlc291cmNlcyBiZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21pc2Fs bG9jYXRlZC48YnI+DQo8YnI+DQpQZXJoYXBzIGNoYW5nZSAmcXVvdDthY3R1YWwgc3RhdHVzJnF1 b3Q7IHRvICZxdW90O2FjdHVhbCBvcGVyYXRpb25hbCBzdGF0dXMmcXVvdDsuPGJyPg0KPGJyPg0K SSBhbHNvIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGxhc3Qgc2VudGVuY2UgdG86PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBTZXJ2aWNlcyBtYXkgYmUgbmVnYXRpdmVseSBhZmZlY3RlZCAoZS5nLiwg ZGVncmFkaW5nIG9yIGJyZWFraW5nIGEgY3VzdG9tZXIgc2VydmljZSkgb3IgbmV0d29yayByZXNv dXJjZXMgbWF5IGJlIG1pc2FsbG9jYXRlZC48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgMy4gRGVmaW5pdGlvbnM6PGJyPg0KPGJyPg0KSXQgc2hvdWxkIHByb2Jh Ymx5IGRlZmluZSB0aGF0ICZsdDtpbnRlbmRlZCZndDssICZsdDtvcGVyYXRpb25hbCZndDssIChh bmQgcGVyaGFwcyAmbHQ7cnVubmluZyZndDspIGFyZSB1c2VkIHRvIGluZGljYXRlIG5hbWVzIG9m IGRhdGFzdG9yZXMuPGJyPg0KPGJyPg0KSXQgc2hvdWxkIGFsc28gZXhwbGFpbiB0aGF0ICZsdDtj b21wYXJlJmd0OyBpcyB1c2VkIGFzIHRoZSBuYW1lIG9mIGEgWUFORyBSUEMuPGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyA0LiZuYnNwOyBEYXRhIE1vZGVsIE92ZXJ2aWV3PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXQgdGhlIGNvcmUgb2YgdGhlIHNvbHV0aW9u IGlzIGEgbmV3IG1hbmFnZW1lbnQgb3BlcmF0aW9uLCAmbHQ7Y29tcGFyZSZndDssPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBhbGxvd3MgdG8gY29tcGFyZSB0d28gZGF0YXN0 b3JlcyBmb3IgdGhlIHNhbWUgZGF0YS48YnI+DQo8YnI+DQpTdWdnZXN0IHJld29yZGluZyB0aGlz IGZpcnN0IHNlbnRlbmNlIHRvOjxicj4NCjxicj4NCiZuYnNwOyBUaGUgY29yZSBvZiB0aGUgc29s dXRpb24gaXMgYSBuZXcgbWFuYWdlbWVudCBvcGVyYXRpb24sICZsdDtjb21wYXJlJmd0Oyw8YnI+ DQombmJzcDsgdGhhdCBjb21wYXJlcyB0aGUgZGF0YSB0cmVlIGNvbnRlbnRzIG9mIHR3byBkYXRh c3RvcmVzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO28mbmJzcDsgdGFy Z2V0OiBUaGUgdGFyZ2V0IGlkZW50aWZpZXMgdGhlIGRhdGFzdG9yZSB0byBjb21wYXJlIGFnYWlu c3QgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzb3VyY2UuPGJy Pg0KPGJyPg0KU3VnZ2VzdCBhZGRpbmcgYW4gZXhhbXBsZSAmcXVvdDssIGUuZy4sICZsdDtvcGVy YXRpb25hbCZndDsuJnF1b3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 byZuYnNwOyBmaWx0ZXItc3BlYzogVGhpcyBpcyBhIGNob2ljZSBiZXR3ZWVuIGRpZmZlcmVudCBm aWx0ZXIgY29uc3RydWN0czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg dG8gaWRlbnRpZnkgdGhlIHBvcnRpb25zIG9mIHRoZSBkYXRhc3RvcmUgdG8gYmUgcmV0cmlldmVk LiZuYnNwOyBJdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWN0cyBh cyBhIG5vZGUgc2VsZWN0b3IgdGhhdCBzcGVjaWZpZXMgd2hpY2ggZGF0YSBub2RlcyBhcmUgd2l0 aGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgc2NvcGUgb2Yg dGhlIGNvbXBhcmlzb24gYW5kIHdoaWNoIG5vZGVzIGFyZSBvdXRzaWRlIHRoZSBzY29wZTxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR11MB43666C3BEDECF2BFA6473FDBB56C9MN2PR11MB4366namp_-- From nobody Mon Mar 15 10:30:00 2021 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 36C043A1802; Mon, 15 Mar 2021 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb2sB0nB3sKn; Mon, 15 Mar 2021 10:29:51 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526E83A17FF; Mon, 15 Mar 2021 10:29:48 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id m21-20020a9d7ad50000b02901b83efc84a0so5522305otn.10; Mon, 15 Mar 2021 10:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qxft1oIVB2upXU6DDEXrM8JBSyfgcc2DMFVnoEY4Qrs=; b=cG8nT8VMez+oA8M2DnT6LDuN/HOhops9fFCPUBUkeUZyhoM/Zagmor57BOqN484G5D KAtj3zoh0ZqV8D0m+hFjXr3FGVOgWlU4yfp6k6eKRbFuDSXNz1PDl8QpBsnXY8GV3fR4 D8EvAYt2+Py4VcOqhd64SFt4bLsZ5k9W67uK42ZdjjeJ7tPRiMlAI0oxURsKbrLzwsgW hpiIIaKdWJP8Y+VDmotQ3AEixh0CvI4GhDJ7NIkptoS6NnxCih8Im9oov/sJMFuulplu i88dXm2BzGOwDt4Ya3EanZSXClw2vjydDQ9AyBgGUJ55sbzL7FMBbV3BktxHyLdPA6kT MwcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qxft1oIVB2upXU6DDEXrM8JBSyfgcc2DMFVnoEY4Qrs=; b=bACKvugin9GRnWo3u9/cdE2VnJqKiGYeZBpD3xX4hGWGoaJTxu4e6+DE+sEJ/6lnmS U4vWhkxqp/UFW1wlpbVm9LUTq1UnSxPQ5VvnUSVKBTZhrZ0Nj7zmtJDq26Sudh9A3zqI ts8gknYb6E2QC/rT0USBqDMIyWBk8l/MuriWjJN3Q3BdE8OGIBtxT86KrxoKUPtmyhj5 cQLeE+etJgh7SYU/S3W009W/4pqKBo1q73II56ABxsxtu/iVgIKwzP5ufL2eO4goZR7u Hfz0vT3iJjL3lAn4reWwOqeOaQ2EK7odiKBPFyeEtybZtJaKQDsBHeoZe03nNLDg+9My tEvg== X-Gm-Message-State: AOAM532Yz6SOjqBhqF1Jyoad2sBQh2uXsbu0fhTu/xnoae5zo3L9NwEg lQNDHNgpOA6wiEEj0JDvMhXqCgG47cqPnX6NKx8= X-Google-Smtp-Source: ABdhPJxb/kOoMoOz7AhguFT10c0BN/H9bPCS1L9NFLz3VuulI4KaStBWy7q+qSqRfozK15LY6vXuPvH5Yp+SaIow6l0= X-Received: by 2002:a9d:6a50:: with SMTP id h16mr171712otn.67.1615829386394; Mon, 15 Mar 2021 10:29:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: joel jaeggli Date: Mon, 15 Mar 2021 10:29:34 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Andy Bierman , NetMod WG Chairs , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000098006f05bd96981d" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 17:29:55 -0000 --00000000000098006f05bd96981d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable yeah when there is an update we'll probably drop a reminder in the list along with a link to the diff, but unless it looks major there's not reason to ask for re-approval. thanks joel On Mon, Mar 15, 2021 at 10:26 AM Rob Wilton (rwilton) wrote: > Hi Andy, > > > > FYI, this issue was discussed in the Netmod session on Friday. > > > > My interpretation of the chairs position is ( > https://www.youtube.com/watch?v=3DglLcpQ9kpv0, starts at 6.10) is : As lo= ng > as the WG is copied on my AD review comments and proposed changes (which > they have been), then the WG has the opportunity to comment or object to > the proposed changes if they wish, and lack of comment from the WG is tak= en > as a tacit acceptance of the proposed changes. > > > > Given this, I think that the authors can apply the mark ups based on the > agreements below (and my original nits), republish, and then hopefully we > should be ready to progress this to IETF LC. > > > > Regards, > Rob > > > > > > *From:* Andy Bierman > *Sent:* 05 March 2021 18:46 > *To:* Rob Wilton (rwilton) > *Cc:* NetMod WG Chairs ; joel jaeggli < > joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; > netmod@ietf.org > *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 > > > > > > > > On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton) > wrote: > > Hi Andy, > > > > I=E2=80=99m not sure which one you think is s a design change: Do you me= an issue > 3 or issue 4 below? > > > > I see that my response to issue 4 may not have been clear, so to clarify: > > > > By =E2=80=9Cokay=E2=80=9D, I meant, that I am okay with how it is written= in the current > draft. My presumption is that this could be addressed as a future versio= n > of the module if this turns out be an issue, or vendors can define their > own augmentation if needed. > > > > If you think issue 3 is a design change that requires WG consensus that I > will leave it to the WG chairs to decide if they wish to issue a consensu= s > call for it. > > > > > > > > The change: > > > > Current: default is to include origin attributes and client adds > exclude-origin leaf to turn this off > > Proposed: default is to exclude origin attributes and client adds > report-origin leaf to turn this on > > Also, report-origin has an if-feature because origin support in NMDA > is optional. > > > > I have no objections to this proposal. > > My point all along has been that this is not my decision to make, it is a > WG decision. > > It does not seem that there are any objections to making this change. > > > > > > Regards, > > Rob > > > > > > Andy > > > > > > *From:* Andy Bierman > *Sent:* 05 March 2021 16:36 > *To:* Rob Wilton (rwilton) > *Cc:* joel jaeggli ; > draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org > *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 > > > > > > > > On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) > wrote: > > Hi Andy, authors, > > > > > > > > I think you mean to address this to the WG since the redesign issues need > WG approval. > > I have no objections to any changes. > > > > > > Andy > > > > Sorry for the long delay in replying. > > > > Please see [RW] inline below =E2=80=A6 > > > > > > *From:* Andy Bierman > *Sent:* 30 October 2020 01:43 > *To:* joel jaeggli > *Cc:* Rob Wilton (rwilton) ; > draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org > *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 > > > > > > > > On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli wrote: > > Rob, > > > > These seem like reasonable suggestions. > > > > Lets see what the authors say. > > > > Thanks for this > > joel > > > > On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) > wrote: > > Hi, > > Here is my AD review for draft-ietf-netmod-nmda-diff-07. Apologies for > the delay. > > Thank you for writing this document, I think that it is useful, and looks > like it is in good shape. > > > Main comments: > > 1. Should there be any text about how to find out what datastores are > supported by a device? E.g., pointing them to either YANG library, or > protocol specific mechanisms in the case of RESTCONF. > > > > Do you have a section in mind and suggested text? > > *[RW] * > > *Perhaps somewhere in section 4, either as part of the description of > source, or perhaps before the parameters are described.* > > > > *Proposed text:* > > *=E2=80=9CA client can discover which datastores a server supports by rea= ding YANG > library [RFC 8525] from the operational state datastore.=E2=80=9D* > > > > > > > > 2. It might be helpful to add a comment about potential issues that could > arise by comparing to , i.e., additional differenc= es > could be reported due to inactive configuration and template processing > between and . > > > > Do you have a section in mind and suggested text? > > You mean if there are differences between and > > then a diff between and will not be the same > > as a diff between and .? > > > > *[RW] * > > *My main concern is that if you have template expansion then comparing > and may not really give a meaningful comparison, > since is pre-template expansion, and (and > ) are both post template expansion.* > > > > *I would suggest putting some text in section 4 or perhaps the YANG > module.* > > > > *Perhaps some text, something like: * > > > > * =E2=80=9CClients should to be aware that comparing to > will report differences due to any configuration transformation (e.g., > inactive configuration, or the expansion of templates) between the > and datastores. In these scenarios, clients may get= a > more useful result by comparing the and datastor= es > instead.=E2=80=9D* > > > > > > > > > > 3. I would prefer if 'exclude=3Dorigin' was in the reverse sense and perh= aps > called 'report-origin' instead. With the reverse sense it seems to be > safer if new datastores are defined, where otherwise the behaviour could > end being under specified. > > > > > > IMO the WG already designed the features so if the functional requirement= s > have changed > > then the draft should go back to the WG for changes and new WG consensus > calls. > > *[RW] * > > > > *I don=E2=80=99t see this as really changing the functional requirements,= but just > changing the default sense and name of an API parameter. Although, given > my comments below =E2=80=9Cwith-origin=E2=80=9D might be better than =E2= =80=9Creport-origin=E2=80=9D.* > > > > *In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D parameter is off by defau= lt, and origin > metadata is only included when the parameter is included. This keyword i= s > also under a feature.* > > > > *So, changing the parameter name to =E2=80=9Cwith-origin=E2=80=9D and put= ting it under > =E2=80=9Dif-feature ietf-netconf-nmda:origin=E2=80=9D, and making the def= ault off, would > make the definition more consistent with RFC 8526.* > > > > > > > 4. Should there be an option to filter on origin metadata? E.g., only > include values that come from intended. Otherwise, things like IP > addresses learned from DHCP may always turn up as differences. > > > > IMO the WG already designed the features so if the functional requirement= s > have changedthen the draft should go back to the WG for changes and new W= G > consensus calls. > > > > *[RW] * > > > > *Okay.* > > > > *Regards,* > > *Rob* > > > > > > > 5. I'm not that keen on the "Possible Future Extensions" section of an > RFC. Personally, I would prefer that this section is deleted, but if you > wish to retain it, then please can you move it to an appendix. > > > > OK with me to remove it > > > > > > > > Andy > > > > > > > I've also included some minor comments inline below, and some nits at the > end: > > Abstract > > This document defines an RPC operation to compare management > datastores that comply with the NMDA architecture. > > The abstract is perhaps somewhat terse. Perhaps: > > This document defines a YANG RPC operation to compare the > contents of network management datastores that comply with > the NMDA architecture and return the differences in the > YANG-Patch format. > > > 1. Introduction > > The revised Network Management Datastore Architecture (NMDA) > [RFC8342] introduces a set of new datastores that each hold YANG- > defined data [RFC7950] and represent a different "viewpoint" on th= e > data that is maintained by a server. New YANG datastores that are > introduced include , which contains validated > configuration > data that a client application intends to be in effect, and > , which contains at least conceptually operational > state > data (such as statistics) as well as configuration data that is > actually in effect. > > I would suggest deleting "at least conceptually", since the > datastore does contain all operational state, but it may be implemented a= s > a virtual construct that spans multiple nodes (e.g., linecards) and > processes. > > > NMDA introduces in effect a concept of "lifecycle" for management > data, allowing to clearly distinguish between data that is part of= a > configuration that was supplied by a user, configuration data that > has actually been successfully applied and that is part of the > operational state, and overall operational state that includes bot= h > applied configuration data as well as status and statistics. > > "allowing to clearly distinguish" =3D> distinguishing" > "status and statistics" =3D> "status information and statistics" > > > As a result, data from the same management model can be reflected = in > multiple datastores. Clients need to specify the target datastore > to > be specific about which viewpoint of the data they want to access. > This way, an application can differentiate whether they are (for > example) interested in the configuration that has been applied and > is > actually in effect, or in the configuration that was supplied by a > client and that is supposed to be in effect. > > Perhaps reword the last sentence to match the logical data flow in the > server: > > For example, a client application can differentiate whether they are > interested in the configuration supplied to a server and that is > supposed to be in effect, or the configuration that has been applied > and is > actually in effect on the server. > > > When configuration that is in effect is different from configurati= on > that was applied, many issues can result. It becomes more difficu= lt > to operate the network properly due to limited visibility of actua= l > status which makes it more difficult to analyze and understand wha= t > is going on in the network. Services may be negatively affected > (for > example, breaking a service instance resulting in service is not > properly delivered to a customer) and network resources be > misallocated. > > Perhaps change "actual status" to "actual operational status". > > I also suggest changing the last sentence to: > > Services may be negatively affected (e.g., degrading or breaking a > customer service) or network resources may be misallocated. > > > 3. Definitions: > > It should probably define that , , (and perhaps > ) are used to indicate names of datastores. > > It should also explain that is used as the name of a YANG RPC. > > > 4. Data Model Overview > > At the core of the solution is a new management operation, > , > that allows to compare two datastores for the same data. > > Suggest rewording this first sentence to: > > The core of the solution is a new management operation, , > that compares the data tree contents of two datastores. > > o target: The target identifies the datastore to compare against > the > source. > > Suggest adding an example ", e.g., ." > > o filter-spec: This is a choice between different filter construc= ts > to identify the portions of the datastore to be retrieved. It > acts as a node selector that specifies which data nodes are > within > the scope of the comparison and which nodes are outside the sco= pe > > --00000000000098006f05bd96981d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yeah when there is an update we'll probably drop a=C2= =A0 reminder in the list along with a link to the diff, but unless it looks= major=C2=A0 there's not reason to ask for re-approval.

<= div>thanks
joel

On Mon, Mar 15, 2021 at 10:26 AM Rob Wilton = (rwilton) <rwilton@cisco.com>= ; wrote:

Hi Andy,

=C2=A0

FYI, this issue was discussed in the Netmod se= ssion on Friday.

=C2=A0

My interpretation of the chairs position is (<= a href=3D"https://www.youtube.com/watch?v=3DglLcpQ9kpv0" target=3D"_blank">= https://www.youtube.com/watch?v=3DglLcpQ9kpv0, starts at 6.10) is : As = long as the WG is copied on my AD review comments and proposed changes (which they have been), then= the WG has the opportunity to comment or object to the proposed changes if= they wish, and lack of comment from the WG is taken as a tacit acceptance = of the proposed changes.

=C2=A0

Given this, I think that the authors can apply= the mark ups based on the agreements below (and my original nits), republi= sh, and then hopefully we should be ready to progress this to IETF LC.

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 05 March 2021 18:46
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>; joel jaeggli <joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi Andy,

=C2=A0

I=E2=80=99m not sure which one you think is s a desi= gn change:=C2=A0 Do you mean issue 3 or issue 4 below?

=C2=A0

I see that my response to issue 4 may not have been = clear, so to clarify:

=C2=A0

By =E2=80=9Cokay=E2=80=9D, I meant, that I am okay w= ith how it is written in the current draft.=C2=A0 My presumption is that th= is could be addressed as a future version of the module if this turns out be an issue, or vendors can define their own augmentation if needed.

=C2=A0

If you think issue 3 is a design change that require= s WG consensus that I will leave it to the WG chairs to decide if they wish= to issue a consensus call for it.

=C2=A0

=C2=A0

=C2=A0

The change:

=C2=A0=C2=A0

=C2=A0 =C2=A0Current: default is to include origin a= ttributes and client adds exclude-origin leaf to turn this off

=C2=A0 =C2=A0Proposed: default is to exclude origin = attributes and client adds report-origin leaf to turn this on=

=C2=A0 =C2=A0 Also, report-origin has an if-feature = because origin support in NMDA is optional.

=C2=A0

I have no objections to this proposal.=

My point all along has been that this is not my deci= sion to make, it is a WG decision.

It does not seem that there are any objections to ma= king this change.

=C2=A0

=C2=A0

Regards,

Rob

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 05 March 2021 16:36
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: joel jaeggli <joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) = <rwilton@cisco.co= m> wrote:

Hi Andy, authors,

=C2=A0

=C2=A0

=C2=A0

I think you mean to address this to the WG since the= redesign issues need WG approval.

I have no objections to any changes.=C2=A0=C2=A0<= /u>

=C2=A0

=C2=A0

Andy

=C2=A0

Sorry for the long delay in replying.<= /p>

=C2=A0

Please see [RW] inline below =E2=80=A6=

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 30 October 2020 01:43
To: joel jaeggli <joelja@gmail.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli <joelja@gmail.com>= wrote:

Rob,=C2=A0

=C2=A0

These seem like reasonable suggestions.=C2=A0=

=C2=A0

Lets see what the authors say.

=C2=A0

Thanks for this

joel

=C2=A0

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.=C2=A0 Apologies fo= r the delay.

Thank you for writing this document, I think that it is useful, and looks l= ike it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are suppo= rted by a device?=C2=A0 E.g., pointing them to either YANG library, or prot= ocol specific mechanisms in the case of RESTCONF.

=C2=A0

Do you have a section in mind and suggested text?=

[RW]

Perhaps somewhere in section 4, either as part= of the description of source, or perhaps before the parameters are describ= ed.

=C2=A0

Proposed text:

=E2=80=9CA client can discover which datastores a server supports by = reading YANG library [RFC 8525] from the operational state datastore.=E2=80= =9D

=C2=A0

=C2=A0

=C2=A0

2. It might be helpful = to add a comment about potential issues that could arise by comparing <r= unning> to <operational>, i.e., additional differences could be re= ported due to inactive configuration and template processing between <running> and <oper= ational>.

=C2=A0

Do you have a section in mind and suggested text?=

You mean if there are differences between <runnin= g> and <intended>

then a diff between <running> and <operatio= nal> will not be the same

as a diff between <intended> and <operation= al>.?

=C2=A0

[RW]

My main concern is that if you have template e= xpansion then comparing <running> and <operational> may not rea= lly give a meaningful comparison, since <running> is pre-template expansion, and <operational> (and <intended>) are both post te= mplate expansion.

=C2=A0

I would suggest putting some text in section 4= or perhaps the YANG module.

=C2=A0

Perhaps some text, something like:

=C2=A0

=C2=A0 =E2=80=9CClients should to be aware tha= t comparing <running> to <operational> will report differences = due to any configuration transformation (e.g., inactive configuration, or t= he expansion of templates) between the <running> and <intended> d= atastores.=C2=A0 In these scenarios, clients may get a more useful result b= y comparing the <intended> and <operational> datastores instead= .=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

=C2=A0

3. I would prefer if 'exclude=3Dorigin' was = in the reverse sense and perhaps called 'report-origin' instead.=C2= =A0 With the reverse sense it seems to be safer if new datastores are defin= ed, where otherwise the behaviour could end being under specified.

=C2=A0

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changed

then the draft should go back to the WG for changes = and new WG consensus calls.

[RW]

=C2=A0

I don=E2=80=99t see this as really changing th= e functional requirements, but just changing the default sense and name of = an API parameter.=C2=A0 Although, given my comments below =E2=80=9Cwith-ori= gin=E2=80=9D might be better than =E2=80=9Creport-origin=E2=80=9D.

=C2=A0

In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D= parameter is off by default, and origin metadata is only included when the= parameter is included.=C2=A0 This keyword is also under a feature.=

=C2=A0

So, changing the parameter name to =E2=80=9Cwi= th-origin=E2=80=9D and putting it under =E2=80=9Dif-feature ietf-netconf-nm= da:origin=E2=80=9D, and making the default off, would make the definition m= ore consistent with RFC 8526.

=C2=A0

=C2=A0


4. Should there be an option to filter on origin metadata?=C2=A0 E.g., only= include values that come from intended.=C2=A0 Otherwise, things like IP ad= dresses learned from DHCP may always turn up as differences.<= /p>

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changedthen the draft should go back to the WG = for changes and new WG consensus calls.

=C2=A0

[RW]

=C2=A0

Okay.

=C2=A0

Regards,

Rob

=C2=A0

=C2=A0


5. I'm not that keen on the "Possible Future Extensions" sect= ion of an RFC.=C2=A0 Personally, I would prefer that this section is delete= d, but if you wish to retain it, then please can you move it to an appendix= .

=C2=A0

OK with me to remove it

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0


I've also included some minor comments inline below, and some nits at t= he end:

=C2=A0 =C2=A0 Abstract

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines an RPC operation to compar= e management
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastores that comply with the NMDA architectur= e.

The abstract is perhaps somewhat terse.=C2=A0 Perhaps:

=C2=A0 =C2=A0 This document defines a YANG RPC operation to compare the
=C2=A0 =C2=A0 contents of network management datastores that comply with =C2=A0 =C2=A0 the NMDA architecture and return the differences in the
=C2=A0 =C2=A0 YANG-Patch format.


=C2=A0 =C2=A0 1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0 =C2=A0The revised Network Management Datastore Archite= cture (NMDA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC8342] introduces a set of new datastores tha= t each hold YANG-
=C2=A0 =C2=A0 =C2=A0 =C2=A0defined data [RFC7950] and represent a different= "viewpoint" on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that is maintained by a server.=C2=A0 New Y= ANG datastores that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0introduced include <intended>, which conta= ins validated configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that a client application intends to be in = effect, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0<operational>, which contains at least con= ceptually operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0data (such as statistics) as well as configurati= on data that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect.

I would suggest deleting "at least conceptually", since the <o= perational>
datastore does contain all operational state, but it may be implemented as = a virtual construct that spans multiple nodes (e.g., linecards) and process= es.


=C2=A0 =C2=A0 =C2=A0 =C2=A0NMDA introduces in effect a concept of "lif= ecycle" for management
=C2=A0 =C2=A0 =C2=A0 =C2=A0data, allowing to clearly distinguish between da= ta that is part of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration that was supplied by a user, confi= guration data that
=C2=A0 =C2=A0 =C2=A0 =C2=A0has actually been successfully applied and that = is part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0operational state, and overall operational state= that includes both
=C2=A0 =C2=A0 =C2=A0 =C2=A0applied configuration data as well as status and= statistics.

"allowing to clearly distinguish" =3D> distinguishing" "status and statistics" =3D> "status information and stat= istics"


=C2=A0 =C2=A0 =C2=A0 =C2=A0As a result, data from the same management model= can be reflected in
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple datastores.=C2=A0 Clients need to speci= fy the target datastore to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be specific about which viewpoint of the data th= ey want to access.
=C2=A0 =C2=A0 =C2=A0 =C2=A0This way, an application can differentiate wheth= er they are (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example) interested in the configuration that ha= s been applied and is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect, or in the configuration that= was supplied by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0client and that is supposed to be in effect.

Perhaps reword the last sentence to match the logical data flow in the serv= er:

=C2=A0 =C2=A0For example, a client application can differentiate whether th= ey are
=C2=A0 =C2=A0interested in the configuration supplied to a server and that = is
=C2=A0 =C2=A0supposed to be in effect, or the configuration that has been a= pplied and is
=C2=A0 =C2=A0actually in effect on the server.


=C2=A0 =C2=A0 =C2=A0 =C2=A0When configuration that is in effect is differen= t from configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0that was applied, many issues can result.=C2=A0 = It becomes more difficult
=C2=A0 =C2=A0 =C2=A0 =C2=A0to operate the network properly due to limited v= isibility of actual
=C2=A0 =C2=A0 =C2=A0 =C2=A0status which makes it more difficult to analyze = and understand what
=C2=A0 =C2=A0 =C2=A0 =C2=A0is going on in the network.=C2=A0 Services may b= e negatively affected (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example, breaking a service instance resulting i= n service is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0properly delivered to a customer) and network re= sources be
=C2=A0 =C2=A0 =C2=A0 =C2=A0misallocated.

Perhaps change "actual status" to "actual operational status= ".

I also suggest changing the last sentence to:

=C2=A0 =C2=A0 Services may be negatively affected (e.g., degrading or break= ing a customer service) or network resources may be misallocated.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Definitions:

It should probably define that <intended>, <operational>, (and = perhaps <running>) are used to indicate names of datastores.

It should also explain that <compare> is used as the name of a YANG R= PC.


=C2=A0 =C2=A0 4.=C2=A0 Data Model Overview

=C2=A0 =C2=A0 =C2=A0 =C2=A0At the core of the solution is a new management = operation, <compare>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0that allows to compare two datastores for the sa= me data.

Suggest rewording this first sentence to:

=C2=A0 The core of the solution is a new management operation, <compare&= gt;,
=C2=A0 that compares the data tree contents of two datastores.

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 target: The target identifies the datast= ore to compare against the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 source.

Suggest adding an example ", e.g., <operational>."

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 filter-spec: This is a choice between di= fferent filter constructs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to identify the portions of the datastor= e to be retrieved.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acts as a node selector that specifies w= hich data nodes are within
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the scope of the comparison and which no= des are outside the scope

--00000000000098006f05bd96981d-- From nobody Mon Mar 15 15:31:17 2021 Return-Path: <010001783803bc3a-37589491-34a8-4874-b914-73176608e853-000000@amazonses.watsen.net> 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 E4A393A1147 for ; Mon, 15 Mar 2021 15:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTpg6sgtuuGU for ; Mon, 15 Mar 2021 15:31:13 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8DE3A1121 for ; Mon, 15 Mar 2021 15:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1615847472; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=emncAaMgmxgBdHPJftV9j5nkeNJ+q2gMZvYssjZMn5A=; b=hu2W+Eb+1lvfF02moGsIs9M/o/9CEguOt1FJVnyUxZybTJEwPemIzq8nsgoWiqDp oLkJhItLpqxYvwkbcM06UiXmlwHQplukSbIhJ/zhOFXS9rjB3fcXzli+OBTgdQjnIaT A+zhJu1I3msFDbIZEXAiTNeuwbB6KyKvF6pXn7IE= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_396713D5-66C7-4B34-8693-01FF605BA9BF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001783803bc3a-37589491-34a8-4874-b914-73176608e853-000000@email.amazonses.com> Date: Mon, 15 Mar 2021 22:31:12 +0000 To: "netmod@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.03.15-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netmod] Draft minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 22:31:15 -0000 --Apple-Mail=_396713D5-66C7-4B34-8693-01FF605BA9BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The NETMOD 110 draft minutes have been posted: = https://datatracker.ietf.org/meeting/110/materials/minutes-110-netmod-00 = = Please provides comments/fixes to the list. Thanks, Kent and Lou --Apple-Mail=_396713D5-66C7-4B34-8693-01FF605BA9BF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

The NETMOD 110 draft minutes have been posted:

  https://datatracker.ietf.org/meeting/110/materials/minutes-110-netmod-00


Please provides comments/fixes to the list.

Thanks,
Kent and Lou

--Apple-Mail=_396713D5-66C7-4B34-8693-01FF605BA9BF-- From nobody Mon Mar 15 16:07:31 2021 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 29AE43A1234 for ; Mon, 15 Mar 2021 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Wij0TB8J0Q for ; Mon, 15 Mar 2021 16:07:27 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3C13A1235 for ; Mon, 15 Mar 2021 16:07:26 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id d3so59423514lfg.10 for ; Mon, 15 Mar 2021 16:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K5ICuvaiyvbKF+g6Rd5gOsicAZ4qMDNBL+bnbXaz968=; b=lBinErFa11OcCMXUVl4PpXex6k2HQZgd1LgHQ+t1dzjM/x6Njm+AKgdirHsqnifoVg SYpqEzlADe3A+wp/6UOdXBE+wzn8XbAzPQv80oqTdN1bteLpe8iA4IJ0glpW817Hibs6 aYhUDTMVdqgPT0kiWSeK7TZe4nx+wqD9rXI1g9Lt3WmgSLg+M2SYQxbL2usSvhGzKw3S /gLRaxzeDk7QFrRKZiLZs+hdkLzs2deRJIEEbO5DxINK0peaD8BrMXlK00aQyFyjCgXa u2fGxjjjUZnsVb/s5dcSsrqweD6T/Byp4M2fH44eBlNzVFc1jSTgmNMe6qpuYst0e2zu cV3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K5ICuvaiyvbKF+g6Rd5gOsicAZ4qMDNBL+bnbXaz968=; b=sJm5g/CCkDP+KV5L2ksgLjSXPnldx+bH67OSiyV0j1Tsq22JEHbsxkOn+4kiUzhdK5 ri/F8xBMYCjctYg3y7EBw2P6JGq57oOEedQl03wawq+OizQQYPQqysMflScTcwf0gP5d z7AhcOETuVXX0VAgDNbbr3GiwrZN3G7568uOZWaUB0c48Z0zbp9y8WRv9nne5lZ4CrSH pDqTEJliF+sBsRakRcVFKHasm0z2mXQ6BAay6B8lofiAz6Vk7at8epDG4rScMXq5uxv3 2Ef8GIF422+xAdL8FFFW5Jvl0s/4AxE4IrffZIS0MSGEj2kTVjMKBgY9enQCn+SX1Roh daDQ== X-Gm-Message-State: AOAM530H6z5nFc059h/boazZjSOySb7mgnyUojgtFpEiraRBC0LaEh95 z0B5BqyUNYi3yytWwUvVWrl/LF7VaF5sbO8u6s2tAg== X-Google-Smtp-Source: ABdhPJxYpzAy2Hf7OrRyVr4XN/QpmCreMH1BbQ0fa6NZHprVG3fVj4tg4aKdDRFDMlwEGPZ06pn7MVQTgljtHvA4ZAs= X-Received: by 2002:a19:ee0d:: with SMTP id g13mr9584944lfb.38.1615849642695; Mon, 15 Mar 2021 16:07:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Mon, 15 Mar 2021 16:07:11 -0700 Message-ID: To: joel jaeggli Cc: "Rob Wilton (rwilton)" , NetMod WG Chairs , "draft-ietf-netmod-nmda-diff.all@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f6aed405bd9b4f62" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 23:07:30 -0000 --000000000000f6aed405bd9b4f62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 15, 2021 at 10:29 AM joel jaeggli wrote: > yeah when there is an update we'll probably drop a reminder in the list > along with a link to the diff, but unless it looks major there's not > reason to ask for re-approval. > > It is actually a much more minor change than I thought when I first looked at it. The new way is better because the origin tracking feature is optional and the current draft ignores this YANG feature. > thanks > joel > Andy > > On Mon, Mar 15, 2021 at 10:26 AM Rob Wilton (rwilton) > wrote: > >> Hi Andy, >> >> >> >> FYI, this issue was discussed in the Netmod session on Friday. >> >> >> >> My interpretation of the chairs position is ( >> https://www.youtube.com/watch?v=3DglLcpQ9kpv0, starts at 6.10) is : As >> long as the WG is copied on my AD review comments and proposed changes >> (which they have been), then the WG has the opportunity to comment or >> object to the proposed changes if they wish, and lack of comment from th= e >> WG is taken as a tacit acceptance of the proposed changes. >> >> >> >> Given this, I think that the authors can apply the mark ups based on the >> agreements below (and my original nits), republish, and then hopefully w= e >> should be ready to progress this to IETF LC. >> >> >> >> Regards, >> Rob >> >> >> >> >> >> *From:* Andy Bierman >> *Sent:* 05 March 2021 18:46 >> *To:* Rob Wilton (rwilton) >> *Cc:* NetMod WG Chairs ; joel jaeggli < >> joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; >> netmod@ietf.org >> *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 >> >> >> >> >> >> >> >> On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton) >> wrote: >> >> Hi Andy, >> >> >> >> I=E2=80=99m not sure which one you think is s a design change: Do you m= ean issue >> 3 or issue 4 below? >> >> >> >> I see that my response to issue 4 may not have been clear, so to clarify= : >> >> >> >> By =E2=80=9Cokay=E2=80=9D, I meant, that I am okay with how it is writte= n in the current >> draft. My presumption is that this could be addressed as a future versi= on >> of the module if this turns out be an issue, or vendors can define their >> own augmentation if needed. >> >> >> >> If you think issue 3 is a design change that requires WG consensus that = I >> will leave it to the WG chairs to decide if they wish to issue a consens= us >> call for it. >> >> >> >> >> >> >> >> The change: >> >> >> >> Current: default is to include origin attributes and client adds >> exclude-origin leaf to turn this off >> >> Proposed: default is to exclude origin attributes and client adds >> report-origin leaf to turn this on >> >> Also, report-origin has an if-feature because origin support in NMDA >> is optional. >> >> >> >> I have no objections to this proposal. >> >> My point all along has been that this is not my decision to make, it is = a >> WG decision. >> >> It does not seem that there are any objections to making this change. >> >> >> >> >> >> Regards, >> >> Rob >> >> >> >> >> >> Andy >> >> >> >> >> >> *From:* Andy Bierman >> *Sent:* 05 March 2021 16:36 >> *To:* Rob Wilton (rwilton) >> *Cc:* joel jaeggli ; >> draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org >> *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 >> >> >> >> >> >> >> >> On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) >> wrote: >> >> Hi Andy, authors, >> >> >> >> >> >> >> >> I think you mean to address this to the WG since the redesign issues nee= d >> WG approval. >> >> I have no objections to any changes. >> >> >> >> >> >> Andy >> >> >> >> Sorry for the long delay in replying. >> >> >> >> Please see [RW] inline below =E2=80=A6 >> >> >> >> >> >> *From:* Andy Bierman >> *Sent:* 30 October 2020 01:43 >> *To:* joel jaeggli >> *Cc:* Rob Wilton (rwilton) ; >> draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org >> *Subject:* Re: AD review of draft-ietf-netmod-nmda-diff-07 >> >> >> >> >> >> >> >> On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli wrote: >> >> Rob, >> >> >> >> These seem like reasonable suggestions. >> >> >> >> Lets see what the authors say. >> >> >> >> Thanks for this >> >> joel >> >> >> >> On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) >> wrote: >> >> Hi, >> >> Here is my AD review for draft-ietf-netmod-nmda-diff-07. Apologies for >> the delay. >> >> Thank you for writing this document, I think that it is useful, and look= s >> like it is in good shape. >> >> >> Main comments: >> >> 1. Should there be any text about how to find out what datastores are >> supported by a device? E.g., pointing them to either YANG library, or >> protocol specific mechanisms in the case of RESTCONF. >> >> >> >> Do you have a section in mind and suggested text? >> >> *[RW] * >> >> *Perhaps somewhere in section 4, either as part of the description of >> source, or perhaps before the parameters are described.* >> >> >> >> *Proposed text:* >> >> *=E2=80=9CA client can discover which datastores a server supports by re= ading >> YANG library [RFC 8525] from the operational state datastore.=E2=80=9D* >> >> >> >> >> >> >> >> 2. It might be helpful to add a comment about potential issues that coul= d >> arise by comparing to , i.e., additional differen= ces >> could be reported due to inactive configuration and template processing >> between and . >> >> >> >> Do you have a section in mind and suggested text? >> >> You mean if there are differences between and >> >> then a diff between and will not be the same >> >> as a diff between and .? >> >> >> >> *[RW] * >> >> *My main concern is that if you have template expansion then comparing >> and may not really give a meaningful comparison, >> since is pre-template expansion, and (and >> ) are both post template expansion.* >> >> >> >> *I would suggest putting some text in section 4 or perhaps the YANG >> module.* >> >> >> >> *Perhaps some text, something like: * >> >> >> >> * =E2=80=9CClients should to be aware that comparing to >> will report differences due to any configuration transformation (e.g., >> inactive configuration, or the expansion of templates) between the >> and datastores. In these scenarios, clients may ge= t a >> more useful result by comparing the and datasto= res >> instead.=E2=80=9D* >> >> >> >> >> >> >> >> >> >> 3. I would prefer if 'exclude=3Dorigin' was in the reverse sense and >> perhaps called 'report-origin' instead. With the reverse sense it seems= to >> be safer if new datastores are defined, where otherwise the behaviour co= uld >> end being under specified. >> >> >> >> >> >> IMO the WG already designed the features so if the functional >> requirements have changed >> >> then the draft should go back to the WG for changes and new WG consensus >> calls. >> >> *[RW] * >> >> >> >> *I don=E2=80=99t see this as really changing the functional requirements= , but >> just changing the default sense and name of an API parameter. Although, >> given my comments below =E2=80=9Cwith-origin=E2=80=9D might be better th= an =E2=80=9Creport-origin=E2=80=9D.* >> >> >> >> *In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D parameter is off by defa= ult, and origin >> metadata is only included when the parameter is included. This keyword = is >> also under a feature.* >> >> >> >> *So, changing the parameter name to =E2=80=9Cwith-origin=E2=80=9D and pu= tting it under >> =E2=80=9Dif-feature ietf-netconf-nmda:origin=E2=80=9D, and making the de= fault off, would >> make the definition more consistent with RFC 8526.* >> >> >> >> >> >> >> 4. Should there be an option to filter on origin metadata? E.g., only >> include values that come from intended. Otherwise, things like IP >> addresses learned from DHCP may always turn up as differences. >> >> >> >> IMO the WG already designed the features so if the functional >> requirements have changedthen the draft should go back to the WG for >> changes and new WG consensus calls. >> >> >> >> *[RW] * >> >> >> >> *Okay.* >> >> >> >> *Regards,* >> >> *Rob* >> >> >> >> >> >> >> 5. I'm not that keen on the "Possible Future Extensions" section of an >> RFC. Personally, I would prefer that this section is deleted, but if yo= u >> wish to retain it, then please can you move it to an appendix. >> >> >> >> OK with me to remove it >> >> >> >> >> >> >> >> Andy >> >> >> >> >> >> >> I've also included some minor comments inline below, and some nits at th= e >> end: >> >> Abstract >> >> This document defines an RPC operation to compare management >> datastores that comply with the NMDA architecture. >> >> The abstract is perhaps somewhat terse. Perhaps: >> >> This document defines a YANG RPC operation to compare the >> contents of network management datastores that comply with >> the NMDA architecture and return the differences in the >> YANG-Patch format. >> >> >> 1. Introduction >> >> The revised Network Management Datastore Architecture (NMDA) >> [RFC8342] introduces a set of new datastores that each hold YANG- >> defined data [RFC7950] and represent a different "viewpoint" on t= he >> data that is maintained by a server. New YANG datastores that ar= e >> introduced include , which contains validated >> configuration >> data that a client application intends to be in effect, and >> , which contains at least conceptually operational >> state >> data (such as statistics) as well as configuration data that is >> actually in effect. >> >> I would suggest deleting "at least conceptually", since the >> datastore does contain all operational state, but it may be implemented >> as a virtual construct that spans multiple nodes (e.g., linecards) and >> processes. >> >> >> NMDA introduces in effect a concept of "lifecycle" for management >> data, allowing to clearly distinguish between data that is part o= f >> a >> configuration that was supplied by a user, configuration data tha= t >> has actually been successfully applied and that is part of the >> operational state, and overall operational state that includes bo= th >> applied configuration data as well as status and statistics. >> >> "allowing to clearly distinguish" =3D> distinguishing" >> "status and statistics" =3D> "status information and statistics" >> >> >> As a result, data from the same management model can be reflected >> in >> multiple datastores. Clients need to specify the target datastor= e >> to >> be specific about which viewpoint of the data they want to access= . >> This way, an application can differentiate whether they are (for >> example) interested in the configuration that has been applied an= d >> is >> actually in effect, or in the configuration that was supplied by = a >> client and that is supposed to be in effect. >> >> Perhaps reword the last sentence to match the logical data flow in the >> server: >> >> For example, a client application can differentiate whether they are >> interested in the configuration supplied to a server and that is >> supposed to be in effect, or the configuration that has been applied >> and is >> actually in effect on the server. >> >> >> When configuration that is in effect is different from >> configuration >> that was applied, many issues can result. It becomes more >> difficult >> to operate the network properly due to limited visibility of actu= al >> status which makes it more difficult to analyze and understand wh= at >> is going on in the network. Services may be negatively affected >> (for >> example, breaking a service instance resulting in service is not >> properly delivered to a customer) and network resources be >> misallocated. >> >> Perhaps change "actual status" to "actual operational status". >> >> I also suggest changing the last sentence to: >> >> Services may be negatively affected (e.g., degrading or breaking a >> customer service) or network resources may be misallocated. >> >> >> 3. Definitions: >> >> It should probably define that , , (and perhaps >> ) are used to indicate names of datastores. >> >> It should also explain that is used as the name of a YANG RPC. >> >> >> 4. Data Model Overview >> >> At the core of the solution is a new management operation, >> , >> that allows to compare two datastores for the same data. >> >> Suggest rewording this first sentence to: >> >> The core of the solution is a new management operation, , >> that compares the data tree contents of two datastores. >> >> o target: The target identifies the datastore to compare against >> the >> source. >> >> Suggest adding an example ", e.g., ." >> >> o filter-spec: This is a choice between different filter >> constructs >> to identify the portions of the datastore to be retrieved. It >> acts as a node selector that specifies which data nodes are >> within >> the scope of the comparison and which nodes are outside the >> scope >> >> --000000000000f6aed405bd9b4f62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 15, 2021 at 10:29 AM joel= jaeggli <joelja@gmail.com> w= rote:
yeah when there is an update we'll probably drop a=C2=A0 remin= der in the list along with a link to the diff, but unless it looks major=C2= =A0 there's not reason to ask for re-approval.



It is actually a much more mino= r change than I thought when I first looked at it.
The new way is= better because the origin tracking feature is optional and the
c= urrent draft ignores this YANG feature.

=C2=A0
<= /div>
thanks
joel

Andy
=C2=A0

On = Mon, Mar 15, 2021 at 10:26 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Andy,

=C2=A0

FYI, this issue was discussed in the Netmod se= ssion on Friday.

=C2=A0

My interpretation of the chairs position is (<= a href=3D"https://www.youtube.com/watch?v=3DglLcpQ9kpv0" target=3D"_blank">= https://www.youtube.com/watch?v=3DglLcpQ9kpv0, starts at 6.10) is : As = long as the WG is copied on my AD review comments and proposed changes (which they have been), then= the WG has the opportunity to comment or object to the proposed changes if= they wish, and lack of comment from the WG is taken as a tacit acceptance = of the proposed changes.

=C2=A0

Given this, I think that the authors can apply= the mark ups based on the agreements below (and my original nits), republi= sh, and then hopefully we should be ready to progress this to IETF LC.

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 05 March 2021 18:46
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>; joel jaeggli <joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi Andy,

=C2=A0

I=E2=80=99m not sure which one you think is s a desi= gn change:=C2=A0 Do you mean issue 3 or issue 4 below?

=C2=A0

I see that my response to issue 4 may not have been = clear, so to clarify:

=C2=A0

By =E2=80=9Cokay=E2=80=9D, I meant, that I am okay w= ith how it is written in the current draft.=C2=A0 My presumption is that th= is could be addressed as a future version of the module if this turns out be an issue, or vendors can define their own augmentation if needed.

=C2=A0

If you think issue 3 is a design change that require= s WG consensus that I will leave it to the WG chairs to decide if they wish= to issue a consensus call for it.

=C2=A0

=C2=A0

=C2=A0

The change:

=C2=A0=C2=A0

=C2=A0 =C2=A0Current: default is to include origin a= ttributes and client adds exclude-origin leaf to turn this off

=C2=A0 =C2=A0Proposed: default is to exclude origin = attributes and client adds report-origin leaf to turn this on=

=C2=A0 =C2=A0 Also, report-origin has an if-feature = because origin support in NMDA is optional.

=C2=A0

I have no objections to this proposal.=

My point all along has been that this is not my deci= sion to make, it is a WG decision.

It does not seem that there are any objections to ma= king this change.

=C2=A0

=C2=A0

Regards,

Rob

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 05 March 2021 16:36
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: joel jaeggli <joelja@gmail.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) = <rwilton@cisco.co= m> wrote:

Hi Andy, authors,

=C2=A0

=C2=A0

=C2=A0

I think you mean to address this to the WG since the= redesign issues need WG approval.

I have no objections to any changes.=C2=A0=C2=A0<= /u>

=C2=A0

=C2=A0

Andy

=C2=A0

Sorry for the long delay in replying.<= /p>

=C2=A0

Please see [RW] inline below =E2=80=A6=

=C2=A0

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 30 October 2020 01:43
To: joel jaeggli <joelja@gmail.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; draft-ietf-netmod-nmda-diff.all@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli <joelja@gmail.com>= wrote:

Rob,=C2=A0

=C2=A0

These seem like reasonable suggestions.=C2=A0=

=C2=A0

Lets see what the authors say.

=C2=A0

Thanks for this

joel

=C2=A0

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton)= <rwilton@cisco.c= om> wrote:

Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.=C2=A0 Apologies fo= r the delay.

Thank you for writing this document, I think that it is useful, and looks l= ike it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are suppo= rted by a device?=C2=A0 E.g., pointing them to either YANG library, or prot= ocol specific mechanisms in the case of RESTCONF.

=C2=A0

Do you have a section in mind and suggested text?=

[RW]

Perhaps somewhere in section 4, either as part= of the description of source, or perhaps before the parameters are describ= ed.

=C2=A0

Proposed text:

=E2=80=9CA client can discover which datastores a server supports by = reading YANG library [RFC 8525] from the operational state datastore.=E2=80= =9D

=C2=A0

=C2=A0

=C2=A0

2. It might be helpful = to add a comment about potential issues that could arise by comparing <r= unning> to <operational>, i.e., additional differences could be re= ported due to inactive configuration and template processing between <running> and <oper= ational>.

=C2=A0

Do you have a section in mind and suggested text?=

You mean if there are differences between <runnin= g> and <intended>

then a diff between <running> and <operatio= nal> will not be the same

as a diff between <intended> and <operation= al>.?

=C2=A0

[RW]

My main concern is that if you have template e= xpansion then comparing <running> and <operational> may not rea= lly give a meaningful comparison, since <running> is pre-template expansion, and <operational> (and <intended>) are both post te= mplate expansion.

=C2=A0

I would suggest putting some text in section 4= or perhaps the YANG module.

=C2=A0

Perhaps some text, something like:

=C2=A0

=C2=A0 =E2=80=9CClients should to be aware tha= t comparing <running> to <operational> will report differences = due to any configuration transformation (e.g., inactive configuration, or t= he expansion of templates) between the <running> and <intended> d= atastores.=C2=A0 In these scenarios, clients may get a more useful result b= y comparing the <intended> and <operational> datastores instead= .=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

=C2=A0

3. I would prefer if 'exclude=3Dorigin' was = in the reverse sense and perhaps called 'report-origin' instead.=C2= =A0 With the reverse sense it seems to be safer if new datastores are defin= ed, where otherwise the behaviour could end being under specified.

=C2=A0

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changed

then the draft should go back to the WG for changes = and new WG consensus calls.

[RW]

=C2=A0

I don=E2=80=99t see this as really changing th= e functional requirements, but just changing the default sense and name of = an API parameter.=C2=A0 Although, given my comments below =E2=80=9Cwith-ori= gin=E2=80=9D might be better than =E2=80=9Creport-origin=E2=80=9D.

=C2=A0

In RFC 8526, the =E2=80=9Cwith-origin=E2=80=9D= parameter is off by default, and origin metadata is only included when the= parameter is included.=C2=A0 This keyword is also under a feature.=

=C2=A0

So, changing the parameter name to =E2=80=9Cwi= th-origin=E2=80=9D and putting it under =E2=80=9Dif-feature ietf-netconf-nm= da:origin=E2=80=9D, and making the default off, would make the definition m= ore consistent with RFC 8526.

=C2=A0

=C2=A0


4. Should there be an option to filter on origin metadata?=C2=A0 E.g., only= include values that come from intended.=C2=A0 Otherwise, things like IP ad= dresses learned from DHCP may always turn up as differences.<= /p>

=C2=A0

IMO the WG already designed the features so if the f= unctional requirements have changedthen the draft should go back to the WG = for changes and new WG consensus calls.

=C2=A0

[RW]

=C2=A0

Okay.

=C2=A0

Regards,

Rob

=C2=A0

=C2=A0


5. I'm not that keen on the "Possible Future Extensions" sect= ion of an RFC.=C2=A0 Personally, I would prefer that this section is delete= d, but if you wish to retain it, then please can you move it to an appendix= .

=C2=A0

OK with me to remove it

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0


I've also included some minor comments inline below, and some nits at t= he end:

=C2=A0 =C2=A0 Abstract

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines an RPC operation to compar= e management
=C2=A0 =C2=A0 =C2=A0 =C2=A0datastores that comply with the NMDA architectur= e.

The abstract is perhaps somewhat terse.=C2=A0 Perhaps:

=C2=A0 =C2=A0 This document defines a YANG RPC operation to compare the
=C2=A0 =C2=A0 contents of network management datastores that comply with =C2=A0 =C2=A0 the NMDA architecture and return the differences in the
=C2=A0 =C2=A0 YANG-Patch format.


=C2=A0 =C2=A0 1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0 =C2=A0The revised Network Management Datastore Archite= cture (NMDA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC8342] introduces a set of new datastores tha= t each hold YANG-
=C2=A0 =C2=A0 =C2=A0 =C2=A0defined data [RFC7950] and represent a different= "viewpoint" on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that is maintained by a server.=C2=A0 New Y= ANG datastores that are
=C2=A0 =C2=A0 =C2=A0 =C2=A0introduced include <intended>, which conta= ins validated configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0data that a client application intends to be in = effect, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0<operational>, which contains at least con= ceptually operational state
=C2=A0 =C2=A0 =C2=A0 =C2=A0data (such as statistics) as well as configurati= on data that is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect.

I would suggest deleting "at least conceptually", since the <o= perational>
datastore does contain all operational state, but it may be implemented as = a virtual construct that spans multiple nodes (e.g., linecards) and process= es.


=C2=A0 =C2=A0 =C2=A0 =C2=A0NMDA introduces in effect a concept of "lif= ecycle" for management
=C2=A0 =C2=A0 =C2=A0 =C2=A0data, allowing to clearly distinguish between da= ta that is part of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration that was supplied by a user, confi= guration data that
=C2=A0 =C2=A0 =C2=A0 =C2=A0has actually been successfully applied and that = is part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0operational state, and overall operational state= that includes both
=C2=A0 =C2=A0 =C2=A0 =C2=A0applied configuration data as well as status and= statistics.

"allowing to clearly distinguish" =3D> distinguishing" "status and statistics" =3D> "status information and stat= istics"


=C2=A0 =C2=A0 =C2=A0 =C2=A0As a result, data from the same management model= can be reflected in
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple datastores.=C2=A0 Clients need to speci= fy the target datastore to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be specific about which viewpoint of the data th= ey want to access.
=C2=A0 =C2=A0 =C2=A0 =C2=A0This way, an application can differentiate wheth= er they are (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example) interested in the configuration that ha= s been applied and is
=C2=A0 =C2=A0 =C2=A0 =C2=A0actually in effect, or in the configuration that= was supplied by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0client and that is supposed to be in effect.

Perhaps reword the last sentence to match the logical data flow in the serv= er:

=C2=A0 =C2=A0For example, a client application can differentiate whether th= ey are
=C2=A0 =C2=A0interested in the configuration supplied to a server and that = is
=C2=A0 =C2=A0supposed to be in effect, or the configuration that has been a= pplied and is
=C2=A0 =C2=A0actually in effect on the server.


=C2=A0 =C2=A0 =C2=A0 =C2=A0When configuration that is in effect is differen= t from configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0that was applied, many issues can result.=C2=A0 = It becomes more difficult
=C2=A0 =C2=A0 =C2=A0 =C2=A0to operate the network properly due to limited v= isibility of actual
=C2=A0 =C2=A0 =C2=A0 =C2=A0status which makes it more difficult to analyze = and understand what
=C2=A0 =C2=A0 =C2=A0 =C2=A0is going on in the network.=C2=A0 Services may b= e negatively affected (for
=C2=A0 =C2=A0 =C2=A0 =C2=A0example, breaking a service instance resulting i= n service is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0properly delivered to a customer) and network re= sources be
=C2=A0 =C2=A0 =C2=A0 =C2=A0misallocated.

Perhaps change "actual status" to "actual operational status= ".

I also suggest changing the last sentence to:

=C2=A0 =C2=A0 Services may be negatively affected (e.g., degrading or break= ing a customer service) or network resources may be misallocated.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Definitions:

It should probably define that <intended>, <operational>, (and = perhaps <running>) are used to indicate names of datastores.

It should also explain that <compare> is used as the name of a YANG R= PC.


=C2=A0 =C2=A0 4.=C2=A0 Data Model Overview

=C2=A0 =C2=A0 =C2=A0 =C2=A0At the core of the solution is a new management = operation, <compare>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0that allows to compare two datastores for the sa= me data.

Suggest rewording this first sentence to:

=C2=A0 The core of the solution is a new management operation, <compare&= gt;,
=C2=A0 that compares the data tree contents of two datastores.

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 target: The target identifies the datast= ore to compare against the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 source.

Suggest adding an example ", e.g., <operational>."

=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 filter-spec: This is a choice between di= fferent filter constructs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to identify the portions of the datastor= e to be retrieved.=C2=A0 It
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acts as a node selector that specifies w= hich data nodes are within
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the scope of the comparison and which no= des are outside the scope

--000000000000f6aed405bd9b4f62-- From nobody Tue Mar 16 05:37:01 2021 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 0402C3A0BED for ; Tue, 16 Mar 2021 05:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_g6ktmNGGPu for ; Tue, 16 Mar 2021 05:36:58 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2074.outbound.protection.outlook.com [40.107.22.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6173A0BEC for ; Tue, 16 Mar 2021 05:36:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KXnqNhA1U92A78auj9as8hs/4f1XdlepHXcxxEwErMxVq2ue2qug9taz8yiJ791s9WaHp+MdHycQBhGeampDd4HH6YGsXybjWtSMQaw4LueLmT7LlSIvFJ4Hz5an0R8adP6v5sthdQwd2Iz1qvbC8tq3Ak7myzYeDlscebdvRJsrsvbkVLEQMiatA0sfr9+c/vnPIZ3U6C7nMUxqxrLS6G52BRUR8YM8hWk+A/R/NWp2+gj/2Srns9EdoPu52K6pbAnK57lzVM84GIRKeqBH37i1X8B063sdI69ZWOmb+WD3su8yh+qz54GKhdQ0CiyrueRijwt7iVT+spe8uRonvA== 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=pq5HV5ThhOEoiczxD3RRBay4Lw4a/PcNUMxlqUWQIw8=; b=kITqXz83Kq20Ns3x6wPxdEIYzoiVIxJZ1GzrFM4i4G6eQki3vMrnwRekbF3kvmkyKuI/KyiJg+95bOeKo7ATmUDnzFWYxm4TxEc9Zg9q4SvQItaRj9ss7IzJk9sOwcunGFMBXzVieEZqS0wku3G8+CP7lA+oWGt95orvZztuLmWKxYXpgRZucURK+IWC5GXNvPCq4fXt4w2tbTWSmIwQXq2U0GrnSqIzBNbBc8u+TcaecQQ+kpahXmsXkoGBsMLvfbzD5T0BsJxhnhnKsfGXtmZxY2n3mu0U0Xc59dNI94MRqc/ZgGx1guIF//HMeiJxbt0EjOkRk10dC8CMeI3Vew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pq5HV5ThhOEoiczxD3RRBay4Lw4a/PcNUMxlqUWQIw8=; b=Qw+cHqtB6ZAtgTz1IxIiKTPOprzDwLB1IUD6vnmoREHTq+yYh6Q+SMGcfXpOhDaVhQioD4z0eCmeeR8MmymclGNcS/QX5e26vuXdX4O2h1OWa6bPS5jSrEt3PokG0p606UKeDe5TyhHapDh/NdQcr7n6RnJYyimuoH/XZsoN6ys= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=lightside-instruments.com; Received: from AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) by AM0PR08MB4244.eurprd08.prod.outlook.com (2603:10a6:208:13b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Tue, 16 Mar 2021 12:36:55 +0000 Received: from AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::9c32:3b20:c739:c891]) by AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::9c32:3b20:c739:c891%7]) with mapi id 15.20.3933.032; Tue, 16 Mar 2021 12:36:55 +0000 To: "netmod@ietf.org" From: Vladimir Vassilev Message-ID: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> Date: Tue, 16 Mar 2021 13:36:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [84.209.6.28] X-ClientProxiedBy: OL1P279CA0046.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::15) To AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.19] (84.209.6.28) by OL1P279CA0046.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31 via Frontend Transport; Tue, 16 Mar 2021 12:36:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 77ecfdff-f6d3-4f97-9dc4-08d8e8782ed2 X-MS-TrafficTypeDiagnostic: AM0PR08MB4244: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gIsfs9Z5429EWdYtk5U9rCZYf8lXOjYy3mrgjVsjUkXf/oP+u2FBK/hYcqNFMSZhiL23csAthlv4gbm0BSuNs/YXIIITcSUh2ljSPi0FbwQEwUwWMWASN3wjUsSCFc/KDV46dg1NYystQOUi8UByuR2REKonMJg0BfWbjsKyEnjdMAHT4dwwL/2IvFSVswimXLwCt295udo74SgagFieUtCxoxbAdB0rbDl5seuJ5juQwABP6pBdseCG7J5G/uz9kpXgFP4dWYBivZ5jcw2k0aa7uKvsa6dGb8oqSIaKltWd0dcrsCAajs0EvUUQcdV2Fx3P50DrB/N1XYe6lQURFb/vTfimx05KqNR4NfYoBxBxFrSY7Wu714t9S08B93o1Lnhmo0WCZ41l2BEadf8JSXiguMbE7JfjNuuYci3ouzAQK/naVJlPN2NrTvBpgdhmatyfNYnlybpaqeTpglmuVtrk79OIINlVNqY+cIg3qlrMdjyHaOFMXeOsvJbpF+lo+o0rlGO8YAZvswJhv91N8EtwTRacQUuACQXLt03+kdfdwXjH7DjEv4PlI1f7loDDdo11JHLMAThLLiJaJ9/GtTOTIwPGRBk72vTq/jWHvXuXciUNtdwaFLzT8pX9d5FBUK+taaeWuivLgoSyWRYfbw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB4084.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(39830400003)(136003)(366004)(376002)(52116002)(83380400001)(186003)(8936002)(36756003)(16526019)(478600001)(16576012)(66556008)(6666004)(66476007)(31686004)(66946007)(316002)(6916009)(2616005)(26005)(31696002)(956004)(8676002)(86362001)(2906002)(4744005)(5660300002)(6486002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?MG1uMkVOaDIrREN4RTRkY3VQWVgvR3MzTmxDWDh2QmxXSkNTbVpJU0lrMitV?= =?utf-8?B?WXdzdWtrTXVoanNnNVNmNUt0cjNQQ3FSTVpSK3dKeFA1NlBOUUJOQUMxUEJV?= =?utf-8?B?ODhFUUZaNmFmb2pUQ0Y1SG4vT1ZhclVhaGR3Q0MzUlVOUVF4K2tubWN3VUhh?= =?utf-8?B?cm4zMkpTMXhER2I0NlRaNm5mRkRBeFBGR1h5QTgveFQ5Sm9CLzVST29OODRz?= =?utf-8?B?aGV1WXh0VWZKTEcrY1Rac3lKdFNHZ1hRa2phTG94bzNNMmp6bUdiY2pCSEdz?= =?utf-8?B?Q1ZObjhoZnFwZkFTRkp3eWZmRnpCNXFwdVVvcTRFaUQwMldMTUtJbWxuL0Nk?= =?utf-8?B?UzBYc3h0c0h3T0M1ck5JZzI3YkVTME9hb21jLzF5MndlWkpEM3MwN1FSR2Fv?= =?utf-8?B?THNPalBPd0o3a2l0Y29nMVFxZlFUcDhCbjJNcE8rRW91eGlpNzVzSVpnZ29K?= =?utf-8?B?QTdscjBOZnBQbVBqME5yRDJLRzlackFGa2hFejJTZU4wZ2JneGFHQm9XZGZM?= =?utf-8?B?V1dQb0lKTTBrcUlZK0dNQitRYWtCZmpENEQ3U3JGZm9FVTlOV3FPMkMwVllM?= =?utf-8?B?N0FVbTVRL0ZiYTN1dDNBeUxZbHB4TzdHaFgrb2JTMGc3QWtvdTJmOWJXT3ZK?= =?utf-8?B?QUF4MmZSZld1aXQ2elVrWHVXQUlSMUlWL0NlWjJKZTU2c2NqT29vVTl0eGl6?= =?utf-8?B?MXRhamtIWmtFNEZEZk5JT0hYandFOUVPTlloRUl1VUNJaW1XUzBlelU4K0xu?= =?utf-8?B?Zm9iYUw0YUxRc1d1eEZsS0xWZUJiZkRaa1ZuM2Y5VDI4SkJYckt3ZS9EU3pw?= =?utf-8?B?R2pZelkyeFNPeXV6NFNDR3RsU2wzQU9WRGdKdUVoOUhSS0kxUzM3QVNXZ2ti?= =?utf-8?B?dGh1eHZsUWZjWDdxYWtxeTl0UFYwNCtZNHlCWHlhSHlSb1d1L3dueHFXanlR?= =?utf-8?B?Tm5VT1ZTYU4zVmZ3bHVZODRnYUZjcUZCQkcvN2RNYlFTQThwbFphNUJxTFdV?= =?utf-8?B?RDFWam5hNGQwTWFFWElNcHFaT0ZhL2JCQkluV2NSbURCUXJJUlEwMEV2K0Ni?= =?utf-8?B?eHdOTnhUY1Excmx1cTNLTDJvRHV0eTVQd25CeHZUejlCT0lGaVE4RXQyU2VN?= =?utf-8?B?UnM0VWFjb3FkUVM3cFprNWh3MzdKVldhb2RHenJvaVRYQjdUOGE4MVhGMFBY?= =?utf-8?B?L2hBUk55SlJnb3BRcCtSLzV5WlFWK3VCZWwweUdtVlhJNEZuV0hpOVRNRWxt?= =?utf-8?B?SG9Dc3JiTGU2OTdTNUhDNW50Wlc2L1hsaEE0TWp5TTFrM0hSOTVtN2lSZEhX?= =?utf-8?B?L2pvMXp3QXJXbUxITE5lQzIwL2lrZ1ZzUVBBa1hpZm5xdW9TbStJMFJaZUox?= =?utf-8?B?bnFhWjloNitIZW1uU0tZUTVjNFNoaDZQOWhpNloveWZqSVhMVEp0cXp2bVZG?= =?utf-8?B?RnhXczZ2dHQvT0NEbmZGbmpCOThrMFZ0cmx2YXFXeURJckJkd1ozbTQzMmhH?= =?utf-8?B?RkVvc1FxU2FoY0RyZnJSdVU0S3M1UWJUZWYycWpNb2tOdDJsc1g0d0tYV3M5?= =?utf-8?B?TUZ0UWJUWlhSNGd0T3pwS2hqeW1wck9nelQ2dnpySnZ3VlcyU1BFWUZUYlRq?= =?utf-8?B?RVZZUk1CZEE5aG9hcEF5Q0hRaTRSZUE3MlFEWnJNait4ZjN6b216eDFGV05P?= =?utf-8?B?b2RnMmpPM0o4cFJ2YkVXc2RoUm10bDdHVFRrcFhxNlExSmFoNUR3L3M3ZG1n?= =?utf-8?Q?mY6rU/MHX713LDoOBNddCNIvzyvJEN9n7qnpNhQ?= X-OriginatorOrg: lightside-instruments.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77ecfdff-f6d3-4f97-9dc4-08d8e8782ed2 X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB4084.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2021 12:36:55.7926 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c0326317-f373-4461-a96f-7946e0abb603 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SlcsAk9i3rao3bhUNnChNsPsbKuFUgvmQACnLnmzwDt4Y1ATWrnw2QjIWC52h7ZoN9ZaTRN5rbxumUZRDLVJr/W7FXIU/rOgNjvkt7V6yPkLLIk9Zpcz+g4hrI1qZx8u X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4244 Archived-At: Subject: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 12:37:00 -0000 Hei, Many drafts and RFCs are flagged with warnings by the tracker validation tools: ... yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p {draftlib} -p {ianalib} -p {cataloglib} {model} -i: warn: Module's revisions are not unique (2018-06-28). ... Does anyone know what causes this warning? Vladimir From nobody Tue Mar 16 11:44:44 2021 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 321D93A0E23 for ; Tue, 16 Mar 2021 11:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRQINTPDH7Ru for ; Tue, 16 Mar 2021 11:44:40 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994FB3A0E1E for ; Tue, 16 Mar 2021 11:44:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eiEcTPicFQw3wcmdZYOgV6qH9KhAB6huzwSQyL4PCpLvMMw4MGlPbtuG4ymNxXXwvD8WSnk/ZcSPWeFCES3e3ZsN/YjOdcN7yqWM+CVER4ttf8iK7d87VKQbu3rg2/NcxeAJ96Xfy0+dDITXq7xUqi7uIi4s3PzzY0J+yNAbwYNp93jHPNhTzkSll03B0x5uiuHu4KnvQFSNJJk3WaufYGVZ7mQCtVx4LYTJTedxT+Q7JYK0UIwc0Z1dl+pz9AWyn/v72rTWfk8l4ps4VhmviebCJIkgRwjuGhA//am7rjvuwBgGAz4+79yXKNRAR8Y6vAtaegiJ+qp0EsFcj/5nGA== 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=Dkx6EBjsVHR5ez9P+1aOuZ7iFVQRbTK+QEckLrW+yiQ=; b=oSQlSxY8b8iD9BlXHTw1OHcw5prJ3aiWp/PROK3VwI3cVAq5qcrw9xXK9QfkbYCw1PmQLOCRHP5uizS02d1Q/Ot0+2iAlbhvbMkEOr0M+RPyYUGGarKm2aYTUZTpYZTo9knNDkn1PTZtMTjhVOThxPRQE0zbJabBWeD8u3d95z++Syd0+3onR/c5qikrSJxTMn+If6sZ8HPhpkDe7/w0uDkN/IcvBzPzcSKMFnpPntWP0xafFUGgjr7BeARX9q7OD+tO/kOW6EdvMVnjEbT0x19Ycpv7NlzyCE234R+YE+DnT8qtPzvbqD1AGOFeHcrx30eV5TqLAknRk/hqEZDTjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dkx6EBjsVHR5ez9P+1aOuZ7iFVQRbTK+QEckLrW+yiQ=; b=iN7o0sR1Epz0OBe1zzbiq0rRelOqhixiD/BAKzrK6qIKTO183W8mG+3uWyBNz64YeCZIJPcNlv+n24wjxSFgmBSCG+aNFvHxW0z1Q6fAAcKo0F+B7XU8JztaUYghDN7PyKpF2FIDqwYDeiOad6GgaCAz+2ye1hhxGOLBwF/08oo= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1156.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Tue, 16 Mar 2021 18:44:37 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.3933.032; Tue, 16 Mar 2021 18:44:37 +0000 Date: Tue, 16 Mar 2021 19:44:36 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20210316184436.ibpp5rfctmjllhdw@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: netmod@ietf.org References: <20210222092455.qupjm2d4lpm4ay4n@anna.jacobs.jacobs-university.de> <20210222.104938.680142326480637892.id@4668.se> <20210222100857.ovetw7udo4ccbezx@anna.jacobs.jacobs-university.de> <20210222.111343.254950973345362316.id@4668.se> <04B94A94-236A-44CE-B47C-BE5F36FFF278@tzi.org> <20210222135333.t4hfa3ekguwm33pm@anna.jacobs.jacobs-university.de> <20210222141715.vhzqka77yzhbkpst@anna.jacobs.jacobs-university.de> <450E683C-4F47-4314-BA63-DAC17AF60970@tzi.org> <20210224203915.2ysjgjv6izjoh6to@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210224203915.2ysjgjv6izjoh6to@anna.jacobs.jacobs-university.de> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR10CA0122.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::39) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR10CA0122.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32 via Frontend Transport; Tue, 16 Mar 2021 18:44:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: af5d26e9-8a30-4172-0591-08d8e8ab8cb0 X-MS-TrafficTypeDiagnostic: AM9P190MB1156: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0WrVBxGD5dwuYGG2isC6Zary18udge8DrFRubi2BZ42ByywOkiLTVN62hTWVBPrxlM1fOzUXAG2Tja0qlFEa0jLPIiEkWag2yPEyH1eoWbD+G+Ur0wTGZRmeVg/XyzfCG6HjrM7OLL3p3GTlcX/rHuWUzoVeExI6l8miWcJHZrS5JMEfvkZ3dgRsbVGc/nGpWmAo1pVNAjzxuBmdneIWgLhw+KB/MrMzP1V71sbb7Uz47d8sq3IPWpsJrPzDlYJx2lky0isZYongg/d2NkDQyK2pk3P1hlT51AX6mtJlexfyCEJG3vu/qS9yvE6ElwucMb95QFQDCWWNqYH/VkvBUBlDgyaAjUOWxmC1RzO9XaV+OaFJ/NCMTXiInb4bgv26wv3kxgeUxDdbewbHbEZA1xKnUVBBRlNPngzt50ZgThMvsM5kN+kqkzKMbUXtEC1FK4Atso9jZ7jQBWFEkWOwRBA59Ru4gAsEt7as+WHfjDw77vBB6niUUYkPH2l64znKmDPUNrvpTr+4k4XDpfyErlgU6BrXhDRL/JrfRlHU8J7oQQgjt/hUBVq1CANPEN8LbFkRi5IXmXC5aH0Y74HAKiDNjkdSOKxbx6NFtgJVXU4Yilm5ESMtFKBv9w/+O91xyCIUHa5WZFlmx11hkpQQRQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(39850400004)(376002)(366004)(396003)(346002)(316002)(478600001)(26005)(66476007)(786003)(6496006)(3450700001)(1076003)(16526019)(956004)(8676002)(5660300002)(86362001)(186003)(52116002)(2906002)(66556008)(8936002)(6916009)(66946007)(6486002)(53546011); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?FgUacYZsRcgVGNx424iuXvDFarsMLTo3ZmnJ483Wj2PZYKhxG4TVnUplso?= =?iso-8859-1?Q?ytjpXLAwMfi0GvNcFmNZ1vzx5vrFRa/yxXLOrghY8/6HOmYUPFkRAZbyQW?= =?iso-8859-1?Q?4s7GoaWU9QTIaI/htVqaBNAYtXxPNQHJAJhCfaGM3WYMKEVyE+Y/yy4epg?= =?iso-8859-1?Q?rIkLXz1++y0zKTCgDRZ3U3kErGxG+BAfvB44dg3iNweEqmapN8aEcX2ywz?= =?iso-8859-1?Q?o3+URXu6Uzh67P1YPX2XcxLzJBKNndkW0XhpXwmkqa2jFeYx/SlG07T73b?= =?iso-8859-1?Q?3JtDVYu6KIzhMmLVIEKxEYdp2NDU6wghzlKeTC4hC8nEOOh8GfVmU0d175?= =?iso-8859-1?Q?khGg3FXl+dNoJKcAxrGQVYwprRSFX5JoWWYkGc/MS+QmzpB3VK1C8jCw4A?= =?iso-8859-1?Q?Bqc0k/Q+gK1pW8fcnzBUki3uYGe85UewA8lGMI7ZDb6UfMEyEzxogB9JWi?= =?iso-8859-1?Q?3VP/zpfOXIS0KvPqRUZKUpRBl+N898S9rptkR0yd3YLyP0H8ZZ1wftgTOi?= =?iso-8859-1?Q?UnyBaFvOmpI8gTMAvtvftvhYWUwRTUx3L11T/sNCbUZXt1Nq5f97B8/5Ik?= =?iso-8859-1?Q?IM6zyj5DU4fIqWSK8a6+otWaHckbHZV0dJWYM9+70qsI5ILyirTqGTm9g1?= =?iso-8859-1?Q?XDeiHmr/2wMtTO67OnPONdVTxgsTOGJ1fa12+Tpi/0js9QzoQmAo0T8LBy?= =?iso-8859-1?Q?xsR5bkbf9eYFpuwBxfLeiutSRhn8LrFuhGBCTF3Rpj/Yn1IJlkw455AncF?= =?iso-8859-1?Q?LhE/CUMFOvtIOT3x94fvIschg2w1PhWw5i+RqxOUW299I1QVPhhekTC50/?= =?iso-8859-1?Q?Zo/6lNiwKHf1RxLiTnvvg0LuX07tkvUbs467O7P+kLThk+zy6moi7r3FmH?= =?iso-8859-1?Q?3vtfx3q7g6GqgDu+QyOkYwkwM7MYiX4mTB++kUMKUF6gB45v9ZJrqhOMkI?= =?iso-8859-1?Q?7XGDNgWfE2cPDaunLxl08Q0mdAshDQh8JHzQTVHr1L6bP2iVBHkNschMPa?= =?iso-8859-1?Q?ydGXSnLc+6qFsAdYsagdhTxSQwzdHxv9T7FWjBtBeWsACnrEp+lJWz5k+L?= =?iso-8859-1?Q?smFcyMZ9EexftNXXXBybHaFNHhiWc+HlqQW6pX3kCfuLkG42EWGYK221xJ?= =?iso-8859-1?Q?iDYY0I93ob/lez8LACSFyrQfBqPSYKk8hn/bmgyT3UilR/JrcXiCgP0+Tm?= =?iso-8859-1?Q?batkNTdZU6OkwtcuKXHhs3k4VgTDCr3n7/a3cCqgt7477IIyhaEvQ/+XzA?= =?iso-8859-1?Q?C4SZuAT+hMJEqJknJr9AyJ0K2VgBUSGjbOHy/QSaW2tXBvhT71jWc9hfxh?= =?iso-8859-1?Q?d+xCOhjVE+kdGZnghK3JNcJTkLA00+Xj2KqXXzD37yP+zae6RgTFLt8q3g?= =?iso-8859-1?Q?voMlT/0Y1t?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: af5d26e9-8a30-4172-0591-08d8e8ab8cb0 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2021 18:44:37.1876 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: KOpQnH+TV6CNs+bratd98aMPHmbdmGtF5tuSghzWwF1tsVX6Cy0yurOc/fnI888LVDQi7rPwQCfp+w6GS38TLRc2IheXdqJ/bKGPEudEx8Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1156 Archived-At: Subject: Re: [netmod] type equivalence X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 18:44:42 -0000 After some iteration with Rob, here is a new version: NEW''' o A "type" statement may be replaced with another "type" statement as long as the underlying built-in type and the representation and semantics of the type do not change (other than allowed by other rules in this section). For example, an inline type definition may be replaced with a semantically equivalent typedef derived from the same built-in type, but an int8 type cannot be replaced by an int16 type, since the underlying built-in type would change. /js On Wed, Feb 24, 2021 at 09:39:15PM +0100, Juergen Schoenwaelder wrote: > Here is an attempt to come up with better wording. If people agree on > a new wording, I volunteer to submit an errata. > > OLD > > o A "type" statement may be replaced with another "type" statement > that does not change the syntax or semantics of the type. For > example, an inline type definition may be replaced with a typedef, > but an int8 type cannot be replaced by an int16, since the syntax > would change. > > NEW > > o A "type" statement may be replaced with another "type" statement > that does not change the semantics of the type or the underlying > built-in type. For example, an inline type definition may be > replaced with a semantically equivalent typedef derived from the > same built-in type, but an int8 type cannot be replaced by an > int16, since the underlying built-in type would change. > > /js > > On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote: > > On 2021-02-22, at 15:17, Juergen Schoenwaelder wrote: > > > > > > I guess considering the built-in types as incompatible is the most > > > robust approach. If we agree that RFC 7950 tried to say this, we could > > > file an errata and propose clearer language. > > > > Right. And we can keep the COMI key-to-URL mapping as is, as this clarification is necessary for its correct functioning. > > > > Grüße, Carsten > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Mar 16 12:57:45 2021 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 920AF3A0EF0 for ; Tue, 16 Mar 2021 12:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8tGgA6aU6Rwi for ; Tue, 16 Mar 2021 12:57:39 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4991A3A0EE8 for ; Tue, 16 Mar 2021 12:57:39 -0700 (PDT) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4F0PG875jMzyVS; Tue, 16 Mar 2021 20:57:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <20210316184436.ibpp5rfctmjllhdw@anna.jacobs.jacobs-university.de> Date: Tue, 16 Mar 2021 20:57:36 +0100 Cc: netmod@ietf.org X-Mao-Original-Outgoing-Id: 637617456.7999099-11d0691b109cc04d0d48d233b68888c3 Content-Transfer-Encoding: quoted-printable Message-Id: <69770096-61F1-4E38-A4AE-432597912939@tzi.org> References: <20210222092455.qupjm2d4lpm4ay4n@anna.jacobs.jacobs-university.de> <20210222.104938.680142326480637892.id@4668.se> <20210222100857.ovetw7udo4ccbezx@anna.jacobs.jacobs-university.de> <20210222.111343.254950973345362316.id@4668.se> <04B94A94-236A-44CE-B47C-BE5F36FFF278@tzi.org> <20210222135333.t4hfa3ekguwm33pm@anna.jacobs.jacobs-university.de> <20210222141715.vhzqka77yzhbkpst@anna.jacobs.jacobs-university.de> <450E683C-4F47-4314-BA63-DAC17AF60970@tzi.org> <20210224203915.2ysjgjv6izjoh6to@anna.jacobs.jacobs-university.de> <20210316184436.ibpp5rfctmjllhdw@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netmod] type equivalence X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 19:57:43 -0000 On 2021-03-16, at 19:44, Juergen Schoenwaelder = wrote: >=20 > representation There are several representations. Which one is meant? Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 17 03:31:17 2021 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 DD09F3A117B for ; Wed, 17 Mar 2021 03:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28qFZZnmz9RH for ; Wed, 17 Mar 2021 03:31:13 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60132.outbound.protection.outlook.com [40.107.6.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4113A1178 for ; Wed, 17 Mar 2021 03:31:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CMkTamzXCSCeVTFAGUKTqKIgdqCwGfNftjIUmLipMcL1hlmpg+NAEwKrNpKR3QYd3J/38Zeej1Vtdfwv7BaoqbwuZCVP61u7ETXHEUolasyv5FscggaSX0TTwYh+31iFw1gZSRwzI1ypPUj8pWC+DigW3M/k64xxCL5QZSecKdV0h9aKaVwa/leeURbanBPMEUUrTdh6qfFf2NL7OUBdfZS5BAKulEHLk2xhA5mrETmFCowtdeDmvUGWTB0QNA+gUuAErfRc3H4yBVqLod8vWK+GrIWpAKNaRM/Va1TISW9cAQya4qFn2ldynybNi5p/9+QRVINx4VYgz3fwGjSZKw== 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=4c5XA504lJhLfYRsjWKrhwd9D0FEL2/3nn62133CC/M=; b=WtY5+sRb+R0ge/HZ33P1i1d8AdcM/7W/yWfDDb+1VZsrGwPIdZgStBp2qAlFX2CO/01mh7TL5Kc6GNSL0vKfj+WH8wLb8UDCKxGKLebKff0kx7rBNn9ustxGMIUG5FEyjc3HcmACSIObqMiU8EF4Ddlmnk5xroHfe/R4Ivhogv7wEq8AsQBkP9LVz2Tvq20Glu77RiqeD983hZ86yobxi/J/DjGW3Hcr7SrTZJIAjCoT3FHIMyP67pUJfVyNCFOGiTuBOGF7vjjoIV9irNJUXyDtprxl0V8YAax+MqFr3t/opw+1cOIkZzIIy/0ILKuYjUupFYBa8gbdCums8mBLNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4c5XA504lJhLfYRsjWKrhwd9D0FEL2/3nn62133CC/M=; b=SxXuea4/NSTO5Bi5NQkMPNXnCS+IruGBlxq7rHSTCDoU63Mk6rMJGWSocq6TQoMna30Wl+pDtVnrjHcHTTp55JtkhIgLcaHQ8CSduwuPxu8BoUIfmgnnX35VPihE3c+PJ0QvETZ2fIeOeeOlhX2QhiqfHUmX4vKks/hFSuIaq1M= Received: from AM6PR06MB5653.eurprd06.prod.outlook.com (2603:10a6:20b:96::26) by AS8PR06MB8104.eurprd06.prod.outlook.com (2603:10a6:20b:3c2::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 10:31:10 +0000 Received: from AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::7d8b:c44e:9517:5ad8]) by AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::7d8b:c44e:9517:5ad8%3]) with mapi id 15.20.3955.018; Wed, 17 Mar 2021 10:31:10 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: "netmod@ietf.org" Thread-Topic: Request for improvement in ACL YANG Model: add prefix-list to the match Thread-Index: AdcbGExc8OTG49eVSoeJejnhX1jHZw== Date: Wed, 17 Mar 2021 10:31:10 +0000 Message-ID: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telefonica.com; x-originating-ip: [79.152.139.53] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 642c6dbc-6ec5-4cd4-510f-08d8e92fc82e x-ms-traffictypediagnostic: AS8PR06MB8104: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sFR0axs1y6BklQJqxzA+NyPWsCcRHSA71zyBvwTceagAAJspTtwV3HYhZSQbv2UBSiTzX/da4zJiDE2X5DzaftnpNVZWAdxVuJfHeqU3mEko+NSnFDRz8latVnfok3lNRSqCakSJ3298l+9vhuNq3gbbRuBkAicj4suF5/imFR4jB20xANMzHskS96oPuYfTShv+QNAVTMWelCsBgZZzg29+ZTge33/Sj+bq2uRzGqjSLKE9NHftn8341J4W+ojk200TST219PyTxbu5HjMHblwYTtnHWBdFYlRQtOs3kIoBKVeQJ8gUEQHrI6hlVOO8wDyWe+tg2D/259s46WcJj2QSDt1HaqgFl/saM/T4VCr8Z/xmQvRejI+vJEnDmDAHJlF4vBtzJHvoK64ou58lgSY6MiqAG7rMbo+Aj9TrXVlA/uVLg1xUdWH+sHwjKDc+qo1UUu5Gsg9WUs5tKjjGD7qrX3Jb0tOS3PLVqyCEVb+FVm/dOg20TvmbDyZDZ2pokR9J5xiC8zGXQDTuTi3DZYQ1nalJytIBDEbNbYW6pke2Q+F6j2RtQ7m5Ncpa8+ESL6nBg+BdYXQZ4xHogt/LvbOT++BHAVu51ZXk6EtQxWW17RRwR10RgGA2FGyTISYO x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR06MB5653.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(396003)(346002)(39860400002)(71200400001)(83380400001)(66946007)(66574015)(52536014)(7696005)(6916009)(66476007)(86362001)(76116006)(55016002)(64756008)(9686003)(8676002)(66446008)(6506007)(8936002)(26005)(33656002)(2906002)(478600001)(19627235002)(5660300002)(186003)(786003)(66556008)(316002)(9010500006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?AsAaT78rfeQ6hpra4aoVvg8JSu/06XDvWOEexVXIGh79j4lHPt5d4JosoH?= =?iso-8859-1?Q?KXwWJ9bkqdyiD8gOC2z2nXcV4ygEU/DmJGW1FOvI5VyxEugWrK/pYNNaj/?= =?iso-8859-1?Q?rvTYraDE03c2PcbgNApIvVtAGXa3rxpJ/9PoVZvutzVx+WuPDxVD7c/NLu?= =?iso-8859-1?Q?wxLJMfkgk8zkuGMvVRpBoHTGA2txxJTOlKT7FO+oUp66W9Uv9rOWgmBRXu?= =?iso-8859-1?Q?WM+WmRKzj7lE5wulZ+znKiOtmvAGi7phiRFS43fa8+FtzK2JazGP22ir0M?= =?iso-8859-1?Q?h5sIUXcvHTdkEis/jTKWkdI/1JSR0fYVMvGBD04a8H62yKL6E86knto6bQ?= =?iso-8859-1?Q?COW+griWx279jZ9HD5XiSUWUFDn+DOaXGKYwBLvZGdzOZB1YsHAVp6c08W?= =?iso-8859-1?Q?3hszfMNzFzP/9om9QVHUE20WyDJlm178BcSvxHNZMtk4HfaG6/Rh+ydajy?= =?iso-8859-1?Q?TKtCUsMmoOc3BwdHOw14RDNCO66jEeZD9IJyjVVAehhnYLk1vV+WwA72Zi?= =?iso-8859-1?Q?m5YqpzcbjN73DUHhtHONw3Mn8yXG5C5hrGlKPGin3VyDXpZNE7yPo8vr4k?= =?iso-8859-1?Q?PHuZKa10QPeEBwF2LHYp5vF32j39qemQJRuYjmkwYHr6j0BfuFy4wN7lS6?= =?iso-8859-1?Q?gijoytYWMdZLVDkbdQdjDhpSC7qH5wLDyEFRs+sx7qLzT6hMCetpu9c239?= =?iso-8859-1?Q?umrKuh87ef/swK84QtrHZfwu9SKvrddIOGJbja0B8fhnCTbqi6AJSfZKib?= =?iso-8859-1?Q?zi30H2GpRXlFoUhcZ+n4p5jl1hWfXgZxyuJZXSn6V6+s809n5UNVR00RG+?= =?iso-8859-1?Q?QhcfkkZEBvhA4p5MC/yvQoA0PadniIqDmGknsoEJifRavcUVvnBmI3sUam?= =?iso-8859-1?Q?xzm75iZXAD1bL/EDV16BIZdqWJoajQiWyiK/mqkiLhzhZEMQDjysCX+x7D?= =?iso-8859-1?Q?mHovuN+v6dNBfol52gc6r0Mv7vFtdW8TFH8uBp1u3dyNVsGHKQjYt+atjX?= =?iso-8859-1?Q?7dLTminddNvommjZ7tqVsgz0Wpgn9CvUeO8ciNZNaIP529582Gv2BwvfXX?= =?iso-8859-1?Q?06se+ZVp4/kRQxfYWQcuYLSoi2L/tmzkgPZ0vdOaz3q/WveD+/6tVU18vc?= =?iso-8859-1?Q?+7PX+oAsj/GSB1IWcalmP8+MeNKKTASxjHDUOPlJnl+9NgY5/4XVhNOspy?= =?iso-8859-1?Q?9buBA2w8SfYfBhRtMQA4trMQNdcl+xAtkK2EKpciLlfUw7b812/dDHMsPF?= =?iso-8859-1?Q?LHhJyFJoGHFuUvmt+mm0ahoMjsnYZIdUlBCC+UPpevCiYpu4qZ2E5+4qwK?= =?iso-8859-1?Q?hJmvOChKGgaiqRBgw2aw0muZ36Ja0w74JZnwBo+792B8QfssJXoRsi7or1?= =?iso-8859-1?Q?cVs5Bm924s?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR06MB565375016D8E2511BD94483BFD6A9AM6PR06MB5653eurp_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR06MB5653.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 642c6dbc-6ec5-4cd4-510f-08d8e92fc82e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 10:31:10.3318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5zAp2p8SyMTEyq/Ez1MALWmaUq/yTsowu8syDEetKheZJZzefBDAZhiC10qA9VoTpMiihHKILxmlg6HfjMRpF0W8KgsUVLVB7jlVfKCN9PahQDUHU2VrLMDl6SdN+uAu X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR06MB8104 Archived-At: Subject: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 10:31:16 -0000 --_000_AM6PR06MB565375016D8E2511BD94483BFD6A9AM6PR06MB5653eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear netmod wg colleagues, The ietf-acl YANG model defined in RFC 8519 allows to creat= e rules, and for each a rule, in case of IPv4/IPv6 you can specify in the m= atch the source-network and destination-network. The source-network (or equ= ally the destination network) is in the model an address prefix. In our use= case in Telefonica we are specifying a prefix-list for source network and = another prefix list for destination network. If you had to create this beha= vior using the ACL model, you would need to create NxM rules. Besides, the = management of those rules would be more complex. The routing policy model has the concept of prefix-sets, bu= t is a separate model (and a different use case). The functionality of specifying a prefix list for source an= d destination in access control lists is available in most vendors that I a= m aware today. Hence, it's a pretty standard functionality. Do you think it is useful to add this functionality to the = ACL YANG model? If yes, what would be the procedure, given that ACL is alre= ady defined in an existing RFC? Best Regards, Oscar ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_AM6PR06MB565375016D8E2511BD94483BFD6A9AM6PR06MB5653eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear netmod wg colleagues,

 

        &nbs= p;       The ietf-acl YA= NG model defined in RFC 8519 allows to create rules, and for each a rule, i= n case of IPv4/IPv6 you can specify in the match the source-network and des= tination-network. The source-network (or equally the destination network) is in the model an address prefix. In= our use case in Telefonica we are specifying a prefix-list for source netw= ork and another prefix list for destination network. If you had to create t= his behavior using the ACL model, you would need to create NxM rules. Besides, the management of those rules= would be more complex.

 

     &= nbsp;          The routing pol= icy model has the concept of prefix-sets, but is a separate model (and a di= fferent use case).

 

     &= nbsp;          The functionali= ty of specifying a prefix list for source and destination in access control= lists is available in most vendors that I am aware today. Hence, it’= s a pretty standard functionality.

 

     &= nbsp;          Do you think it= is useful to add this functionality to the ACL YANG model? If yes, what wo= uld be the procedure, given that ACL is already defined in an existing RFC?

 

     &= nbsp;          Best Regards,

 

     &= nbsp;           &nbs= p;             = Oscar

 

     &= nbsp;         

     &= nbsp;         

     &= nbsp;         



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_AM6PR06MB565375016D8E2511BD94483BFD6A9AM6PR06MB5653eurp_-- From nobody Wed Mar 17 04:16:17 2021 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 C63573A12EC for ; Wed, 17 Mar 2021 04:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plOYywQi4DcF for ; Wed, 17 Mar 2021 04:16:10 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2125.outbound.protection.outlook.com [40.107.21.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0563A12EA for ; Wed, 17 Mar 2021 04:16:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XLdkcHgSv+H0lpmNkpStQKu3FcfQdhz5PRlagDuS0ASVJJXl72cDqQnZWbXVwlGx4sOmh898pD92OcFtQTREC1l6dEV81nfwpqui6XzP7J5aEP+ChgJbkB3s4LeBlUFx4QuMdt3kTTuSHz1s7+Zf9qlwUGMKcm6cz+CRY/Ecbm9tUdMs+oABaXxRM16KkOmCnFn+HWLspmmd7fAuEA0M4e8Vr9jCGM7nsGqTYxfj6pep0g/OPL8tQzZaAc4CPz+KSnmuR8uiExGXDO91gjJl2FcGAekAW/DZkABnMDX6mKuqqyJeL8XXO+tuh3+ETnJbO4QF70ddYfxDgScPZcREWQ== 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=Oqz57STpn5F/OPuPhR9stFbHxdh9hylFi+LJXyJTk/Y=; b=QB2S2XifPp7kYVpKEg8yJJ6qLmb9QtKORbChinIKrjjKNGSNhKm3D1w8BBeqLTVtI/CJIqZ7So2R7+esfvxTT/rxUKLU6e2YG2TZXYIExB67yGJLGZHPdnGrH6N6gsYT8Xch9T4tkgACBhbZm+IxBSwgwxJI7RHFg4d6QsK5q2YePW4WR+yqEeX7kOqEEUKgUWegMBulxFEt/lAG0P8ZC2f7dJqrwLNLBZjiicc5vTtUfxu6jpJVsN8inXcmC1alrbvxdiuKXNXvFixt2KuZXgqHYpiRhOKtbTvaLYl/Qf43k6QjRBtaJ2Y6rJE+UQQxt/KYGDNMtyunsMRUrUhAcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oqz57STpn5F/OPuPhR9stFbHxdh9hylFi+LJXyJTk/Y=; b=b39d4w6ihmxNmYA9C7vQGwDXiLQ9Ed0Yk4FJLoQqxWqmVLOv3MaueoDq3FmhCKC8wSBmdhjxYrVUuZn/BmvAOmWQX4nwld6mwroErav1qmUBZfkVfnYFm9oREfGuLi/kYgyObUpekauIq07boasS1zPicCn0vxzGd6f+RGruDG4= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6529.eurprd07.prod.outlook.com (2603:10a6:20b:1a0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Wed, 17 Mar 2021 11:15:56 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.3955.010; Wed, 17 Mar 2021 11:15:56 +0000 From: tom petch To: Randy Presuhn , "netmod@ietf.org" Thread-Topic: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent Thread-Index: AdcVX5UyabdLLRhXR7azT92xVCZekwAKdlYAABRyoYABUNmpwQ== Date: Wed, 17 Mar 2021 11:15:55 +0000 Message-ID: References: <20210310084324.xkr4xbsainfnxrvr@anna.jacobs.jacobs-university.de>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alumni.stanford.edu; dkim=none (message not signed) header.d=none;alumni.stanford.edu; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b425dbb1-1e63-4326-fc67-08d8e93608f0 x-ms-traffictypediagnostic: AM7PR07MB6529: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qRF+nxUcpVpWp/ccVQi5diJv6N9y4pLbe3Q1ikz6FPXFB/Qd2nyCalAD67YxD9g0dNGzaiyp30JC/+RKOAEfcQTyEsZ7Tg5DswTSGQPhl9wp0Y5rQWS0nXozNfCZpdluPvr0nbdCx2WTCgtyrBFneZxjXk48eLnFbwiTMhs+C/cmo6mCYPAzbf29NhDOYGTFbiFNeeFnhyRTDrBgmU25RoNDyOxjfQAvoNO20u0lDl/MC6e1gR+EsxBKICPHqYbAysDawh0f61x/TRB9iOvIXovHkOJJS+8TcTq0PJYAAPYiYem9ZEiBlyeRpDPWwqCSK+UduXs/YCGJnhwI/BFHEXCcJWlTO/VuxAZWIM9ln9JgtrCW7QSAcDSlVVsKBdq177oh6R6sp0su8zeThEL8jpMSS/MEKiN714kg6quDSTNv+ClAXAxHNjp30XvCz7Jp5iLQscFfc0n3XHysN4reGk2lYs1XYbUCwdW4i3nJ2C4jufLea7BtPdF22E0f7lLALycqZSh4HtzP/tGyCSXIY+oM3LbjZPWGwFYWSR+DCkBZ2w7yS4qTEPC0wmKaDqsuyTJWlrZotRd3sNu9+HQ2cHLZwFQ+RImkmkG+oS1kZyqidGQKtejSjQgqlm1/lqJ7BreNqnM3hj01A+rIg1TUoA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(39860400002)(396003)(136003)(186003)(53546011)(66946007)(9686003)(26005)(66446008)(7696005)(76116006)(55016002)(110136005)(6506007)(86362001)(66556008)(66476007)(316002)(64756008)(83380400001)(52536014)(8936002)(966005)(71200400001)(8676002)(5660300002)(2906002)(33656002)(478600001)(91956017); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?nC29+k5bS/5jgJnEtEPD+bulIqBcnZFZhabVSUD+4BTuJngE9b0lGBmID1?= =?iso-8859-1?Q?/AL6RYPFWbxIbGMDiMHxx7vleMQQ6tR2Vv8v1Lsrn0b0aj1IR8ZuDz7Qhw?= =?iso-8859-1?Q?IfqiDriSKfp/+Imb0s7d1Jvym/rtbrOwRHmMfrsuRoxnTGYZu5RzNSTuXk?= =?iso-8859-1?Q?kB1oj2BDFgSbrp3EI60cvg+W/gLO6rJNaAIrXh6U1myLdnIiytl/cZd1tJ?= =?iso-8859-1?Q?PdA3OrG4pjuufTkokLsuaEmF5eShX9PYljc+3li/0xL0pEQIzqtBZ1IO/t?= =?iso-8859-1?Q?0BsAVKgO7MLXdn4CquLW2FZsHamC5GG8zRZ1o+GBJrcjvOuyy6ncrJt2dd?= =?iso-8859-1?Q?n9S8jIfvCmmT7AlV3sQqnjhKEf5SucZU2jK4wku5VdeZB0itLpvHUQXZFp?= =?iso-8859-1?Q?yTTMQZ0axxSaGOiQcaHkqqyozDTGSRAku1ftC9z7gZJPHiLQMrZCU9C8m/?= =?iso-8859-1?Q?uMsIDEmNrnOXOZJeZ/xc6B05NIgb4adFG1OBPPe0nRM3owV+rZnDg4sofK?= =?iso-8859-1?Q?FMuCt4BpDVA5KTWQ2BNaLiknL+zrYonPjvY5FCmdsWe6fP21vhVqkwpbpO?= =?iso-8859-1?Q?7tQCTAOF5x/Yk3Mbh18xPMYJkUoYUWQAZ5qH+rLUU72mIMwjr59OMT7wN2?= =?iso-8859-1?Q?blqCg3JxcSY7IA9uh7BOwsWkg2RlwrFTAw/U4av/KBx2ASFCySR5eMdziA?= =?iso-8859-1?Q?Rd98gxn8oQPYIXtJ45z5AY8CmLkL2nDahmXTU2YzNJd7kNLI+TfqZ4u1oz?= =?iso-8859-1?Q?QYxNujNdvgnFC/i+otz1eKx/Muw70m2D0slIpN9PJ6S2kyEqE/Vk9n0VUF?= =?iso-8859-1?Q?ua/TuGbK/aR7IM/phrZOBNLh9zI9hOXv/aNFRFvh5WFz3kFCs6G40OKq6H?= =?iso-8859-1?Q?WOzc4F/N/N0k/AertoYkdNhvuN/+890Lo+WCv+fb+v3qSEfAQ1IP7igniy?= =?iso-8859-1?Q?JsfrdCdtGOtrx7lFmXji1cxGmaFXnjhYoFQTgzF0oJkY+umTjEcI2Ipnsm?= =?iso-8859-1?Q?1vRDnsyjzE9hyyGB896d1YyN/sbe3FrJb1r4KA1mQXo11nRsjACBf72K6R?= =?iso-8859-1?Q?fxk/lJQPgzWx5EhkCGvyxaOOwlO0NZ1PFkZ2wPUuyoTKgOOcwOKyEjv92a?= =?iso-8859-1?Q?/nW1TDyf4cTRofDeuruR394J+GAkd6+iqjSpl4NZr1YUahvISVEykelnGD?= =?iso-8859-1?Q?9rqbnasOJwcXPzjDDuXTcmUq/qp6Xs9N5nVso+bY4wmWXQp9fD6fwC3MGA?= =?iso-8859-1?Q?4wkqhEpqqGzisxrkeq4EJa5FvX7s4rFjqLLUImo86I75Rq+cbNjyrPftq7?= =?iso-8859-1?Q?mLHpaHsWIrCd2mQFbAYDfR3+0XJh3lChf7qvF49JCLQwmQCkqeGwiQ95uD?= =?iso-8859-1?Q?9Zldeju2tk?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b425dbb1-1e63-4326-fc67-08d8e93608f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 11:15:55.9137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bE/ES+21H3rQFptGQ9L06JLpUPnayDWz8HzSHxd0k4dbY4nDSXTrIX+UV5kcTUy8uosP60F/Oe8pfzk74K5LSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6529 Archived-At: Subject: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 11:16:16 -0000 From: netmod on behalf of Randy Presuhn =0A= Sent: 10 March 2021 18:28=0A= On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote:=0A= > Dear Qin,=0A= >=0A= > I believe this work repeats failures of the past but since the WG=0A= > agreed to entertain this, I will keep my mouth shut. I suggest you do=0A= > not spend your energy to convince the that this work is viable since=0A= > it is rather unlikely that I will change my mind.=0A= =0A= =0A= =0A= Meanwhile the ITU-T has just liaised the IETF that it is starting work on i= ntent-based management. I have not looked to see if the same words mean th= e same thing but guess that they do.=0A= =0A= Tom Petch=0A= =0A= I'm inclined to agree with Juergen.=0A= =0A= I participated in policy-based management work in ISO/ITU projects=0A= starting in the late 1980's, culminating in System Management:=0A= Management Domain and Management Policy Management Function (ISO/IEC=0A= 10164-19) as well as the later projects in the IETF and DMTF. Whether=0A= the problems are in the architecture, the specification, or=0A= implementation, there's an ample body of experience suggesting=0A= that this stuff is hard to get right, and to the extent that a=0A= proposal resembles any of the previous work, one would be well-=0A= advised to learn from the ways in which that previous work has=0A= crashed and burned, or in some cases never really left the ground.=0A= =0A= Have fun, and good luck.=0A= =0A= > YANG is for me _not_ a suitable policy language, it is at best a=0A= > language to carry policies written in a suitable policy language (and=0A= > I am not even sure about this). All attempts in the past to reach=0A= > agreement on a common usable standard policy language leading up to=0A= > interoperable implementations failed. The reasons are manifold but=0A= > strong (I think), standards-based interoperability at a generic policy=0A= > language abstraction layer is for me a myths.=0A= =0A= Complete agreement with Juergen. One *might* use YANG to describe=0A= the structure of policies, but it would be cumbersome for representing=0A= policy semantics. The current trend in YANG-land embracing ever-=0A= increasing deviation from "standardized" models means that standards-=0A= based interoperability is getting harder, rather than easier, when=0A= it comes to machine reasoning about the semantics of "related" models.=0A= =0A= > Please don't take this personal in any way. I just do not believe into=0A= > this work but I am happy to be proven wrong.=0A= =0A= Ditto, kinda. I still think policy / intent-based management is a=0A= laudable goal. But it's really hard, and there are many factors in=0A= both the IETF's technology toolkit as well as its standardization=0A= process that compound the difficulty of the problem itself.=0A= =0A= Randy=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Wed Mar 17 05:29:30 2021 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 20CE23A14A8 for ; Wed, 17 Mar 2021 05:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1moyhNZksKf for ; Wed, 17 Mar 2021 05:29:25 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20630.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD4E3A14A6 for ; Wed, 17 Mar 2021 05:29:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EK0FKHyNC+R1D/ruGa62dN7vapnkw+zpMnHkUJKl01tQIoE6gwpzMpY/W20T2H0s8/BPTaa1AtlUdjQSIUOBZdIowDF3hkSpxxYp3pEsNqHkro2M3Qd/qAba9UlJ2Bjjg7cH8n6E64SiBkIIvzn+OdfnwnCs505QORcoycBn0fRyzlgKo9ZxCd2Ru7a2df8qpUrnW1CripQy3tMbrANm3eTGbVWPDcvbVmGyhnWUmN66M65uePUadSQ4QdMgRuw+nPULqJX58suOufBTJVAW4s+KCq9jAlIr3U0JIs67L8FUCyIxkCEC7XsJRVsjv8jq32o03EpHn/JK35bkE/XPLg== 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=a0yMFAdb/iUenAeLzJG7TkNExBx+1iPDtW4cL9WmGJU=; b=gxL/NRepV1JWyoAZerIbN+kJWY6cZgoLxMWHry3Lai/p4rlP9rdMgpK/iKT+FTVBn2gWfrS57/AQjAFbSftC2HkUzpAOu1qQj9tQPK9fGP1g8rQ1P1dD8mAO5EtUBtjz6n6KUjMlikMBRvjr8SD0w2kqyRme4m80EJcMfy+vORP7SKjlLtDDAkq2d9xm1zHWbwTLqSV9sRIgMjoHpj6fM56mDAo15aM7bXicXmpdU0VPfkA9EfbRj7mmlNwwY/g1E4ftjhBbxkHAsmIRyvcxs7iwwEWC03r6tozWS6ecS+79OOtD+kZDsOFTPnD+EVdX7mZmuMO59zN9on/e7sVhug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a0yMFAdb/iUenAeLzJG7TkNExBx+1iPDtW4cL9WmGJU=; b=ZTajTKm0p7SUubvFGe4MvmmdtfMybv2GPH87cJUtdw4rshwJ2DSkWFB12l28gLmHEllK6WEIn0D1DLw9FWJU/49CjCmQ7WIEHxwabroSBayO3ev8wLgNphbhxSE7SaoO2QYYSze4yRKqco6JVoE7eLrz33MApGgIFVLzacmPykU= Authentication-Results: telefonica.com; dkim=none (message not signed) header.d=none;telefonica.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1682.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 12:29:09 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 12:29:09 +0000 Date: Wed, 17 Mar 2021 13:29:07 +0100 From: Juergen Schoenwaelder To: Oscar =?utf-8?B?R29uesOhbGV6?= de Dios Cc: "netmod@ietf.org" Message-ID: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Oscar =?utf-8?B?R29uesOhbGV6?= de Dios , "netmod@ietf.org" References: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR10CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::12) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR10CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Wed, 17 Mar 2021 12:29:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b61bfcb8-279d-441d-2cd6-08d8e9404313 X-MS-TrafficTypeDiagnostic: AM9P190MB1682: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mnTUmp3QIP2V2135sejDCChjO9OwiIsfC09BZM1uNJTZmx3nc6ERy7v7+w2m2c9yRgBePDibJb/y+9uGvNFA7r7s6gwYEsWVA1ntZ0zgkIprv4wi6tb6Q3Jj8SG4SiqTXs8Zv94KGZY0ZLupbjE7WR+o/ljisBlI5I+DLoStGEUy2sXhVqbCI+D2ZOuEtCTXgCDoS71065kT5eIn2MqBCqMtE5lvIDN83mUdeXgUenAX5U9f3jrhpe8+S8+Gox9k0o43LK3sbhbKNFhpJ7qkKNr9MVYqmXat0hApiuycHVHIsKQ3XibURgbW7qyrcHAYaggn7sg5eLJAj9MDPc2Ax6t4or691HrimfX98oK+kKnbDQ1sxNB9K/CVzkG8uIp3oDqgqB3FLrPzjHV5IlUG+JbDZKDHaGMJ4q2Y47u5qJhfM5gi/GhaQKnlY8s8ymehUrl2fny3UzVfj/I736VunvfuymaADHB6AhBIY4PYjy9Vqc7qbcoG1y6XH+rutjqrcPXu/wqm7whujDiypnrxf+UNYllDnCm0rDkvI/3YvoIDBeEQUkZ1xHt0cGLbxJp4ok01rCyl7zErALSM+73jp3YidbTxrQZaa7iT9PDdLdO3K3uCuv5FyczITLoYGNY/O1QLOLx3JSkmjUGlMvhFRQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(396003)(39850400004)(346002)(186003)(6496006)(16526019)(316002)(66476007)(86362001)(83380400001)(52116002)(6486002)(4326008)(8936002)(956004)(66556008)(26005)(6916009)(1076003)(66574015)(8676002)(2906002)(478600001)(966005)(66946007)(5660300002)(3450700001)(786003)(296002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?iso-8859-1?Q?sWFrylqet9fw4wMXP8KL6/zRLf9OSNPZrAX1G9F4DdzyBda+mVB71GS1q0?= =?iso-8859-1?Q?Ybd9YfgH7keBIFgd4veKwljayTpXZOJbgtCF8UuroGKgMaxXkxuUO5hzLj?= =?iso-8859-1?Q?hj1wCkW1H6fCsHz8dT0+OgJKkYB5tXkOswIKTcOXu3jbCJbyhCEg+Aw/sE?= =?iso-8859-1?Q?hCBJoprvkm9Ce3hAg8lf7taWAhZ5K/jox96HG75K24a5vwQygeFCZQrhFM?= =?iso-8859-1?Q?fX5obh4ZNHQDAxVZ8pYVz3SN1/Bm6tnAN0ZRVO7KR4IB4UK/sZQUCZuvEB?= =?iso-8859-1?Q?SUB/EKXXRO9g7y0uya/SGHByX6ekxh3f/UZFp9+HZGRjhnJhsoE3hFX2BP?= =?iso-8859-1?Q?AOGXV2P4yBg0YH6p+uavtn0lERNMyxvyFclHCQdtTRsZjoozhgdaeKR7Vu?= =?iso-8859-1?Q?/YP3Yh/wbA83gBUXIT6CfOMdRPYxgSiNKJX3XRazOR2+QtrFoejJYX1DlC?= =?iso-8859-1?Q?pqwYgmcAIlWeSHAD4udFgU0GiFTdfrFMlAOJwSeMJzNjO2XKhqiQs0MNMc?= =?iso-8859-1?Q?LRKv40Z/kJwG1e0RgOMPgtb4GqfVH/WUh5x3P2ppYinF+ASeo5GKWofJrH?= =?iso-8859-1?Q?tM+K3KWdlua1xHqe+1CLb/fgLapAwa6PILJwzzJGEMGPfiG84s5QDWo1Ey?= =?iso-8859-1?Q?9y/euqJvf9B7nw3MOkVfkpZ86dwsL4leRNya0WVjyQCie9rTC5zwb8dUI6?= =?iso-8859-1?Q?cSNh9H2Lf8Q17haFGl1iPmvmm3VotFgPNM2Q3WsDTfWNVg2nGYGhG8E4gY?= =?iso-8859-1?Q?lmKYZuhPipcSYbS7m5fcZholIvHOTCmFJbEtjtfgcjYVWf9CcNLvBkim0M?= =?iso-8859-1?Q?UUsxrpSRoXvRpV5Kzx5KRKKyp8GLauuVCjCyXl7rVUWuwMudHdO2NcibfY?= =?iso-8859-1?Q?GULjCWjaCQqaHxsClt9m7ZxIP+U1nzAPW8VoFOmOIDG35oVEQ8aGJM977D?= =?iso-8859-1?Q?jCdMflemqsyDuI2McQtq7EoPiSTlgNbuC+7QsVxcsVq9197A1mdObc+EgD?= =?iso-8859-1?Q?75fHI3tMKXVxmisAgcnpJNfkuOJ6ymxzj7yTwDUo4z7e/L1lcsXsNh390n?= =?iso-8859-1?Q?KXv51oXdStXZesIV8w/GJj3+gidMiMkAXUGf0cxIVQVY9/I8thiExIFAQ7?= =?iso-8859-1?Q?n9qCDiWVl078JMCGXA5lA2P/HS7TnRwe2I+r7FYt2xjW2VerROd58jBaDv?= =?iso-8859-1?Q?sYg79G/ZuHHxJsC0NUJMRbiFdmGzsgXIJAkyE9EgNg8aTH1mh6OQuXO6vu?= =?iso-8859-1?Q?mPs7m3MoYLSlq11a0BfsnK+n3Ox2VcT7YKGBuoLV6Rw5DB/KQ+TTLX5F0M?= =?iso-8859-1?Q?qyQlynzdMtFKyiItN4eg+iFBLFpm6pGtjClefkPyPyKqHQSb7Lu1RKb/Pj?= =?iso-8859-1?Q?wjwepbQNsD?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: b61bfcb8-279d-441d-2cd6-08d8e9404313 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2021 12:29:09.4334 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /TaO74ZpZwDcWYUQB/GzT2Q84//wjQTJRzhYOe1Rw5HgjYNh3xxThG3VG+WGjhgMGe1ywj5/bsdxDFDy6S+Bge+HwBsZZhkz0M3BhlR4Ia8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1682 Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 12:29:28 -0000 Hi, let me check whether I understand your request correctly: I heard you saying that you would like to have leaf-list destination-ipv6-network { type inet:ipv6-prefix; description "Destination IPv6 address prefix."; } instead of just leaf destination-ipv6-network { type inet:ipv6-prefix; description "Destination IPv6 address prefix."; } (and similar changes for the other IP prefix related leafs). While such a direct change may be difficult, given that the header fields are defined in a choice, it should be possible to add additional choices for sets of prefixes. So from the YANG side, this seems to be something possible to address without too much trouble. Whether implementors are happy with supporting such a change is something others have to comment on. /js On Wed, Mar 17, 2021 at 10:31:10AM +0000, Oscar González de Dios wrote: > Dear netmod wg colleagues, > > The ietf-acl YANG model defined in RFC 8519 allows to create rules, and for each a rule, in case of IPv4/IPv6 you can specify in the match the source-network and destination-network. The source-network (or equally the destination network) is in the model an address prefix. In our use case in Telefonica we are specifying a prefix-list for source network and another prefix list for destination network. If you had to create this behavior using the ACL model, you would need to create NxM rules. Besides, the management of those rules would be more complex. > > The routing policy model has the concept of prefix-sets, but is a separate model (and a different use case). > > The functionality of specifying a prefix list for source and destination in access control lists is available in most vendors that I am aware today. Hence, it's a pretty standard functionality. > > Do you think it is useful to add this functionality to the ACL YANG model? If yes, what would be the procedure, given that ACL is already defined in an existing RFC? > > Best Regards, > > Oscar > > > > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 17 06:09:49 2021 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 113143A15BB for ; Wed, 17 Mar 2021 06:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6d5cK4hiHDP for ; Wed, 17 Mar 2021 06:09:45 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2117.outbound.protection.outlook.com [40.107.20.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FFA3A15BA for ; Wed, 17 Mar 2021 06:09:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RjNxPvfIHDK3W2JzlCdIi0iiS99UtNsq1o0qUvgA5mtiscHsQ/yjlq3IVDJ68SJUjsOUp+dWsxTTEPr5/JcWUYlW/t/NHlWBH1nRKF9OVm/BS2sl1UQYMkFmt+tum9ZV8zpxj/Whxtgp5iyoClW/VxIuBIqb66nZ8h/Rg5I6l1Pdu8kIdnSHme5FQ082z86ICjnrZqyn/Vc89Flav6tCteMSMJyFI2nNo5q34XE9paE0js2ryZzI6XHvbtdGAInDZpKfOL1SO1OFbAeZ+S262HgAAchK9qQfyXRzw57/uQNh1eYXK4qjIFGl/kZhCIqf3/eoCQdsnl1R0BigqN7tRA== 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=cC5Dpf94FSuR7F0g8tsRRImYNhTsNzwWfJTgU7yUcN4=; b=Lt6nTkjpUvkH+ADWwbzyXIjd1dvCgYT6mtlz/fXlkpw4jtoDwYlmoAJnryh9qxHEY65+qR4JWR3MrOJkFV1IbN+1YwDSgVO/IfGzJi6ku5fGp8UOmnNi3JKycETf8RxWl4ksVQVAs/4ydypuo+Zx4LyOg/KGxcxDCdrtSYfiDzuso0zGCM9BXAStXnCoCHMD6XSZzjiGHm+nsb4Jbvr4pJnoPn7ea8vHfj50itIOljz/gIrCcoSCaB4HRkFG5Jr+Rq9mPP57uWP6Bga201C3/+dnigI+e1D00byJKj6SajOhWv+eqw+3HuDiOr7QYl2TTEcdpMUjeiD0UpqRA+Bm+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cC5Dpf94FSuR7F0g8tsRRImYNhTsNzwWfJTgU7yUcN4=; b=ASdmcKVuzhNTXIaRv1JmGUkR8YayXCluFTp8dL0HqribyCbqMHCpsPZInSUSqxl+vz9tthy6U8pcSF+Ijm9tVJsxC8twU26NH/2VkG9I21Y3WShlXVVcjRY3yWI60eGE5PCOKhaW84u0Hr23cGHuchKtstYg8SrRua6Uu5Ji1WM= Received: from AM6PR06MB5653.eurprd06.prod.outlook.com (2603:10a6:20b:96::26) by AM6PR0602MB3752.eurprd06.prod.outlook.com (2603:10a6:209:18::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 13:09:42 +0000 Received: from AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::7d8b:c44e:9517:5ad8]) by AM6PR06MB5653.eurprd06.prod.outlook.com ([fe80::7d8b:c44e:9517:5ad8%3]) with mapi id 15.20.3955.018; Wed, 17 Mar 2021 13:09:42 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match Thread-Index: AdcbGExc8OTG49eVSoeJejnhX1jHZwAENNWAAAC8GLA= Date: Wed, 17 Mar 2021 13:09:42 +0000 Message-ID: References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> In-Reply-To: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=telefonica.com; x-originating-ip: [79.152.139.53] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 95d4fc1b-bbae-4abe-649b-08d8e945edb0 x-ms-traffictypediagnostic: AM6PR0602MB3752: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Jw8buBLX7/hI8d6Vwvmq3OWCYn8XdX6USwlrXH4l6Z2lai5vbNeExEGBRyagOryuXk4xCRxBjjf4uUS8xhH6kUqTB1CH8kIooW8liPCqHZwEe79S+0I/hl6T9srBL/6BGjl59cobAYwOJj/jKofZKEUAfc4cW4vhWoCd1NEikh5ZXiQNOjX2BghqQFJQTjENLOu5IE/j1iiSWCQuN7Sa/yWyE2vwfLNMSLpLvMU5soI5+u47aZf6/HacRGQz5DtW2lhdnDhRPTmFesWp7g6BsgURtCJj5sYjfhaTFPpNJ99fcwO3RtmRQyrYeAcFvCyDDMlWOKGtZcP7B1VzBoq46AEVMpuEy+4rdLDY9xAhOalX8NJGiXYmr7R403/ye1hptb+znYAAvU3WOD4G1rKvSWBiWqq0vcMlr46fWCI3s+X0cJIj6BqWawGJgMd3bfQ9rPc7yQcWADk9v9+vVy9/Xk+VT2Y62DHJ2wmLWwhBk0SnEjcZAbG12Awcfi/1LpGItQ9v/helQ1/SqXPcNCrsdb1WPezGozYmUvdXrJ/kAFGOD8395AsdYcwbuP+Kgks9BVrKsbsRnYo8lH/d9lBzJhn0Yogjrn4pW66TrZFjHa5RjtNzHdmVphgtunIJ1U7PwcWkcDJ29NjedD8OH+pRV/+Ng5HGZ8xmsJHQmmQfrmkzxylvVPCXtiCfx5MeUdzZ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR06MB5653.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(376002)(39860400002)(136003)(6506007)(86362001)(6916009)(2906002)(478600001)(966005)(8676002)(52536014)(83380400001)(5660300002)(66574015)(71200400001)(7696005)(55016002)(26005)(64756008)(66556008)(66476007)(66446008)(186003)(66946007)(8936002)(9686003)(76116006)(786003)(4326008)(316002)(33656002)(9010500006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?6zKzYvjFxvrm1UHpeueCRb+qK3uFrjufLBeqxmL4Jj3qCbJmFen00+UFVM?= =?iso-8859-1?Q?LDTsNRXSxfSapJSo45+yANMbWXr0+80fvU/U3MYAE4QexDGVcIXnUlqoqH?= =?iso-8859-1?Q?4FXRbluerI5crkWU6a/4ZLwEhJbTSrF3EveYme1lepLYv1tUU95Nq9iRqC?= =?iso-8859-1?Q?ORgQb0iDaHNL4SX6TOgiwaIGQg2u+712Ci3+O0Y5y1Ua9UQlnj0RAJrA9p?= =?iso-8859-1?Q?z1w0DaAkFjRXKBQxDMnjnZeo71bhThN8/Pk/sMceqmgIEBknDxHEkiXpNe?= =?iso-8859-1?Q?9oAyo5nhFuwsZXIR40kx/itpc/eICPAdBto7R+JmlfL3fQG6BBDLujzp3A?= =?iso-8859-1?Q?jqiARUoqXszrdZtS6jqdxAMcz+tCGzRKEdeJIU5wzZP8GW2aCxUAYaJZSH?= =?iso-8859-1?Q?N4VRw31MRUc3wWebenEQS7Dg0GsFRZeWkMYtMi5bTwsxvXu1N896U8D+yG?= =?iso-8859-1?Q?BBkY7yWojLn+qEZ7RSDWnmFYLhwr8Bo2Dke4tbk0TO/KJxNd8acpu7QFsM?= =?iso-8859-1?Q?eXDce/k5FMx3ixiX6d6i0ed2j/C/JfpTgarSKkv2nJ86vnHMdoStiufJBP?= =?iso-8859-1?Q?eUqsEkeNamQJSZaixO2/l1UW61ifd+sOwcf64X2lAlkwefrQLhifmf92CQ?= =?iso-8859-1?Q?76JDcckknKgIlqUNwITGnOnQx1aWfR03ss+yRUE/u9svS8YR7P0XMFy+f4?= =?iso-8859-1?Q?nuWCLwDn7iYmFAKabdiV4OA9obh1lyb/atWDqPy+PFIR2Mtgj9d7mjDq4z?= =?iso-8859-1?Q?6lve18+W9KBs43yhs6LvgOJQmCXE1HpqTHzdfNmD0UgXP1ia0IaDq/i4Z/?= =?iso-8859-1?Q?LhrsJboLmEnQ2XOa5Dl0iqLatZ9pTJsN0FSvfdToha4PFCO5PNt14rlEBy?= =?iso-8859-1?Q?25XiwoVwdUjz5DWsjlsVZ+JNT7jMhfPhS+2Egw/a/BdCcIlCuGLB59mkIe?= =?iso-8859-1?Q?BBDvNIt/mwoajYgVwjJE+iXolVaTVjnMpC1ralGBrvkfpYeBDwMenUkjfr?= =?iso-8859-1?Q?UmbA5P63MGGS3g9URPStmmgVhveYSDBJ8NJeygDp8rdaJk/WXtKE5jTOmb?= =?iso-8859-1?Q?5h/nsdlo2xhjDgaiHpg+VGwDUrj8S0MeM1edjclQMDPoUIWIZ2nRf7FEpC?= =?iso-8859-1?Q?2C8a1kzOPRGMzfuGSEvnGwvFVVSazv2tX+inYYtMufouWqjj0fyQPJTWZW?= =?iso-8859-1?Q?wERJruvkaZpnDnz9t4zVOXHZ/Zy7q14TbuP8CDFgY0YOYCLgRs7yU5QdM7?= =?iso-8859-1?Q?v9Wx4lHzfxFB+QpwhD19G9JPsHfU1E5gAzyUDStNBKMEDXW4TDXouk/CSa?= =?iso-8859-1?Q?smtw4l17OFZy9A2VKYzcLeGBm7CvU/t0IzMKblkdbqFdsM6R7Ui0F3plCa?= =?iso-8859-1?Q?V+286SbWZU?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR06MB5653.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95d4fc1b-bbae-4abe-649b-08d8e945edb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 13:09:42.1331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: soyJCl4WxVGzOaT7om2cp/VCIFrJUTf/z3L7pe1d8b3nAQYsTjoh6xhivkZchiosX1nbvBIGsGsAwnpB4F9m7L5GShT7L83BxRW/t/3pbA/09Lt8wySBAdMoCJZeHaNN X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0602MB3752 Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 13:09:48 -0000 Hi Juergen, I'd like to be able to choose between a single prefix and a prefix-list whi= ch could be handled separately for reuse. Hence, in the same level as acl[] a container to handle the = prexi-lists would be added: The model would look like CURRENT --rw acls +--rw acl* [name] ..... +--rw attachment-points ...... PROPOSED --rw acls +--rw acl* [name] ..... +--rw attachment-points ...... +-rw prefix-lists | | +--rw prefix-list* [name] (Here the list is defined and is reusable by the acls) ----- Then, in the matches, a possibility is to add a case, to avoid touchi= ng the current model and be backwards compatible. CURRENT choice destination-network { case destination-ipv4-network { leaf destination-ipv4-network { type inet:ipv4-prefix; description "Destination IPv4 address prefix."; } } description "Choice of specifying a destination IPv4 address or referring to a group of IPv4 destination addresses."; } PROPOSED choice destination-network { case destination-ipv4-network { leaf destination-ipv4-network { type inet:ipv4-prefix; description "Destination IPv4 address prefix."; } case destination-ipv4-prefix-list { leaf destination-ipv4-prefix-list { type leafref {path_to_where_the_prefix_list_is_defined}; description "Destination IPv4 address prefix list."; } } description "Choice of specifying a destination IPv4 address or referring to a group of IPv4 destination addresses."; } I hope this clarifies the intention. Thus, not only specify multiple prefix= es, but also handling the prefix list for reusability. Best Regards, Oscar -----Mensaje original----- De: Juergen Schoenwaelder Enviado el: mi=E9rcoles, 17 de marzo de 2021 13:29 Para: Oscar Gonz=E1lez de Dios CC: netmod@ietf.org Asunto: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-= list to the match Hi, let me check whether I understand your request correctly: I heard you sayin= g that you would like to have leaf-list destination-ipv6-network { type inet:ipv6-prefix; description "Destination IPv6 address prefix."; } instead of just leaf destination-ipv6-network { type inet:ipv6-prefix; description "Destination IPv6 address prefix."; } (and similar changes for the other IP prefix related leafs). While such a direct change may be difficult, given that the header fields a= re defined in a choice, it should be possible to add additional choices for= sets of prefixes. So from the YANG side, this seems to be something possib= le to address without too much trouble. Whether implementors are happy with supporting such a change is something o= thers have to comment on. /js On Wed, Mar 17, 2021 at 10:31:10AM +0000, Oscar Gonz=E1lez de Dios wrote: > Dear netmod wg colleagues, > > The ietf-acl YANG model defined in RFC 8519 allows to cre= ate rules, and for each a rule, in case of IPv4/IPv6 you can specify in the= match the source-network and destination-network. The source-network (or e= qually the destination network) is in the model an address prefix. In our u= se case in Telefonica we are specifying a prefix-list for source network an= d another prefix list for destination network. If you had to create this be= havior using the ACL model, you would need to create NxM rules. Besides, th= e management of those rules would be more complex. > > The routing policy model has the concept of prefix-sets, = but is a separate model (and a different use case). > > The functionality of specifying a prefix list for source = and destination in access control lists is available in most vendors that I= am aware today. Hence, it's a pretty standard functionality. > > Do you think it is useful to add this functionality to th= e ACL YANG model? If yes, what would be the procedure, given that ACL is al= ready defined in an existing RFC? > > Best Regards, > > Oscar > > > > > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=F3n privilegiada o confidencial y es para uso excl= usivo de la persona o entidad de destino. Si no es usted. el destinatario i= ndicado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y= /o copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. > > The information contained in this transmission is privileged and confiden= tial information intended only for the use of the individual or entity name= d above. If the reader of this message is not the intended recipient, you a= re hereby notified that any dissemination, distribution or copying of this = communication is strictly prohibited. If you have received this transmissio= n in error, do not read it. Please immediately reply to the sender that you= have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinat=E1rio, pode conter informa=E7=E3o privilegiada ou confidencial e= =E9 > para uso exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa > senhoria o destinat=E1rio indicado, fica notificado de que a leitura, > utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode esta= r proibida > em virtude da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destrui=E7=E3o > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Wed Mar 17 08:18:08 2021 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 34A303A0FE5 for ; Wed, 17 Mar 2021 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2XGbt18NKWJV for ; Wed, 17 Mar 2021 08:18:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9423A0FE7 for ; Wed, 17 Mar 2021 08:18:05 -0700 (PDT) Received: from jmbp.local ([IPv6:2601:1c0:cb00:5dd1:7971:245e:a50c:b466]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id 12HFI53o001539 for ; Wed, 17 Mar 2021 15:18:05 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:1c0:cb00:5dd1:7971:245e:a50c:b466] claimed to be jmbp.local To: "netmod@ietf.org" From: Joel Jaeggli Message-ID: <2d2632f5-c7d7-71c3-b27f-a44f679e66d8@bogus.com> Date: Wed, 17 Mar 2021 08:17:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [netmod] draft minutes ietf 110 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 15:18:07 -0000 We had posted an initial set, I have subsequently updated the draft minutes for ietf 110. they are viewable here: https://datatracker.ietf.org/meeting/110/materials/minutes-110-netmod-01 and remain editable in the codimd https://codimd.ietf.org/notes-ietf-110-netmod?edit The transcript exceeds the line length for a codimd note with or with out timstamps, (perils of talking for 125 minutes) but is viewable on the youtube file at https://www.youtube.com/watch?v=glLcpQ9kpv0 joel From nobody Wed Mar 17 08:35:34 2021 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 C1F083A105E for ; Wed, 17 Mar 2021 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsejuASt3zYq for ; Wed, 17 Mar 2021 08:35:30 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797F03A1060 for ; Wed, 17 Mar 2021 08:35:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oZ8KkOes/7b+A61aDc4aQd8Kl1y8zjHJlh/w7487Q2UhyyCTeL01v+Yxk3s5+FidiH07By9lmJlJne2zFJkRCtGK54x+q8rtCEqS2c7Vbwn8AFeQDuANDwRiuJ/2nZmKe2AI8CtSwsLkksggpK9Nn1lJIBuAHZ2HAIGc68x6iIE+VFHE+Jsy2l29ck0fSYGTuT+0y6w1uEJQumtV8f6iv+WvsfpDl/R+omzjcajcQA13EZf4E+u8rWczYW6iXzWr5byjEWr26Iv0l1TcVIi/DsxRkFDbK4DSi2aiO4iE5tpG7/koPXr5YUCed2WSAAuzs0y1Z0gnT7tWFk/VRGDBPA== 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=TlbQopKs+21bWlYpQLuRnGJWHZrp/Wh0DzcFdX4SEpU=; b=Jg5TWdQ3VZJq6/32SSFVrNwW1npksGEDdpGQ42WED/NVmN6eF3NwnqPpk0SqrVIvCvEeuWGC/INdSifJzwXRncIC38Cb61EkNV83/xhyL0u5vyC9Y83ZNaL89FSJU4gBoRwSl66rt1ceel6KFQiJdvqNqzDW0zsBqfRcYzIt9424LmdRIFGYMmVOAE406UOz+UMbR6zqD6YUms2/MDnQLMm1xLzFxhkRxmv6YiKjdqF44Wv0FtnjyGywq5+p/IvBXUAkOHvmhkjGn0TXlCxsMrjafuUFjUoWKZilN043V1TC5dGNFIoCU9RPwhN8vdY/kKpsCSZmFJxmbBIHXa9RUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TlbQopKs+21bWlYpQLuRnGJWHZrp/Wh0DzcFdX4SEpU=; b=BX8gH2LIRXu9TfZxHlg9UsjUtEt3E/5KAbjUepWe9tTx0qqfSEp8ZDOoIK5iOsb2mrwP2SfqHheUlS0F64KZw+MIfZ+siNa9o9XbMzr7H2YWUWwsoS/UbXArPfU3pJjrd9Ga31RTYgv+RVTE6yUWUexVBxW9dhP5+ghpaAU0nys= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=lightside-instruments.com; Received: from AM6PR08MB4086.eurprd08.prod.outlook.com (2603:10a6:20b:a8::32) by AS8PR08MB6136.eurprd08.prod.outlook.com (2603:10a6:20b:292::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 15:35:25 +0000 Received: from AM6PR08MB4086.eurprd08.prod.outlook.com ([fe80::698e:5271:2a70:5ee2]) by AM6PR08MB4086.eurprd08.prod.outlook.com ([fe80::698e:5271:2a70:5ee2%3]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 15:35:24 +0000 From: Vladimir Vassilev To: "netmod@ietf.org" References: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> Message-ID: <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> Date: Wed, 17 Mar 2021 16:35:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [84.209.6.28] X-ClientProxiedBy: OL1P279CA0064.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:15::15) To AM6PR08MB4086.eurprd08.prod.outlook.com (2603:10a6:20b:a8::32) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.19] (84.209.6.28) by OL1P279CA0064.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:15::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Wed, 17 Mar 2021 15:35:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c6b4e4d7-fd09-4c7a-2e0c-08d8e95a4887 X-MS-TrafficTypeDiagnostic: AS8PR08MB6136: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:163; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4Tosyxd5Usttx5z2nUFxJz3JU5us4EImwYQ5JArKQQKbs+GioZ1lXVl0av4ybuEXSlO1mh5Ynt5AzWV3ti3cT1dfceoR96htSSUf7Q9ATwHzNGMVjcUxBEXvk25RFbzcHrRyoz9bz6eQCSpewhNwUPEPb66dvOBUbA4T+kIlPCLh47mWG06ai91PLMmak1RPPJ6JysPgwTyYZUSSjQThybBaN/Rv900iQA6i+bSQ0BUgjOkrrFRx8X4oD3LW7odljdHqhgxJL3JYphlkx2kp39MHNEGYgrw0t4XPlDTVgdJo+9xH94RiSallWhXwnH05sms8KjeY3onWbTxfhTeYVK5aRaAzrjlK6g5GWcEOd+tyEk3Kv/GXB4Ds8HLJMLX1DrkJfSj8t9ZWw7kI2gN9iY31IvJN4sBoA/RVAtWiSSRX2nM55UgrKuCBYaD8WhauT5ESrEjP8C6khoZJ45Gx7WBMbBkQ2IsCoW4vQsArUUU6/5hDMf4ldJ1gwUwKMA94PcxeKGJpoO9/dkn+O/Eqlj/Ofc4g2pyv1qDc+0luwUFuyaAiTX9pvew9Zj+K6W2Me1Y2cItXBM6b5BtRgn0aBzLLy8HV+5IKrZ4RHe1NahRCocNMtP5djHzR5K3AsA9sdtCfI5aQJf0oCFwMTeWB8w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4086.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(366004)(39830400003)(136003)(346002)(478600001)(2906002)(31696002)(956004)(2616005)(316002)(16526019)(36756003)(5660300002)(186003)(66556008)(66946007)(16576012)(52116002)(83380400001)(8936002)(8676002)(6486002)(26005)(6916009)(66476007)(86362001)(31686004)(4744005)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ZDlGcithcitSd1RMYUtaRlhNZ2poaHFGdElKWlhvRG5STHhjNUxTVUtjUHhX?= =?utf-8?B?WVdhaEhocVc0dUl6T20rVjVXbUVIZjkwQnk5RVlRSHM5UVg4S0V2dWg0dHA0?= =?utf-8?B?bW1qaEFSdXRWdTlvWUl5WkZhLzBWcVZhM2NzY25CQjJleXdwWGIxUEdUd1oz?= =?utf-8?B?UGJYMFE3S2FQa1F4ZWswQlpzWm11TGtCLzZ5SjM3VUxyUzJNbEM3RDBWYTdy?= =?utf-8?B?Zmh5bGxjNnBRbS9WajkrRzNqV25ZeFlpNHlEbVY1d1pnSEU3MEFyK3lhQVJx?= =?utf-8?B?YW90V2QvR21mWVFrOXo0Q2ZhVnVvdlFnNng0ajRnNEFxVkpxTjFPQ0JaYUND?= =?utf-8?B?Yk9sTXlEd3VoaHhnem1sZk1aNVdZL3lXbEcvQ3JRQkZzRzl3dEpTUDZIeXpC?= =?utf-8?B?SEt4ZVJGL1ZSVEJUQllUV3FaVzBuK3B3Q1lVbnZIZ0owWnEwalIzb3RZNThF?= =?utf-8?B?VlpEblhnWWVHNVh3Z2NSSzVoajhEYUxiTitraGJUcXBIbmRtOTZCdGoyMGVM?= =?utf-8?B?cnFYNUJkeHhQZVlwR05PbXRsQ1M1WUxhemVNOHI0ZHhSc2R4OTJPTU9kdmZu?= =?utf-8?B?dElVNVRuQ3hUNU43QUVnWm9hNDE4Q3poTnAwUndJYjg1OWtwWWRSVFlIenJz?= =?utf-8?B?YjM3SkZkTms3RnFQRFl4SjFCSU9scjEwSkZ3SDdIVFd5ZGl2czdyVWtqNmxU?= =?utf-8?B?dEFocEtvVEE1QitDbDJSOWNNc3U2ZmxXV0tDeDd6RlN1Skoxb2YyR1BGV2Nx?= =?utf-8?B?WGtjaGJBbFNrcGRWUW9GTk1rZXQrWmZDcG5ud1FhYi92cFB6U0NnTnJ0aUkz?= =?utf-8?B?aE1JaFl4QndOc1l1Tkh6L0tCbi9uZmFLcFFGY2FFM0t0MUhkMnp1VjI5c2p5?= =?utf-8?B?Vlh0NkN6U21ncXBFb3hoY2VXM3BPU3JkTC83bDJrMXlySkVOMXZjRUQ5OHI3?= =?utf-8?B?NE00SWYyVVgveDlOaFgyQlhSRHNJQVJtR3YyRlJDZkQzamIvQVZjYXpHWEl0?= =?utf-8?B?djQ0TjVyYks3Z3VIREU1V0NLUzFJTXBESk5kSEVkU2c5V2RxWnZVSUdNbkc0?= =?utf-8?B?SmdkQlZWdUZxQ1dDbmxzbFlwNzFRcnJ5WllRSEVnWHd3VEdVakd3NDFad0Rj?= =?utf-8?B?ZjJxSFlXZkhZT0dBVG1UL3FudFRNbE95OVBMdjRlck53QUZvRXQ4UmpWOHNW?= =?utf-8?B?R0l4dURJUXA0dEc4ZDhpaUhSZWUrVXpYWFZOeG9tckFaeTdyd25xcUlscnQ2?= =?utf-8?B?cUlvanFIeXpDSzRacEp2YnB1Uy9JOTd1MGRjdDlVUklibkQzNHhzRHBDZjVG?= =?utf-8?B?UFNkQ2U4dnlZQlBnNTlHZy9saEprOVFiMDFpbmxEYnZZSGYvSFVtMFlHRkVF?= =?utf-8?B?eCszNXVjbFRobDJVdWk2ajNHelBOTHhMY21ES05YeVhsUDhpcWpjbG5HNi9j?= =?utf-8?B?OWIyZVlWQmw0VjRXcmxnTHdUK2NXVnM4YlVTMytxemVUemM1enBJNFFFWXpW?= =?utf-8?B?U0tkWVEyU0RuNXNDS0IyZUMyRU5PS1g2M2g5QnlQVU1WQ1NIM21rblBYTXo1?= =?utf-8?B?TGxmTTR5c2V1eTVoamI2SDFSeG1UbDcxWFdTa1NIdnNoMHRDK1pRUHh2bkta?= =?utf-8?B?SW80a1VCTHVSWWdCVG9yWmg0eit4azF6UEh6cENWSGdBZHFDNlVBWUN0Y2Uw?= =?utf-8?B?UmxKb1haazFQTGdwTUlUTlpkTUtYb3BCaVhnT2ZlN0d1ZjZZRDl4a3JxWjdo?= =?utf-8?Q?mmcR9u13mQALnF8HFxXWVTF9s+2ynPn9WvRGDFW?= X-OriginatorOrg: lightside-instruments.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6b4e4d7-fd09-4c7a-2e0c-08d8e95a4887 X-MS-Exchange-CrossTenant-AuthSource: AM6PR08MB4086.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2021 15:35:24.7171 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c0326317-f373-4461-a96f-7946e0abb603 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RJXIpJrPZyA9nrnodpp4MxfaXTceR/2T4+j0OsLfts1mESXo2yGU5KJ6dhl4DsaUrNr5G8HywNtMWkWTp4J6zY+WSNY69hcU5oRYENeKtb5UOSSKzZeLGFQm80EeR6C+ X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6136 Archived-At: Subject: Re: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 15:35:33 -0000 On 16/03/2021 13.36, Vladimir Vassilev wrote: > Hei, > > Many drafts and RFCs are flagged with warnings by the tracker > validation tools: > > ... > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p > {draftlib} -p {ianalib} -p {cataloglib} {model} -i: > warn: Module's revisions are not unique (2018-06-28). > > ... > > Does anyone know what causes this warning? Seems the warning is issued when iana-if-type@2020-01-10.yang is processed. It contains 2 revision (history) statements with identical dates 2018-06-28. IMO Multiple revision statements with the same date are valid so the tool reporting the warning has to be fixed. Vladimir From nobody Wed Mar 17 08:49:18 2021 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 F00093A108F for ; Wed, 17 Mar 2021 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=UhXDyl6N; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xqyi3RXP 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 qb6mnl04iijN for ; Wed, 17 Mar 2021 08:49:15 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050EB3A108B for ; Wed, 17 Mar 2021 08:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6640; q=dns/txt; s=iport; t=1615996155; x=1617205755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kkcrfQwwqfXmdF8ynxfUhDcak9Fod5sPbATcbqfclfk=; b=UhXDyl6NxjAIhG/9hEwzsp/TDBgiMSWPbqF0IS4+drnSACC063MRmRxC wjBlsxXJBfznIX5DvKvduXh0mX90dvJcohbq7NtHTqAFDOHIXLuBFiET6 Z8fVS+/w3yy8n6mxbfRsUn3M+lJnLUHMvzOlCqeeLhkuhBUENfLza6F+d U=; X-IPAS-Result: =?us-ascii?q?A0DACQC0JFJg/40NJK1XAx4BAQsSDECBRQuBU1EHdlo2M?= =?us-ascii?q?YRCg0gDhTmIRAOZLYFCgREDVAsBAQENAQEdCwoCBAEBhAxEAheBYAIlNwYOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgRxhTQBByUNhkUBAQEDAQEhEQwBASwLAQ0CA?= =?us-ascii?q?gEGAg4CCAICJgICAhkMAgkVEAEBBAENBYJwAYJVAy8BDpAMkGoCih53gTKDB?= =?us-ascii?q?AEBBoUGGIIUAwYFgQoqgnaECYVKeiYcgUpCJoESHIIqLj5rGQGBWwEBgSEEO?= =?us-ascii?q?hcKJoJPNYIrgVgBawYCVwgbPyA7DGM3FwaQek+CfaYOCoMEl0uEfQMfg0CKY?= =?us-ascii?q?IYEj3pDlDOdVUiEQAIEAgQFAg4BAQaBaiQqgS1wFTsqAYI+UBcCDYEaG4xqF?= =?us-ascii?q?x+DOTOEYYVFczgCBgEJAQEDCXyQAgEB?= IronPort-PHdr: A9a23:6NoraRPF+tY0pABVahwl6nfPWUAX047cNxMJ6pchl7NFe7ii+JKnJ kHE+PFxlzfhX4zQ7PhfzvfQsr7tQ3cB/YfHvH1ROJBPVhpQj8IQkkRgBcOeEkT0IbbsaDByB 8VNUlJpvhTZeUhYEcrzfRve93u16zNBGBz0MgBuY/nzG5Dfld+2y/H095CAKwlNjSC2NLV1K hj+pA7Nt84Q1I1lLKtUqFPJr3JEdv4Qy3lvIAeYng334YG7+5swmxk= IronPort-HdrOrdr: A9a23:AIcS+6hMmk3uLnK/e/eqTaBAWXBQX8tx3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5 tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4YOf Onl4p6jhCnfmkaadn+I3EDUfTKqdGjruOZXTctARk75A6SyQ6y4LnhHBSCmjsYWTVDwbAtmF K10DDRzKOlrv2911vgx3behq4m2efJ5/liIIi3isYTIijxkQrAXuRccpCLoTxdmpDV1H8Ei9 /Jyi1QWvhby3SURW2tpAuo5g+I6kdT11bH6Xu1xUTuutb4QjVSMbsCuat8fgHC40Qt+PFQuZ g7pV6xjJZcARPekCmV3bGhPHsG+jvW0BgfuNUegHBFXYwVZKU5l/1jwGpuDJwCECjmgbpXdt VGMcDG6P5aNXOcYnzJ11MfuOCEY3UpEh+KBnUFo8yeugIm5UxR8k1w/r16ol4wsLYGD7VU7e XNNapl0JtUSNUNUK57DOAdBeOqF23kW3v3QSevCGWiMJtCF2PGqpbx7rlwzvqtYoY0wJw7n4 mEeE9EtFQ1Z1nlBaS1rdl22yGIZF/4cSXmy8lY6ZQ8kKb7XqDXPSqKT01rtMe8vfMFAIn+V+ yoMJxbR9/vRFGeXrph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jVa/DWKL3xESs1W2/2D3 cZNQKDfflo3wSOYDvVkRLRU3TidgjU5pRrCpXX+OAV1cwMO+R3w1AooGX8wvvOBSxJs6Qwck c7CqjgiLmHqW6/+nuN621oPxFaH1tE+bmIaQIQmSY6d2fPNZoTsdSWfm5fmFGdIAVkcs/QGA lD41Jt+ay2KJSUzTs4C82uN3+bi3d7ngPNc74s3om4oev1cJIxCZgrHIZrEx/QKhBzkQF27H tYZBQcXU/ZHDP2gaCjhJgZbduvLeVUsUOOG4p5uHjfvUKTqYUTXXMdRSepStPSqx0pXSBoil p49LI/jLKMlS20E3Y2hP01PTR3GTmqKYMDKD7ARY1P3pj3ZQl7TA6x9E2noiB2XlCvymI/qS jKKzaOdfTCH1xH00oooprCwRdTbWWSf0V5d3Zgl5ZyfF625kpb4Kusere51XeXZx8kxOwQWQ u1Pwc6E0dJ28290gKTlXK5MUgegr8qPuDbEd0YAu7u83uwNYyFkrwHFfdI/JBjcMvjqPMPTP j3QX7mEBrlEe8znwSaqnE5URME20UMgLfm3gbo43O/22N6Cf3OIE5+T7VeON2E6XP4Lsz4nK lRnJYwveGqNH/2ZcPDwabLbyRbIhe7mx/9c8g47ZRVt7k1rr19At3SVibJzmhO2FE7IN3vnE 0TBKR977apAP4jQ+UCPyZY9EEujtKBMQ8itRH3GPY3eRU1lGDAVun5qobguP4qGAmMtQHwMV 6Q/2lU+OrERTKK0fofB7grKWpbZUAg4B1Zjay/XpyVDB/ve/BI/VK8PHP4arNbRaSfEbgbrx px4biz7qSqXju93BqVsSpwI6pI/WriXNi7BxiUH/VUt9O9IlaBj8KRkYCOpSayTSH+bUsWhY dILxNNKstCjyQvl40x3Gy5TLftrkcsjltZ5nVmmzfWq/+byXaeGVsDNwvTxohSV31UNHODiM ze6+iW1Hjn+lF+qNH+PVYVessLAsQaS4j8MjxnJscRtqO55qZHuFU2XD4+S2onzC3n1+xo3b 2lyOzfVu3rB3DvI08A81d+d/hJtz1ur3pBfci45Y+8ZQtSFvdgOYpL2rxr X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,256,1610409600"; d="scan'208";a="664203534" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2021 15:49:13 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 12HFnD0I003178 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 17 Mar 2021 15:49:13 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 17 Mar 2021 10:49:13 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 17 Mar 2021 10:49:12 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 17 Mar 2021 10:49:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QW497dJY3Vl5VGaMbJUV8BEjwJWi7HKRrDWv+N5P3qbQ+bC9eB2cMG91pYKblo5/ke4kSqXMUGNpcyKlOCofkaa19tfGAvBm7qerrLwCNRSNAvgc+7RckUjk0zZ4QB+UIFdVbKjELT0a/gvt3QrQwjQszhUvQSWfgSrL+3KYRd2QtvBn4hJWyxVKSQCyaAKLTlSebJ1DsoTNWi11cuzCxAZhql5AK1CPFONWKUuxh3Q6Z/U2QDvcgksQVleF+H4GVfH6ZKSnMPhbrxcdzlrai+F3xl5fIgmJQ3KxOCRRNtVQ6GpULkZ8ssr8/iloSI3QPuF7jPUGK1xzh4lg+U0apQ== 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=kkcrfQwwqfXmdF8ynxfUhDcak9Fod5sPbATcbqfclfk=; b=Q7+ZmaYCIS+IUJnB2lRnm2zSUkWj7jAzZ2ebMtYOtC/KB8AmBUZzalbvrsQKwOEi45+bg9yEcsB3jYSORtwYLuygDZdlO2n2tOrkPnHpxA7UU/oy+HXJwgEUKV+Nu0IA+X9FTpMFjB139BdKuYE6/jR3r1kegRBbCNbsnLM4dVCSKsMT6nW3klnEyISJ7aXbu7rooY0qV6TqAaeralHMPDU3PX0L+DpF5Sr+NmHAhwC8bP9pKFdzawoDxzyuKwn97JKAGQSEGxxSsHlb3s5isQVxdBPZmkyTXbhuarOzZNQpob9jXISQ0fKBAuy0ry+3Eh90oHSpM8CR7ycwUP+Nzg== 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=kkcrfQwwqfXmdF8ynxfUhDcak9Fod5sPbATcbqfclfk=; b=Xqyi3RXP/0wDRibdS6w7lIyXNE6XEsacYBzvwuO+LTqVPMVmBtuV+lFNOykTcdWRAriBluhEWKuXQy2sV1Aen9mpE8YNfUyYjzdH4P8NJ2+C3HCZniuiPUlDN9dKiAf+OX89YX14TTBtZgldh36I+pDQcFLAHatMq6lGD+JIDQA= Received: from BYAPR11MB3174.namprd11.prod.outlook.com (2603:10b6:a03:76::27) by SJ0PR11MB5024.namprd11.prod.outlook.com (2603:10b6:a03:2dd::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 15:49:12 +0000 Received: from BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::f506:5a18:a23:5125]) by BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::f506:5a18:a23:5125%7]) with mapi id 15.20.3955.018; Wed, 17 Mar 2021 15:49:12 +0000 From: "Aseem Choudhary (asechoud)" To: Juergen Schoenwaelder , =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= CC: "netmod@ietf.org" Thread-Topic: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match Thread-Index: AdcbGExc8OTG49eVSoeJejnhX1jHZwAENNWA///CiIA= Date: Wed, 17 Mar 2021 15:49:11 +0000 Message-ID: <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> In-Reply-To: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2600:1700:e320:64a0:ed29:c2cb:5c4:91b9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 393303a6-677d-441d-03ad-08d8e95c35b2 x-ms-traffictypediagnostic: SJ0PR11MB5024: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 73Ch39e16GRlsBqx/rnukSPRTvuVRsydT4oYpj/X6UoNG31mRA8yEjPgDhD7jOXHNnz7GBVdXdLrw9B+yfu8ZRnQbwKzCySScVbi4bXL5VumUcroVc+nU99SOXMeW3CzoUNm/Ce9TgYJZT6ZUw9BEQYNkj1KOuN4wCutmzGbN3viLNdsPKOfqc/7YnoNwhzOZh0LuF/eANmKsnKduc0xIZTqAuCyEiPHp8SaYSZjZgOGT+uv+fq6HUx/+Wew+ITxGX+ztiVXs1mwr9jjVu7PHxrd1dnTpRfu/9rZNF+k2jpjBOXCqsBbaUHNwu+YtA+DX4lMlboem5d27L6VNVHdwZDAyS2FgKSUl1zyvVuP8IJlKh1xJTrQxCoY5LfcEDs02XxbDpLKGxuHVREuVVdbYPfLFrd77qqEad3rMx/fZBthf/X81VtjNW4KvXp61XPxg32HRe8sOh1U9Fh6HjTsaWngv5SesB2/SofkxKPZLBkNmw7AwejxuMua+Q2NTN2a6ykeRzgJMmrHyzz7qqM4VT7NZrZ2vqGBXEEDH2/4WMtLxcivalTGG6BJqDUjMxOhz3Y/WzIsaNfUFJ6BfTsmQQkuQqo+vavQphFAvJgP5bbx2wqGmAPjnJaN2NImmbqj2O/pwII+qzAv65TSoeUendOHHAq514pFWD+QvXx5KoFnXs3YuGRsDvQ6tq+4uM99urTy9CQB+bIzQ3mx0maFXg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3174.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(376002)(39860400002)(136003)(6486002)(66476007)(76116006)(66946007)(36756003)(8936002)(66556008)(33656002)(64756008)(6506007)(66446008)(83380400001)(6512007)(4326008)(71200400001)(66574015)(110136005)(2616005)(86362001)(8676002)(316002)(186003)(478600001)(966005)(5660300002)(2906002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TVhBc2NvL3dBUlV3Nm1tVkVJcU5iQWdnVmZpQy8zaFk4MFNud2VFa1ZSeGNM?= =?utf-8?B?UzA2UEdOWGNMdU9pY1ppS00vbXJQU2dweGNyNVN4OFMvQldKVVF4M2hMYnhQ?= =?utf-8?B?OWxCZ3U0dDRuQS9STjltWGRRdFZlRTgxclBWc1lPQW51ODc1ekRpSW82eSt2?= =?utf-8?B?THVWTkpEa1g5ZDBrQUVCMW11Wkw5NXR1MkRLSHVKT0w4OTVmY2p1ZHNJbUR1?= =?utf-8?B?NUMrVEk2OVpGejNwQXluN1NMMWNOcERkRWNoVTRTb1ZpTEx6SHI2eTFURkFT?= =?utf-8?B?TkhIRExRR0kxcjNkZGR6YUFLYjFBYTlMZ3NqNXhEenJtOFFKRGFtWWdUZm1H?= =?utf-8?B?djMydyswWUEyMFI0OVF3Z0lUY2J2S1VCS1VwNkZQZWFCZno4NFZOeTlOVzQr?= =?utf-8?B?NGV6Q1RZbmpmd1FpZnM1V1RBc3ZvMTJDSVJpbTNLWis0MjZBVEhlb2RGSXFH?= =?utf-8?B?VkFicWpITHRkeDc0ZW5oQWljKzhEcWpkcENRZUlZTjNhSGJGejh5NnAyVmdi?= =?utf-8?B?L0RyMm1vb0R2YlZ6aFc1a1FVYXpNSG1TdklKaDZwTE03c2NCVzB6dFFvc2NL?= =?utf-8?B?VjFJY2pIQzVla0VsbFVubE41cGNYTjVya0k3bXY1WVY5aTFqSEYrSW1sSDUy?= =?utf-8?B?dFJxamZTbG15Si9udldKZTloRlZGNERQdndXUlh5dFY5RElyWDZuaTNmbWUw?= =?utf-8?B?V1NQQjAxUjJGclV0ZC9PVy9La3B5UG9YUm5UVjNSRUdHWFhqZTI3TkE5Tzh4?= =?utf-8?B?MEFBdkxYK2lIcFhvSm54SnVZMEZQNUlYait4Q0ZQRDUvbmdsN2RCd21LUU5y?= =?utf-8?B?NkwrY242NCs2blVlVngzVzFCNnczdnhGSDZ1eURURk5jV0RreEZmazVLbFRK?= =?utf-8?B?TGVocGhzNHBSb0luZUVJQXBxTUtzcFo2cUlRSXVjZW03ZG5peTQvVzZlM3d0?= =?utf-8?B?by94NnpwT1dzRjJ6UWZ1RTVQNkgzaXN2dXJPMmp4NXBPSUthelVXNHNlOHU1?= =?utf-8?B?Y1RzZ3RIUlJZRGJnQTlYN1dnZFJFSlRQOVNnQlhBY3hZc3BFb1NaemtOV3Jo?= =?utf-8?B?RmlVR1ltWHZqZHlTZUZDOHVoemFoNzE4TGgzbGVIbTFHaVdjM1UzbllNOEVi?= =?utf-8?B?em9QT0V2WkFDNzhZeFp6Zi9aY3Vmdk5HbDd4dWNIbFM3S3VCU3NCT1Y2KzNr?= =?utf-8?B?R2F5WjQ5Z29WQzhhdWJickpPemtjNUR1RWVuT295NTdQdmxDSlF2ZGM5Vlc4?= =?utf-8?B?WjE2WTFBbHQ2MWR1OTFFbXBpUTRBek9ESXpkY1BHUHNodlIzYWkweEVKOTYv?= =?utf-8?B?eXZQQ3dUUHk3T0VNWGp1aGhmVUcvSjhZUnlTYVByV2FpbjEzQ0laeEpJSEo2?= =?utf-8?B?TDFhTVFUWlUvSjlhN3lYYVZTNWhoNDVUTEgxRDY2MmI2ZmdJblROVTNVR1li?= =?utf-8?B?OUdLeUpKaFJhYVJCNmxScEFDWnB6RVBWVmQ2dGE2VktBekxQREVSSTRlQ3FD?= =?utf-8?B?VnN1QnFzdGMrR1ZLaTE2L1NEYWpjWTZSUTlBUGpvcHEycTA0RFkzUVdoTW9l?= =?utf-8?B?UVY2eTVmb0lHYnN4UjB2dHNOL2p0amd2aE1acHpUMEV4Mm9Ha2JBaGFvdWxt?= =?utf-8?B?Mys2TnM1a3FKTkp0QU5tc1dEanh3c1Z6b045Z2RCazB0ZkZBUFEzajViRWFr?= =?utf-8?B?ZGtLSjRwTGMzWEJzNFFUNFYrMW0wa3RHb0ZWbjJFTEI2NWVkUm5UTzFFMWJq?= =?utf-8?B?TzdXOEp2RU5EWWJPQ0N5WVMvak9zdkNqdjY3Z01GcGN1VTBpOUZPSG54UlZu?= =?utf-8?B?SWUvK2hDbXhXWnIxZ0FaMTZwR3JMUUpUTkRRZkJONEZnTEJKWGdyVlV0TmRL?= =?utf-8?B?MXZjT1FhY2k2K1paSzdQcXI3OG5tTFlqRjQ1TWQrdlcycnc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <79953539FB653241A5EBEC04085E9E76@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3174.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 393303a6-677d-441d-03ad-08d8e95c35b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 15:49:11.8667 (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: GAhQk7VhqHlQK3+rJY/5t/DjcW93EuOSRtsOmysnvqf3/RB6q+5A1H5CTnKlS8Xus/wq9MhkoxMUOWV2MtwBOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5024 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 15:49:17 -0000 SGksDQoNClNpbWlsYXJseSwgdGhlcmUgaXMgTnhNIGlzc3VlIHdoZW4gdGhlcmUgYXJlIG1vcmUg dGhhbiBvbmUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBwb3J0L3BvcnQgcmFuZ2VzLg0KDQotdGhh bmtzLA0KQXNlZW0NCg0K77u/T24gMy8xNy8yMSwgNToyOSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCiAg ICBIaSwNCg0KICAgIGxldCBtZSBjaGVjayB3aGV0aGVyIEkgdW5kZXJzdGFuZCB5b3VyIHJlcXVl c3QgY29ycmVjdGx5OiBJIGhlYXJkIHlvdQ0KICAgIHNheWluZyB0aGF0IHlvdSB3b3VsZCBsaWtl IHRvIGhhdmUNCg0KICAgICAgICAgICAgbGVhZi1saXN0IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29y ayB7DQogICAgICAgICAgICAgIHR5cGUgaW5ldDppcHY2LXByZWZpeDsNCiAgICAgICAgICAgICAg ZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAiRGVzdGluYXRpb24gSVB2NiBhZGRyZXNzIHBy ZWZpeC4iOw0KICAgICAgICAgICAgfQ0KDQogICAgaW5zdGVhZCBvZiBqdXN0DQoNCiAgICAgICAg ICAgIGxlYWYgZGVzdGluYXRpb24taXB2Ni1uZXR3b3JrIHsNCiAgICAgICAgICAgICAgdHlwZSBp bmV0OmlwdjYtcHJlZml4Ow0KICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAg ICAgICJEZXN0aW5hdGlvbiBJUHY2IGFkZHJlc3MgcHJlZml4LiI7DQogICAgICAgICAgICB9DQoN CiAgICAoYW5kIHNpbWlsYXIgY2hhbmdlcyBmb3IgdGhlIG90aGVyIElQIHByZWZpeCByZWxhdGVk IGxlYWZzKS4NCg0KICAgIFdoaWxlIHN1Y2ggYSBkaXJlY3QgY2hhbmdlIG1heSBiZSBkaWZmaWN1 bHQsIGdpdmVuIHRoYXQgdGhlIGhlYWRlcg0KICAgIGZpZWxkcyBhcmUgZGVmaW5lZCBpbiBhIGNo b2ljZSwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGFkZA0KICAgIGFkZGl0aW9uYWwgY2hvaWNl cyBmb3Igc2V0cyBvZiBwcmVmaXhlcy4gU28gZnJvbSB0aGUgWUFORyBzaWRlLCB0aGlzDQogICAg c2VlbXMgdG8gYmUgc29tZXRoaW5nIHBvc3NpYmxlIHRvIGFkZHJlc3Mgd2l0aG91dCB0b28gbXVj aCB0cm91YmxlLg0KDQogICAgV2hldGhlciBpbXBsZW1lbnRvcnMgYXJlIGhhcHB5IHdpdGggc3Vw cG9ydGluZyBzdWNoIGEgY2hhbmdlIGlzDQogICAgc29tZXRoaW5nIG90aGVycyBoYXZlIHRvIGNv bW1lbnQgb24uDQoNCiAgICAvanMNCg0KICAgIE9uIFdlZCwgTWFyIDE3LCAyMDIxIGF0IDEwOjMx OjEwQU0gKzAwMDAsIE9zY2FyIEdvbnrDoWxleiBkZSBEaW9zIHdyb3RlOg0KICAgID4gRGVhciBu ZXRtb2Qgd2cgY29sbGVhZ3VlcywNCiAgICA+IA0KICAgID4gICAgICAgICAgICAgICAgIFRoZSBp ZXRmLWFjbCBZQU5HIG1vZGVsIGRlZmluZWQgaW4gUkZDIDg1MTkgYWxsb3dzIHRvIGNyZWF0ZSBy dWxlcywgYW5kIGZvciBlYWNoIGEgcnVsZSwgaW4gY2FzZSBvZiBJUHY0L0lQdjYgeW91IGNhbiBz cGVjaWZ5IGluIHRoZSBtYXRjaCB0aGUgc291cmNlLW5ldHdvcmsgYW5kIGRlc3RpbmF0aW9uLW5l dHdvcmsuIFRoZSBzb3VyY2UtbmV0d29yayAob3IgZXF1YWxseSB0aGUgZGVzdGluYXRpb24gbmV0 d29yaykgaXMgaW4gdGhlIG1vZGVsIGFuIGFkZHJlc3MgcHJlZml4LiBJbiBvdXIgdXNlIGNhc2Ug aW4gVGVsZWZvbmljYSB3ZSBhcmUgc3BlY2lmeWluZyBhIHByZWZpeC1saXN0IGZvciBzb3VyY2Ug bmV0d29yayBhbmQgYW5vdGhlciBwcmVmaXggbGlzdCBmb3IgZGVzdGluYXRpb24gbmV0d29yay4g SWYgeW91IGhhZCB0byBjcmVhdGUgdGhpcyBiZWhhdmlvciB1c2luZyB0aGUgQUNMIG1vZGVsLCB5 b3Ugd291bGQgbmVlZCB0byBjcmVhdGUgTnhNIHJ1bGVzLiBCZXNpZGVzLCB0aGUgbWFuYWdlbWVu dCBvZiB0aG9zZSBydWxlcyB3b3VsZCBiZSBtb3JlIGNvbXBsZXguDQogICAgPiANCiAgICA+ICAg ICAgICAgICAgICAgICBUaGUgcm91dGluZyBwb2xpY3kgbW9kZWwgaGFzIHRoZSBjb25jZXB0IG9m IHByZWZpeC1zZXRzLCBidXQgaXMgYSBzZXBhcmF0ZSBtb2RlbCAoYW5kIGEgZGlmZmVyZW50IHVz ZSBjYXNlKS4NCiAgICA+IA0KICAgID4gICAgICAgICAgICAgICAgIFRoZSBmdW5jdGlvbmFsaXR5 IG9mIHNwZWNpZnlpbmcgYSBwcmVmaXggbGlzdCBmb3Igc291cmNlIGFuZCBkZXN0aW5hdGlvbiBp biBhY2Nlc3MgY29udHJvbCBsaXN0cyBpcyBhdmFpbGFibGUgaW4gbW9zdCB2ZW5kb3JzIHRoYXQg SSBhbSBhd2FyZSB0b2RheS4gSGVuY2UsIGl0J3MgYSBwcmV0dHkgc3RhbmRhcmQgZnVuY3Rpb25h bGl0eS4NCiAgICA+IA0KICAgID4gICAgICAgICAgICAgICAgIERvIHlvdSB0aGluayBpdCBpcyB1 c2VmdWwgdG8gYWRkIHRoaXMgZnVuY3Rpb25hbGl0eSB0byB0aGUgQUNMIFlBTkcgbW9kZWw/IElm IHllcywgd2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlLCBnaXZlbiB0aGF0IEFDTCBpcyBhbHJl YWR5IGRlZmluZWQgaW4gYW4gZXhpc3RpbmcgUkZDPw0KICAgID4gDQogICAgPiAgICAgICAgICAg ICAgICAgQmVzdCBSZWdhcmRzLA0KICAgID4gDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgT3NjYXINCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQog ICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gDQogICAgPiBFc3Rl IG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRl c3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNv bmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRh ZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBx dWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2Fj acOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVu IHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBt ZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlh dGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4N CiAgICA+IA0KICAgID4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlz c2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQg b25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUu IElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0 aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhl biBkZWxldGUgaXQuDQogICAgPiANCiAgICA+IEVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBz ZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRl ciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNv IGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2 b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBk ZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBz ZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNs YcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1v cy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZp YSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQoNCiAgICA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBuZXRtb2QgbWFpbGluZyBsaXN0 DQogICAgPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KICAgIC0tIA0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQogICAgUGhvbmU6ICs0 OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy bWFueQ0KICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlLz4NCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5ldG1vZEBp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQoNCg== From nobody Wed Mar 17 08:58:43 2021 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 B823E3A10CA for ; Wed, 17 Mar 2021 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcYkV82Jpa6x for ; Wed, 17 Mar 2021 08:58:39 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2059.outbound.protection.outlook.com [40.107.21.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC6A3A10C0 for ; Wed, 17 Mar 2021 08:58:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FMmIdS/swImGsiYppnnHKiDSKwcSaBT1qloYq0dmI5yv13tRDgeXdK9QZHIrQFHiHx2kry+dVHAi2r7hvgtBjEtwyjf1KfcJ5SAqAOkZXuxbiiY/eGVFP2g0sfH9+L/3JybIjPBwOEriIFg/53GLwN1yhoRZFMexAYGCUs1Otpjj47BEblrTEDcSTmifrPp/R9a+Y3ymWa8daSQKD/opr6djEqJnJTsfUFpj6pCvN3W/E5avTWd8LoBQFQlYyME491ikR3zjXOAMo1blZS1HdtFoKyEpgl77hlctNkDevIO5ZsHZzQ2ksaj6+rxPDWQhMq695AGg7AjgiK7+JoRlPw== 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=Y+MeBpuUIyHZyGu/Gqf1lYiU6xDLo0YMS0eR6D2S+5c=; b=ZUGjSjNGWthfCTT0DcD/GHoGh+FQMuVUaORUJ4QxDVoGsylBa4LM6RGMXuLdKiiYNDX3ig6Lt0nTjXMLxngRLGSsAlF5BaPmG4xWdbS24SQ/eG5x7hrV7A12bPLGeXY9W8F2A0AiFuyNHmYVgATUKES2oNBdAbK5SSkh54RvDmMuvEou9Gvc9qmGCtbccrK8ifV+4/f3UK15+JLt35OlAg/cm98UDDJdlMU0OjEXjXyJhR5KnOy7q3M52JmjP5eXz2GXzJf7MB/aEiixMnYucusW5VGUma7UGTvsex1agGm3xq5uLerAWsZXlRBHUjLHrKmsLwCfOkpllYxF6rMZWw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y+MeBpuUIyHZyGu/Gqf1lYiU6xDLo0YMS0eR6D2S+5c=; b=lyxubV4d7ePWx9XJnyDV0TDyJdi5Ok+Dx3HtLJwRxV8PFwKe3SW8xbuv23BtcxHnF8SZHEqoO0698gQhkPsOPqz/ikIeUy8VuptwpyrURahPaNaq5lopcXyMWp8lzFvNqptCt180u5E+nFMPPNLfwxRS1ixVNqeMNM6TnrFWMHQ= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1044.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:267::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 17 Mar 2021 15:58:35 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%5]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 15:58:35 +0000 Date: Wed, 17 Mar 2021 16:58:34 +0100 From: Juergen Schoenwaelder To: "Aseem Choudhary (asechoud)" Cc: Oscar =?utf-8?B?R29uesOhbGV6?= de Dios , "netmod@ietf.org" Message-ID: <20210317155834.nz6cv4mefwxrjgmq@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Aseem Choudhary (asechoud)" , Oscar =?utf-8?B?R29uesOhbGV6?= de Dios , "netmod@ietf.org" References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM4PR0302CA0033.eurprd03.prod.outlook.com (2603:10a6:205:2::46) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM4PR0302CA0033.eurprd03.prod.outlook.com (2603:10a6:205:2::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Wed, 17 Mar 2021 15:58:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fa90e76e-ee1d-4ee3-ff21-08d8e95d85a4 X-MS-TrafficTypeDiagnostic: AM9P190MB1044: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lrrLyhtsXb/d8vvwQTfRvwtxUJG9zQ27DINCpk3jr0SGE5qi/DeTP4kuXbOSdQ7wLplp+/myJYNgo0phtUrsz7ZfqmPNvpSQFkqt77ihNSysLkxrbugYePDUYrwOl+dBcm1am+lnak3L82TXkkgikC+hXRXtS2Ftj56hT6Xd2/Hn8kK9l0gPvciU+mQj4QCSrmJxSMnzDXvw1UO6ECe2qvU80xA4Djq72NU9+6t//kyQiT9MZ0hHcZFuShvjn2LzVuyIk9RlSeahTeIGGt7LtQpImGi7wBwrjeJU/hvfV4+CD1pwPrj62Kojp4bZZWkk8K9k2FlGAQFaOzTZoiau1x5ZdkmtZnqWutUrTJ2yBWDT2j/FKmC7AmIHyOIq4GMHdaC5Xy4lz3Dh+mfGwZBTDm+XIEvv8eST8ne1rKBFCgfpx68O8n3tfIdXOTX/LWEjpy/l01qGrHvYXQHmlIR46h0TBP5WYiPWxcfBhE3H+G8Fn1ltmNScQI6LzKvBRZWCVYXRfLCduQ7Zivm67oIbKSszzmEYGs5jkp8VuCUTCK1/pC+GcYoEVmkrRMcsnsaTf9l5RVVGJiqM8YDDyvzjHzdVkkC4pcWeqLwWsUwNLA3SatfWiNA9kkhcKjw3RORybpW/NtLJ7S3ZqF5a4jqGgQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(136003)(346002)(39850400004)(316002)(5660300002)(6916009)(786003)(6486002)(52116002)(66946007)(66556008)(66476007)(478600001)(54906003)(956004)(8676002)(2906002)(66574015)(8936002)(26005)(4326008)(16526019)(6496006)(186003)(3450700001)(86362001)(966005)(83380400001)(1076003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?cHRPdVdLOXVzdzNCZENqNmM4WVJmTU82TTAwenpWSGhPdndqZmFSbzdWWW1t?= =?utf-8?B?Wld4K1Z1S25KNEFMcE5MK253cmYxd21CZWVsNlg1VW9lc3dkMVVBNnhvcUFn?= =?utf-8?B?RmhjcjhRNXlGTS8rUUxLTUFveW9lNnBFRnMxSExseTY5RnBzYk5MZjc4RDVy?= =?utf-8?B?MG1xNTcyRU1EZS9LYjJiM2dWTG5TN1JqRFRTcUk1Z1ZaNDE3ZEdzdEpQZmNE?= =?utf-8?B?eS9tQm9VZjkrTkdCRjNLS3RLYzNTK3ZLMjhVU1RTZFlwWUlyeWRoeEl1d01K?= =?utf-8?B?bmt0eHcrd0RwWFgxdmpCY2NjT2t4VzBCMkdudDdseUQ4aHQ0UXdDZjJBMjJS?= =?utf-8?B?MHEwWjFDbFVaWE5xRDlIUjROVmk1dXRiSnhCdHZ0VUNHSFhWd3FRaGVzMXp6?= =?utf-8?B?L01Oa1MyN0xmWDMxV3BxOWExVEM2RFpQNTVuNVM3NjBMMVM1NitFRzRvOUdR?= =?utf-8?B?WWhNOUkwWW9LTVFVZU5GMmRwWVBQM280c1VMWk5POHQwUVE0b3dGdjlkdTlJ?= =?utf-8?B?R1BGMS9naTYvOVRBZTZPRnV4ZmwxaWNraWJhdjZ4TGdHKzdsdzJCbFg5WG9k?= =?utf-8?B?T1lwMitRYVJ0MmhSbVZYQ0xQR2lVc3BIUU9PY1FPVStENHQ4R0JyWUhjMnpy?= =?utf-8?B?VWZUaGZZOWJQQWlialJwMFduOWloSmhCNzhPZENBQjdoSFRnRXJnc00xM2hF?= =?utf-8?B?V1NMd1gyR25ZUWZHQWhxTitvckRmRG9DQk4yLytMRVJNRkU2TTJNNys4L3JC?= =?utf-8?B?MjlVTmduV3gxeEliU2VJWHVSRzJ3MkdlQ0dkNzgrRDF1RlpyWE1oMDh1aHNM?= =?utf-8?B?WVQvNHFGanVuZFhhdWtFT0cxT0tVQWFpL0VmUkd2NnhNS3drd1dsejhUYXAv?= =?utf-8?B?dVZSZEJ6eTdTbGM4T3JkL3N5bk1QT1JEd2ZVMG85b2I4SU5GNFNxd3UvZ295?= =?utf-8?B?OGZtSm5TRE85YzlBT29jVVpzWURlZ09CcitkR05NUnQ5Tll6WDZQMlBOMWZk?= =?utf-8?B?TUNseldRa3FramFiNnBqRGN2L0NINzdmaGs1R3huZWV3V09sYnJDOU5QQk1l?= =?utf-8?B?alBOK2tUbm9jZHBWUkdRTHNkRC9iVGRPYk5XTmF1VTlqNzdYVWNnaGRPV1Nk?= =?utf-8?B?SUNWaGlKNTV2TXJ3NmpXMVNodUVBWndQbFJCZGczV1R6UytFMTlGUlNRdThj?= =?utf-8?B?R2Z3NkcyYmZoUUxSZjEwbnNtSUJUNEk1dGhhbE04R21VQzVIc2Z3b2FORHJJ?= =?utf-8?B?bG5JNjFpY0c0TGh5MTRCUzVTVENjUmc4eTFZRWVLUFdDOGE2OG5QWlJaMG5T?= =?utf-8?B?UVVESkNVWWhWWGhmeU5pUnBMM2kzVCtsbkJYVGs5anFzQW1KdklUQlFteGh1?= =?utf-8?B?VGRObFhXbnkwcHpROTJYWDNPVjBwcGxMYm1RdkFsbGpaRXo1SldlWmZYZzhm?= =?utf-8?B?SzFNSUgxVjh3a2MzbmNWeFIyeXdNTWpNdHZoS1NGT1lpVGlOcHBCUDRvY2Ja?= =?utf-8?B?MC81cXlSMXpscVY3eVh1OU0xbVBzbFhZa0N1SWUwcSsxS3ZjbUJsRXFXeFYr?= =?utf-8?B?SlhvWGduaFdtbEJtaStSMmpSM2k3OExNcDZpT2xBT1E5V25ReHdyb3k0V0wv?= =?utf-8?B?Q0hPR1JOcHMvZFhkaXFRbEZzdHVvVzU4ZGZTQ0pzR1kvWEkzcUdmVXZwb1Uy?= =?utf-8?B?bm1Mck13eGUxMExTRHRPMFYrekNNN3RFR2Vqb2ptcnZtMHhMY2NYUlBnd3h3?= =?utf-8?Q?KA7h7jdYmCSK6OTpl2mFVfRwF7tBEOwblNsO34W?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: fa90e76e-ee1d-4ee3-ff21-08d8e95d85a4 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2021 15:58:35.7523 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YZ0To6A6DXy46aOJaNdDfMMY5sC0hgxsQKapabbpet/oHI32JLY4NtVK5ynhNAI8NSBs6Yh37oCbVV+ivHylqNDtrgd9vD+Moqaj470UVu4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1044 Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 15:58:42 -0000 I now understand that the original request was about two things: - allowing sets of prefixes in an ACL (instead of just a single) - sharing of sets of prefixes between ACLs And yes, if the WG goes there, then of course the same questions will come up for all the other possible header fields... - allowing sets of ports/port ranges - sharing of sets of ports/port ranges between ACLs [...] /js On Wed, Mar 17, 2021 at 03:49:11PM +0000, Aseem Choudhary (asechoud) wrote: > Hi, > > Similarly, there is NxM issue when there are more than one source and destination port/port ranges. > > -thanks, > Aseem > > On 3/17/21, 5:29 AM, "netmod on behalf of Juergen Schoenwaelder" wrote: > > Hi, > > let me check whether I understand your request correctly: I heard you > saying that you would like to have > > leaf-list destination-ipv6-network { > type inet:ipv6-prefix; > description > "Destination IPv6 address prefix."; > } > > instead of just > > leaf destination-ipv6-network { > type inet:ipv6-prefix; > description > "Destination IPv6 address prefix."; > } > > (and similar changes for the other IP prefix related leafs). > > While such a direct change may be difficult, given that the header > fields are defined in a choice, it should be possible to add > additional choices for sets of prefixes. So from the YANG side, this > seems to be something possible to address without too much trouble. > > Whether implementors are happy with supporting such a change is > something others have to comment on. > > /js > > On Wed, Mar 17, 2021 at 10:31:10AM +0000, Oscar González de Dios wrote: > > Dear netmod wg colleagues, > > > > The ietf-acl YANG model defined in RFC 8519 allows to create rules, and for each a rule, in case of IPv4/IPv6 you can specify in the match the source-network and destination-network. The source-network (or equally the destination network) is in the model an address prefix. In our use case in Telefonica we are specifying a prefix-list for source network and another prefix list for destination network. If you had to create this behavior using the ACL model, you would need to create NxM rules. Besides, the management of those rules would be more complex. > > > > The routing policy model has the concept of prefix-sets, but is a separate model (and a different use case). > > > > The functionality of specifying a prefix list for source and destination in access control lists is available in most vendors that I am aware today. Hence, it's a pretty standard functionality. > > > > Do you think it is useful to add this functionality to the ACL YANG model? If yes, what would be the procedure, given that ACL is already defined in an existing RFC? > > > > Best Regards, > > > > Oscar > > > > > > > > > > > > ________________________________ > > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. > > > > The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Mar 17 09:16:27 2021 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 6CF823A0163 for ; Wed, 17 Mar 2021 09:16:25 -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=PdhTQ9kd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MsymY5nd 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 DFOIefj8j7KE for ; Wed, 17 Mar 2021 09:16:23 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6293D3A00E5 for ; Wed, 17 Mar 2021 09:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8654; q=dns/txt; s=iport; t=1615997783; x=1617207383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pmK7GXt2aQkNJhWqsBunkG3BXZdG/WMkrM4cBSzT6uo=; b=PdhTQ9kdRXJxiCyTgQsnbi6U8roRrRPOCbU+1YRGTv+Pkp14c1WW7q18 cJRuxuPu1DW0ZXEYU09yBGF7cdDLApgCrtZp61J7Jxe3You+LxMHAG+7w kgSh8gCIGKZsOpDSSJGxBPZlPt6liDeRCTO57JOSyro/l8FT+JWQQs+CF k=; X-IPAS-Result: =?us-ascii?q?A0C6AADtKlJgkI9dJa1XAxwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IE/BAEBCwGBUlF9WjYxhEKDSAOFOYgfJQOZLYFCgREDVAsBAQENAQEdCwoCB?= =?us-ascii?q?AEBhAxEAheBYAIlNwYOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhgsBB?= =?us-ascii?q?yUNhkUBAQEDAQEhEQwBASwLAQ0CAgEGAg4CCAICJgICAhkMAgkVEAEBBA4Fg?= =?us-ascii?q?nABglUDLwEOkA6QagKKHneBMoMEAQEGhQYYghQDBgWBCioBgnWECYVKeiYcg?= =?us-ascii?q?UpCJoESDBCCKi4+axkBgVsBAYEhBFEKJoJPNYIrgVgBEFsGAlcIGzcIIDsMM?= =?us-ascii?q?TIUIxcGkHpPgn2mDgqDBJdLhH0DH4NAimCGBI96Q7IISIRAAgICAgQFAg4BA?= =?us-ascii?q?QaBaiKBWXAVOyoBgj5QFwINgRobjGoXAh2DOTOEYYVFczgCBgEJAQEDCXyQA?= =?us-ascii?q?gEB?= IronPort-PHdr: A9a23:TF/H8B0X5PvrzoAFsmDPY1BlVkAck7zpIg4Y7IYmgLtSc6Oluo7vJ 1Hb+e4FpF3AVoLR8LdZjevIvrr7WHARp5qM4zgOc51JAhkCj8he3wktG9WMBkCzKvn2Jzc7E 8JPWB4AnTm7PEFZFdy4awjUpXu/vjwbERL1Lk9oIOXrF5TJjtimkey/qNXfZgxSj2+7ZrV/Z By9sQTWsJwQho1vT8R5yhbArnZSPepMwmY9LlOIlBG67cC1r/Ze IronPort-HdrOrdr: A9a23:FU566Km17h6ItpmBLZljd2troeDpDfM9jmdD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3AUV4hLxW5Ce2GmO2dxQxRLAod8NL f03LsGmxOLf3MLYsOnQlwMWOber9PG/aiWHyIuLRgh9QWIkHeU87b8CReVxVMzVDlIzLck/w H+4k/Ez4+ktOy2zQKZ6n/L4/1t6Zrc4/ZgJOjJsMgaLT3wlh2lDb4AZ5SutC04ydvfk2oCv8 LLp34bTqFOwlPXOlq4uB78nzTnuQxel0PK7X+9rT/drdfiRDQ8YvAxx75xVhfC8UIvsJVd/c twrhiknqFaBx/BgyjxjuKgP3oB+ybEwgtBrccpg3NSSocYYrNKxLZvgX99KosKHy7x9ekcYY 9TJfzc//pffBe7aH3UrwBUsaSRd0kzBRuPTww+vNWU2VFt7QlE5nYfrfZv+ksoxdYYcd1p9u 7EOqNnmPVlVckNd59wA+8HXI+eFnHNaQikChPWHX3XUIU8f17doZ/+57s4oMuwfoYT8Zc0kJ PdFHtFqG8JfV70A8Hm5uwOzjn9BEGGGRj9wMBX4JZ0/pfmQqDwDCGFQFcy1+ytvusYGc+ef/ qoIppZD7vCIALVaMF09jy7f6MXBWgVUcUTtNp+cUmJuNj3JorjsfGef+3UILbrDDY4SmLyCn YOR1HIVZx9x3HufkW9rAnaWnvrdEC614l3CrLm8+8az5VINoAkiHlMtX2JouWwbRFSuK0/e0 VzZJn9lLmgmGWw9WHUq2FgOh9XCFdJ8KztOkk6/jMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFw ZZuhBw4qK4L5uZwCg4ENK5OmeGj38ezUj6Cas0q+mm34PIa5k4BpEpVOhaDgPQDSF4ng5stS NecgMeX1TeETnvkK2hi5QRCIjkBoNBqTbuBfQRhWPUtE2aq81qe2ASWCS2V9WLxSw0QSBPu1 F3+6gDobaJlDq1M1EjiOAgPFAkUhXLPJt2SCC+IKRdgPTCZRx5R2biv03qtzgDPk7Rs3g0qk OkByuOYv3PCkdaoRljo9bX2WIxUH6ccUJ2Ym19qqtnGw39yypO+N7OQLav2G2MbVZH5ecRPF j+EGUvCzIr4cyr3xiInzvHL1Ea/9EFO+zQC6lLScCN5lqkNJCImaYaH/Vd4ZZiM5T0vvUWVP +EEjXlXg/QF/kkwEicqHojJUBP2QoZuOKt1xv/4Gei2nkjRfLUPVR9XrkeZ8qR9m7+Wp+zod lEpMNwueu7KWPqbNGajanRcj5YMxvWyFTGBd0AuNRRvagosqF0EISeWTzU1Gtf1BF7KMvvjk sRTOB657/GU7UfMvA6amZc/lAzks6II1ZuugvqAvUmdVVolmTFJbqykvP1gKtqBlfEqBr7OF GZ/SEY9/DZXzGb3bpfD64rO2xZZEU19XwKxpLMS6TATAGxM+1T9luzNXGwNKVQT6WIAr0cpB d36dPgpZ7dSwPonATL+TdrKKNH9GiqBd6oCAWXAOhS7pi0P0+PjqbC2r/8sB7nDT+gL0IWio 1OeRZOMoBNijw+gJY21Sb3QKrtuU4hm0Zf5zYillOF4PnQ3E7LWUVddQveidFKWDMWNH6Ch8 HM6/KZ23Tw+yIt4+iKKG5AOtVVX8ENRY32JTp0IccevLS077Mi6x4zFCsGHio5knThxOto0r eyxeXKV+DjAXnuP0gd+TQtPP8DogU77Wdac8a/6pqhYgIYUu4QasFPk7xrrA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,256,1610409600"; d="scan'208";a="686445550" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2021 16:16:22 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 12HGGMG6022514 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 17 Mar 2021 16:16:22 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 17 Mar 2021 11:16:22 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 17 Mar 2021 11:16:21 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 17 Mar 2021 12:16:21 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=be0/dn7/o05pM63iK7u5IV6s9dizq8aoRO3AJnjDspTxbcVqkUPePA05mVl0P5N4lTp+pD1ZQHyheE7ApLNm3OYA/4vTU0yvuLkweK8miytCbiwJ4MgisZymz0EwBmYsHC8pRg3Nd7bBVbghf8ejiY0Ap+ZL0fs4sygGmeVH/5l52j4WVkRPu55pRaWDFECo0VZ3vx9tnjTsWFN79ZIXg8F6lNMVXIEM4MXBmHEdfTGBGnnHs8dIC6thIaKW+5KRUNsbKiSXHhs776UrkxDkQsASnRZMnaNMcxxm0WBgeSQ5quRZ8u04T6kebkiPWSFa3cSf/isH9e4oITeYGrHyDQ== 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=pmK7GXt2aQkNJhWqsBunkG3BXZdG/WMkrM4cBSzT6uo=; b=S6P7wH2TJGu9lt1kSu4H1zBRRM34c80xZGvrP4rxVFPSpy8ZCH28EBTVOuV8GcDcPoRkfyxrhxt2b4eFX4gAxBxcHcWchMAY/QFsGX6i5cmPyq4m+FICSzM/Kqc44X9WsCKkA5VBDeu70u8HECHKss8LLQ7BsS3/+vqbMnxITpCo1Jn8DKnpyOUeNs9LYST+3QYbdu8PoTFNY6l2bwpqLPYErbzLp0YkmA7ychPhr8R1QhO1ueGZqo1HOOTZ9WAZK6ZNgiy7TBY6Q4eK3ulpgwuFy58HxqWaecHdqWSzPompPQ0NuqIbVxPuJtLfjsyFm1f8iqBNDshtc4DwDaXVQQ== 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=pmK7GXt2aQkNJhWqsBunkG3BXZdG/WMkrM4cBSzT6uo=; b=MsymY5nd4iuX71a2hJGDwJpTeAgqxjHQ2eTe6vk21oiGWlEjCo72CsaDjuoaRgtf1SpVRttjJIGF5lvX1vOu1lUdfFZE6NhqoId1PnWnNRubrXHD/75NjLYkZG2KZZvfMZh3jrDA0O2nVKNFLg+BzfSN4T3HA5zRHNqwDfN+IkE= Received: from BYAPR11MB3174.namprd11.prod.outlook.com (2603:10b6:a03:76::27) by BYAPR11MB3781.namprd11.prod.outlook.com (2603:10b6:a03:b1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Wed, 17 Mar 2021 16:16:20 +0000 Received: from BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::f506:5a18:a23:5125]) by BYAPR11MB3174.namprd11.prod.outlook.com ([fe80::f506:5a18:a23:5125%7]) with mapi id 15.20.3955.018; Wed, 17 Mar 2021 16:16:19 +0000 From: "Aseem Choudhary (asechoud)" To: Juergen Schoenwaelder CC: =?utf-8?B?T3NjYXIgR29uesOhbGV6IGRlIERpb3M=?= , "netmod@ietf.org" Thread-Topic: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match Thread-Index: AdcbGExc8OTG49eVSoeJejnhX1jHZwAENNWA///CiICAAHf9AP//j5kA Date: Wed, 17 Mar 2021 16:16:19 +0000 Message-ID: <4BBA1D6B-F2CC-4099-A640-88F003327529@cisco.com> References: <20210317122907.x6v65uspqvls6p3p@anna.jacobs.jacobs-university.de> <327D2A1F-A646-42C9-BEE7-0A3EA73D537E@cisco.com> <20210317155834.nz6cv4mefwxrjgmq@anna.jacobs.jacobs-university.de> In-Reply-To: <20210317155834.nz6cv4mefwxrjgmq@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2600:1700:e320:64a0:ed29:c2cb:5c4:91b9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c722542-cdf1-4a1b-55d4-08d8e960000e x-ms-traffictypediagnostic: BYAPR11MB3781: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4u1UleVDQE5fjIrGygNITxWYwgl2lzy2i7BSK7qexNFAN/Lj8w4VbKaLyg9fDeZn35T9hKzY1rk+i5bs6BmLcIWcBcxWp//eaFiC+Zb/YvjJf7X9yVMoaQQKLkpssyIGefm2o5eOVuY+sVlKYZRg32T7m3ALgdRf+dyRP1fW3t/r8Ml6ZGkPafgQFJ14mB568ahbCU76gsQL8KeQ5sNQ0apqw4FJ51rPAkwgzjAFohbja4ym35f6Nif3EWr/jq+fAKrZPeSYVdkLL7HrSq5HlOzfI0vfKfj7kQbStUIUd9NDJw3RdY01Scal064JThoUqoZxGRhMLyGYftp6y1d5JwL2dTilK8PAys97VSL+v22hlBuMMq+XFahQrbDsWKOtn30VtCBecaPxt3ywSzzlSe4eaSDsjjPbp5fEHoGDWwTHUKDQRwPC3Vs6pmaMOZqQLJiFTvelSQM1zF7nQLXXnSBZanad3H5fnDKfaAQmLuDxDOgRTkFDiySYYHoHrJQJTWylnbKfd0h4ZE3KaUtw37n5o1b4I6ULlb6YQqB54ubflGnS6HXlvTOt6f1UEc1pQJyIGL96jUL9NHdCHJekk6O/4er7QL0H1RAYWe6LMMAiY5IvqWpHMlkW0XDR8J9SqjMR5WGQMumVh4MBARciSeOszRA/9FRvkfxFYbGaECEPYy46TA2SOetqoAJUt3Kd115NxVkS6VU67TWpe1d4Ow== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3174.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(346002)(366004)(39860400002)(53546011)(76116006)(64756008)(66574015)(6512007)(66446008)(66476007)(2616005)(66556008)(186003)(316002)(5660300002)(2906002)(6506007)(478600001)(4326008)(33656002)(36756003)(966005)(66946007)(71200400001)(54906003)(6916009)(83380400001)(86362001)(8676002)(6486002)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?M1F3aVh5RXAzL1E5VFNBNEljRlMrK1BsUTdrZjNUU25ORnZldGd3emZBYTBi?= =?utf-8?B?b3c4aWtyQTgyNVJLR3lzWUxES081cGt1cnNvbmlEaVVGb3g4bnVLb1JqZ3Rv?= =?utf-8?B?Q3pIOG11K0NDY0lmdU16eUNXZWx1MzZxQnJ4MXBmVmxvNk1tc3JpemJTR1Z4?= =?utf-8?B?b2ZMZEtPZDQyeTQ2eDVFUHJJU2d5VHpkdzN5Y1krbU9iMkhhZTl4SjBUVWFY?= =?utf-8?B?MUpVM04rUUQzTDcrVG0yTkd2MFF3WngydEsxN3d3ZXdvRnV1ZFF5K0lrbjVC?= =?utf-8?B?YVNBbjk0dXErMkI3RjNUaDhmUVV6a04wWUp5Tm10RDg3T1lySEtnUjhkajlQ?= =?utf-8?B?ZG83RjJKTjNEc2lBak1FbitmSVVHc0E1TGV1dG8xUmlUWDFhVGRyZnVUT1dE?= =?utf-8?B?UTVBd2pveXdrbDRDL3A2Vk5OL2x6SE1pOGdLSERqNXQzUzVHc0RnZ2lpYkFL?= =?utf-8?B?OWNIdHhvSFFQSUxRUEJ6SlFISUlhaldaT20yTUI5Umd4Y3EvNXdPSEpkSnZp?= =?utf-8?B?MU1oTmE0RWVadnk1UFJvWmNqRXplQ1dXL2hNVTBlcmpCQm9EekpHKzNYTnE1?= =?utf-8?B?MlFyMFA0NEp3VHVuc2FIaWVVVDNiME9MRDFaaXhreHEyVjV0cGRqRDFIOW9Y?= =?utf-8?B?T0NOQTlxYVJrTFJ0dEk1YkpURms1V3pCTnJxcFlVZ0ludWNIOGR4Yk1QUzVk?= =?utf-8?B?ZnYyajhxcHVOcm1kMmtJM3ZPT1pqc1dLMmtQRXFpdjhNdERrRWRvZk9CeDNk?= =?utf-8?B?QTlvWmVyNVBmbHkwTDN6REFnUVJRK2RweG9CN01nTjJUT1dxSXVWTGUyL1Nj?= =?utf-8?B?aVRDVjJHWU1oYTc3TWJjV2JKUnFPRVRINHJucUxlR0ViNndvTmpNUHR4Y2tR?= =?utf-8?B?Q3JtNmlyaEhIRlI1b3dFdnNUdERIOUYvMHhSSXFHWmw0aEVWMCtUejNYRStm?= =?utf-8?B?QlRnYlhmOXVseUlCZVZsNEdBSkZmVDdzSFN1Nk9jaGR4aUd3QVlLUG02VXhY?= =?utf-8?B?MkpkeGhaUlZ4RlZGZGMvSGtWK3ViVWUyTlN5VnVSb3dtdUhLdUwzczQyRTQz?= =?utf-8?B?am5kYVZKczUzQnBVSGpQSzZjM3pnZ0ExL0JkZTVTT09vYkxuWmxUeVhxSUlO?= =?utf-8?B?eGw2NGgxcjA4bzZ1U0VwblFFYzR3VUl6VFpEcVZwSTA0cjNzem92T2l0TDRS?= =?utf-8?B?emR3NHBHUUtPdll0WjBNeUdkUitjS01vd0c5bVo0VzNoWldJQXV5Z1MwbStN?= =?utf-8?B?cEhrVUxVV1V6TENyUkp5UTdBbXo2bE5vd3ZjUGVaNWNzZVBITWRoUkFlM1JT?= =?utf-8?B?TmZuQ0ptTHRac1pOMzRhUzREOHJZOFJpZ2pUWmh2aVo1RDF6V3pNM21ROVRr?= =?utf-8?B?SHJ6TmQ1ZktkZmNYZ3hHVlRBM1RiT0xPUnpBWHM1RTd0clp1TnZwKzVBU1hM?= =?utf-8?B?N05JQXZqeVdDWlVjQkxFRTA4T01oUDMzc2pOejN5dE5tWlh2U2tiTHBLNU1D?= =?utf-8?B?R1FYQno1dWZXT2UzQnJZSUdaN0dUQmliUzNlN1E5TEtGWTJ3QUxLZVVaTFZY?= =?utf-8?B?MDhraGlDUFVaNGZWZEpDb0p2Mlp1OUVJZTVNUkE2bzRKUzI1V3QxaXpqZmJL?= =?utf-8?B?aExIbmxvVGVjWUtxbUZVTjc3MHJ5Q2lEb1pkT2FnNlR5c2FRenZBWUE3QXh6?= =?utf-8?B?MXVBTEl3MmdmR1AzamFMTnJqS0dZdXdWRG04WFNJM25HZnVnK1E5dmN6TEpB?= =?utf-8?B?MWh2OUFpY2crVHU2aWl2emhKSkJsS2RlNjYxOEo1VVRXSTRhNFM4cEFmMWVJ?= =?utf-8?B?Q29vazNMQ0tvWWU5akFvOE1YTXlSbHB3b20xeGFTN0xRcUVlZ3BxdXhTeEwy?= =?utf-8?B?dm5LZEI4bGUrdUU0alN3YkJpcDlvTGNRODVEVmtsSmhKamc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3174.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c722542-cdf1-4a1b-55d4-08d8e960000e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 16:16:19.8237 (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: vm8KXdMZgo85iyS7YdCkYQWDjaMbhM96P41rX3DoREAdjuOBi82JDzbXOYmXYCLyrN12JQ1ndPl4yCusracK3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3781 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netmod] Request for improvement in ACL YANG Model: add prefix-list to the match X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 16:16:25 -0000 SSBhZ3JlZSwgYSB0ZW1wbGF0ZSBiYXNlZCBhcHByb2FjaCB3b3JrcyB3ZWxsIGFzIGl0IGhlbHBz IHRvIHNoYXJlIHRoZSBzZXQgb2YgZmllbGRzIGJldHdlZW4gQUNMcy4NCg0KLXRoYW5rcywNCkFz ZWVtDQoNCu+7v09uIDMvMTcvMjEsIDg6NTggQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQogICAgSSBub3cg dW5kZXJzdGFuZCB0aGF0IHRoZSBvcmlnaW5hbCByZXF1ZXN0IHdhcyBhYm91dCB0d28gdGhpbmdz Og0KDQogICAgLSBhbGxvd2luZyBzZXRzIG9mIHByZWZpeGVzIGluIGFuIEFDTCAoaW5zdGVhZCBv ZiBqdXN0IGEgc2luZ2xlKQ0KICAgIC0gc2hhcmluZyBvZiBzZXRzIG9mIHByZWZpeGVzIGJldHdl ZW4gQUNMcw0KDQogICAgQW5kIHllcywgaWYgdGhlIFdHIGdvZXMgdGhlcmUsIHRoZW4gb2YgY291 cnNlIHRoZSBzYW1lIHF1ZXN0aW9ucyB3aWxsDQogICAgY29tZSB1cCBmb3IgYWxsIHRoZSBvdGhl ciBwb3NzaWJsZSBoZWFkZXIgZmllbGRzLi4uDQoNCiAgICAtIGFsbG93aW5nIHNldHMgb2YgcG9y dHMvcG9ydCByYW5nZXMNCiAgICAtIHNoYXJpbmcgb2Ygc2V0cyBvZiBwb3J0cy9wb3J0IHJhbmdl cyBiZXR3ZWVuIEFDTHMNCg0KICAgIFsuLi5dDQoNCiAgICAvanMNCg0KICAgIE9uIFdlZCwgTWFy IDE3LCAyMDIxIGF0IDAzOjQ5OjExUE0gKzAwMDAsIEFzZWVtIENob3VkaGFyeSAoYXNlY2hvdWQp IHdyb3RlOg0KICAgID4gSGksDQogICAgPiANCiAgICA+IFNpbWlsYXJseSwgdGhlcmUgaXMgTnhN IGlzc3VlIHdoZW4gdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgc291cmNlIGFuZCBkZXN0aW5hdGlv biBwb3J0L3BvcnQgcmFuZ2VzLg0KICAgID4gDQogICAgPiAtdGhhbmtzLA0KICAgID4gQXNlZW0N CiAgICA+IA0KICAgID4gT24gMy8xNy8yMSwgNToyOSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg SnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQogICAgPiAN CiAgICA+ICAgICBIaSwNCiAgICA+IA0KICAgID4gICAgIGxldCBtZSBjaGVjayB3aGV0aGVyIEkg dW5kZXJzdGFuZCB5b3VyIHJlcXVlc3QgY29ycmVjdGx5OiBJIGhlYXJkIHlvdQ0KICAgID4gICAg IHNheWluZyB0aGF0IHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUNCiAgICA+IA0KICAgID4gICAgICAg ICAgICAgbGVhZi1saXN0IGRlc3RpbmF0aW9uLWlwdjYtbmV0d29yayB7DQogICAgPiAgICAgICAg ICAgICAgIHR5cGUgaW5ldDppcHY2LXByZWZpeDsNCiAgICA+ICAgICAgICAgICAgICAgZGVzY3Jp cHRpb24NCiAgICA+ICAgICAgICAgICAgICAgICAiRGVzdGluYXRpb24gSVB2NiBhZGRyZXNzIHBy ZWZpeC4iOw0KICAgID4gICAgICAgICAgICAgfQ0KICAgID4gDQogICAgPiAgICAgaW5zdGVhZCBv ZiBqdXN0DQogICAgPiANCiAgICA+ICAgICAgICAgICAgIGxlYWYgZGVzdGluYXRpb24taXB2Ni1u ZXR3b3JrIHsNCiAgICA+ICAgICAgICAgICAgICAgdHlwZSBpbmV0OmlwdjYtcHJlZml4Ow0KICAg ID4gICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgID4gICAgICAgICAgICAgICAgICJEZXN0 aW5hdGlvbiBJUHY2IGFkZHJlc3MgcHJlZml4LiI7DQogICAgPiAgICAgICAgICAgICB9DQogICAg PiANCiAgICA+ICAgICAoYW5kIHNpbWlsYXIgY2hhbmdlcyBmb3IgdGhlIG90aGVyIElQIHByZWZp eCByZWxhdGVkIGxlYWZzKS4NCiAgICA+IA0KICAgID4gICAgIFdoaWxlIHN1Y2ggYSBkaXJlY3Qg Y2hhbmdlIG1heSBiZSBkaWZmaWN1bHQsIGdpdmVuIHRoYXQgdGhlIGhlYWRlcg0KICAgID4gICAg IGZpZWxkcyBhcmUgZGVmaW5lZCBpbiBhIGNob2ljZSwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRv IGFkZA0KICAgID4gICAgIGFkZGl0aW9uYWwgY2hvaWNlcyBmb3Igc2V0cyBvZiBwcmVmaXhlcy4g U28gZnJvbSB0aGUgWUFORyBzaWRlLCB0aGlzDQogICAgPiAgICAgc2VlbXMgdG8gYmUgc29tZXRo aW5nIHBvc3NpYmxlIHRvIGFkZHJlc3Mgd2l0aG91dCB0b28gbXVjaCB0cm91YmxlLg0KICAgID4g DQogICAgPiAgICAgV2hldGhlciBpbXBsZW1lbnRvcnMgYXJlIGhhcHB5IHdpdGggc3VwcG9ydGlu ZyBzdWNoIGEgY2hhbmdlIGlzDQogICAgPiAgICAgc29tZXRoaW5nIG90aGVycyBoYXZlIHRvIGNv bW1lbnQgb24uDQogICAgPiANCiAgICA+ICAgICAvanMNCiAgICA+IA0KICAgID4gICAgIE9uIFdl ZCwgTWFyIDE3LCAyMDIxIGF0IDEwOjMxOjEwQU0gKzAwMDAsIE9zY2FyIEdvbnrDoWxleiBkZSBE aW9zIHdyb3RlOg0KICAgID4gICAgID4gRGVhciBuZXRtb2Qgd2cgY29sbGVhZ3VlcywNCiAgICA+ ICAgICA+IA0KICAgID4gICAgID4gICAgICAgICAgICAgICAgIFRoZSBpZXRmLWFjbCBZQU5HIG1v ZGVsIGRlZmluZWQgaW4gUkZDIDg1MTkgYWxsb3dzIHRvIGNyZWF0ZSBydWxlcywgYW5kIGZvciBl YWNoIGEgcnVsZSwgaW4gY2FzZSBvZiBJUHY0L0lQdjYgeW91IGNhbiBzcGVjaWZ5IGluIHRoZSBt YXRjaCB0aGUgc291cmNlLW5ldHdvcmsgYW5kIGRlc3RpbmF0aW9uLW5ldHdvcmsuIFRoZSBzb3Vy Y2UtbmV0d29yayAob3IgZXF1YWxseSB0aGUgZGVzdGluYXRpb24gbmV0d29yaykgaXMgaW4gdGhl IG1vZGVsIGFuIGFkZHJlc3MgcHJlZml4LiBJbiBvdXIgdXNlIGNhc2UgaW4gVGVsZWZvbmljYSB3 ZSBhcmUgc3BlY2lmeWluZyBhIHByZWZpeC1saXN0IGZvciBzb3VyY2UgbmV0d29yayBhbmQgYW5v dGhlciBwcmVmaXggbGlzdCBmb3IgZGVzdGluYXRpb24gbmV0d29yay4gSWYgeW91IGhhZCB0byBj cmVhdGUgdGhpcyBiZWhhdmlvciB1c2luZyB0aGUgQUNMIG1vZGVsLCB5b3Ugd291bGQgbmVlZCB0 byBjcmVhdGUgTnhNIHJ1bGVzLiBCZXNpZGVzLCB0aGUgbWFuYWdlbWVudCBvZiB0aG9zZSBydWxl cyB3b3VsZCBiZSBtb3JlIGNvbXBsZXguDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICAgICAg ICAgICAgICAgICBUaGUgcm91dGluZyBwb2xpY3kgbW9kZWwgaGFzIHRoZSBjb25jZXB0IG9mIHBy ZWZpeC1zZXRzLCBidXQgaXMgYSBzZXBhcmF0ZSBtb2RlbCAoYW5kIGEgZGlmZmVyZW50IHVzZSBj YXNlKS4NCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gICAgICAgICAgICAgICAgIFRoZSBmdW5j dGlvbmFsaXR5IG9mIHNwZWNpZnlpbmcgYSBwcmVmaXggbGlzdCBmb3Igc291cmNlIGFuZCBkZXN0 aW5hdGlvbiBpbiBhY2Nlc3MgY29udHJvbCBsaXN0cyBpcyBhdmFpbGFibGUgaW4gbW9zdCB2ZW5k b3JzIHRoYXQgSSBhbSBhd2FyZSB0b2RheS4gSGVuY2UsIGl0J3MgYSBwcmV0dHkgc3RhbmRhcmQg ZnVuY3Rpb25hbGl0eS4NCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gICAgICAgICAgICAgICAg IERvIHlvdSB0aGluayBpdCBpcyB1c2VmdWwgdG8gYWRkIHRoaXMgZnVuY3Rpb25hbGl0eSB0byB0 aGUgQUNMIFlBTkcgbW9kZWw/IElmIHllcywgd2hhdCB3b3VsZCBiZSB0aGUgcHJvY2VkdXJlLCBn aXZlbiB0aGF0IEFDTCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gYW4gZXhpc3RpbmcgUkZDPw0KICAg ID4gICAgID4gDQogICAgPiAgICAgPiAgICAgICAgICAgICAgICAgQmVzdCBSZWdhcmRzLA0KICAg ID4gICAgID4gDQogICAgPiAgICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3Nj YXINCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50 b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29u dGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEg dXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBl cyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1 ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1 dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xh Y2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUg cm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNt YSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCiAgICA+ICAgICA+IA0KICAgID4g ICAgID4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBw cml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSBy ZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCBy ZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUg aXQuDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IEVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhv cyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNv bnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEg dXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDD qSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2Fk byBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3Bp YSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVn aXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9n YW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21h IHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvDQogICAgPiANCiAgICA+ICAgICA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAg PiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiAgICAgPiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+ ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAg PiANCiAgICA+IA0KICAgID4gICAgIC0tIA0KICAgID4gICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQogICAgPiAgICAgUGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueQ0KICAgID4gICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0 dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCiAgICA+IA0KICAgID4gICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgbmV0 bW9kIG1haWxpbmcgbGlzdA0KICAgID4gICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgID4gICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgPiANCg0KICAg IC0tIA0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp dHkgQnJlbWVuIGdHbWJIDQogICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1w dXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgIEZheDogICArNDkgNDIxIDIw MCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0K From nobody Wed Mar 17 11:21:35 2021 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 8B96E3A1045 for ; Wed, 17 Mar 2021 11:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNNDXXDzAzXz for ; Wed, 17 Mar 2021 11:21:32 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB3D3A1043 for ; Wed, 17 Mar 2021 11:21:31 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id w37so363272lfu.13 for ; Wed, 17 Mar 2021 11:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m0MslIQE/qMMRwzC8E10zTzxkSWCOLEHjkH7T+gYuyg=; b=RAH1EspVIcNkw9pJmrr7VlYF4xKZYbC9KAmDzbspCxednkK6qUO1P6XZPlawocPLbC rQgXXJ/rNzB4VZuFTGd+bxTFwevYCxPPkTccD3oachvhNzePx21lbjc4b4C5i8hmiw9P rzBsOBOzwVFOeIA+6CEDWViXIOi8ztfnx5mLvZSieBSLXLvfAeSvUKEpYNdX2f0T1SMW jvih7OCHL2UN08BQWmzrd56HdMf3fL9v043W62GFtmsHrEU8FGua7i9kScFj3RSLX9cr VF1Nvx7Qofq4r2wmZEtuMNeY5yhziuJcfRDxAQ3QY48rBOmvcfoFA97uATjiGPIFzOWK Aeqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m0MslIQE/qMMRwzC8E10zTzxkSWCOLEHjkH7T+gYuyg=; b=ISxoR0STcaN8/FAGsWmCNcC5vEGH38udw7T6XyHiBPqCTPSG9at1p7VtTXbT8z0322 DiIZtd1vpHAq5WiBp+9SxF1BdwpVQWXTLbZROdhe2jEgAm2NqrRtYbCQGi+7e7SA0V4q EhDfEu6ZW/LNRUKWpE3U5BMLdwhe3tVPOcN7vIkAMDnkPylxQ+r9zLaQU8xwnuaRZ64V BbzGztrOQUm0jw2wYg9qB05RsrNIF/Qhlc1HI+kCHv8i8fSdY+nxBFxmMjlNEQkDFEG+ m1OZC1FcyQQM3NVMcQEMSRHG6qNDT8gLSBLFklmBQfYd5dpQSjUDF4ZRaDoq3tcBD3AV /rTQ== X-Gm-Message-State: AOAM532b1NEHHOCQSzWj/qzoA9kOMm+uBhcZLsXh0X23XNSuw2A/L2JO HM6JLuQHPWclTzBbWAFWEmZWVv60aiko82ck/U5Qjg== X-Google-Smtp-Source: ABdhPJxZYZmMNTdUUg+OeiUAJb4IJql4HlDQNcPQ9AV/SxXzHKin5eWumgjwKb7B6Jzp0wOqropnvnOncNDoMlhvlRg= X-Received: by 2002:a05:6512:a90:: with SMTP id m16mr2861548lfu.577.1616005289612; Wed, 17 Mar 2021 11:21:29 -0700 (PDT) MIME-Version: 1.0 References: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> In-Reply-To: <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> From: Andy Bierman Date: Wed, 17 Mar 2021 11:21:18 -0700 Message-ID: To: Vladimir Vassilev Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003e30c505bdbf8d97" Archived-At: Subject: Re: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 18:21:34 -0000 --0000000000003e30c505bdbf8d97 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev < vladimir@lightside-instruments.com> wrote: > > On 16/03/2021 13.36, Vladimir Vassilev wrote: > > Hei, > > > > Many drafts and RFCs are flagged with warnings by the tracker > > validation tools: > > > > ... > > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p > > {draftlib} -p {ianalib} -p {cataloglib} {model} -i: > > warn: Module's revisions are not unique (2018-06-28). > > > > ... > > > > Does anyone know what causes this warning? > > Seems the warning is issued when iana-if-type@2020-01-10.yang is > processed. It contains 2 revision (history) statements with identical > dates 2018-06-28. > > IMO Multiple revision statements with the same date are valid so the > tool reporting the warning has to be fixed. > > I disagree. Our compiler has a similar warning. The YANG Library treats entries with the exact same module name and revision-date as the same module. The protocols that currently advertise YANG module capabilities all use module name and revision-date to identify a unique module revision. A compiler warning simply means "Are you sure you meant to do this?" This is usually a cut-and-paste error. > > Vladimir > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000003e30c505bdbf8d97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 17, 2021 at 8:36 AM Vladi= mir Vassilev <vlad= imir@lightside-instruments.com> wrote:

On 16/03/2021 13.36, Vladimir Vassilev wrote:
> Hei,
>
> Many drafts and RFCs are flagged with warnings by the tracker
> validation tools:
>
> ...
> yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
> {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
> warn: Module's revisions are not unique (2018-06-28).
>
> ...
>
> Does anyone know what causes this warning?

Seems the warning is issued when iana-if-type@2020-01-10.yang is
processed. It contains 2 revision (history) statements with identical
dates 2018-06-28.

IMO Multiple revision statements with the same date are valid so the
tool reporting the warning has to be fixed.



I disagree.=C2=A0 Our c= ompiler has a similar warning.

The YANG Library tr= eats entries with the exact same module name and revision-date as
the same module.=C2=A0 The protocols that currently advertise YANG module = capabilities
all use module name and revision-date to identify a = unique module revision.

A compiler warning simply = means "Are you sure you meant to do this?"
This is usua= lly a cut-and-paste error.

=C2=A0

Vladimir


Andy
=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000003e30c505bdbf8d97-- From nobody Wed Mar 17 11:36:50 2021 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 4016D3A1123 for ; Wed, 17 Mar 2021 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luvINbAfXwNf for ; Wed, 17 Mar 2021 11:36:46 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0723A1122 for ; Wed, 17 Mar 2021 11:36:46 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id b9so25680ejc.11 for ; Wed, 17 Mar 2021 11:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w4kwFkbR1b9IZWE5nh31a6W6JJlCml5XPNS4lDGFaxU=; b=un9brJpNAMFTfStbWHQZwV6P3OrmgV0RDt+ujzZh0O4Xwxgl33Vp+HTHwop6P2lTOd jB53qLIrb0TlxqTDiF8F2YohJiVPax6s3x+1HiupyaPM4Itfw3xjLpYXVQFtxNiJhpAW 2BLP/7UCrqXRAnCMAzHWPNkTNahQodc3ohezXLotR37mlPU96A7eOFOAAXHmf1N0No9p /tjwCgKusdcLo4lsTWjb4zPa/b48E15Zq6J8CcJq0/I9KmZzER6yM8P9o2noB4oNrOnZ PBqCABkwmwNE6OapBllefoiEHeqbP+2X7JF3qUmtzaNSsQab8NvSZGt7Uc8ZKG0v1Uqr cmgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w4kwFkbR1b9IZWE5nh31a6W6JJlCml5XPNS4lDGFaxU=; b=pSQOljgjg/ixsw/7sMlZK/2OZhvfu0pv3Fg49b47bQoo7uDHY/d/cjO2i2HjbqB2WU dqVi6fZILFfkGg6rhIkwGcyCvmW60ZBGSXjmylkVJdwR13Q37TurZe0Y6DbN4o2djlH/ /vip0+YAOujShU+/7/u46iAT366QVpJHiOpmRwBSUwHZyZAi/njbtXW+BWm9iITMdQG9 xa6IRGz4dxNdeMgEFtnCVmejx49sIeXaAx5bmVJHY6M/5CubSVZdFD69eimEUQy07agS S3jMyNHPW/n58wY7P06k+aBwAnYyc9rDFsqztQK95BQaar2Yo/H/amwJMNTYHAG4t9lt Jtnw== X-Gm-Message-State: AOAM533AVASs/xASURr1GUDF+yvXZuSEZaNNExcpkHItqA87kTmvwY8g jn4NyBDHngFKl8Qi9A8bs+O8qdOzyEmAYZkEU+SEm7FBgHY= X-Google-Smtp-Source: ABdhPJxk9V0Usis3Lv8W3l5wc0n0YxBBiomUtxbOSU1FYZMxvqLYfKOyLYBu9JkLGEnxB2/imsNhsGLdsRmhC5grMbk= X-Received: by 2002:a17:906:8043:: with SMTP id x3mr36239364ejw.149.1616006204679; Wed, 17 Mar 2021 11:36:44 -0700 (PDT) MIME-Version: 1.0 References: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> In-Reply-To: From: William Lupton Date: Wed, 17 Mar 2021 18:36:33 +0000 Message-ID: To: Andy Bierman Cc: Vladimir Vassilev , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9011605bdbfc361" Archived-At: Subject: Re: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 18:36:48 -0000 --000000000000c9011605bdbfc361 Content-Type: text/plain; charset="UTF-8" Also note that the YANG catalog keys modules by (name, revision, organization). On Wed, 17 Mar 2021 at 18:21, Andy Bierman wrote: > > > On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev < > vladimir@lightside-instruments.com> wrote: > >> >> On 16/03/2021 13.36, Vladimir Vassilev wrote: >> > Hei, >> > >> > Many drafts and RFCs are flagged with warnings by the tracker >> > validation tools: >> > >> > ... >> > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p >> > {draftlib} -p {ianalib} -p {cataloglib} {model} -i: >> > warn: Module's revisions are not unique (2018-06-28). >> > >> > ... >> > >> > Does anyone know what causes this warning? >> >> Seems the warning is issued when iana-if-type@2020-01-10.yang is >> processed. It contains 2 revision (history) statements with identical >> dates 2018-06-28. >> >> IMO Multiple revision statements with the same date are valid so the >> tool reporting the warning has to be fixed. >> >> > > I disagree. Our compiler has a similar warning. > > The YANG Library treats entries with the exact same module name and > revision-date as > the same module. The protocols that currently advertise YANG module > capabilities > all use module name and revision-date to identify a unique module revision. > > A compiler warning simply means "Are you sure you meant to do this?" > This is usually a cut-and-paste error. > > > >> >> Vladimir >> >> > Andy > > >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --000000000000c9011605bdbfc361 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also note that the YANG catalog keys modules by (name, rev= ision, organization).

On Wed, 17 Mar 2021 at 18:21, Andy Bierman <andy@yumaworks.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev <vladimir@l= ightside-instruments.com> wrote:

On 16/03/2021 13.36, Vladimir Vassilev wrote:
> Hei,
>
> Many drafts and RFCs are flagged with warnings by the tracker
> validation tools:
>
> ...
> yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
> {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
> warn: Module's revisions are not unique (2018-06-28).
>
> ...
>
> Does anyone know what causes this warning?

Seems the warning is issued when iana-if-type@2020-01-10.yang is
processed. It contains 2 revision (history) statements with identical
dates 2018-06-28.

IMO Multiple revision statements with the same date are valid so the
tool reporting the warning has to be fixed.



I disagree.=C2=A0 Our c= ompiler has a similar warning.

The YANG Library tr= eats entries with the exact same module name and revision-date as
the same module.=C2=A0 The protocols that currently advertise YANG module = capabilities
all use module name and revision-date to identify a = unique module revision.

A compiler warning simply = means "Are you sure you meant to do this?"
This is usua= lly a cut-and-paste error.

=C2=A0

Vladimir


Andy
=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--000000000000c9011605bdbfc361-- From nobody Wed Mar 17 11:48:00 2021 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 BD4BE3A1165 for ; Wed, 17 Mar 2021 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpZ7J3BoQGhD for ; Wed, 17 Mar 2021 11:47:57 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4783A1164 for ; Wed, 17 Mar 2021 11:47:56 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id x28so489067lfu.6 for ; Wed, 17 Mar 2021 11:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R8RyjXXsv+GckTpZed92bsAN8ArH+uromY5On8r31Ak=; b=aRdCL1l0O8rMP8aHSo2Z//VlS+xImUYbz5DzwVXOOcmszC5jArxNax90aYkw8k5rzd kG6wh2PfBGPjx5C8HTD5g6QcAreBEFR8hQExo1l3MMy5FurpYpT98q2rwpVHdoRLwaON BsqEAUAYC2f/8AXiLnJBu2ZGiv9E0bo46J242y1C+GRBys8a/rTlfbf6/OoVbT/1CmK3 nsgxrdDPFwUXpN/OHlkfhgaMZe56jOa0LNHF0t8S2/9/AHqr9BOVG56W2Fpr1ZiL+4Zy 3Nct4d0nvPJgwBnycJuTXZ1b4ZVYJkXDPPzpYWyvrQUqn9ItnT1mHCu/iLvSWU24iugf XSiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R8RyjXXsv+GckTpZed92bsAN8ArH+uromY5On8r31Ak=; b=XT/Fz1YsKpIR8P297nZtZIJbTzgyXkN4SbfUmHOAZndqd8VvRRRoZ0uPs/nzMKtOXP J2G7IFJLVa78IOjClWCtZ7cpadWQpq9FDWOK2Y01gTI74kSkCPmpFJ0/WuEQBcbaE3kC kME9cAiRUPoakJVZ9NFjcsRz4QPzoiFPP+gMUwZoOzlQ+VZY7CCsubbhO/1Ozyiq4TYC uvHg3W5rHeKxFgQCRzt+j6BXf0J1DZFvOv8yrJ40e/Cqw0U2/NYjiTvZ4GCtk+t4s4HV iEDMmrrCt7l1tYvnkhEGPp9JiSsp5n6ZjPBg3RLlRC5O2XqmWrhR8rYwflwJSfjbtPeb spIg== X-Gm-Message-State: AOAM531FKN3bscM9rNMC9fYpcQA+rwYU2R/4IN+T6GaSyqYKzAz9K9r/ +DkAUj/37UuTx/pc4izKDZCDARXNk+ElHWquzHRiQIJzSwGQww== X-Google-Smtp-Source: ABdhPJx0RTyQ+TTQUdU8ZwhonHpJle5N6C+oZJoFekxSloyySFLZcN6NP2K20nE0amuURK0/tLfefuyPe5f16lygkik= X-Received: by 2002:ac2:434d:: with SMTP id o13mr2977002lfl.478.1616006874860; Wed, 17 Mar 2021 11:47:54 -0700 (PDT) MIME-Version: 1.0 References: <0713027c-3716-11f3-9a6f-69b7dff60916@lightside-instruments.com> <13cdc883-3d57-ad5a-1fa6-7c2802d4aae4@lightside-instruments.com> In-Reply-To: From: Andy Bierman Date: Wed, 17 Mar 2021 11:47:44 -0700 Message-ID: To: William Lupton Cc: Vladimir Vassilev , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bb224305bdbfebe4" Archived-At: Subject: Re: [netmod] warn: Module's revisions are not unique (2018-06-28). X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 18:47:59 -0000 --000000000000bb224305bdbfebe4 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 17, 2021 at 11:36 AM William Lupton wrote: > Also note that the YANG catalog keys modules by (name, revision, > organization). > This 3rd key implies that some organizations have their own versions of YANG modules from SDOs. We have a bit of that only to fix known Errara in some IETF modules. YANG has deviations so vendors can change the modules from other organizations without hacking the original modules. Andy > On Wed, 17 Mar 2021 at 18:21, Andy Bierman wrote: > >> >> >> On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev < >> vladimir@lightside-instruments.com> wrote: >> >>> >>> On 16/03/2021 13.36, Vladimir Vassilev wrote: >>> > Hei, >>> > >>> > Many drafts and RFCs are flagged with warnings by the tracker >>> > validation tools: >>> > >>> > ... >>> > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p >>> > {draftlib} -p {ianalib} -p {cataloglib} {model} -i: >>> > warn: Module's revisions are not unique (2018-06-28). >>> > >>> > ... >>> > >>> > Does anyone know what causes this warning? >>> >>> Seems the warning is issued when iana-if-type@2020-01-10.yang is >>> processed. It contains 2 revision (history) statements with identical >>> dates 2018-06-28. >>> >>> IMO Multiple revision statements with the same date are valid so the >>> tool reporting the warning has to be fixed. >>> >>> >> >> I disagree. Our compiler has a similar warning. >> >> The YANG Library treats entries with the exact same module name and >> revision-date as >> the same module. The protocols that currently advertise YANG module >> capabilities >> all use module name and revision-date to identify a unique module >> revision. >> >> A compiler warning simply means "Are you sure you meant to do this?" >> This is usually a cut-and-paste error. >> >> >> >>> >>> Vladimir >>> >>> >> Andy >> >> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > --000000000000bb224305bdbfebe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 17, 2021 at 11:36 AM Will= iam Lupton <wlupton@broad= band-forum.org> wrote:
Also note that the YANG catalog keys modules= by (name, revision, organization).

T= his 3rd key implies that some organizations have their own versions of YANG= modules from SDOs.
We have a bit of that only to fix known Errar= a in some IETF modules.
YANG has deviations so vendors can change= the modules from other organizations
without hacking the origina= l modules.


Andy



On Wed, 17 Mar = 2021 at 18:21, Andy Bierman <andy@yumaworks.com> wrote:


On W= ed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev <vladimir@lightside-instrumen= ts.com> wrote:

On 16/03/2021 13.36, Vladimir Vassilev wrote:
> Hei,
>
> Many drafts and RFCs are flagged with warnings by the tracker
> validation tools:
>
> ...
> yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
> {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
> warn: Module's revisions are not unique (2018-06-28).
>
> ...
>
> Does anyone know what causes this warning?

Seems the warning is issued when iana-if-type@2020-01-10.yang is
processed. It contains 2 revision (history) statements with identical
dates 2018-06-28.

IMO Multiple revision statements with the same date are valid so the
tool reporting the warning has to be fixed.



I disagree.=C2=A0 Our c= ompiler has a similar warning.

The YANG Library tr= eats entries with the exact same module name and revision-date as
the same module.=C2=A0 The protocols that currently advertise YANG module = capabilities
all use module name and revision-date to identify a = unique module revision.

A compiler warning simply = means "Are you sure you meant to do this?"
This is usua= lly a cut-and-paste error.

=C2=A0

Vladimir


Andy
=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod